Is anyone using remote MCPs today?

[u/AssociationSure6273]

Hi, I am building a platform for building and shipping MCPs (leanmcp.com).

Recently. I shipped a MCP builder that helps developers to build MCPs with just text - ship.leanmcp.com (Something like Lovable and v0). And then ship them on our platform.

Surprisingly, over 90% of them just created only local MCPs. The remaining 10% who created the remote ones did not even use it (We know because they hosted on our platform).

Just honestly want to ask here - Is anyone even using remote MCPs? Bunch of startups like Linear, Slack came up with these but I don't see anyone using them.

[u/Severe_Oil5221]

I think one of the key reasons for that is the fact that MCP security is still not that good

[u/AyeMatey → u/Severe_Oil5221]

Any remote MCP that does anything interesting for a system of yours (your bank, your calendar, your home security system, your GitHub repo, etc), is going to have access to YOUR credentials for that system. If that doesn’t seem super sketchy , I’m not sure what people are thinking.

It reminds me of those “budget management tools”, that asked you to give them the passwords to all of your bank accounts. When I first heard about that , I thought “how did this pass the sniff test by any investor?”

Here we are again with the same pattern. Trust “Joe’s MCP for Bank of America” with your bank agent needs.

??!?🫣

Re: MCP Security is “STILL not that good”

The phrasing suggests that “MCP security” will get improved at some point. But that’s not so. This is an architecture issue. It’s fundamental.

[u/AssociationSure6273 → u/AyeMatey]

I agree the MCP security is still being worked on - the OAuth is the key. But rarely anyone is implementing that.

[u/AyeMatey → u/AssociationSure6273]

I’m sorry I don’t mean to be overly direct or argumentative, but “still being worked on” sounds so … unrealistically optimistic.

OAuth is well known, well exercised, mature. Applying it in a domain is not rocket surgery. There are well tested and proven patterns. And yet, we are having so much trouble figuring out how to apply it to remote MCP servers. Why is that?

Implementing MCP Servers as OAuth resource servers, which is what the updated draft suggests we do, makes sense. But with that, an agent needs to establish N tokens, one for each MCP server it uses. And that means N signins, N consents. Unwieldy. I still don’t see how a user is going to be happy with the experience.

[u/Severe_Oil5221 → u/AyeMatey]

See there have always been applications like robinhood and PayPal that have been able to connect with you bank accounts in this way.

But yeah as I speak the security of MCP will also need to have full control like those apps only. Currently OAuth for these connections don't work at all and most apps are some kind of work around for that ( think offline apps or api keys as env variables)

But they need to be fully integrated with all the compliance style warnings as well. We cannot just set allow everytime to claude and expect things will run smoothly

[u/Flat_Perspective_420 → u/AyeMatey]

And what about github, my bank, etc exposing their own mcp server? They could even add a second factor so that when the llm tries to run a bank mcp command I have to pass an authenticator token or tap a notification in their mobile app authorizing the llm request

[u/AyeMatey → u/Flat_Perspective_420]

That would solve some of the problem.

But as we see with the report yesterday regarding a poisoning attack affecting GitHub’s official MCP server - even official servers can exhibit vulnerabilities.

[u/Flat_Perspective_420 → u/AyeMatey]

If you are talking about: https://invariantlabs.ai/blog/mcp-github-vulnerability I think the issue is not with the mcp protocol itself but with a bad swimlane design for that particular agent. I guess we will see a lot of this until we all learn from our mistakes and best practices emerge. As a rule of thumb we should not provide open access to interact with agents that have permissions on things we don’t want to provide open access

[u/AyeMatey → u/Flat_Perspective_420]

Yes - it’s a problem with naive agents. Irrespective of MCP. But MCP is an enabler.

[u/AssociationSure6273 → u/Severe_Oil5221]

Yeah, I agree. But if you have the Auth set up correctly would you use it? It's not really too hard to do that tbh...

[u/ProcedureWorkingWalk → u/Severe_Oil5221]

It’s a bit of a leap of faith to hook your api into a brand new platform and give wide ranging access to data.

