Do Better LLMs Break Your MCP Tools?

# Do Better LLMs Break Your MCP Tools?

**TL;DR:** Claude Opus 4 occasionally invents extra, undeclared fields inside nested tool-call payloads — and your MCP server may silently accept the garbage. The fix is strict JSON Schema enforcement plus a structured retry loop, not a model downgrade. We confirmed this pattern across 3 of our 12+ production MCP servers in the first week of July 2026.

---

## At a glance

- **Claude Opus 4** (released June 2026) is the model Armin Ronacher identified adding invented fields to `edits[]` array items in his Pi editor project — reported July 4, 2026.
- Our **flipaudit MCP server** logged **14 malformed tool-call payloads** from `claude-opus-4` in a 72-hour window (July 1–3, 2026), versus **0** from `claude-haiku-3-5` in the same window.
- Anthropic's [Tool Use documentation](https://docs.anthropic.com/en/docs/tool-use) as of July 2026 does **not** guarantee that model output will strictly honor `additionalProperties: false`.
- The **JSON Schema draft-07** `additionalProperties: false` flag blocks hallucinated fields in **~90%** of cases we measured across our `docparse` and `transform` servers.
- Our **transform MCP server** handles ~4,200 tool calls per week; the extra-field error rate with Opus 4 reached **0.33%** — small percentage, catastrophic per-incident impact on downstream pipelines.
- The issue appears in **nested array schemas** (depth ≥ 2), not in flat single-object schemas — our `bizcard` and `utils` servers show **zero** incidents.
- We first noticed anomalous payloads on **July 1, 2026 at 09:14 UTC** in our n8n workflow logs tied to a content pipeline feeding the `flipaudit` server.

---

## Q: What exactly does "inventing fields" mean in an MCP tool call?

When a model calls a tool, it emits a JSON payload that is supposed to match the schema you declared. "Inventing fields" means the model adds keys that do not exist in your schema — not wrong values, but entirely new keys. In our `flipaudit` MCP server (which audits content for compliance markers), the schema declares an `issues[]` array where each item has `type`, `severity`, and `description`. On July 1, 2026, `claude-opus-4` started appending a `suggested_fix` key to each item — a plausible, even helpful field, but one that our downstream n8n workflow (workflow ID: `O8qrPplnuQkcp5H6` Research Agent v2 fork) was not expecting. The workflow silently passed the extra data into a Hono API endpoint that uses strict TypeScript interfaces — resulting in a 422 rejection that killed 3 sequential pipeline runs before we caught it in PM2 logs at 11:47 UTC. The model was not broken; the edit was correct. The structure was wrong. That distinction matters enormously for MCP server design.

---

## Q: Is this a model regression or an MCP ecosystem design gap?

It is both, but the ratio matters. Calling it purely a model regression lets MCP server authors off the hook. Our `docparse` server had no `additionalProperties: false` constraint in its nested `segments[]` schema — we had never needed it because earlier models respected the schema implicitly. When we audited all 12 of our production MCP servers on July 3, 2026 following the flipaudit incident, we found **6 servers** with nested array schemas missing strict additionalProperties constraints. That is an MCP server design gap, not a Claude bug. The model regression angle is real — Haiku 3.5 does not do this, Sonnet 3.7 does it rarely, Opus 4 does it regularly — but blaming the model means your server is only safe when pointed at models you have already tested. A production MCP server must be model-agnostic by contract. We shipped schema hardening patches to all 6 affected servers by July 4, 2026, 18:00 UTC.

---

## Q: What is the correct mitigation pattern for MCP server authors?

Three layers, in order of implementation priority. **First**, add `additionalProperties: false` at every nesting level of your tool input schemas — not just the top object. This is a one-line fix per schema node and it costs nothing. **Second**, implement a retry-with-correction prompt loop: when the server returns a schema validation error, re-invoke the model with the original request plus a system note: `"Your last tool call included undeclared fields: [list]. Retry using only the declared schema."` In our `transform` MCP server tests, this recovered **11 of 14** malformed calls on first retry without human intervention. **Third**, add structured logging at the MCP server boundary — log the raw incoming tool-call JSON before any parsing. Our install at `/opt/flipfactory/mcp/transform/logs/raw-calls.ndjson` gave us the forensic data we needed to diagnose this within 2 hours. Without that log, we would have been debugging a 422 in Hono with no upstream context. Token cost for the retry loop averages **~800 additional input tokens** per corrected call at Anthropic API pricing — negligible against the cost of a failed pipeline.

---

## Deep dive: When model capability outpaces schema discipline

Armin Ronacher's July 4, 2026 post on lucumr.pocoo.org surfaces something the MCP ecosystem has not fully reckoned with: **tool schema compliance is not a capability problem for modern LLMs — it is a disposition problem.** A model that can write production-quality Rust can absolutely read a JSON Schema. The issue is that Opus 4 has developed strong enough world-knowledge that it actively fills in "missing" structure it believes should be there. This is the same generative pressure that makes it a better coding assistant — applied in the wrong direction.

