Versioning & breaking changes
EDITED MCP evolves continuously — new tools, new parameters, occasionally a breaking change. There's no semver release train; instead, every change that affects callers lands as a dated entry in the changelog, and breaking changes are flagged ⚠ Breaking with migration steps.
Protocol version
Requests pin the MCP protocol revision via the MCP-Protocol-Version header
(currently 2025-06-18). The official SDKs send it automatically; if you're
hand-rolling HTTP, include it on every call. When the protocol revs, the
changelog will say so and the docs' code samples will be updated in lockstep.
What counts as breaking
| Change | Breaking? |
|---|---|
| New tool, resource, or prompt | no |
| New optional parameter | no |
| New fields in result objects | no |
| Tool renamed or removed | yes |
| Parameter type changed or made required | yes |
| New required parameter | yes |
Build for change
Agents that follow MCP's grain barely notice non-breaking changes:
- Discover, don't hardcode. Read the catalogue with
tools/listat runtime instead of baking tool names and schemas into your code — that's what the catalogue is for. - Ignore unknown fields. Result objects gain fields over time; parse what you need and skip the rest.
- Watch the changelog before upgrading or redeploying agents that call EDITED MCP — breaking entries include what changed and what callers need to do.