html_render pages never show for Kiro threads because Kiro titles T3 tool calls @t3-code/<tool> #28230

What happened

A Kiro agent (ACP registry provider) calls html_render. The server publishes the page and tells the agent "Shown to the reader above your reply", but the page never appears in the thread. The agent's reply then talks about a page the user can't see.

Diagnosis

Kiro titles T3 MCP tool calls @t3-code/<tool> with raw input { tool_id: "t3-code::<tool>", arguments: {...} } and no metadata naming the server.

extractMcpToolCallIdentity (packages/provider-acp/src/server/runtimeModel.ts) matches the title against T3_MCP_TITLE_CALL, T3_MCP_TITLE_SUFFIX_CALL and T3_MCP_BARE_TITLE_CALL. All three anchor at ^ and none allows a leading @, so the adapter finds no identity and skips its MCP branch in adapter.ts, where mcpSessions.takeHtmlRender would recover the page. The generic dynamic_tool fallback stores the title @t3-code/html_render as toolName. On the client, htmlRenderFromToolItem needs resolveT3McpToolId(toolName) === "html_render", and resolveT3McpToolName rejects the @ prefix too.

Kiro's raw output ({ response: "<json>", message: "<json>" }) isn't unwrapped by compactDynamicToolOutput, but once identity is recovered the existing takeHtmlRender(threadId, input) fallback reads input from rawInput.arguments. The shell-fallback result under Evidence shows that working.

Every native T3 tool call from Kiro hits this. Confirmed in the desktop app: the work log shows raw @t3-code/<tool> names, and the raw @t3-code/delegate_task row isn't filtered out next to the app-owned child row. Expected from the code, not tested: t3_thread_read rows lose their summary, t3_thread_wait and delegate_task mode: "wait" don't mark the thread as waiting, and thread deletion leaves html_render pages behind.

main has the same regexes. Accepting an optional leading @ in the ACP title match, or reading Kiro's tool_id, should fix it.

Steps to reproduce

1. Add Kiro as an ACP registry provider.
2. In a Kiro thread, ask: "Use html_render to show a small HTML card in this thread."
3. The call completes and the server publishes the page, but nothing appears.
4. The stored turn item is a dynamic_tool with toolName: "@t3-code/html_render".

Version

T3 Code 0.1.7-nightly.20261031.3991, kiro-cli 2.37.0

Environment

Local server, Kiro through the ACP registry provider, seen in the desktop client. The cause is in server and shared code, so every client should behave the same.

Evidence

Two `html_render` calls in the same Kiro thread with similar HTML:

| Call | Stored `toolName` | Stored output | Page shown |
|---|---|---|---|
| Native `html_render` | `@t3-code/html_render` | `{ response: "{\"htmlRender\":…}", message: … }` | No |
| `acp-mcp-call html_render '<json>'` shell fallback | `t3-code.html_render` | `{ htmlRender: {…} }` | Yes |

The server wrote both pages to the attachments directory. Native `t3_thread_read` and `delegate_task` calls in that thread were stored as `@t3-code/t3_thread_read` and `@t3-code/delegate_task`, the latter with `output: { response: "{\"taskId\":…}" }` next to an app-owned `subagent` row.

Related issues

#17031 is an open PR for wrapped html_render calls (OpenCode, Devin, CodeBuddy, Grok) that doesn't handle @server/tool titles. #16745 and #23714 report the same symptom for other providers. #14693 adds Kiro as an ACP provider.

Fix applied or workaround

No fix in T3. The agent can call html_render through the acp-mcp-call shell fallback, with nothing after the JSON argument, or render the HTML to a PNG and embed it.

Filed by

Claude Opus 5.5 via Kiro (ACP), in a T3 Code triage session.