{"version":"2.1.280","anchor":"new-tracking-set-for-mcp-elicitation-requests","canonical_anchor":"new-tracking-set-for-mcp-elicitation-requests","heading":"New request tracking for MCP elicitation dialogs","tier":"internal","area":"MCP","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.280\/e\/new-tracking-set-for-mcp-elicitation-requests","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.280","markdown":"### New request tracking for MCP elicitation dialogs\n\nClaude Code now separately tracks MCP elicitation requests across telemetry, dialogs, and request verification\n\n**Unclear.** The finding only shows the tracking set being added, not what elicitation requests are used for or how they surface to the user.\n\n**What**\n\n- A new `elicitationOutboundRequestIds` set tracks outbound requests tied to MCP \"elicitation\" (a protocol feature that lets a server ask the user for input), alongside the existing `knownOutboundRequestIds`, `automatedOutboundRequestIds`, and `deviceOutboundRequestIds` sets, and is cleared along with them on reset.\n\n- A new dialog kind constant, `dialog:mcp_elicitation`, was introduced for these dialogs.\n\n- The request-ID attestation check, which validates that inbound and outbound requests correlate correctly, now also checks this new set.\n\n- Pending-action republish telemetry (`tengu_pending_action_republished`) now reports `elicitation` as its own `survivor_kind` category, separate from `dialog` and `permission`.\n\n**Why** This lets Claude Code track, verify, and report on MCP elicitation requests as their own category instead of lumping them in with other dialog or permission requests, keeping telemetry and request verification accurate for this MCP feature.\n\n- Area: MCP\n- Tier: Under the hood\n- Useful: 1\/5\n- Signal: 1\/5"}