Description
Originally posted by @PederHP in PederHP/mcpdotnet#57.
There is a first cut of Tool Annotations and Category being added to the MCP spec:
modelcontextprotocol/modelcontextprotocol#185
I think this is much better than some of the alternatives being discussed, so I am personally in favor of the general direction of the proposal.
So far it looks like it will add these properties to Tool:
string? category;
bool? readonly;
dictionary<string, object>? extraInfo;In the proposed spec change, category is a more complex type:
export type ToolCategory =
"search" |
"repl" |
/* ... | */
string;So an alternative to string, could be something like (with proper validation, convenience, etc.):
public record ToolCategory(PredefinedToolCategory? predefinedCategory, string? customCategory);
public enum PredefinedToolCategory { Search, Repl }I personally lean towards using string with convenience constants for the predefined categories. I am not a big fan of the spec having these predefined categories. I understand why it's done, as it increases pluggability of MCP servers, but I worry slightly that it will lead to a bloated spec down the road.
I would rather such conventions be built on top of the protocol than into it. These two categories also look like the ones claude.ai uses in their first party chat solution. I don't think it's unreasonable to push back on such concerns bleeding into the spec - even if it might end up being the right choice in the end.
That was a digression. As for implementing this change if it is added to the draft spec: It's very easy on the basic handler, as that's just updating the DTO to reflect the schema change. But for the extension methods, it would mean adding the properties to the McpToolAttribute, which turns it into a pretty heavy-weight attribute. Especially the kwargs-style ExtraInfo adds some complexity. Maybe that's ok as this is all optional.
It also means a decision needs to be whether to support these at the class level in McpToolTypeAttribute. One option could be to add a McpToolAnnotationAttribute instead of extending McpToolAttribute.
Addendum: For those curious, my impression is that the point of this change is
- Metadata for applications that want to toggle Tools based on category instead of individually. It's a relatively common use case to bundle a number of Tools to be used with a feature like Web Search, Code Interpreter, Artifacts/Canvas, Data Analyst, etc. This could also be done at the user level.
- Metadata for applications to determine when to require user approval to run tools. The readonly field is much cleaner than some of the more complex solutions discussed in the MCP community.
- And of course optional metadata for MCP servers that are domain specific or internal. I can see many use cases where I, as a generative AI service and application developer, would want such a feature.