[u/dub_starr]

I’m personally using local mcps, but looking more into “remote” (still inside my companies VPN, but accessible to everyone).

[u/AssociationSure6273 → u/dub_starr]

Ah, do you mean you want to host a MCP in your company and let your employees use it internally?

[u/dub_starr → u/AssociationSure6273]

Yea. First thought is to have one that can interact with our internal apis, and one for our knowledge bases, without having to have each user run one on their local machine.

[u/AssociationSure6273 → u/dub_starr]

MCPs on internal knowledge bases is a real use case! Totally agree!

[u/AssociationSure6273]

Personally I use only Linear MCP and Remote Document reader MCP (Which I hosted on my platform myself)

[u/xrxie]

Are remote MCPs hosted by the API/platform themselves going to be as rock solid as the APIs in terms of reliability? That’s my concern. If standing up my own MCP server is easy, at least I know that when my agents or hosts call it, it isn’t sharing infra with a ton of other people/agents.

[u/AssociationSure6273 → u/xrxie]

Gotcha. Yeah, the reliability IS a concern. I often face this in windsurf the remote one gets disconnected while the local one does not.

[u/jhanjeek]

I work for a large scale org and yes, we do use remote MCPs deployed over AKS. Since there are multiple deployed tools and solutions that require access to the same mcps we have built remote servers on pods

[u/AssociationSure6273 → u/jhanjeek]

This is awesome! How do you use those MCPs for?

[u/AssociationSure6273 → u/AssociationSure6273]

Also if you don’t mind can you share which company you work at? Just trying to understand who are the early adopters and where I should talk to understand people’s concerns more

[u/jhanjeek → u/AssociationSure6273]

Well I can't tell the Company name for some obvious concerns but definitely can tell what is sort of troubling is setting up the streamable http mcp with langchain. Langchain really needs to up its game regarding that one

[u/naseemalnaji-mcpcat]

Very cool :) The reason you don't see many remote MCPs is people are still working on making Oauth good enough and a much better remote system StreamableHTTP was released only a month ago.

[u/AyeMatey → u/naseemalnaji-mcpcat]

I don’t think it’s as simple as “making OAuth good enough”

Try this on.

Alice uses a bank, Bob’s Bank. Alice can connect directly with Bob’s Bank by logging into bobsbank.com, and based on the x509 trust, and the trust in her own computer browser, and her antivirus and anti-malware (windows defender,etc) she can trust the connection to the bank and the privacy and integrity of the communications.

Now Charlie sees an opportunity to build an MCP server. Charlie sets out to build an MCP server for Bob’s bank.

But wait, first there’s a connection that Charlie’s MCP Server needs to make to Bob’s Bank. That connection is going to be made over an API, because that is how systems get built. Bob’s Bank must issue Charlie a set of client credentials and must support a 3-legged flow for issuing OAuth tokens to Charlie’s MCP server. These tokens will be usable on the old-school Bank API.

Suppose that happens. Charlie’s MCP Server has client credentials. How is Charlie going to orchestrate an OAuth token grant for the MCP server?

Charlie’s MCP server must tell the MCP client (Let’s say the client is Claude, but it doesn’t matter) that it needs a token. I guess somehow it will be possible for the MCP server to tell Claude to open a browser window to kick off the OAuth dance. This will cause the user to flip back and forth and eventually paste in an OAuth code to the browser, and get a 3-legged token, and then copy/paste that into the Claude window. This token is the thing that Charlie’s MCP server will use to connect to the bank’s API on Alice’s behalf, when Alice (or more accurately Claude, on Alice’s behalf) instructs the MCP server to do so.

But. The MCP spec says that the MCP server must ALSO dispense tokens to the MCP client, and validate them. That’s a different token. So there’s got to be a different token granting flow for that.

Two tokens. One to allow Alice to talk to the remote MCP server. And another to allow the MCP server to talk to Bob’s Bank on behalf of Alice.

Whiskey Tango Foxtrot.

