Expose a per-server snapshot rendering hook with page and snapshot identity #2688

Is your feature request related to a problem? Please describe.

An embedder that needs bounded, redacted accessibility snapshots currently has to customize internal response methods. Customizing take_snapshot alone does not cover snapshots included by other tools, such as wait_for or input actions when a snapshot is requested.

In 1.8.0 and the inspected current main (a918b7b4086bcb14105b80abab1deb882535f15e), McpResponse privately associates the page with snapshot generation. The public format method receives a SnapshotFormatter, whose underlying snapshot is also private. An embedder cannot use that method alone to associate a bounded excerpt with the exact page/snapshot for later continuation.

Post-processing only the final text is insufficient: structured output can still duplicate the full tree, and truncating before redaction can split a value so the later exact-value redactor no longer recognizes it.

Describe the solution you'd like

An opt-in, per-server snapshot-rendering extension point after sampling and before MCP response serialization. The exact interface is open for discussion. It should let a trusted embedder:

• Associate output with the exact page and immutable snapshot identity used by that response, without parsing formatted UID text or sampling the page again.
• Render bounded text and the corresponding structured output consistently for both explicit and automatically included snapshots. Redaction can then happen before excerpt boundaries are chosen, with no hidden full-tree duplicate in structured output.
• Distinguish response rendering from full snapshot file export. A response-size policy must not silently truncate exported files or bypass the existing file-root validator.
• Keep extension state local to one server and invalidate continuation state when the relevant snapshot/context changes.

The redactor, excerpt cache and continuation policy can remain embedder-owned; this does not request a generic caching or secret-management framework upstream. A supported native bounded-snapshot interface could also meet the need if it preserves these distinctions.

Suggested acceptance checks: default output unchanged; long synthetic snapshots are bounded in both response forms; values crossing an excerpt boundary are redacted before slicing; continuation refers to the same snapshot without UID reassignment; page/reconnect changes cannot reuse stale continuation state; full file exports and file refusals remain unchanged.

Describe alternatives you've considered

• Customize only take_snapshot: misses snapshots generated through other tools.
• Disable automatic snapshots: useful and already supported for input tools, but some workflows still need a bounded observation after an action.
• Rewrite final response strings or override McpResponse.setPage/handle and formatter internals: introduces coupling to output layout and private state.
• Request only a subtree: helps size, but is a separate selection feature and does not address consistent rendering/redaction across all response paths.

Additional context

Related embedding request: #2687. Tool registration and snapshot rendering can be designed and delivered independently.

Sources: McpResponse, SnapshotFormatter.

Related: #716 requests subtree selection; #726 added control of input-tool snapshots; #835 concerns snapshot diffs. PR #833 proposed size/selector options and was closed as stale without merging. This request concerns a supported programmatic rendering boundary for embedders, rather than reopening those CLI/tool-parameter proposals.

This is an API-design request based on source inspection and downstream requirements, not a claim that a new upstream implementation has been tested.