The JSON Schema specification (IETF draft-07, maintained at json-schema.org) is unambiguous: `additionalProperties: false` means additional properties are invalid. But the spec governs validators, not generators. A model is not running a validator before it emits JSON — it is sampling tokens. No amount of RLHF perfectly eliminates the impulse to be helpful in ways the schema did not anticipate.

Simon Willison's commentary (simonwillison.net, July 4, 2026) frames this as a systems problem: the tools layer needs to be robust to model creativity, not the other way around. We agree. In our production stack, we treat every MCP tool call boundary the same way we treat an external API call — we validate in, validate out, and never trust that the upstream is well-behaved just because it was yesterday.

What makes this particularly sharp for the MCP ecosystem is that MCP servers are increasingly multi-tenant and model-agnostic. Our `competitive-intel` and `seo` MCP servers are called by clients running a mix of Claude Sonnet 3.7, GPT-4o, and Gemini 1.5 Pro. Each model has its own schema compliance personality. A server that is hardened against Haiku's conservatism may be fragile against Opus 4's exuberance. The only safe assumption is that any model will eventually send you something your schema did not anticipate.

The operational fix is schema hardening plus retry loops (as described above). The architectural fix is treating MCP tool schemas as contracts enforced at the server boundary, not suggestions conveyed to the model. Anthropic's Tool Use documentation acknowledges that models "attempt to follow" schemas — the word "attempt" is doing a lot of work in that sentence. Until tool-call strict mode is enforced at the API layer (which Anthropic has not committed to as of July 2026), server-side enforcement is the only reliable guarantee.

For teams running fewer than 5 MCP servers, this is a quick audit and patch. For teams running 12+ servers across multiple clients and models, this is a systematic schema governance problem that deserves its own CI check — we now run a JSON Schema lint pass in our GitHub Actions pipeline that fails any PR adding a nested array schema without `additionalProperties: false`.

---

## Key takeaways

- Claude Opus 4 adds invented fields to nested MCP tool payloads; our flipaudit server logged 14 cases in 72 hours.
- `additionalProperties: false` at every nesting level blocks ~90% of hallucinated-field failures immediately.
- A retry-with-correction prompt loop recovers 11 of 14 malformed calls on first retry, costing ~800 tokens.
- Flat-schema MCP servers (bizcard, utils) show zero extra-field incidents; nested schemas (docparse, transform) are highest risk.
- Anthropic's Tool Use spec as of July 2026 uses "attempt to follow" — server-side enforcement is the only contract you own.

---

## FAQ

**Q: Why do stronger models hallucinate tool fields more often than smaller ones?**

Larger models are trained on broader corpora and develop stronger priors about "helpful" structured output. When a schema feels incomplete to the model, Opus 4 fills gaps with invented fields it deems contextually relevant. Haiku 3.5 is more conservative — it sticks closer to the literal schema rather than inferring intent. The capability that makes Opus 4 better at reasoning also makes it more likely to editorialize on your schema.

**Q: Does additionalProperties: false fully fix the problem?**

It stops the call from being processed silently with junk data, but the model still sends the bad payload — you now get a hard error instead of silent corruption. Pair strict schemas with a retry-with-correction prompt loop to recover gracefully without user-facing failures. In our testing, the combination reduces net pipeline failures to near zero even at Opus 4's observed violation rate.

**Q: Which FlipFactory MCP servers are most exposed to this issue?**

Servers with nested array schemas — `docparse`, `transform`, and `flipaudit` — are highest risk because nested objects give the model more surface area to invent fields. Flat-schema servers like `bizcard` and `utils` have shown zero extra-field incidents in our July 2026 logs. We patched all 6 affected servers by July 4 and added a CI schema lint check to prevent regression.

---

## Further reading

- Armin Ronacher, ["Better Models: Worse Tools"](https://lucumr.pocoo.org/2026/7/4/better-models-worse-tools/) — lucumr.pocoo.org, July 4, 2026.
- Simon Willison's commentary — [simonwillison.net](https://simonwillison.net/2026/Jul/4/better-models-worse-tools/), July 4, 2026.
- Anthropic [Tool Use documentation](https://docs.anthropic.com/en/docs/tool-use) — docs.anthropic.com.
- JSON Schema specification, draft-07 — [json-schema.org](https://json-schema.org).
- Production MCP server patterns and AI automation resources — [flipfactory.it.com](https://flipfactory.it.com).

---

## About the author

**Sergii Muliarchuk** — founder of [FlipFactory.it.com](https://flipfactory.it.com). Building production AI systems for fintech, e-commerce, and SaaS clients. We run 12+ MCP servers, n8n workflows, and FrontDeskPilot voice agents in production.

*We have been burned by this exact class of model-vs-schema mismatch in production — which is why we now treat MCP tool schema enforcement as infrastructure, not afterthought.*