get-revision returns page source with no size cap, unlike every other read

[alistair3149]

What is wrong

get-revision applies no size cap to the content it returns. Every other text-returning read does.

src/tools/get-revision.ts:100-101 assigns the revision content straight through:

if (needsSource && rev.content !== undefined) {
	payload.source = rev.content;
}

get-page, get-pages, compare-pages and parse-wikitext all import truncateByBytes from src/results/truncation.ts; get-revision is the only one that does not.

This contradicts what the server tells every client about itself, in src/server.ts:24:

Reads that exceed a per-call cap return a truncation marker describing what was returned and how to fetch the rest.

Measured

Against en.wikipedia.org, page Salt, revision 1363477261, wikitext size 75222 bytes, with the default MCP_CONTENT_MAX_BYTES of 50000:

call	bytes returned	truncation marker
get-page { title: "Salt", content: "source" }	50514	yes — lists the page's sections and a remedy hint
get-revision { revisionId: 1363477261, content: "source" }	75348	none

Same content, same wiki, same call. Salt is a middling article; the largest are several times that, and the gap grows with the page.

Why it matters

A caller that hits the cap on get-page and follows the documented workflow is protected. A caller that reaches the same content through get-revision — which is the natural route when it already holds a revision ID from get-page's metadata, from get-page-history, or from a previous edit's response — gets the whole thing with no signal that anything unusual happened.

The consequence is a context window spent without warning, and no truncation marker to tell the caller it should have paginated. get-page's marker is what makes the large-page workflow discoverable; get-revision offers no equivalent, so a model has no cue that section-wise reading exists.

There is a second-order effect worth naming, because it may be the reason to leave this alone: get-revision is currently the only way to obtain the full source of a page larger than the cap in one call. Capping it closes that route. Whether that route is a feature or an accident is the decision here — it is not documented as either.

Options

Not picking one.

1. Apply truncateByBytes in get-revision, with a truncation marker matching the other readers. Consistent with the advertised contract. Removes the only single-call route to an oversized page's full source, which some caller may be relying on.
2. Cap it, and add an explicit opt-out so the full-source route stays available deliberately rather than by omission.
3. Leave the behaviour and correct the contract in src/server.ts, naming get-revision as uncapped. Cheapest, and honest, but it leaves an unbounded read on a tool a model reaches for routinely.

Related

Turned up while writing #536, which describes editing a section larger than the cap. get-revision's uncapped read is one of the escape routes from that problem, so options 1 and 2 here interact with it.

---

_{AI-authored — Claude Code, Opus 5 1M (ultracode); found while verifying a claim for #536 and written up at @alistair3149's request; not human-reviewed; the file:line references were read on master at 8fa0cff and the byte counts measured by driving the built server against en.wikipedia.org over stdio.}