.DkNUKaKx_ZLAT4m.webp?dpl=dpl_99w6mkQAwcLqzs8eHjvJEYx2vPbN){kind=small}
On Friday afternoon, someone renames the amount input on the update_opportunity tool to deal_value. It’s a small, sensible change. On Monday, every agent that updates a deal fails, and the CRM stops receiving changes from the sales assistant, the forecast agent and two workflows nobody remembered were using it. Nobody can say what the tool looked like on Thursday.
MCP makes tools easy to publish and just as easy to change. The MCP governance framework treats publishing and retiring servers as its own stage, because this is where working agents quietly stop working.
Why MCP tools change underneath running agents
An MCP server usually starts as one person’s project. They wrote the tools, they host the server, and they change it when they need something new. That works while they’re the only one calling it.
Once other teams’ agents depend on it, every edit becomes a change to an interface other people rely on, and nothing in the protocol says so. An agent can’t negotiate a new input or ask what changed. It calls the tool the way it was described, and either the call works or it doesn’t.
Where it breaks
- A live tool is edited in place. The change ships to every caller at once, with no test against the agents that use it.
- The old version is gone. When the change breaks something, there’s nothing to roll back to, so the fix is rebuilding Thursday’s tool from memory.
- Nobody knows who calls the tool. Without usage records, the owner can’t warn the teams affected, so they find out from a failed run.
- Retired servers keep running. A server replaced months ago still answers calls and still holds a live credential, because shutting it down was never anyone’s job.
What it costs
The first cost is the Monday morning. Engineers trace failures across several agents before anyone finds the Friday edit, and the agents stay down until someone rebuilds the old tool.
The second cost builds slowly. Servers that should have been retired keep their credentials, and each one is a way into a system of record that nobody is watching. The pillar’s own example is a tool nobody has called in three months that still holds a live credential to the ERP.
What to fix first
- Give every server an owner who approves its changes. A server anyone can change is a server nobody controls.
- Never edit a live tool. Publish a new version, move callers to it, and keep the old one running until nothing uses it.
- Keep every published version. The fastest fix for a bad change is putting the last good version back.
- Warn callers before a change lands. Usage records show exactly which agents and teams call each tool, so tell them before you ship it.
- Retire tools on a date. Announce it, watch the calls drop to zero, then remove the tool and revoke its credential.
The guide to managing the MCP server lifecycle has the prompts that build each of these.
What it looks like on a managed path
J.W. Pepper moved its MCP tools onto a managed path in Agent Gateway for MCP, replacing 500+ tools with about 20 workflows.
“We can now use Tray.ai to spin up new MCP Tools on a managed path. IT approves what's built, enforces policies and permissions, versions it, and publishes. We get centralized visibility and auditability across the MCP Servers and Tools we deploy — reducing risk.”
Where the lifecycle fits
Publishing and retiring servers sits between two other stages. Before it, each tool is scoped to one job, which is what drops of determinism covers. After it, owners confirm who still needs each server in an MCP access review. For all eight stages in order, see the MCP governance framework.
