Repository navigation
[FEATURE]: V2 tool-card labels and progress across MCP and Code Mode #54812
Description
Feature hasn't been suggested before.
- I have checked existing requests. Related: [FEATURE]: Surface MCP tool progress in the TUI (revive #32480 with a dedicated progress event) #49929 and [FEATURE]: Progress indicator for MCP calls #26328 (MCP progress), MCP tool calls render Unknown despite tools/list title metadata #26044 (titles), and [FEATURE]: Show MCP tool activity in the TUI sidebar #43717 (sidebar activity). This request asks for a shared v2 tool-card presentation contract, including nested Code Mode calls and persisted completion labels.
Describe the enhancement you want to request
For a long-running MCP tool, the existing card should show a readable action, the latest progress message, and a useful final detail. For example: Running tests → 12 tests completed → a server-provided summary. Two concurrent calls to the same tool through execute must keep separate labels and progress, even when they finish in reverse order.
Proposed v2 approach:
- Carry standard MCP
title/annotations.title, eligible icons, and correlated progress into optional host presentation metadata. No percentage when the server omitstotal. - Preserve that metadata through terminal results and history. Keep raw result
_metain a separate namespace; plugins can explicitly validate a server's extension and map a final summary. - Give each Code Mode child an invocation ID and bounded presentation snapshot.
- Render it in Web/TUI cards, including collapsed and error states. Keep tool names, arguments, canonical output, permissions, error badges, and old-history fallback intact.
This belongs in the host because a server/plugin cannot make the generic renderer display metadata or prevent nested-call data from being discarded. It should work for any MCP server, without vendor-specific handling in core.
I have an exploratory v2 prototype and a short contract. Root bun run check and focused tests pass. Browser visual acceptance is still pending because the local Storybook fixtures did not mount; I am not claiming verified screenshots.
Requesting design approval before opening an implementation PR, per CONTRIBUTING. Is this metadata-based approach acceptable, and would you prefer separate PRs for MCP propagation, Code Mode identity, and rendering?
Activity
opencode-agent commentedon Oct 12, 2026
Thanks for the detailed proposal and for checking the existing requests first!
To restate it: you're proposing a shared v2 presentation contract for tool cards. MCP titles, icons and progress would be carried as host metadata and kept through completion and history. Each nested Code Mode (
execute) call would get its own identity, so concurrent calls keep separate labels and progress, and both the Web app and the TUI would render all of this.The maintainers will review the design and answer your questions about the metadata approach and how to split the PRs. I can't say yet what they'll decide.
Related issues:
romanilyin commentedon Oct 26, 2026
Following up on the design request before opening an implementation PR. Is optional host presentation metadata an acceptable direction for preserving tool titles and progress through completion and history?
I can split the work into focused PRs for MCP metadata/progress propagation, nested Code Mode invocation identity, and Web/TUI rendering. Would that split fit your plans, or would you prefer a smaller first step? The linked v2 prototype and contract are available for review; browser visual acceptance is still pending as noted above.