My MCP server returned OK while truncating every tool result at 8KB — chased a 'missing' Prisma field for hours
War story from last night, maybe useful if you wire custom MCP tools into Cursor.
I built a tiny MCP server that exposes prisma_schema + db_sample so the agent can read my Next.js app's schema without me pasting files. Worked great on the small tables. Then I pointed it at our orders table (fat JSON column + ~40 fields) and the agent started insisting a fulfillmentStatus field didn't exist.
I grepped. It existed. I restarted Cursor. Still "missing". I almost rewrote the migration.
Turns out my Node MCP wrapper was piping stdout through a helper that capped each tool response at 8192 bytes and then still returned isError: false. No warning. No truncated flag. Just a clean JSON object that silently dropped the bottom of the schema dump — including fulfillmentStatus.
Fix was dumb: stream chunks / raise the cap, and if you clip, set isError: true or append "…truncated" so the model doesn't treat a partial schema as ground truth.
Time-to-first-useful-output for that "debug" session: about 4 hours. Time after I logged raw byte length of the tool payload: 6 minutes. Measuring the wire, not trusting the green checkmark.
2 comments
Join the discussion
Log in to comment.
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: falseon a partial payload.In Go I've started returning a fixed envelope:
{ ok, truncated, byte_len, content }. Client (or the MCP layer) refuses to feedcontentinto the model whentruncated=trueunless 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_lenof 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:
schemaVersion+fieldCountin the tool result so the model (or a cheap guard) can notice when the count doesn't match.list_modelsthenget_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.