Improvements for remote MCP

[jspahrsummers]

Starting a tracking discussion for various improvements we want to work on related to remote MCP specifically, where a local or remote MCP client connects to an MCP server over the internet.

• Authentication #64
  • [proposal] Add auth as a capability with support for OAuth 2.0 and secrets. #101
• Statelessness #102
• .well-known/mcp directory
• Service discovery for MCPs #69

Scope

• Protocol Specification
• SDK Features
• Documentation
• Developer Experience
• Other

[boukeversteegh]

First, I want to thank you for developing MCP - I'm very excited about its potential and would like to share my experience to help inform its evolution. I wasn't entirely sure where best to share this feedback given the various discussions, but since these are early days and there isn't too much user input yet, I thought I'd contribute my perspective here.

Since MCP's release, I've developed several servers for local use. The local-first approach has been fantastic for rapid prototyping - being able to quickly hack together code and immediately use it with an advanced LLM (within Claude Desktop and Cline at the moment) is incredibly powerful. While similar capabilities existed before (e.g., custom GPTs in ChatGPT), the barrier to entry was much higher since they required publicly accessible, fully secured APIs, or a full local chat implementation with persistence etc.

As my tools have become more useful, I've encountered an interesting scaling pattern:

• Initially: Pure local development, which MCP handles beautifully
• Multi-device: Currently solving by syncing code via git between my work laptop and home desktop
• Team usage: This is where I see the next challenge - while I haven't implemented team sharing yet, I'm planning to experiment with this soon and can already see the git sync approach becoming unwieldy

For team scenarios, I envision wanting to let developers install a local MCP server that connects to a central server hosting shared tools (Jira access, Confluence integration, server monitoring, etc.). Importantly, this would still be internal (intranet) rather than public-facing.
This perspective seems relevant to several of the discussions:

• Authentication (Authentication #64): Need something between local trust and full OAuth for internal deployments
• Statelessness (Statelessness #102): Local-to-central connection model might influence this architectural decision
• Service discovery (Service discovery for MCPs #69): Could help with managing tool availability across a team

I imagine something like a secure bridge / federated / proxy pattern could help extend the local client-server architecture into a networked one while maintaining MCP's low obstacle developer experience. Happy to elaborate on any of these points if helpful!

[Madd0g]

My suggestion is about SSE servers (local too), while STDIO servers can accept parameters in multiple ways (args and env), I found no way of passing parameters to the SSE MCP server (not a specific tool). I tried passing query parameters like /sse?myDifferentId=123

I saw a linked thread about statelessness, but I actually want my MCP server to be more stateful - there's currently an internal session id that's per connected client or something like that?

But what if I want to pass parameters from my app that change how the server behaves? for example I want my server to have 2 states - a read-only state and a read-write state (listing different tools for each scenario).

Thanks