[nissa-seru]

A tool result's content array went to the model, and to the agent's history, as the whole array's JSON whenever one of its blocks was one the tool-result lane didn't recognize. For example, [text, audio] was stored and sent as [{"type":"text",…},{"type":"audio","data":"<base64>",…}]. That put into the agent's context:

• inline audio's base64, with a media type or without;
• an image's base64, when it had no media type;
• the uri of a block of a type the host doesn't know, such as video, a signed URL's signature included;
• any native image in the same array, as base64 text instead of an image.

The push lane shows each of these blocks as a marker, or inline audio with a media type as audio. With this change the tool-result lane shows each block on its own too, in both copies of the result: the text history stores and the content the model reads when the result is answered.

What changes

Each block of a content array is one of:

• itself: text, or an image with data and a media type, which the live copy sends natively and the stored copy shows as its [image: …] placeholder;
• a reference's stub, or a link's own line, for some links the host can't fetch (below);
• inline data withheld for a contradiction;
• a marker saying what the block was and why it isn't shown.

The markers are the ones the push lane shows. Inline audio has one of its own, because this host's tool results carry only text and images: [Audio not shown: this host's tool results carry only text and images (audio/wav, ~3KB).]. One function, toolResultBlocks, classifies each block for both copies, so they read each block alike.

The live copy of a result with an image sends the image natively beside the other blocks, as before: each text block cut at the cap, and each reference's stub and withheld line whole. Its links and markers go too while they fit the cap together. Past that, the live copy is the stored text, cut at the cap, as a result holding a link or inline audio was before. So no number of links and markers carries a result past the cap.

Which arrays are content. A protocol result's content is content whatever its blocks' types. The new optional ToolResult.dataIsContent says so. The framework sets it on an MCPL tool's result, from the model's dispatch and from an in-process call, and a module that returns a content array can set it too. Any other array, such as a module's, a script's or a direct caller's that doesn't set the flag, is content only when every element is a block of one of MCP's types (text, image, audio, resource, resource_link). An array with any other element is data, written as JSON as before, so a list of records of other types isn't hidden behind markers.

MCP's resource_link is a reference, as RFC-005 §8.1 maps it. Its uri, name, mimeType and size (as sizeBytes) make the reference record, with no disposition. No uri reaches context that main keeps out of it.

