jspahrsummers

You can find more information on some design questions like these in https://spec.modelcontextprotocol.io/specification, which is a much more "implementors" focused guide than the user documentation at https://modelcontextprotocol.io

We're still in the process of thinking through and fleshing out full details for remote MCP connections. This is definitely a good idea to include in the mix!

Definitely not geolocked! Please try the debugging guide here: https://modelcontextprotocol.io/docs/tools/debugging

There's a debugging guide here that may be helpful: https://modelcontextprotocol.io/docs/tools/debugging

Your concerns are very valid. This is partly why right now, in Claude Desktop, it's not possible to grant permission permanently. The most you can do is "Allow for this chat," which applies to one tool from one server at a time.

We definitely hope this will solve the NxM problem.

On tools specifically, we went back and forth about whether the other primitives of MCP ultimately just reduce to tool use, but ultimately concluded that separate concepts of "prompts" and "resources" are extremely useful to express different _intentions_ for server functionality. They all have a part to play!

Our thinking is that prompts will generally be a user initiated feature of some kind. These docs go into a bit more detail:

https://modelcontextprotocol.io/docs/concepts/prompts

https://spec.modelcontextprotocol.io/specification/server/pr...

… but TLDR, if you think of them a bit like slash commands, I think that's a pretty good intuition for what they are and how you might use them.

This is a great idea! There's also the matter of requests' result types not being automatically inferred in the SDK right now, which would be great to fix.

Could I convince you to submit a PR? We'd love to include community contributions!

We do want to improve this over time, just trying to find the right balance between usability and security. Although MCP is powerful and we hope it'll really unlock a lot of potential, there are still risks like prompt injection and misconfigured/malicious servers that could cause a lot of damage if left unchecked.

We're definitely interested in extending MCP to cover remote connections as well. Both SDKs already support an SSE transport with that in mind: https://modelcontextprotocol.io/docs/concepts/transports#ser...

However, it's not quite a complete story yet. Remote connections introduce a lot more questions and complexity—related to deployment, auth, security, etc. We'll be working through these in the coming weeks, and would love any and all input!

You can read how we're implementing versioning here: https://spec.modelcontextprotocol.io/specification/basic/ver...

It's not exactly immutable, but any backwards incompatible changes would require a version bump.

We don't have a roadmap in one particular place, but we'll be populating GitHub Issues, etc. with all the stuff we want to get to! We want to develop this in the open, with the community.

Sorry, I think that's just the nav on those docs being confusing (particularly on mobile). You can see the spec here: https://spec.modelcontextprotocol.io/specification/

Already available in the latest at https://claude.ai/download!

Probably, yes! You could imagine building an MCP server (integration) for a particular piece of legacy software, and inside that server, you could employ Computer Use to actually use and automate it.

The benefit would be that to the application connecting to your MCP server, it just looks like any other integration, and you can encapsulate a lot of the complexity of Computer Use under the hood.

If you explore this, we'd love to see what you come up with!

We do need some examples, but the headers are documented quite extensively, FWIW.