Expand spec for capabilities #604
Replies: 1 comment 2 replies
-
|
@kentcdodds are you saying that in theory a client could act just like a server, and vice versa, within the same application? (like, e.g. the client may have tools that the server can call, or that a server might itself have roots, etc.) In other words are you proposing to expand the capabilities that a client and/or a server can offer, or rather that the Capabilities objects should be expanded so that ClientCapabilities and ServerCapabilities carry the same information? I hope this isn't too tangential, and am happy to raise separately, but personally I find it a little confusing that "support for X" (disregarding sub-capabilities related to X) is indicated by the presence or absence of the key |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Pre-submission Checklist
Your Idea
As the spec evolves (and even now) clients have a wide range of support for the MCP spec features and severs should be able to adjust their responses based on these capabilities. For example, currently Cursor does not support embedded resources, so it would be better to simply use content of type text as a fallback.
Right now Capability Negotiation only specifies the client supporting
roots,sampling, andexperimental. I think it should include all the server features.In fact, I think it would be useful if the server also include in its capabilities all the client features as well. It could be useful for a client to know whether a server is going to make a sampling call or expect roots for example.
Scope
Beta Was this translation helpful? Give feedback.
All reactions