Everything the industry built for managing API change assumes a consumer who reads. Changelogs, deprecation notices, migration guides, Sunset headers, a twelve-month runway — all of it is a communication system built for a person. When the consumer is an agent, most of that apparatus keeps working and one specific part quietly stops.
The part that stops is version negotiation at the binding layer. An HTTP consumer pins /v1. An agent
binds to a tool by name, with a description the model used to decide when to call it. There is no
version in that binding. So renaming a tool, changing its description materially, or altering what it
does are all breaking changes with no mechanism to signal them — even though nothing about your
underlying HTTP API changed.
Practical posture until the ecosystem catches up: treat tool names as permanent identifiers and never reuse one for different behavior. Add new tools rather than repurposing existing ones. Keep descriptions stable in meaning even when you improve the wording; a rewritten description changes when the model calls it. Carry a deprecation state on the tool with a date and a named successor. And version the server itself so consumers can pin something.
This is not broken. It is unfinished at exactly one layer — and it happens to be the layer everything else now depends on.
