The server does not respect the negotiated protocol version

[mikekistler]

Describe the bug

MCP has supported protocol version negotiation since the 2024-11-05 version of the MCP Specification.
Version negotiation is done through the "initialize" message and response which is always the first message sent in a session.

But the C# MCP server does not respect the negotiated protocol version. In particular, if the negotiated protocol version is 2025-03-26, a tool with structured output has an "outputSchema" property in the response of "tools/list".

To Reproduce

Create a session with an MCP server with tools that support structured output (a feature added in the 2025-06-18 version of the MCP spec) with a negotiated spec version of 2025-03-26. Then make a "tools/list" request. The response will contain "outputSchema" for the tool that supports structured output.

Expected behavior

The response schema should conform to the negotiated protocol version.

Additional context

The ProtocolVersion project in the v0.3.0 branch of this repo, with a few small modifications, can be used to reproduce this problem.

[stephentoub]

Does the spec consider it an error to send additional properties in these response types?

If not, then the additional outputSchema from the perspective of a 03-26-2025 client would just be an unknown and ignorable additional property.

[mikekistler]

Good point. I checked the schemas in the spec repo and all appear to include some form of additionalProperties: {} -- so additional properties do seem to be allowed.

So I agree that this particular case is not an error. Let me see if there is another scenario that may be more serious.

[mikekistler]

I've done a little more research and could not find another scenario where correct processing requires respecting the protocol version. What I was looking for was a case where a client might sent a field in a request that was defined in spec version n but the negotiated protocol version was n-1. In this case, I think the server should ignore the field (since it is allowed in older versions) but not perform the behavior it would imply in spec version n.

So for now I'll close this out but we should be on guard for a scenario like this as we add support for new spec versions.