• A link the host can fetch shows as a stub that offers fetch_reference, on every lane: in a tool result's content, at any depth in its data, and on the push, channel and injection lanes (convertBlock).
• What the host can fetch is an http(s) uri on the origin of a server the host dials by URL, delivered by that server and not expired. That rules out a uri with another scheme, such as file:// or a server's own; a uri off its server's origin; an http uri from a server dialed over a secure connection; a reference from a server with no address, such as a stdio one, or from a server the host doesn't know; and a module's link, which no server delivered.
• A tool result's link the host can't fetch shows its name, uri and type, as [resource link "report.csv": file:///…/report.csv, text/csv; not fetched]. That's how feat(mcp): modern MCP (2026-07-28) servers beside MCPL, over stdio and Streamable HTTP #262 shows a standard MCP server's link. A tool result's JSON showed every link's uri on main, and the uri is the agent's only handle on a link the host can't fetch. RFC-005 §5 allows this (a MAY) for a reference with no disposition, which §8.1 makes every link, when the host's policy classifies it as non-capability-bearing.
• Unless its uri may carry a credential. §5's reason is that "signed URLs and query capabilities are bearer credentials that look like locations". So a link the host can't fetch gets the stub that says why, with no uri, when its uri carries userinfo or a query or fragment parameter on one fixed list, CREDENTIAL_PARAMETERS. The list covers AWS's, Google Cloud Storage's, Azure's, CloudFront's, Discord's CDN's and Backblaze B2's signed URLs, OAuth's tokens and secrets (OAuth 1.0a's too), generic names such as token, key, x-api-key, api_token and password, and a session's id (session_id, jsessionid), which is a bearer credential too. A fragment is read as a query is, so #access_token=… counts, and a ? or ; inside either may separate parameters too, as in a route kept in a fragment, #/reset?token=…, so the parameters are read both with and without them as separators, and one with a value in either reading counts. Names are compared by their letters and digits alone, so accessToken, access-token and token[] count as access_token and token do. Only a parameter with a value counts, since a credential is always a value, so a docs link to an anchor such as #token shows. A parameter's value that is itself a uri is read the same way: an absolute one, as an image proxy's ?url= holding a percent-encoded signed URL is once decoded; a protocol-relative one, or a relative one with a query or fragment, as a login's ?next=%2Freset%3Ftoken%3D… is; and one encoded again inside the value, as a redirector leaves it. Each read and each decode is a level, up to four, and a uri reached deeper counts too, since a bound that let the next level through would be the same gap one level down. A uri that doesn't parse, even as a relative reference, counts too, since its parts can't be read. Ordinary links with a query, such as watch?v=… or ?usp=sharing, still show.
• A data: link never shows its uri either: it holds its content rather than naming where it lies, and a link's line isn't a way for inline data to reach context. It gets the stub that says why it can't be fetched.
• On every other lane, a link the host can't fetch gets the stub that says why, with no uri. No lane but a tool result's showed a link's uri on main: the push, channel and injection lanes showed a link as an unknown block.
• A link is registered with the server that sent it, but never fetched eagerly (autoFetchReferences), nor on a script's demand, because a tool's links are what it offers to follow, and fetching them would spend the server's fetch budget on bytes nobody asked for. A uri a link names is fetched only when a block of the result that isn't a link names it too.
• A link's testimony never replaces a reference's in the registry, since a link claims no digest, expiry or disposition. A later link to a uri can't lift a reference's expiry or its digest check.

A stub's promise is the fetch's own check. Which server a fetch dials, and whether it may, is one pure function, dialCheck, of the reference's record and the addresses its servers are dialed at. It's the fetcher's pre-dial check from #518, moved into references.ts, with dialServer as its server part. A resource stub asks it too, so a reference whose server or expiry stops a fetch now says why, where it offered fetch_reference. The stub reads an expiry with its result's claims, where the fetch reads the record alone, so where one result names a uri both expired and fresh, the stub says expired while a fetch can succeed ("One reading of a result's claims", below). Examples are a stdio server's reference, one off its server's origin, or one with a scheme the fetcher refuses. A fetch's own limits, a spent budget or a claim over its ceiling, still apply when it's made, as before.

• The fetch reads its own framework's configs. It checks a uri's origin against the address in the same config its token comes from, as fix(mcpl): a reference from a server with no address says so when refused #518 checked it against the binding the token came from. So a server's token goes only to the origin its own config names.
• The stub reads the reference registry, where each framework records the address of each server it configures, since the code that makes a stub can't reach its framework. The registry keeps each framework's entry for an id, with the latest one in force. A framework that removes a server takes back only its own entry, and one that stops takes back all of its entries and records them again when it starts.
• Where two frameworks share a server id. In a process with one running framework, or with running frameworks that agree on each id they share, the stub and the fetch read the same addresses, so a stub promises what the fetch does. A stopped framework's addresses leave the registry. Its stubs then read another running framework's entry for the same id where there is one, and otherwise say its servers are unknown, while its fetcher, which keeps its configs, can still dial them until it starts again. Where two frameworks configure one id differently, a stub's words can be wrong for the other framework's fetch, but a token still goes only to its own config's origin.
• A stub's words. A stub ends with the clause fetch_reference's refusal gives, in its own words where the clause would name the uri's parts, and never with the remedy. A third-party origin in a stub doesn't name the origins, and a refused scheme doesn't name the scheme, though fetch_reference's refusal names both. A server's id is bounded and stripped of controls, as a label is, in a stub and in fetch_reference's refusal alike. So no stub ends with a refusal longer than a saved copy's path, the longest ending a stub has, and a stub stays within REFERENCE_STUB_MAX_CHARS. fetch_reference's own refusal can be longer, since it names the origins. save_recent_image counts a stub line as an image slot only up to that length.

An empty uri beside inline data is no link. This completes the rule that #506's comment leaves open. Inline data beside uri: '' is now plain inline data on every lane, and a link that isn't empty still withholds it.

What callers will notice

• A block the tool-result lane can't show now reads as its marker in both copies, where it sent the whole array to JSON. Any other block in the same result now shows as itself, and an image stays native while the result's links and markers fit the cap together. Past that, the model reads the stored text, cut at the cap.
• A tool result's link, from an MCPL server or a module. A standard MCP server's result is read as feat(mcp): modern MCP (2026-07-28) servers beside MCPL, over stdio and Streamable HTTP #262 reads it, its links' uris shown as sent:
  • One the host can fetch shows as a reference stub, with its name, type and size and fetch_reference, where today it showed its uri in the JSON. fetch_reference returns its content.
  • One it can't fetch whose uri can't carry a credential shows its name, uri and type in a line of its own, where today it showed them in the JSON.
  • One it can't fetch whose uri may carry a credential shows a stub that says why it can't be fetched here, with no uri. Today its JSON showed the uri. So an agent no longer sees such a link's uri, such as a presigned storage URL, a URL with user:pass@, one with a token in its query or fragment, or one holding such a URL percent-encoded in a parameter's value, and has no other handle on it here. This is intended, since RFC-005 §5 treats such uris as bearer credentials. A data: link, whose uri is its content, shows the same stub.
  • One whose uri a reference marks disposition: never, any reference in the same result, or, where no reference in the result names the uri, the host's latest record from an earlier one while it keeps it, shows the same stub, with no uri, where today its JSON showed the uri. RFC-005 §5 removes such a uri unconditionally.
• A link on the push lane showed as an unknown block, [Content not shown: this host can't display "resource_link" content.]. Now it shows as a stub where the host can fetch it, and as the stub that says why where it can't, never with its uri.
• A resource stub says why a fetch would be refused, where its server or its expiry stops the fetch. Before, it offered fetch_reference, and that fetch was refused: a stdio server's reference, one off its server's origin, one with a scheme the fetcher refuses, or one from a server the host no longer knows.
• save_recent_image counts a fetchable image link's stub as an image slot, a failing one, as Truncation adds back every reference-stub-shaped line past the cut, so a text result can be stored far over the inline cap #403 counts every reference's stub that names an image type. So where a result's newest image is such a link, index: 1 refuses and says to fetch it with fetch_reference, where before it saved an older inline image, since the link was JSON and no slot.
• A label (a name, a type, a server's id, a provenance or a saved path) loses any line or paragraph separator (U+2028, U+2029), as it loses control characters, so none starts a line of its own.
• A script's demand fetch registers each reference first, so a re-issued reference's digest and expiry replace an earlier link's or reference's claims before the fetch reads them, as on every other path, while the record isn't fetched yet.
• A script that calls an MCPL tool reads, in its result's text block, the same text history stores, now with markers, stubs and links where it read the array's JSON. That JSON gave it inline audio's base64 and an unknown block's uri.
• A script's structured result, from an MCPL tool or a module, gives a link as a reference object. An MCPL peer's link was the unknown-block notice there, and a module's link was its fields, its uri among them. The object carries uri where the model's line for the link shows it. A reference the fetcher would refuse carries unfetchable, the words a stub gives, which say why a fetch_reference with the object's refId would be refused, as the result's references claim it. So does a reference a module made itself, bound to no server. A link whose line shows its uri carries it too, since the line has no id to fetch with. A link the script lane made into its object, given to the script lane again, reads the same, where sanitizeLabel left its uri as it was.
• A script's structured view reads the claims of every reference it shows, those nested in a block's fields included. So a disposition: never nested in one block withholds that uri from a link anywhere in the view, where the model's line, which shows a block and not its fields, can still show it. A link's object carries its uri only where the model's line for the result shows it, by the claims that line reads and the uri's record as that line leaves the registry, before the script lane's own registrations, so a script never sees, through a result's blocks, a uri the line withholds, within 2,000 references in one result (past that, under Not covered); structured content reaches a script as sent, as on main. Reading more claims can loosen as well as tighten, since an expiry makes a link one the host can't fetch, whose uri the line shows. Where the walk of those claims stops, at a value too deep to convert or one that answers differently when read again, the view isn't written: a peer's result is one the script can't convert, and a module's is a failure naming the tool. A script reading a result's text meets the same failure, so on both of its routes isError says nothing could be shown.
• A result's data that can't be read through, or shown once it has been, shows the model [Result not shown: the tool ran, but its result couldn't be read through, checked for references and shown, so this host withheld it.], in the copy sent and the copy stored alike, and the round goes on, with a log line naming the tool and the error. Before, it was shown with none of its references' claims where the walk that reads them stopped and the render's didn't, or, for data no JSON can hold, such as a cycle or a BigInt, a getter that throws, or data too deep, the serializer threw. A module's results reach this only past the dispatch's own conversion check, by depth, since that check is a plain JSON.stringify and the render's walk takes more stack; a host passing such a result to the Agent class directly gets the notice where it got an exception, with the tool-result guard off, and with it on, its archive of the result, and the fields it keeps of a result it withholds, still throw, as on main, as does an error result whose own error field can't be read.
• A uri inline data marks disposition: never beside its data, which is withheld, is withheld from every other block of the result too, such as a link naming it, as a reference's never is (RFC-005 §5). Its other claims, such as an expiry, count for nothing, since they could loosen.
• Inline data beside an empty uri reaches a script as sent, from an MCPL peer as from a module. 0.26.1 and 0.26.2 gave a script an MCPL peer's as the withheld notice. An empty uri carries nothing a credential could ride on. Beside a disposition, a reference's claim, it's still withheld, at the top and nested.
• A script's demand fetch passes over links, and over a uri the claims of everything the script's view shows give an expiry that counts, nested fields included, for a module's result and an MCPL peer's alike. Where the walk of those claims stops, nothing is fetched for the view, which isn't written.
• Inline data beside an empty uri is shown on every lane the model reads, where it was withheld as data that also claimed a link.
• An image whose data or media type is an empty string shows its marker on the tool-result lane, as on the push lane. Before, it was sent to the model as an image with that field empty.
• A module's array now shows its blocks this way when the module sets dataIsContent, or when every element is one of MCP's types, as above. One that does neither is written as JSON as before.
• A link that names no uri, nested in data, shows its fields on every lane, as main shows every link nested in data: they hold no uri RFC-005 governs, though a value in them, such as an untyped object's uri, is data as anywhere else. A link naming an empty, null or non-string uri is its marker at depth. A block of a content array naming none is its marker on the model's line; a script's view of a module's array shows its fields, which hold no uri, as module data reached a script on main, and as the script lane's own object for a link whose uri it leaves out is left when a module hands it on.
• A peer's link that names a sizeBytes and no size (or a null one) is labelled with it, on every lane; MCP's size, where a link names one, still decides.
• A result already in history keeps the text it was stored with.

What each part is for

• toolResultBlocks and toolResultBlock (tool-result-history.ts) classify each block once, for both copies.
  • Before: the stored copy (tryHistoryStringFromContentArray) and the live copy (tryNativeToolResultContent) each branched over the block kinds, in parallel loops. The live copy's shown ranges depend on the two agreeing.
  • What it buys: one place for every block rule, which the stored copy, the live copy, a script's text and the direct API's messages all read.
  • What it costs: an exported function and its type, in place of the two loops' branches.
• goesNative (tool-result-history.ts) decides for both copies whether the live copy goes as native blocks: only when the result holds an image and its links' blocks and markers fit the cap together. A link's block has a kind of its own, link, so it's counted apart from a reference's stub.
  • What it buys: links and markers can't carry a result past the cap, where a result holding a link or inline audio went as the capped stored text before. The stored copy keeps only the image slots the live copy showed, since both copies ask one function.
  • What it costs: a function, a block kind, and a rule with an exception to explain: a reference's stub and a withheld line still go whole beside an image whatever their length, as Truncation adds back every reference-stub-shaped line past the cut, so a text result can be stored far over the inline cap #403 designed.
  • Not taken:
    • One budget for every block sent whole, stubs and withheld lines included. An image beside stubs that pass the cap would then go as the stored text. That changes Truncation adds back every reference-stub-shaped line past the cut, so a text result can be stored far over the inline cap #403's design for small caps and for many stubs, which three of its tests pin.
    • One cut shared by both copies, so the live copy carries exactly the stored copy's text. That would also bound several large text blocks beside an image, which main cuts one by one, but it changes the cap for results this change doesn't touch.
• ToolResult.dataIsContent classifies by where an array came from, not by its shape, when that's known.
  • Without it, no rule can tell an MCPL server's [text, video] from a module's list of typed records.
  • Kept by checkedToolResult: it's a flag there beside success, isError and endTurn, read by name and for its truth. So it survives the copy the admin puppet stores its pair from, and the puppet stores what a model's call does (its doc says its storage "byte-follows the ordinary path").
  • Not taken: a mark on the array object, in a WeakSet, with no new field. The puppet builds its stored copy from a JSON copy of the in-process result, so a puppeted MCPL call would have stored JSON where a model's call stores markers.
• The rule for an array without the flag, every element one of MCP's five types, keeps the fix for a module's array of MCP blocks, such as audio from an in-process tool, without hiding a list of records of other types.
  • Not taken: keeping today's rule (every element shown as itself) for these arrays. Once an empty link beside data is no link, audio data beside uri: '' in a module's array would go from withheld to JSON with its base64.
  • The miss it leaves is under "Not covered".
• The audio marker's type and size tell the agent what came back and how big it was, as an image's placeholder does.
• The resource_link case in classifyBlock is RFC-005 §8.1's mapping, in the one classifier every lane uses.
  • convertBlock's case gives the push lane the same treatment, and showsAsItself's lets a render result carry a link, as a resource.
  • governedByRfc005's line keeps a fetchable link's uri out of data at any depth, as a resource's is.
  • fromLink on the testimony marks a link's, so the registry never lets it replace a reference's claims, and the eager fetch and the script's demand fetch pass it over.
• The unfetched link's line, and StubOptions.unfetchedLinkUri, keep the agent's only handle on a tool result's link the host can't fetch, where main's JSON showed it. The option is the tool-result lane's alone, so no other lane shows a link's uri.
• uriMayCarryCredential and CREDENTIAL_PARAMETERS keep a link's uri out of context where it may be a bearer credential. The list sits in one place, with an example of each family.
  • Not taken: fetchability as the test, showing every link the host can't fetch. A presigned URL off its server's origin can't be fetched either, so it would reach context, on the push lane for the first time.
  • Not taken: hiding every uri with a query or fragment. That would hide the ordinary links agents use most, such as watch?v=… and ?usp=sharing, to catch the few that carry a credential.
  • Not taken: showing the uri of a resource reference, or of a link on another lane, that the host can't fetch. main hides both, so a credential the list misses, such as a token in a path, would reach context for the first time.
• dialCheck, with dialServer its server part, gives a stub and a fetch one check. The fetch runs it on its own framework's configs, and a stub on the registry's addresses. fix(mcpl): a reference from a server with no address says so when refused #518's eager check joins a fetch under way with dialServer alone.
  • The registry's addresses, kept per framework, are how a stub reaches the addresses at all.
  • The fetcher's credential and limits come from the same resolver answer whose address dialCheck read, held for that check, so no second read can pair one answer's address with another's token.
  • Not taken: the fetch reading the registry too, and checking the origin against its own binding again before it dials. Its token would stay safe, but a server only another framework knows could still shadow one this framework would dial.
  • Not taken: each framework's addresses passed down every path that makes a stub, in place of the registry. That's convertBlock's callers in three lane classes, the history serializer's helpers, the guard's kept fields and the direct Agent API, and every later path that makes a stub would have to carry it too.
  • Not taken: the record-only check (no server, expired, not http(s)). It can't tell a stdio server's reference, or one off its server's origin, from one the fetcher would dial.
• One classification for both copies. The stored copy's blocks, the ones its text is made from, are what the live copy is built from (StoredToolResult.live), never classified again.
  • What it buys: a link's text depends on the registry and the clock, and the spill's write lies between the two copies. Classified twice, they could decide goesNative differently, and the live copy could show an image whose slot the stored copy didn't keep.
  • What it costs: one field carried from the stored pass to the live copy. The path with no stored copy still classifies once on its own.
• One reading of a result's claims (ResultClaims). A result's references are read as one, and the strictest claim wins: a uri any of them marks disposition: never is withheld from every block that names it, and one any of them gives an expiry that counts is expired for each. Where a reference in the result names a uri, a plain one included, the result's claims decide it: a reference is its result's word on the uri, the latest, as the registry already keeps it, so an earlier result's never or expiry gives way to it. Where none does, as for a link alone, the record's testimony from an earlier result decides. In a content array shown to the model the claims are read from its elements as the array shows them, so a reference inside an element's own fields, which the model's line doesn't show, doesn't count there, where a script's view, which shows them, reads them (scriptViewClaims); at depth they're read by the walk serialization itself takes, through toJSON and the fields of inline data. Each uri's claims are read once per result. Each block's decision reads them: a link's uri, a stub's reason, a script's object; and so do the module demand fetch and a withheld result's kept fields, each as showing the whole result reads them (resultClaimsOf), and a module's result shown to a script reads the claims its demand fetch read. Where a value stops that walk, such as a getter that throws, what the rest of the result claims is unknown, so a withheld result keeps none of its fields, as for a failed result, and the result itself isn't shown with fewer claims: the model gets the unchecked notice and a script a failure naming the tool, below. Across results the registry keeps the latest testimony, as before, for a record not yet fetched; a fetched record keeps the testimony its saved copy was verified against. So a never from an earlier result holds for a link while the registry keeps its record and no reference in the result names the uri.
  • What it buys: a result means the same whatever the order of its blocks, and whatever the registry evicted while it was read. A never keeps a uri out unconditionally, as RFC-005 §5 asks, and the module demand fetch passes over an expired uri as autoFetchReferences already did.
  • What it costs: one optional parameter through buildReferenceStub, shownLinkUri, dialCheck, referenceBlockForScript and the serializer's options, and a second walk of a result's data at depth, which calls its values' toJSON and getters a second time. Desmond-2579 measured that, at an earlier head of this change, at 1.7 to 2.1 times main's time for a 4 MB result of 10,000 records, and too little to notice at the usual few KB. A value that answers differently the second time can claim what the shown text doesn't show, or show a reference the claims never read; only the direct Agent API's results can, since a module's result is parsed JSON from its dispatch and a peer's blocks parsed wire JSON.
  • Not taken: registering every reference before showing any. Each block registers its own testimony again as it's shown, so a link read whichever reference came just before it. And a never could be evicted from the bounded registry before its link was shown.
  • Not taken: latest-wins within a result. A plain reference later in the result would lift an earlier never.
• The fetcher reads each server's resolution once per check, so the address the origin check passes and the token the fetch sends come from one answer, whatever a resolver answers the next time.
• One clock reading for each script object and each stub, passed to every check it makes (shownLinkUri, referenceExpiry, unfetchableReason).
  • What it buys: an object's or a stub's words can't disagree with each other across an expiry, such as no uri beside expired for a link that was fetchable a moment before.
  • What it costs: one nowMs passed to three calls that already took it.
• A script's object says why its refId would be refused, expired as feat(mcp): modern MCP (2026-07-28) servers beside MCPL, over stdio and Streamable HTTP #262 has it and unfetchable where the fetcher would refuse, a link whose line shows its uri included. It costs no rule of its own: both words come from what the stub reads. The fetch itself reads the record, which keeps the latest testimony until it's fetched, so where a result names one uri both expired and fresh, the words say expired and a fetch can still succeed.
• shownLinkUri (references.ts) decides whether a link shows its uri, for a tool result's link line and for a script's object alike.
  • What it buys: a script, whose output comes back to the model, holds what the model's line holds. Two copies of the rule could drift, and the drift would be a credential hidden on one lane and shown on the other.
  • What it costs: one exported function. The object's unfetchable reads unfetchableReason, the stub's own source, so it costs no rule of its own.
• The empty-link line in classifyBlock completes fix(mcpl): a failed MCPL request, the framework's refusals of an MCPL tool call, and the blocks the host can't show say what happened in the agent's words #506's rule now that every inline shape has a marker. The script lane's '' read as no uri (referenceBlockForScript) carries it to scripts, where the lane withholds inline data beside a uri of any other value, since a script reads every field and an object can carry a credential.
• scriptViewClaims gives a script's view the claims of everything it shows, nested fields included, as claimsInHistory's walk reads them, less an MCPL peer's top-level block the classifier rejects, whose fields the view doesn't show. shownToScript and shownToScriptFromServer pass them to every object the view makes. Without it, a nested never the script is shown as a stub would leave a link to the same uri its uri.
• Failing the view closed where that walk stops keeps the treatment from running without claims. Its own walk carries other replacers, so at a stack's edge their depths can differ by a frame; a value whose toJSON or getter answers differently when read again would stop one and not the other too, though a module's result reaches the script lane as parsed JSON from its dispatch, and a peer's as wire JSON, so for them the stack is what's left. Either way a link would fall back to the record's testimony, its own. A peer's stop is a RangeError, a result the script can't convert, or a fault, which fails the dispatch, as for the round trip; a module's is the script's failure, with no fetch made. A script's text route renders through the serializer, whose own claims walk throws where it stops, so a stop there is the same failure (a script meets one rule on both routes, and a failure there wedges nothing).
• The unchecked notice on the model's lane (UNCHECKED_RESULT_TEXT) answers the same stop in historyJson. The model's lane has no failure that doesn't wedge the round: a throw there goes uncaught from handleProcessEvent's ready branch, leaving the round's results unstored and unsent. A notice of its own, since INLINE_WITHHELD_TEXT's reason would be false here.
• The line's claims for a link's uri on the script lane (referenceBlockForScript's line) keep a script from seeing a uri the model's line withholds; without them a nested expiry, which the view reads and the line doesn't, made a link one the host can't fetch, and so showed its uri to the script alone.
• The peer's demand fetch reading the view's claims (autoFetchReferences's claims) makes one rule on both routes: a nested expiry stops a fetch, and a view that can't be read fetches nothing, its references only registered. The claims are read once, at dispatch, and the script lane's reading of the same blocks takes them, or what stopped their walk, from there (SCRIPT_VIEW_CLAIMS), so the fetch and the view read the same claims; the reading reads them itself only where nothing did at dispatch.
• A contradictory inline block's never in the claims (inlineNeverUri) honours §5's unconditional removal for a uri that block names; only never counts, since its other claims could loosen.
• The nested pass leaving the top-level blocks to the treatment above it (the peer route's replacer) keeps a link's object from being read again as a link to the uri sanitizeLabel cut, which registered a second record and took the result's claims off it.
• The model lane's catch (nonErrorResultText) makes whatever stops reading or showing a result the unchecked notice, computed once for both copies, with a log line naming the tool and the error, since it can also be a fault of this host's: the lane's other answer is a wedged round. It's the lane's one catch: historyJson throws where its claims walk stops, so the depth case logs too. A script's routes call the serializer, or nonErrorResultTextOrThrow for a result with no data, directly, and fail. thrownLine gives the log the first line of what was thrown, and says so where what was thrown can't be read as text, since a throw from the catch itself would wedge the round it's there to keep going.
• The registry's journal (openJournal, ScriptLine): a script's link object decides its uri by the model's line, which reads each record as that line leaves the registry, before the script lane's own registrations. The treatment registers, rebinds and evicts as it goes, so without the journal a reference nested before a link changed what the link read, an expiry or a plain reference that clears an earlier never, and its uri turned on the order of the blocks; and more references nested before a link than the registry holds evicted the link's record, an earlier never and its server binding with it. The journal copies a record the first time a registration names its uri or evicts it while the lane runs, each open its own copies, and closing it lets them go. A uri with no record before reads as the record the link's own registration makes. An MCPL peer's journal opens after the dispatch, which a model's call makes too. A module's opens after its demand loop where the model's line renders the result's blocks, a content array that isn't a failure, since the loop's registrations are then the line's own; elsewhere the line walks at depth, or shows a failure's error and registers nothing, so it opens before the loop. journalCount says how many are open, which a test reads to see that every lane closed its own, since nothing else shows a journal left open.
• The module demand loop registering links in the result's order, where the model's line renders the result's blocks, without fetching them: the registry then holds its records in the order the model's own render makes, so a registration there evicts what that render's would, and a script reading a module's result as text, which renders against the live registry, decides each link's uri as the model's line does. Skipping links, the loop's registration of a later reference could evict, in a full registry, the record of a link before it that the model's render keeps, an earlier never with it. isContentArray is exported for it, so the loop's decision and the model's render read one predicate, with the flag coerced as the render coerces it; a change to what counts as content then moves both.
• The dispatch reading a peer's view claims only where a view is written (structuredContent, reading()'s own condition): a script reading the model lane's text has its demand fetch pass over what each top-level block's own expiry marks, as a model's call does, so a reference nested in a field the text never shows can't stop the fetch of a top-level link's reference the text offers.
• Finding a never by the text a link shows (shownUri, neverShown): a link shows sanitizeLabel's cut, made well formed as every copy is before it's shown, so a never on a uri has to withhold every link in the result that shows the same text; without the well-forming, a link with a lone surrogate would be matched against text no copy shows, and a never on the U+FFFD form would miss it. Every other claim is about the record, which the fetch reads by its raw uri, so it stays keyed by the raw uri: an expiry on one uri says nothing of another that cuts alike. The set of withheld texts is read once per result's claims. resultClaims keeps one entry per raw uri, made the first time an inline never or a reference names it (its entry).
• The tests' helpers: testimonyOf makes a testimony as the classifier reads a block, and fillAfter fills the registry with 1,999 records after a uri's, so its record is the oldest of a full registry, which an eviction case needs and no smaller fixture reaches; ScriptAnswer and answerText read main's one answer shape for a script (scriptResultAnswer); permutations runs a result's blocks in every order, for the claims' "whatever the order"; demandFetch drives a module's demand fetch with a fetcher that records its calls, and NOT_MADE_EXPIRED matches the line it logs for an expired uri it passes over.
• governedByRfc005 governing a link that names a uri, of any value, keeps an empty, null or non-string one its marker, and leaves alone the object the script lane makes of a link whose uri it leaves out, so a script's view given it again doesn't turn it into a notice. A link naming no uri is data, as on main. The classifier reading a link's size from sizeBytes too, the object's name for it, keeps the object's size when it's given again.

Not taken:

• Saving inline audio to the workspace and naming the file in its marker. That's new behaviour beyond showing what came back, and no caller has asked for it.

Merge order

This builds on main at 8ec1de5a, merged in. Since this branch's last merge of main, at 00eb87a8, main changed the same code in four places, and the merge keeps each beside this change's reading:

• A lone UTF-16 surrogate in a tool result's text block is sent raw, while its stored copy has U+FFFD #695 and fix(tool-results): send a string result as its text, not JSON-quoted #698: a tool result's text reaches membrane well formed, a lone surrogate as U+FFFD, and a string result is kept as text. Each block toolResultBlocks gives is made well formed, a stub's labels and a link line's uri included, so the copy sent and the copy stored carry the same text. A text block whose text isn't a string is the converters' placeholder, a marker here.
• fix(tool-results): keep a spilled result's pointer within every reader's cut #669's readers' bound: a turn's results stored by their shares keep each one's live blocks beside its stored text (StoredToolResult.live), so an image result still goes natively at the cap.
• The script lane (fix(code-execution): a module's blocks reach a script with RFC-005's treatment, as the model reads them #755, fix(code-execution): what's nested in an MCPL peer's structured blocks reaches a script with RFC-005's treatment #767, fix(code-execution): the script lane's round trip catches only a RangeError, and any other fault fails the dispatch #781), which now answers every tool in one shape, treats a module's blocks at every depth, and treats what's nested in an MCPL peer's blocks:
  • each route's objects read the claims of the whole view (scriptViewClaims);
  • a module's demand fetch reads them, or the model's text's, before it fetches;
  • the text a script reads takes dataIsContent and those claims.
  • Ada-1017's two calls change what 0.26.1 and 0.26.2 give a script, as "What callers will notice" says: inline data beside an empty uri from an MCPL peer, and a module's resource_link, which fix(code-execution): a module's blocks reach a script with RFC-005's treatment, as the model reads them #755 pinned as its fields.
• feat(mcp): modern MCP (2026-07-28) servers beside MCPL, over stdio and Streamable HTTP #262's fragment was released, so what this change had added to it, a link's uri where its line shows it and unfetchable, is in this change's own changed fragment.

Tests

test/tool-result-blocks.test.ts:

• every block the lane can't show, as its marker in both copies, alone and beside a native image, audio with empty data among them;
• a text block cut at the cap in the live copy, with its marker shown whole;
• an image beside link lines that pass the cap together, which goes as the stored text cut at the cap, while one such link still goes beside the image, and thirty through a model's round, the image's placeholder keeping its ledger ref, and with the image after them, its slot not kept past the cut;
• an image beside audio markers that pass the cap together, which goes as the stored text too, while two still go beside the image;
• an image beside reference stubs, or stubs and withheld lines, past the cap, which still goes as blocks;
• the content rule with the flag and without it, and the flag read for its truth;
• resource_link's mapping;
• a link the host can fetch as a stub, in a content array, at any depth and on the push lane; one it can't as its line in a tool result, where its uri can't carry a credential, with plain links that have a query, and as the stub that says why where it may, with a uri from each family of the list; and one it can't as that stub on the push lane;
• a render result's block check;
• a link's testimony never replacing a reference's claims;
• a link's registration with no eager fetch or script fetch;
• each refusal a stub gives, and the fetcher's own check agreeing with it, with a server's id bounded and a refused scheme unnamed in a stub;
• two frameworks that configure one id at two urls: neither fetch dials the other's origin, and a removal takes back only its own address;
• a server url that doesn't parse;
• five links through a tool result's line and a script's object, which agree on each link's uri and each stub's reason;
• a disposition: never anywhere in a result withholding its links' uris in every order: in a content array, at depth, inside inline data's fields, in a script's object, and past more references than the registry holds;
• an expiry any reference in a result gives a uri read for every block that names it, whatever their order, and the module demand fetch passing over it;
• claims read through toJSON, as serialization reads, and nothing registered that serialization never reaches;
• competing expiries of all three kinds worded by EXPIRY_REASON's order, in every order of the blocks;
• a result's own references to a uri deciding over what an earlier result left: a fresh expiry over an expired one, and a plain reference lifting an earlier never whether the link or the reference comes first, while a link alone leaves it;
• a reference inside an image's _meta counting where showing descends into it, at depth, and not in a content array, which shows the image alone;
• the module demand fetch reading claims at depth, with a fresh control, and not reading a content array's unshown block;
• a withheld result's kept fields shown as the whole result claims them, and none kept where a value stops the walk of its claims;
• a result's data read once without a stored copy, natively and as text;
• a link with an empty or non-string uri at depth, shown as its marker, never its fields;
• the live copy built from the stored pass's blocks, never classified again, handed over through the stored pass itself, and the cap's exact boundary with and without a stored copy;
• the fetch's token and the eager check's limit each from the answer whose origin its check passed;
• an MCPL send whose result holds a null element before its channel's id;
• a result's own dataIsContent read whatever the options say, each credential parameter alone, an audio marker's bounded type;
• a script's object for a link whose line shows its uri carrying why its refId would be refused, one clock reading for each object and each stub, the resolver asked once per check, and an MCPL result with a null element shown as its marker;
• a server connected at runtime recording its address (mcpl-runtime-lifecycle);
• a link whose uri a reference withheld with disposition never, a credential name split by a control character, and a link line holding line separators, which reads as no slot;
• a script's demand fetch reading a reference's claims over an earlier link's;
• the empty link beside data on both lanes;
• dataIsContent through checkedToolResult, a model's round, and an MCPL call from the model, in process and through the puppet, with the server's address recorded and forgotten.

Turned round for the new behaviour:

• inline audio beside text (tool-result-history);
• a resource_link's uri in data (tool-result-reference-uri);
• the empty link beside audio (mcpl-agent-words);
• a script's structured result from an MCPL peer (feat(mcp): modern MCP (2026-07-28) servers beside MCPL, over stdio and Streamable HTTP #262's script-structured-references), where a link is a reference object and an expired reference carries unfetchable.

With the merge of main at 8ec1de5a:

• script-structured-references: a nested never decides over a plain reference to its uri at the top, for a link at the top or nested, from a peer and from a module; a peer's rejected block's fields claim nothing; where the walk of a script view's claims stops and the treatment's wouldn't, the view isn't written, on both routes, and a script's text route fails, for a module's object and for a list that isn't content; inline data beside an empty uri reaches a script from a peer as from a module, and beside a disposition is withheld, at the top and nested; a nested expiry doesn't show a fetchable link's uri to a script, whose line shows none; a peer's demand fetch passes over a uri a nested reference calls expired, and fetches nothing for a view it can't read; a peer's top-level link keeps the record of the uri its result named; a treatment that fails after the claims walk read the view is a result the script can't convert (peer) or a failure naming the tool (module); the nested-never test checks the view was written, with the link's object; a nested link's uri is the same whichever block comes first, and an earlier result's never stays with the line's reading of the record when a later result's nested reference clears it; a peer's result a script reads as text has its demand fetch read each block's own claims, as the text does; the view reads the claims its dispatch read; inline data's expiry claims nothing for a fetchable link to its uri; an expiry on one uri says nothing of a link to another that shows as the same text; a module's result with no data and an error that can't be read fails the script; a link's uri reads its record as it stood before the script lane registered anything, through an eviction 2,001 nested references make, from a peer and from a module, and a module's nested link keeps an earlier result's never whichever block comes first; an earlier result's never on one uri doesn't withhold a link to another that shows as the same text, where the model's line shows it; a never nested where only the script's view reads it withholds a link that shows as the same text.
• mcpl-reference-fetcher: a registry journal keeps each record as it stood when it opened, through a change of testimony, a second server and an eviction, two journals opened at different times each with their own copies, and a closed one copies nothing more.
• tool-result-blocks: data whose claims walk stops shows the unchecked notice, and a round with it stores and sends the notice alike; the model's lane shows the notice, with a line naming the tool, for a content array's block whose text can't be read and for a render that stops after the walk, where the serializer throws for a script; a uri inline data marks never is withheld from a link naming it, in a content array, at depth and in a script's view, and an inline expiry counts for nothing; a link's size is MCP's size, a size of 0 included, and sizeBytes only where it names none; a never withholds a link whose uri shows as the same text once a bidi control is cut, or once a lone surrogate is made U+FFFD, the mark or the surrogate on either side; the model's lane shows the notice for a result whose data, error or content flag can't be read, and logs a value thrown that can't be read as text; data whose claims walk stops throws for a script and shows the notice, with a line naming the tool, in a round's stored and sent copies; a result's native live copy survives its turn being stored by shares; a link naming no uri shows its fields, and the script lane's own link object, given again, reads the same.
• Turned round from this change's own: a cycle in a result's data shows as the unchecked notice, where main's serializer threw, and nothing past it is registered.
• Turned round from main's tests: a module's resource_link reaches a script as a reference object (fix(code-execution): a module's blocks reach a script with RFC-005's treatment, as the model reads them #755 pinned its fields); a module's reference made with no server carries unfetchable; a module's demand fetch passes over an expired reference; inline data beside an empty uri from a peer reaches a script as sent (fix(code-execution): what's nested in an MCPL peer's structured blocks reaches a script with RFC-005's treatment #767). main's script-lane tests read the link at the treated blocks' eighth place as a reference object, and fix(tool-results): show each block of a content array, never the array's JSON #527's own script tests call scriptResultAnswer, main's exit.

mcpl-reference-fields, mcpl-reference-binding and save-recent-image now configure their servers as the framework does, and script-structured-references' harness records its peer's address as configuring one does, so the registry knows their addresses. save-recent-image's check that a stub stays within REFERENCE_STUB_MAX_CHARS now takes each refusal before a dial at its longest.

Checks

At 3bdc67097's tree, which merges main 8ec1de5a, on Linux with Node 24.22.1:

• tsc --noEmit and the build are clean.
• npm test, CI's command, passes 7,126 of its 7,170 tests. The 44 it skips are tests for a disk that folds case or Unicode forms, which skip on this disk, and one that needs context-manager 0.20.0, which CI doesn't install. CI's three files that run without force-exit pass 132 of 132, and tool-result-blocks passes 77 of 77.
• Removal: each of this change's 98 variants, each taking out or loosening one piece of it, fails at least one test, those the merge and its rounds moved rewritten to apply to the code as it now stands. Of 76 variants of the merge's own pieces and of the fixes since the maintainer's review, 75 fail a test: the script view's claims and where their walk stops, on both routes, and the dispatch keeping them for the view, only where a view is written; the line's claims for a link's uri, and the registry's journal behind its records (a copy for each open, a copy at an eviction, servers copied, closed on each route's ways out, the record a link makes for a uri new to the registry); on a module's route, the demand loop registering links in the result's order and the journal opening after it only where the model's line renders the result's blocks, a content array by its elements or its flag that isn't a failure, and before it elsewhere; a never found by the well-formed text a link shows, and an expiry by the raw uri; the peer's demand fetch reading the view's claims; the text lane's throw where its claims walk stops and the model lane's one catch, its log line, and its reading of the result's own fields; a script's failure for a result with no data; an inline never; the empty uri; the link object left as it is; the nested pass leaving the top-level blocks alone; the live copy kept beside a stored copy cut by its share; a uri in a parameter's value read for credentials, as an absolute uri, as a relative one by its form as the parser reads it against one fixed base, or decoded once more, leniently, each a level, four levels deep; a value past the bound that would still decode withheld; a protocol-relative value that doesn't resolve withheld; and a data: link's uri never shown, in any letter case. The one that passes holds back the blocks nonErrorResultText hands its caller until the text is made: after they're made only the text's join is left, which throws only for a text past the runtime's longest string, which no test can build. neverShown's cache has no variant: it bounds the work of finding a never, which no test can see.
• Red-first: with main's src and this change's tests, 69 of tool-result-blocks' 77 tests fail. main's tool-result-history was given the notice's text, which it never returns, and a scriptViewClaims that throws, so the file loads. Of the 8 that pass, four are controls that pin behaviour this change keeps. A fifth passes on main because main wrote the whole array as JSON, which keeps no slot either. Two pin one resolver answer per fetch check, which main's fetcher already gives. The last pins that a module's demand fetch fetches a uri only an unshown block marks expired, where main fetches every reference on demand. script-structured-references fails all 53 of its tests on main at their setup, since main's registry has no setServerAddress, so its red-first says nothing.
• With today's main: 3bdc67097 merged with main at 689bfc61, cleanly, passes 7,302 of the whole suite's 7,346 tests, skipping the same 44.

Not covered

• A module's list of records that all carry MCP's type names, such as [{ type: 'image', url }], reads as content, and shows a marker where it showed JSON. By our reading, no module in agent-framework returns one.
• This host can't read an MCP resource by its uri (resources/read), so a link with a uri the fetcher refuses can't be fetched here. In a tool result it shows its uri, where the uri can't carry a credential (above).
• A credential the list doesn't name, or one carried in a path, such as a webhook's https://discord.com/api/webhooks/<id>/<token>, isn't caught. OAuth's authorization code, ?code=, is one such name: ordinary links use it, and a code is single-use and needs the client's secret or PKCE verifier. Nor is a credential in a uri nested in a parameter's value in any form but those read above: absolute, protocol-relative, or relative with a query or fragment, percent-encoded, up to four levels. One carried in another encoding, such as base64, gets past. A stray % doesn't stop the reading: each value is decoded leniently, as the parameter itself was. A protocol-relative value (//, or the backslash form a special scheme reads as //) that doesn't resolve counts, as a uri that doesn't parse does, so an ordinary value starting with // whose authority doesn't parse, such as q=// note, withholds its link. In a tool result, such a link the host can't fetch shows its uri, as its JSON did on main. That's why a resource reference and a link on another lane, which main keeps opaque, stay opaque where the host can't fetch them.
• An earlier result's never lasts as long as the registry keeps its record. The registry holds 2,000 records and lets the least recently used go, so in a long-running process a later result's own references can evict that record before the result's link to the uri is read; the model's line then shows the uri, where it can't carry a credential. Within 2,000 references in one result, a script and the line agree on a module's content array. Past that, either can lose an earlier never, and a script can lose it where the line, rendering in order, hasn't yet: a script's demand fetch registers the whole array before anything is shown, so 2,000 references after a link evict its record first. Such a result's sender holds the uri already and could write it as text, so evicting its record gains it nothing; never guards against an honest re-mention. A never in the same result is read whatever the registry holds.
• A module's result a script reads as text, where the result is an array but not a content array, such as a list of records with references nested in them. Its demand fetch registers the top-level references first, while the model's render meets each nested one in its place, so with the registry full, a link nested before a later top-level reference can lose an earlier result's never on the script's text alone: the script then sees a uri, one that can't carry a credential, that the model's line would withhold. A content array is read as the line reads it, within the bound above.
• A stub in history says what was true when it was written. A server removed since, or an expiry passed, shows when fetch_reference is called, which answers with what's true then.

Not verified

• Other Node versions, by our own runs: ours used Node 24 on Linux. CI ran the suite on 3bdc67097 merged with main, on Node 22.12.0 on Linux and macOS, and on Node 24 and the latest Node on Linux, and every leg passed.

Found, not changed here

• MCP's EmbeddedResource. That's a resource block with its content under resource. RFC-005 §8.1 reads it as an ordinary inline block. An MCPL peer's tool result and a module's show it as [Reference not shown: it arrived without a link.], before this change and after it. A standard MCP server's result is read as feat(mcp): modern MCP (2026-07-28) servers beside MCPL, over stdio and Streamable HTTP #262 reads it, which this change leaves as it is.
• Several text blocks beside an image are each cut at the cap on their own, with no budget across them, before this change and after it. So together they can pass the cap, with or without a link beside them.

Who did what

Ada-1017 made the design calls. Petra-1012's reading of RFC-005 §5 set the link rule. Desmond-2579 (Claude Opus 5.5) read the change whole and each fix since, and his probe found that an anchor named like a credential, such as #token, hid an ordinary link. Three rounds of our internal review read it before it opened. A fourth, run for a change built on this one, read the commits after the third and found what 1dc2c9eaa fixes. Greptile's review found that links beside an image could carry a result past the cap. A fifth internal review then read the whole change again at 34418e2b9, after the merge of main with #262, and its fixes are in ec8809b98 through 9a4068c83. A sixth read those fixes and the merge of main at 00eb87a8, and cddaa5803 holds its fixes. A seventh read them, and 262f3489d holds its fixes. An eighth read those, and 6341f5fc0 holds its fixes. I had judged one of its findings not real, and Desmond's probe showed it was: a withheld result could keep a link's uri that a later reference in the result marked never. 125db579c holds that fix. Crispin-2406 (Claude Opus 5.5), #262's author, gave the reason that settled a script's object: what a script prints comes back to the model. Cordelia-2434 (Claude Opus 5.5) built the merge of main where #531 meets this change, and the test that pins its server-id clauses, and I read both. I built and tested the rest.

I merged main at 8ec1de5a, and Ada-1017 made the calls where it meets the script lane main rewrote since. Tabitha-2467 (Claude Opus 5.5) and Desmond-2579 read the merge and each commit after it, neither having built any of this change. Tabitha found that a stopped claims walk let the treatment run without claims, on the script lane and then on the text lane. Desmond traced what a throw there would do to a round, and his run showed the notice also replaces what main's serializer threw on.

slimepriestess's review at 17633af71 found a listed credential percent-encoded in another parameter's value, a data: link's payload in its line, and ?code=. Tabitha-2467 and Desmond-2579, reading each fix, found the shapes the fixes still left: a uri encoded twice inside one value, a relative value, a stray %, a relative value that doesn't resolve, a uri that can't be a base, and a lead the URL parser trims. Ada-1017 made each call, and stopped the series of encodings there.

---

• Changelog fragments added: changelog.d/tool-result-blocks.fixed.md, changelog.d/tool-result-blocks.changed.md and changelog.d/tool-result-blocks.added.md

Written by Beth-2709 (Claude Opus 5.5).

Description checked and posted by Lottie-2661 (Claude Opus 5.5), its revisions at 59b1bef0c and 125db579c by Fiona-2757 (Claude Opus 5.5), and its revision at 17633af71 checked by Lottie-2661.

🤖 Written using Anthropic's Claude Opus 5.5 through the Rookery's tooling, and posted from the shared nissa-seru account.

[greptile-apps]

Confidence Score: 4/5

[Medium impact] The changes reach tool-result handling and reference fetching across agents that use MCPL tools.

Fix the live text cap for image results containing links before merging.

Findings

1.  Link results bypass text limits ▶

Fix with agent prompt

### Issue 1
src/framework.ts:18848-18859
An image beside a large list of `resource_link` blocks now bypasses the live result's text cap. Each link can add a 4,096-character URL, but this loop sends every reference line whole. Previously, this combination used the capped JSON fallback.

`estimateAppendedRoundTokens` still measures the cut saved text, so it can miss enough live text to send a request beyond the model's context limit. Give the native result a shared text budget and estimate request growth from the content actually sent.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

Shows protocol result arrays block by block, preserving native images and replacing unsupported blocks with markers.

• Tool results show each content block on its own.
• Resource links get safe reference stubs across tool results and other lanes.
• Reference stubs reflect the server and expiry checks used by fetches.

_{Reviews (1) · Last reviewed commit: "fix(tool-results): show each block of a ..." · Reviewed by Greptile}

[greptile-apps]

Link results bypass text limits

An image beside a large list of resource_link blocks now bypasses the live result's text cap. Each link can add a 4,096-character URL, but this loop sends every reference line whole. Previously, this combination used the capped JSON fallback.

estimateAppendedRoundTokens still measures the cut saved text, so it can miss enough live text to send a request beyond the model's context limit. Give the native result a shared text budget and estimate request growth from the content actually sent.

Knowledge Base Used:

• Tool result safety and integrity
• Tool result presentation

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/framework.ts
Line: 18848-18859

Comment:
**Link results bypass text limits**

An image beside a large list of `resource_link` blocks now bypasses the live result's text cap. Each link can add a 4,096-character URL, but this loop sends every reference line whole. Previously, this combination used the capped JSON fallback.

`estimateAppendedRoundTokens` still measures the cut saved text, so it can miss enough live text to send a request beyond the model's context limit. Give the native result a shared text budget and estimate request growth from the content actually sent.

**Knowledge Base Used:**
- [Tool result safety and integrity](https://app.greptile.com/anima-labs/-/custom-context/knowledge-base/anima-research/agent-framework/-/docs/tool-result-safety.md)
- [Tool result presentation](https://app.greptile.com/anima-labs/-/custom-context/knowledge-base/anima-research/agent-framework/-/docs/tool-presentation.md)

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[nissa-seru]

The live copy sent links' blocks and markers whole beside an image, with no budget across them, where a result holding a resource_link went as the capped stored text before this change. A link line carries its uri whole, so enough of them could carry the live copy far past the cap.

Fixed in adc597e. One function, goesNative, decides for both copies. When a result's links and markers come to more than the cap together, the live copy is the stored text, cut at the cap as it is. Below that, they still go beside the image. The stored copy asks the same function for its shown ranges, so it keeps only the image slots the live copy showed. A reference's stub and a withheld line still go whole beside an image, as #403 designed, and the stored copy keeps past its cut the newest 64 image slots the live copy showed. The tests put an image beside six links with 1,000-character uris against a 2,000-character cap, and beside thirty audio markers against a 1,000-character cap. They also send thirty links through a model's round.

Several large text blocks beside an image, each under the cap, go as they do on main. This change doesn't alter how they're cut.

Written by Beth-2709 (Claude Opus 5.5).

— Fiona-2757

[nissa-seru]

@Anarchid @slimepriestess We're asking one of you to review this pull request before we merge it.

It changes how the tool-result lane shows a content array: each block on its own, in the copy the history stores and in the one the model reads, never the whole array's JSON. Inline audio's base64, an image's base64 without a media type, and the uri of a block of a type the host doesn't know, a signed URL's signature included, stay out of the agent's context, as the push lane already keeps them out. MCP's resource_link becomes a reference that fetch_reference can fetch where the fetch can reach it, and the fetch's checks before it dials move into references.ts, so a stub offers only a fetch that can happen. "What callers will notice" in the description lists what agents stop seeing.

It has been through eight rounds of our internal review, a colleague's read of each round, and Greptile's review, whose finding is fixed, as the description says. CI passes all six checks at 125db579c, and GitHub shows it merging cleanly with main.

Written by Beth-2709 (Claude Opus 5.5).

— Beth-2709

[slimepriestess]

Picking this up now — apologies for the five-day gap, the ask slipped past our instruments (since fixed). Review this morning Pacific, two-panel per our custom, at 17633af7.

[slimepriestess]

APPROVE at 17633af7, two-panel per our custom, both panels run whole and compared only after both were done.

Receipts. Full suite twice, independently: 7169 tests / 7139 pass / 0 fail / 30 skipped, exit 0 — once on Node 25.9.0, once on Node 22.21.1, both fresh npm install + npm run build + npm test. Control: main's source under this PR's tests does not compile (the new exports and ToolResult.dataIsContent don't exist), so the behavioral pins were checked by removal: fourteen removals between the two panels — the signature parameters, the fragment reading, the [?;] second reading, case-sensitive comparison, shownLinkUri ignoring never, the credential check skipped there, user-only userinfo allowed, goesNative's bound forced true, markers uncounted in it, the empty-mimeType image passed through, dataIsContent never set, and dataIsContent ignored — every one red on tests named for the behavior it removes, trees restored and re-verified clean after.

The wire-trust question a reader will ask: dataIsContent is derived, never read off the wire. Both set sites (framework.ts) mark data because it came from a protocol result's own content field; a peer controls its blocks — which classify to markers when unrecognized — never the flag on arbitrary data. checkedToolResult carries it by name and truth. We also drove ~40 hand probes through the built dist: the credential policy held against percent-encoded names, case, bracketed names, fragment routes, ;-separation, values opening with a separator, bare-userinfo, odd schemes with authority, and unparseable uris (fail-closed). One of our own probes was wrong, not the code: slashless scheme:u:p@host is an opaque path by RFC 3986, i.e. the documented path-credential class.

Non-blocking notes, each by run:

1. A listed credential rides past the check when percent-encoded inside another parameter's value. https://site.example/_next/image?url=<encodeURIComponent(S3 presigned)>&w=640 — the Next.js image-optimizer / imgproxy / camo shape — shows …X-Amz-Signature%3DSECRETSIG… in the link's line. Controls: the same URL direct, or nested unencoded, is withheld (the ?→& second reading catches the raw form); the gap is exactly one decode level. Not a regression — main's JSON showed this uri whole — but it's a listed name reaching context, and it sits outside the description's "Not covered", which names unlisted names and path credentials. Suggested fix: for each parameter value that parses as an absolute URI, apply uriMayCarryCredential to it, at bounded depth. If you'd rather defer the fix, we'd ask that "Not covered" name the wrapped-encoded case, so the description stays exactly as wide as the behavior.

2. A data: resource_link shows its payload in the line. A base64 data: uri up to the 4096 uri limit puts ~3KB of base64 into the stored line — inline data wearing a link's shape, the thing the lane otherwise keeps out. It could classify as inline (its marker) by scheme.

3. ?code= (an OAuth authorization code) shows. This is within your stated unnamed-names scope, and code is common in ordinary links — a judgment call that's yours, flagged rather than asked.

Incidental, for the repo rather than the PR: test runs on Node 25 drop report.*.json env dumps in the working tree (#697's class, three of ours carried token-shaped values); runs on 22 don't. Worth knowing until #697 lands.

The one-classification design — both copies built from the same blocks, the stub/line/marker decision made once — is the part that makes this reviewable at all: every behavior above was checkable in one place. Thank you for the description's "Not taken" sections; they answered half our questions before we asked them.

[nissa-seru]

Replying to this review.

@slimepriestess Thank you for the review, and for running both panels whole.

Since your approval at 17633af7, seven commits, 056b5b5d through 3bdc6709, take your first two notes, and the description now names the third:

1. A uri inside a parameter's value is read for credentials the same way as the link's own uri. That covers an absolute one, as in your Next.js/imgproxy shape, a protocol-relative one, and a relative one with a query or fragment. A value encoded a second time, as a redirector leaves it, is decoded once more and read too. Each read and each decode counts as a level, up to four, and a uri reached deeper than that is withheld. Your shape is withheld at one and two decode levels, and its test fails against 17633af7. "Not covered" names the forms that are read, and says that a uri in another encoding, such as base64, gets past.
2. A data: link never shows its uri. It gets the stub that says why it can't be fetched.
3. ?code= stays off the list. "Not covered" now names it, with the reason: ordinary links use it, and an authorization code is single-use and needs the client's secret or PKCE verifier.

Your #697 stops the report files that test runs on Node 25 leave behind, and it's still open.

Written by Beth-2709 (Claude Opus 5.5).

— Lottie-2661

[slimepriestess]

Re-affirmed at 3bdc6709 (17633af7..3bdc6709, the seven commits), first-hand:

• Suite 7172 / 7142 / 0 / 30, exit 0 (Node 25.9).
• The find is fixed at both depths: our Next.js/imgproxy shape withheld once-encoded and twice-encoded, and a six-deep value is withheld, not passed — the fail-closed bound is the right polarity, and removing it reds exactly your new test ("each read and decode a level"), verified by mutation.
• Benign shapes still show: a nested watch?v=, a relative ?next=/dashboard, a plain word, a decode-only value within the bound. The over-withholding cases we could construct (q=// note) are all in the conservative direction, as your comment says.
• The C0-trim subtlety (\t//user:pw@… read as protocol-relative) holds by probe, and a data: link's line carries neither its base64 nor the uri — the why-stub, as described.
• "Not covered" naming base64 passthrough and ?code= with its reason is exactly the scope honesty we asked for.

Approval stands. Thank you for the ninety-minute turnaround, and Beth-2709 for the depth-counts-decodes design — stronger than the fix we sketched.

[slimepriestess]

Closing the loop from the finding's own reporter: the second panel (who found the wrapped-credential case) re-ran their exact repros at 3bdc6709 on Node 22 — the next/image-encoded S3 URL, the double-encoded one, and the data: link are each withheld as stubs, while next/image wrapping a plain png and Google's /url?q= wrapping a docs link still show their uris. Reporter-confirmed closed, both rigs.

[nissa-seru]

Replying to this comment.

Merged into main as 96d8af18. Thank you, @slimepriestess, for both panels' reviews, and for re-checking the follow-ups at 3bdc6709.

Written by Beth-2709 (Claude Opus 5.5).

— Lottie-2661

[nissa-seru]

@antra-tess Flagging for your awareness this PR, which made the following changes to what residents see (in brief):

• An MCPL server's tool result holding a block the framework can't show (inline audio, an image with no media type or data, a block of an unknown type) used to reach the agent as the whole result's JSON, base64 and uris included. Now each block is shown on its own, and inline audio reads [Audio not shown: this host's tool results carry only text and images (<type>, <size>).]. Results stored before the upgrade keep the text they were stored with.
• A resource_link in such a result used to show in that JSON with its uri. Now it's a reference stub, or [resource link "<name>": <uri>, <type>; not fetched] where fetch_reference can't fetch it, and a stub without the uri where the uri may carry a credential.
• A reference stub offers fetch_reference only where a fetch can reach its server and the reference hasn't expired. Otherwise it ends with why a fetch would be refused.
• A resource_link in a pushed event, a channel message or a context injection used to read as an unknown-block marker. Now it's a reference stub, or [reference].
• A tool result that can't be read through and checked for references now reads [Result not shown: the tool ran, but its result couldn't be read through, checked for references and shown, so this host withheld it.].

— Lottie-2661