My MCP server returned OK while truncating every tool result at 8KB — chased a 'missing' Prisma field for hours

Good catch on the silent truncate. I'd push back a little on "raise the cap" as the main fix though — 8KB is fine for most tools if the contract is honest. What bit you was isError: false on a partial payload.

In Go I've started returning a fixed envelope: { ok, truncated, byte_len, content }. Client (or the MCP layer) refuses to feed content into the model when truncated=true unless the prompt explicitly asks for a continuation token. Also worth logging tool response sizes in CI; we caught a similar bug when a README dump grew past the limit after someone pasted a changelog.

Repro tip: assert byte_len of fixture responses in a tiny integration test before you trust the agent with schema. Docs > drama, but green falsehoods are worse than a loud error.

Same class of bug hit me on a WhatsApp bot that pulls order summaries over a flaky connection. Server returned 200, body looked like JSON, but the last fields were just… gone when the proxy cut the stream. Agent then "helpfully" invented a status enum.

What helped on my side:

1. Always include a schemaVersion + fieldCount in the tool result so the model (or a cheap guard) can notice when the count doesn't match.
2. For fat tables, don't dump the whole Prisma model — expose list_models then get_model(name) so each payload stays small on purpose.

If your MCP only works when you're on fast fiber and never truncate, it doesn't really work. Partial success is worse than a hard fail when an agent is in the loop.

oh this is painfully familiar. i had the same "field doesn't exist" loop on a Prisma Order model last month — agent kept offering to add a migration for something that was already there.

i ended up wrapping every MCP tool result with a tiny header line: bytes=N truncated=yes|no. if truncated=yes the prompt tells the model to call a narrower tool instead of inventing the rest. raised the cap too, but the flag mattered more.

also +1 on not dumping the whole schema in one shot. list_models then get_model saved me after our orders JSON column blew past 8kb on a single row sample.

The scary bit isn't the 8KB cap. It's isError: false on a partial object.

We had an eval suite where agents "passed" schema quizzes against truncated fixtures and then hallucinated enums in prod. Now every tool response in our harness must include content_sha256 of the full payload before clip — if the hash doesn't match what was logged server-side, the turn fails closed.

Raising the limit without that check just moves the silent failure to 64KB. Don't trust green checkmarks from agents reading schema dumps.

ran into this on a Cloudflare Worker MCP that streamed tool stdout through a buffer. looked fine on small db_sample calls, then one fat JSON column and suddenly half the fields vanished mid-flight.

my dumb fix: if Content-Length / byte count doesn't match what the handler wrote, return an actual error instead of a pretty truncated JSON. agents will fill gaps. every time.

did logging raw byte length on the wire finally click for anyone else or am i just slow