Declares protocolVersion and handles version mismatch
Why it matters
The protocolVersion field in the initialize response is how MCP clients determine whether this server is compatible with features they intend to use. An invented version string (e.g., "1.0") does not match any valid MCP release and breaks version-gated features in strict clients. A missing protocolVersion entirely leaves clients unable to negotiate compatibility. The MCP spec uses date-based versions (e.g., "2024-11-05") as the canonical format — non-date strings signal that the server was not built against the actual specification.
Severity rationale
High because an invalid or missing `protocolVersion` breaks version negotiation, which can prevent clients from enabling features the server actually supports.
Remediation
The SDK sets the correct protocolVersion automatically. For custom implementations, use the exact date-format string from the MCP specification.
// src/handlers/initialize.ts — correct version string
return {
jsonrpc: '2.0',
id: request.id,
result: {
protocolVersion: '2024-11-05', // date-based, not semver
capabilities: {
tools: { listChanged: true },
},
serverInfo: { name: 'my-server', version: '1.0.0' },
},
}
Check the MCP changelog for the latest valid protocol version string and update when you adopt new spec features.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the MCP Server Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- external · mcp-spec-versioning — MCP Specification — Protocol version negotiation
Taxons
History
- 2026-04-18·v1.0.0·Initial import from mcp-server·automated