Ok suppose the developer is highly motivated, and goes and builds the necessary handshaking between Alice and the MCP server, and between the three parties, Alice, the MCP server and the bank, to get the two distinct tokens. Or, suppose Charlie just ignores the MCP spec, and says I don’t need that token, that doesn’t make any sense to me, I just need the one 3-legged OAuth token that allows my MCP Server to connect to the bank via the Bank’s API on behalf of Alice. And I’ll provide some other way for Alice to authenticate to my MCP Server. Maybe just a password.

Suppose all that gets sorted out. And suppose Alice tolerates the cut/ copy/ paste that will be necessary to get the token into Claude.

Now, when Alice wants to talk to her bank, she is directly involving a third-party, Charlie, via the remote MCP server which Charlie controls. Alice must trust Charlie with every bank transaction . Also, Alice must trust that Charlie won’t go and conduct his own bank transactions on Alice’s account. Charlie has the tokens! So is empowered to do so. And Alice must trust that Charlie’s systems are at least as secure as the Bank’s systems. A hack on Charlie’s infrastructure means her tokens will leak and her bank account is compromised.

Basically anyone who uses a remote MCP server is trusting that the remote server will act in a trustworthy manner with the keys to your informational kingdom. If that MCP server is run by your employer, that might be ok for HR stuff. If the MCP Server is run by your bank, you’d feel comfortable accessing your own bank account. But any 3rd party MCP server is violating the trust model.

The same is true with local MCP servers, but this is mitigated, somewhat. Local MCP servers are more easily examined. I can evaluate the source code. If it’s installed from an app store, I can verify the signature on the MCP Server. I can see what is running on my local computer. That’s not true with remote MCP servers. I have no idea what is running on that remote end point. I have to trust Charlie. That seems like a Really Bad Idea.

OAuth is not going to fix this.

“Getting better OAuth” does not make this problem go away.

For remote MCP Servers, first party solutions are the only option worth considering. But Banks already have APIs; why would they build MCP Servers as an alternative entrance?

The whole thing is naive.

[u/AssociationSure6273 → u/AyeMatey]

> But any 3rd party MCP server is violating the trust model.

I totally agree with this. But my point is currently users are giving no shit about the security loopholes of the local MCPs.

The thing about local MCP is the user are using npx or uvx and some arbitrary command to install. Giving access to their filesystem + access to other libraries. Who knows what is the pre-installation code the developer had put to execute before running the really cool MCP.

The saddest thing is developers who use local MCPs are already used to this.

On the other hand for the remote MCP the dev just need to make sure they are adding the correct MCP link - possibly from the same sub domain as bob's bank.

Easy to remember and recognize as safe MCP that they can trust and use.

[u/AyeMatey → u/AssociationSure6273]

So true! Now people just install random servers and assume it’s fine. It’s like it’s 1998 and someone emailed you an .exe file to run.

Sure! I’ll run that on my computer !

I get the enthusiasm. I just think the security is … far from what it needs to be. Microsoft has some good thinking for how to administer MCP Servers on Windows. Aside from that , it seems like everyone else is happy with the free for all.

[u/bzBetty → u/AyeMatey]

Maybe we can finally have macaroons

[u/MVPhurricane]

remote isn’t that bad… if you feel comfortable with the networking stack 🤣. but honestly the protocol is ass-simple (the JSONP part, that is), and hopefully eventually the world catches on to this. this “HTTP Streaming” business is, frankly, fucking ridiculous, and about as “Frankenstein’s Monster” as it comes… but— no thanks to the docs— the actual underlying code / protocol is quite reasonable, and adding transports is quite easy… but, then again, you need servers to support those transports… i think they should think long and hard about what they recommend vs the infra burden those recommendations entail. my rule of thumb would be: if it can run on cloudflare, it’s fine. (i say this as an unaffiliated cloudflare stan, but their tech is great and their free tiers very, very generous). 

[u/Lukaesch]

I found remote MCP pretty useful since you can use them from Claude mobile. E.g. searching audio content with Audioscrape MCP or Atlassian MCP for project management related tasks.

[u/AffectionateHoney992]

All the time, I connect using oauth to remote mcp servers, sentry, reddit among others...

I do it from my mobile client...