Add version property to McpServerToolAttribute for manifest clarity and tool lifecycle support

[SeanAMcKinney]

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

Hi all, I’m new to posting here and just starting to explore MCP, so apologies if this isn’t the right format or place—happy to adjust if needed.

I’m planning to build out a manifest-driven orchestration layer and wanted to suggest a small feature that could help clarify tool registration and versioning.
Would it make sense to add a version property to McpServerToolAttribute?
The idea is to support:

1. Manifest clarity: Explicit versioning for tools in orchestration manifests
2. Session safety: Ensuring clients invoke the correct tool version
3. Tool lifecycle management: Supporting multiple versions side-by-side or deprecating older ones cleanly

This could help with reproducibility, compatibility enforcement, and clearer inventory tracking—especially as orchestration scales and tools evolve.

Since I’m still getting familiar with MCP, I’d love to hear thoughts from others. Is this already handled elsewhere in the SDK or tooling? Would this belong in a different layer?

Thanks in advance!

Scope

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

[PederHP]

Where would this go in the MCP Tool schema? I am not sure there's any field for it. There's a _meta property at the response level, but that's really awkward to use, and only your 1st party client hosts would see it.

It has to align with the spec, or no 3rd party clients will benefit. If it's a non-standard property, some may even fail the tool call cause of strict schema validation.

The idea makes sense, and there are suggested changes to the protocol involving manifests to ensure per version tool schena integrity, but I am not sure it's possible now.

Note that LLMs dont need tool versioning like REST API consumers need API versioning. They're inherently never coupled to a specific shape. So versioning is more an auditing and governance concern imo.

[SeanAMcKinney]

Thanks for the clarification, that really helps. I see now that adding a version property to the attribute doesn’t automatically surface it in the manifest, and without spec-level support, it wouldn’t be usable by third-party clients. I hadn’t fully considered how strict schema validation could block non-standard fields, so that’s good context to have. Really appreciate you taking the time to walk through that. It gives me a much clearer sense of how tool metadata is handled in the current protocol and where versioning ideas might fit down the line.