Claude Code Truncation: Our Open-Source Fix

The first time I noticed the problem, I assumed I’d done something wrong.

I was building the Quartermaster MCP (the part that lets the tool live inside Claude Code and respond to commands from the terminal). I ran a query. Claude returned the data. And then it just… stopped. Cut off mid-table, somewhere around line twelve, with no indication that anything was missing. The output looked complete. It wasn’t.

I ran it again. Same result. Tried a different query. Same place, same cut. It wasn’t my code. It was Claude truncating long outputs at what appeared to be an arbitrary line count.

This is a known problem. Claude, Cursor, most of the AI-native IDEs: they all have some variation of it. When a tool returns more than roughly ten lines of output, the display layer starts making decisions about what to show. Sometimes it collapses the rest. Sometimes it just doesn’t render it. The model sees the full response; the developer doesn’t. For a productivity tool where the whole point is surfacing information in the terminal, this is a real problem.

What we tried first

The instinct was to fight the formatting. If tables weren’t rendering, maybe something else would. We tried ASCII art. Pipe characters. Progress bars built from dashes and brackets. The classic three-dot vertical progress bar looked right in theory (clean, familiar, universally understood), but Claude Code’s output panel just doesn’t render it. You get the raw characters instead of anything resembling a UI element. None of it held up across environments. A layout that looked clean in Claude would break in Cursor. Something that rendered in one IDE became noise in another.

The issue was that we were treating formatting as decoration when it’s actually infrastructure. The output format isn’t separate from the tool. It’s part of how the tool communicates. Getting it wrong means the tool fails, even if the underlying logic is perfect.

The fix that actually worked

Markdown table syntax. That was it.

Not because it’s elegant. Because it’s a format these environments already know how to parse. Bold, headers, rows: the standard stuff. When the IDE sees a markdown table, it renders it as structured content instead of raw text, and the truncation behavior changes. We’re not sure it’s a deliberate design decision on the IDE side or a happy accident, but the result is consistent: outputs that used to cut off at line ten or eleven now display fully.

The output format isn’t separate from the tool. It’s part of how the tool communicates.

We also added what we’re calling AI hints: two layers of metadata that signal to the model how to handle the output. The first is a hidden markdown comment embedded in every response: it tells the AI client to render the content as-is, not summarize or paraphrase it or wrap it in a code block. The second operates at the server level, embedded in the MCP server constructor so it persists across every tool call, telling Claude to always render results verbatim instead of summarizing. Formatting alone solves the truncation problem. The hints solve the interpretation problem: the tendency for the model to collapse a table into a sentence or restate what the tool just said in its own words. Both problems look the same to the developer: you asked for data and got something else.

Once we had something that worked reliably, we extracted it into a standalone library: mcp-fmt. The idea is simple: when you’re building an MCP, you import this and apply consistent styling to all your outputs. No more trial-and-error per IDE, no more format-it-yourself every time. We tested across Claude and Cursor. It holds up.

Why we’re open sourcing it

We can’t monetize a formatting library. That’s just honest. Nobody is going to pay a subscription for a table formatter.

But that’s not the whole calculation. We’re building at the edge of what AI-native tooling looks like: what it means for a tool to live inside an IDE, respond in the terminal, feel like a real interface rather than a text dump. That’s genuinely new territory, and working through it means building a lot of infrastructure that doesn’t have a direct revenue model.

The Supabase comparison is one I keep coming back to. Their open-source database layer isn’t the thing they charge for, but it’s the thing that makes everyone know who they are and trust what they ship. Giving away the layer that creates distribution and credibility isn’t charity. It’s strategy.

For us, there’s a practical version of that. Every MCP developer who uses this library is someone who now has a consistent experience with how Tortuga thinks about terminal interfaces. When they see “Tortuga MCP format” in their IDE, that’s a signal about quality and about who built it. The initial audience is anyone building MCP tooling: a small but fast-growing group right now, mostly engineers who’ve already hit this exact problem and assumed it was their fault.

The thing that still bugs me

The truncation problem shouldn’t exist. These are professional tools built for developers, and they silently drop output without warning. The model sees the full response. The developer doesn’t. That’s a failure mode that looks like normal behavior, which is the worst kind.

I don’t think the fix we built is the permanent answer. It’s a workaround for a gap that the IDEs should close themselves. We built this specifically for Claude Code. That’s where we work, and that’s where the problem was costing us time. But it turns out the pattern is wider than that. OpenAI Codex has an open issue requesting token-based limits instead of arbitrary line counts, Grafana’s MCP server has a reported bug for silently dropping log results with no indication data was omitted, and Claude Code has its own tracked issue where responses get cut to roughly 700 characters. The markdown table approach holds up across Claude and Cursor. It may well work in other environments too, though we haven’t tested everything. What I do think is that this pattern (building in the open to fill gaps the incumbents haven’t addressed yet) is the right posture for a small team right now. You can’t wait for the platform to fix it. You build the fix and you share it, and the sharing is part of the point.

The next few MCPs we ship will use the same library. So will whatever comes after that. Eventually, if we do this right, the terminal stops feeling like a place where information goes to get truncated, and starts feeling like a real interface. That’s the bet we’re making.