jspahrsummers

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!

Comment · 1 year ago

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.

Comment · 1 year ago

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!

Comment · 1 year ago

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.

Comment · 1 year ago

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!

Comment · 1 year ago

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.

Comment · 1 year ago

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/

Comment · 1 year ago

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

Comment · 1 year ago

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!

Comment · 13 years ago

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