Allow MCP-provided Edit/Write tools to render diffs in the UI

Summary

Let file-editing tools provided by MCP servers surface a rendered diff in the
conversation UI, the same way the built-in Edit/Write tools do. Today the
diff view is hard-gated to the built-in tools, so an MCP editing tool can only
return its diff as collapsed plain text.

Use case

I built an MCP server that provides Read/Edit/Write for CP1251 (Windows-1251)
files — the built-in tools are UTF-8 only and corrupt single-byte legacy
encodings (e.g. 1C 7.7 and many CIS enterprise codebases). It mirrors the
built-in Edit/Write, including emitting a unified diff in the result. But that
diff only appears as collapsed monospaced text; the rich diff widget never
renders, because it is reserved for the built-in tools.

Observed behavior / root cause

The diff builder accepts a tool-use only if ALL hold:

1. toolUseResult.filePath is present and equals the target path;
2. the tool name is exactly Edit or Write;
3. toolUseResult echoes the input (oldString/newString for Edit,

content for Write);

1. toolUseResult.structuredPatch is a valid hunk array

({oldStart, oldLines, newStart, newLines, lines}).

MCP tools fail (1)–(3): their name is namespaced (mcp__<server>__<tool>),
and toolUseResult is the MCP response envelope (content/structuredContent),
not the built-in executor's object. So no MCP tool can ever trigger the diff
view, regardless of what it returns.

Proposal

Let an MCP tool opt into diff rendering by returning a structuredPatch
(the existing hunk shape) in structuredContent (or _meta) of the tool
result, and render it independently of tool name. Optionally gate on a declared
server/tool capability so it is explicit. The hunk format is already what the
built-in path consumes, so the renderer change is minimal.

Alternatives considered

• Returning the diff as plain text — works, but collapsed and unstyled.
• Naming the MCP tool Edit/Write — impossible; MCP namespacing forces the

mcp__ prefix.

Impact

Third-party editors (alternate encodings, remote/VFS files, binary-backed
formats) get the same review-quality diff UX as built-in tools — important for
non-UTF-8 ecosystems.