💡 MCP MRTR-Native Confirmation: Protocol-Level Avatar Approval Gates for Any Connected Tool

[github-actions[bot]]

Summary

Implement native support for the MCP 2026-07-28 specification's Multi Round-Trip Requests (MRTR) feature, routing mid-call tool confirmations through TalkTerm's avatar overlay card system. When ANY MCP server triggers an MRTR — requesting user approval before a destructive or sensitive action — TalkTerm's avatar explains the action in plain language and presents approve/modify/reject overlay cards. This turns TalkTerm's UX advantage (FR20 confirmation gates) into a platform-level capability that automatically extends to every connected MCP tool.

Market Signal

The MCP 2026-07-28 specification (released July 28, 2026) introduced Multi Round-Trip Requests specifically to enable mid-call user interactions like confirmations without requiring persistent bidirectional streams. This is the protocol's answer to "how should agents ask for permission?" Google's Gemini ships computer use with OPT-IN safety guardrails — safety is the developer's problem, not the product's. Anthropic data shows 93% of Claude Code permission prompts are approved — users want flow, not friction, but they still want the safety net. MRTR provides the protocol-level mechanism; TalkTerm provides the best UX to render it.

Sources: MCP 2026-07-28 Specification, MCP 2026 Roadmap, AI Agent Security: Guardrails and Permissions

User Signal

TalkTerm's FR20 (pre-action confirmation gate) and existing idea #70 (Conversational Permission Approvals) address the UX of avatar-explained permissions at the application level. MRTR elevates this to the PROTOCOL level: a new Jira MCP server, a database tool, or a deployment pipeline can all trigger TalkTerm's familiar avatar confirmation flow without any custom integration. Non-technical users get consistent, conversational safety across ALL their connected tools — the avatar explains "This tool wants to delete 3 rows from your database. Should I allow it?" whether the action comes from a file system tool or an enterprise connector.

Technical Opportunity

MRTR is designed for exactly this interaction pattern: the MCP server sends a tool response with a "needs_confirmation" status, the client (TalkTerm) presents it to the user, and sends the user's decision back. TalkTerm's architecture is perfectly shaped:

1. MCP client layer handles MRTR status in the Agent bounded context (main/agent/)
2. IPC bridge forwards confirmation requests via the agent:confirm channel
3. Avatar explanation — the avatar speaks a plain-language description of the action using the MCP tool's metadata
4. Overlay cards — ActionCard + ActionPanel (UX-DR2/DR3) present approve/modify/reject options
5. Response routing — user's decision flows back through IPC → Agent → MRTR response to MCP server

The AgentBackend port is the extension point. Implementation maps directly to existing confirmation architecture — MRTR is the protocol representation of what TalkTerm already plans to do at the application level.

Assessment

Dimension	Score	Rationale
Feasibility	high	MRTR maps directly to TalkTerm's existing IPC agent:confirm channel and overlay card architecture. Protocol is standardized with clear message types. Low integration risk.
Impact	med	Extends TalkTerm's UX advantage to the entire MCP ecosystem. Any MRTR-capable server automatically gets avatar-mediated confirmations. Platform-level differentiation.
Urgency	high	MCP 2026-07-28 released 10 days ago. First-mover advantage for implementing MRTR in a consumer-friendly way. Positions TalkTerm as the reference MCP client for interactive confirmations.

Adversarial Review

Strongest objection: MRTR is brand new (released 10 days ago). MCP server adoption will be slow — most servers won't use it initially, making this feature invisible to most users in the near term.

Rebuttal: Early adoption of MRTR positions TalkTerm as the reference MCP client for interactive confirmations. When MCP server developers build MRTR support, TalkTerm will be the best showcase — the avatar explanation + overlay cards are dramatically better than a generic "Allow/Deny" dialog. Being first to implement a new protocol feature is how platforms establish ecosystem leadership. The implementation cost is low because MRTR maps directly to TalkTerm's existing confirmation architecture. And as the MCP ecosystem grows, this investment compounds — every new MRTR-capable server automatically benefits from TalkTerm's avatar-mediated UX.

Suggested Next Step

Read the MCP 2026-07-28 MRTR specification in detail. Map MRTR message types to TalkTerm's IPC agent:confirm channel and overlay card rendering pipeline. Create a proof-of-concept with a simple test MCP server that triggers MRTR confirmations to validate the end-to-end flow through the avatar.