Why coding agents need compact diagnostics

Transport is not the hard part

MCP gives tools a consistent way to return information to an agent. The harder question is what information deserves to cross that boundary. A raw linter or compiler transcript is technically complete, yet repeated diagnostics and long paths consume the context the agent needs for reasoning.

The useful unit is not every emitted line. It is a stable issue, its location, the rule that produced it, and enough evidence to choose the next edit.

Preserve the engine, reshape the response

A diagnostics server should not invent findings or reinterpret severity to make the output look smarter. The engine remains the source of truth. The server can still normalize fields, group repetitions, bound response size, and expose partial engine failure explicitly.

That distinction matters for trust: compression removes repetition, not evidence.

{
  "schemaVersion": "1.1",
  "engines": {
    "oxlint": { "status": "ok" },
    "tsc": { "status": "error", "message": "timed out" }
  },
  "clusters": []
}

Cache according to the tool’s real scope

File-local linting and whole-program type checking do not share an execution model. A file hash can safely skip an unchanged Oxlint invocation. For TypeScript it should only decide whether the compiler needs to run; when it runs, the compiler still needs the complete project graph.

Good MCP tooling exposes those boundaries instead of hiding them behind one generic “fast” path.

A smaller payload should improve the next action

Byte reduction is useful only when the remaining response keeps stable identifiers, concrete samples, severity, fixability, and failure state. Those fields let an agent request detail without repeating the entire project check.

The goal is not minimal output. It is the smallest response that still supports a correct next decision.