Loading today’s stories
Build1 distinct publisher3 min readPublished
A dev.to walkthrough treats each MCP tool as a contract with the AI client rather than a wrapper, and counting the entries in its own change taxonomy shows how little upstream drift you get to absorb quietly.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Count the buckets before you adopt the process. The compatible list has five entries [8]. Review-required has seven [9]. Breaking has nine [10]. That is twenty-one named change types, of which nine need migration planning and five can ship on normal testing: 43 percent breaking, 24 percent quiet [1]. If your upstream is an API you do not own, that ratio is the whole cost model for publishing MCP tools against it.
The worked example shows how slippery the classification is in practice. The ticket API moves status from open and closed to open, pending and resolved, and adds a resolution_reason field [13]. The updated input schema publishes the three new enum values [14]. Adding enum values sits in review-required, while removing them is breaking [9][10], and this edit does both, because closed is gone from the set [2]. By the article's own table, the demo that reads as a schema tidy-up is the case that needs coordinating with clients.
The second half of that example is the more interesting constraint. resolution_reason is added as a property, and the required array stays as ticket_id and status [14]. The article's advice, when the schema cannot cleanly express that resolution_reason is required once status is resolved, is to explain the rule in the tool description and enforce it in the API [15]. That moves enforcement out of the machine-readable part of the contract, which the piece identifies as where API changes become visible to the client [17], and into prose a model weights however it likes, backed by a rejection the client only meets at call time. The schema stops being the contract and becomes a hint.
I would also move one entry. Adding a write tool is filed under review-required, alongside changing error messages and changing default pagination limits [9]. A new write tool changes the side-effect surface an agent can reach, and side effects are listed as part of the contract in the first place [2]. That is a coordination event in my book, whatever the testing burden looks like.
The eight-step sequence only works if step one has a trigger. Detection is specified three ways: diff the OpenAPI or Swagger definition, compare exported Postman requests and variables, or compare code and tool schemas directly for a hand-written server [12]. All three assume something to diff. Where the upstream ships no machine-readable definition and no changelog, detection collapses into the last step, monitoring the first production calls [4], and the article is explicit that the MCP server keeps initialising and the tool keeps advertising itself while real calls fail or return unexpected data [3]. Nothing in a health check knows the difference.
The piece says the goal is boring in the best way, that existing users should not wake up to broken tool calls because a route changed quietly [16]. Boring has a price list: a diff per upstream release, a version bump, a rollback path, and call-level monitoring on the way out. In my context that is worth paying only for tools with real users, which is also the honest test for whether you published a contract or just a wrapper.
Ranked by verification strength, evidence, and original report placement.
An MCP tool is not a random wrapper around an endpoint; it is a contract exposed to an AI client.
The contract an MCP tool exposes includes tool name, tool description, input schema, required fields, optional fields, enums, default behavior, response shape, authentication expectations, side effects and error behavior.
If the underlying API changes, the tool can break while the MCP server is still running: the server may still initialize and the tool may still be discoverable, and the break appears when real calls start failing or returning unexpected data.
The stated goal is boring in the best way: existing users should not wake up to broken tool calls because an API route changed quietly.
The input schema is where many API changes become visible to the AI client.
The recommended safe update process for API-backed MCP servers is eight steps: detect the API change, identify affected MCP tools, classify the change as compatible or breaking, update schemas, names, descriptions and authentication details, test valid and invalid calls, publish a versioned update, keep a rollback path, and monitor the first production calls.
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 29, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
build
MCP standardizes the tool call, not the authority to cause the effect1 distinct publisher
build
Two ways to point Claude at production, and only one of them keeps the password1 distinct publisher
build
MCP is four trust boundaries, and credentials only close one of them1 distinct publisher
build
Metadata discovery turns an MCP client into an unauthenticated fetch primitive1 distinct publisher
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Internally checkable, externally unchecked
Everything factual here can be verified by reading the post, and the diffs and schemas are concrete enough to be wrong in public — which is a genuine strength. But the prescriptive spine, from the eight steps to the twenty-one classified change types, is prefaced by 'I usually' and backed by no incident, no postmortem, no survey and no second voice. The self-consistency check even turns up a crack: the enum edit in the worked example lands in the breaking bucket by the author's own table.
No usage signal in the record
Not a single deployment, download, server count, release note or user report appears anywhere in this reporting. dev.to's post describes a method; it never claims anyone besides its author follows it, and we will not manufacture a number from a tutorial.
Undersells its own finding
Nobody is being sold anything: no product, no benchmark, no launch, and the author's stated ambition is to be 'boring in the best way'. If anything the piece understates itself — it presents the ticket-status edit as routine schema housekeeping when its own table puts that edit in the migration-planning column, and it never adds up the lists that show most upstream drift cannot ship quietly. The loudest number attached to this story is our count, not the author's.
Nothing on sale
The commercial pull here is about as light as it gets: a personal developer-platform post with no vendor, no tool being pitched, no pricing and no funding to talk up. The residual pressure is reputational — dev.to rewards authoritative-sounding how-tos, which is exactly the incentive that produces confident numbered lists like the eight steps and the nineteen-item scan, whether or not they have been stress-tested.
Sure what was said, unsure it holds
We can state with near-certainty what this reporting contains and what the counts come to — the text is explicit and the arithmetic is ours to check. Confidence drops on whether the advice generalises, because there is one publisher, one author, no adoption signal, and one unresolved contradiction between the taxonomy and the example that follows it.