Problem

MCP tool servers that return structured, deterministic data (regulatory filings, financial statements, structured records) often need their response rendered verbatim, in a specific order, with no client-side summarization. Common use cases:

• Financial statements with a regulatory order of accounts (e.g. PCG, IFRS, US GAAP) where omitting subtotals breaks the auditability of the document
• Regulatory disclosures (KYC, sanctions hits, compliance flags) where the consumer expects to see every flagged item
• Structured records where the response shape is the value (e.g., a hierarchical org chart, a multi-level taxonomy)

Currently, even with explicit instructions inside the tool description (e.g. "render every line in _layout.sections[*].lines, do not summarize, use - for null values"), client implementations (the LLM agent plus its host prompt) routinely:

1. Pick a subset of fields they consider most relevant
2. Collapse subtotals into a flat summary
3. Skip "low-value" sections (e.g. CAGR breakdown, dividend history)
4. Reorder rows for readability

The end-user sees a "helpful summary" that omits regulatory-required structure. This is invisible to the user (they don't know what's missing) and to the server (which has no way to enforce verbatim rendering).

Current workarounds (all insufficient)

• Verbose imperative instructions in tool description ("MUST render all lines, NEVER omit")
• Structured _layout / _rendering metadata in the response payload describing the canonical order and sections
• Explicit user prompt: "show me everything, do not summarize"

Each of these is overridden by the client's default summarization heuristic. In our testing, the same payload renders correctly in some clients (full table) and as a 5-line synthesis in others — the server has no leverage.

Related discussions

• #2211 (response size limit) discusses the opposite problem: clients summarizing because the response is too large. Our case is the inverse — response size is fine, but the client summarizes regardless.
• #1138 (tool annotations) defines readOnlyHint, destructiveHint, idempotentHint, streamingHint. None covers rendering directives.
• SEP-1382 (docs best practices) frames good tool descriptions but doesn't address server-controlled rendering.

The content vs structuredContent split already acknowledges that human-facing rendering and machine-facing data have different needs. But neither field gives the server a way to declare "this content was crafted intentionally exhaustive — do not abridge."

Proposals

Two complementary options, not mutually exclusive:

Option A — Tool annotation: verbatimHint

A boolean on the tool definition declaring "responses from this tool should be rendered verbatim to the user, with minimal client-side reformulation":

type ToolAnnotations = {
  readOnlyHint?: boolean;
  destructiveHint?: boolean;
  // ... existing
  verbatimHint?: boolean;  // NEW
};

Clients are expected (but not forced) to:

• Render the full response structure when displayed to the user
• Avoid eliding or paraphrasing fields/rows
• Defer to the response's intrinsic ordering

Option B — Response-level rendering directive

Servers attach a hint to individual responses, allowing per-call control:

{
  "content": [...],
  "structuredContent": {...},
  "_rendering": {
    "mode": "verbatim",
    "guidance": "Render all rows from sections.* in order. Null values shown as '-'."
  }
}

This complements verbatimHint for tools that sometimes return summary data and sometimes return exhaustive data based on call parameters.

Why this matters

Without a standard signal, MCP servers in regulated or audit-sensitive domains either:

• Accept that clients show a synthesis (and the user can't tell)
• Push the user to add "do not summarize" to every prompt
• Build their own non-MCP rendering layer outside the protocol

A protocol-level affordance lets ecosystems converge on respecting server intent without each server reinventing the directive in prose.

Open questions

1. Is verbatimHint an appropriate annotation, or should this live entirely at the response level?
2. How should clients balance verbatimHint=true with context-window pressure (e.g., tool returns 5 MB)? Truncate-but-warn? Refuse?
3. Should there be a complementary summarizeOkHint (default behavior, opposite signal) for symmetry?
4. Does this interact with MCP Apps UI capabilities — could a future "rendering region" concept replace this hint entirely?

Happy to prototype either option in a reference client/server if there's appetite. Curious whether others have hit the same gap.