MCP servers evolve — new tools added, old ones changed or removed. Without a versioning strategy, clients break silently or every change is a coordinated upgrade. The patterns from REST API versioning apply with some MCP-specific twists.
Additive changes are free
Adding a new tool: no client breaks. Old clients ignore unknown tools. New clients see them via discovery. This covers most real evolution.
Schema changes — protocol-level
Tool's argument schema gains a new optional field with default. Backward-compatible. Required new field: breaking. Renamed argument: breaking. Treat tool schemas like protobuf: additive changes only, deprecate before remove.
Deprecation
Mark tool deprecated in metadata; emit warning log on use. Keep working for one release cycle. Remove. Document timing in changelog. Older agents will need migration; warn at sufficient lead time.
Capability negotiation
MCP supports client-server capability handshake. Server advertises supported features. Client requests subset. Server enforces. Lets you evolve protocol features (streaming, batch) without breaking older clients.
Multi-version coexistence
Don't run multiple incompatible MCP server versions; consolidate behind a router that exposes one stable surface. Hide migration complexity from clients. Many ops issues come from version sprawl no one tracks.