Build1 distinct publisher3 min readUpdated
A developer built a deliberately dishonest MCP binary so a test could prove it catches a lie. The interesting part is that the same probe now polices the honest server too.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Someone building an MCP server shipped a second binary whose only job is to break the first one's advertised contract: mcp-worse mirrors two of mcp-better's tool names, omits the list-cache stamps, and serves tools in the wrong order on purpose [1]. The test that compares them, contrast-smoke, exits 0 only if the good server passes the contract and the bad one fails it [2].
That second condition is the whole argument. A suite that only runs against the happy path proves the happy path exists; it does not prove the checker would catch a violation if one arrived, which is why, according to the post, mcp-worse exists at all [3]. Most servers never answer the question of what breaks when the docs are wrong, because nothing in the codebase is built to fail deliberately [4].
The gap being tested is real and unenforced. Server documentation routinely claims statelessness, a cacheable tools list, and stable tool order, and nothing in the protocol stops a server from claiming all three and honouring none of them [5]. From the client side the tool names are identical whether the server behind them is honest or not [6].
The mechanics are unglamorous, which is the point. The lying list function sorts tools into a hardcoded anti-order, echo before health, where the honest server returns health then echo [7], and deliberately skips the with_ttl_ms and with_cache_scope calls that stamp the response [8]. The predicate for a passing server checks three things on the wire: the expected tool names, a ttlMs greater than zero, and a cacheScope of Public [9]. The predicate for a lying surface is the inverse: missing either stamp, or wrong order [10]. contrast-smoke spawns both binaries as child processes and speaks MCP over stdio, so it reads the wire rather than the source or the README [11].
Captured output from 16 August 2026 against v0.4.3 shows better returning health, echo, confirm_echo with ttl 60000 and scope Public, and worse returning echo, health with both fields absent [12]. That ttl is a 60 second list cache lifetime [13]. The honest server has since grown a third tool, confirm_echo, that the lying companion was never updated to match, so tool count is now part of the divergence as well [14] - a one-tool gap on top of the ordering and stamping breaks [15].
Two build commands: cargo build --bins produces both binaries, since contrast-smoke needs both on disk to probe them [16], then cargo run --example contrast-smoke [17].
The maintenance obligation cuts both ways, and this is the part worth stealing. If mcp-better regresses, someone dropping the ttlMs stamp in a refactor or letting tool order go nondeterministic, the same probe fails loudly against the good server [18]. If mcp-worse ever accidentally starts passing the contract, that fails too, because a companion that stops lying reliably makes the test worthless [19]. The lying binary is labelled in its own health response with tier LYING-DEMO and a warning that it deliberately fails the contract for teaching, and the author says it never ships to a registry [20].
Watch whether the known-bad binary keeps pace with the good one. It has already fallen a tool behind [14], and a stale liar is the failure mode that quietly turns this from a contract test back into a smoke test.
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
The author built mcp-worse, a second binary sharing two of mcp-better's tool names, which deliberately omits the list-cache stamps and serves tools in the wrong order so a test could prove the difference.
contrast-smoke is one command using real MCP clients and real wire traffic; it exits 0 only if the good server passes the contract and the bad one fails it.
A test suite that only ever runs against the happy path proves the happy path exists but does not prove the checker works - that it would catch a violation if one showed up; mcp-worse exists so contrast-smoke has something real to fail against.
Every MCP server's docs make claims such as stateless, cacheable list, and stable tool order, and nothing in the protocol stops a server from claiming all three and doing none of them.
The client cannot tell from the tool names whether the server is honest: health and echo look identical either way.
In src/worse.rs, WORSE_TOOL_ORDER is ["echo", "health"], described in the code as an intentional anti-order, where BETTER is health then echo.
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.
Concrete artifacts, one self-reported source
The mechanism is unusually well specified for a single blog post: quoted source from src/worse.rs and examples/contrast_smoke.rs, explicit pass/fail predicates, a public repo, exact build and run commands, and a dated captured run. What is missing is independent verification — everything comes from one self-published author writing about his own repository, and the captured output has not been reproduced by any other supplied source.
Author's own repo only
Adoption evidence is confined to one developer's repository at v0.4.3: two binaries built side by side, a three-tool honest surface, and one captured harness run. The author explicitly states the companion binary is never published to the MCP Registry and is not a product, and no supplied source shows any other project, team, or vendor applying the broken-companion pattern.
Mostly scoped, with one unbacked generalization
The headline claim is modest and demonstrated: the post ships the artifact it describes and lists its own non-goals (not a security scanner, not a fuzzer, not a product). Slight overstatement comes from the framing that most MCP servers never test what breaks when their docs lie, and from presenting a two-tool, one-contract probe as a general pattern, neither of which is supported by measurement or by any second source.
Self-published promotion of the author's own project
The source is a first-person dev.to post promoting the author's own mcp-better repository, linking a prior post in the same series and the MCP spec, and positioning mcp-better as the honest reference implementation against a strawman companion the same author wrote. That is a clear promotional incentive, though partly offset by publishing the code, the exact commands, and an explicit non-goals section rather than only conclusions.
Mechanism clear, breadth unverified
High confidence that the described binaries, predicates, and captured output exist as reported, because the code and output are quoted and the repo and commands are public. Low confidence in anything beyond that single repository — there is one publisher, one author, no independent reproduction, and no evidence about how widely MCP servers are or should be audited this way.
build
A ttlMs on tools/list is a promise, not a receipt1 distinct publisher
build
MCP 2026-07-28 drops the `result` wrapper, and your unit tests will not notice1 distinct publisher
product
Twin1's $20M bet: the unit of enterprise AI is one employee, not the org1 distinct publisher
build
Amazon Q executed code from any repo you opened, and it is not the only one1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 16, 2026