Improvements to Server Capabilities and additional Tool Annotations

[pantanurag555]

Pre-submission Checklist

• I have verified this would not be more appropriate as a feature request in a specific repository
• I have searched existing discussions to avoid duplicates

Your Idea

Server Capabilities

As part of server session initialization, the server currently responds with the following details:

1. Protocol Version
2. Server Info: Server name and version
3. Instructions: Description about the server and how it can be used
4. Server Capabilities
   4.1 Tools: Expresses support for tools (along with server level tool settings) based on whether ListTools handler is set up
   4.2 Resources: Expresses support for resources (along with server level resource settings) based on whether ListResources handler is set up
   4.3 Prompts: Expresses support for resources (along with server level prompt settings) based on whether ListPrompts handler is set up
   4.4 Experimental: Experimental capabilities that are passed by the server owner during setup

This information can be used by the client to decide whether the server offers capabilities that are useful for the task it is trying to achieve. These will useful if the client is scanning a server registry to try and find a tool best suited for its purpose i.e. establishing connections at run time.

Suggestion

Some additional information that can be passed by the server to the client during initialization:

1. Provider Information: Name and url of the organization that created the MCP server. Clients might want to restrict themselves to servers offered by a subset of organizations due to legal and/or quality issues.
2. Additional Server Capabilties
   2.1 Resource Templates: Expresses support for resource templates based on whether ListResourceTemplates handler is set up
   2.2 Completion: Expresses support for completion based on whether Complete handler is set up

Tool Annotations

Tool annotations are used to offer additional metadata about a tool's behavior. While these annotations are hints and taken in good faith, they can be used to convey the impact and nature of a tool. Clients can rely on them (if from trust worthy sources) to decide whether a tool should be used for a task or not. Current annotations:

1. title: A human-readable title for the tool, useful for UI display
2. readOnlyHint: If true, indicates the tool does not modify its environment
3. destructiveHint: If true, the tool may perform destructive updates (only meaningful when readOnlyHint is false)
4. idempotentHint: If true, calling the tool repeatedly with the same arguments has no additional effect (only meaningful when readOnlyHint is false)
5. openWorldHint: If true, the tool may interact with an “open world” of external entities

Suggestion

Some additional tool annotations that can help the client when deciding on which tool to use:

1. statelessHint: If true, indicates that tool maintains state from the last request and that the context from last request can influence the new response. This could help the client decide on whether it needs to pass the entire context from last time or not. It can also help the client determine if multiple follow-ups with the server might yield better responses. This could be especially useful in scenarios where the server might be making use of another agent under the hood.
2. streamingHint: If true, indicates that the tool will stream its responses. This can help the client decide which tool will respond with the entire response at once vs which tool will stream the response over time.

Scope

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

[hesreallyhim]

Provider Information: Name and url of the organization that created the MCP server. Clients might want to restrict themselves to servers offered by a subset of organizations due to legal and/or quality issues.

Wouldn't we maybe want to distinguish/include both the org that creates the MCP and the org that provides it (e.g. hosts it as an API)? Not sure how the latter would work really, but that would also seem pretty important.

I like these suggestions.