{"version":"2.1.315","anchor":"elicitation-requests-join-prompt-redelivery-fields","canonical_anchor":"elicitation-requests-join-prompt-redelivery-fields","heading":"Pending MCP elicitation requests are carried with other pending prompts","tier":"use","area":"Agents","scope":"individual","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.315\/e\/elicitation-requests-join-prompt-redelivery-fields","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.315","markdown":"### Pending MCP elicitation requests are carried with other pending prompts\n\nWaiting MCP elicitation requests are now kept in session state and sent with pending permission and dialog requests, then removed before delivery\n\n**What**\n\nAn MCP elicitation is a question an MCP server (an outside tool Claude Code connects to) asks you through Claude Code. Claude Code already kept track of pending permission requests and pending user dialogs so they could be sent again. Elicitation requests now join them:\n\n- The session's state snapshot now includes `pending_elicitation_requests` next to `pending_permission_requests` and `pending_user_dialog_requests`.\n\n- The reply sent when a client first connects (the initialize response) can now carry `pending_elicitation_requests`.\n\n- The SDK, and the handler for worker responses, strip this field from the reply before passing it on, as they already did for the other two.\n\n- If these fields turn up on a reply that is not the first-connect reply, they are ignored and a note is logged.\n\n**Why**\n\nIn practice, an MCP server's question that is still waiting for an answer is now tracked like a waiting permission prompt, so it can be offered again to a client that connects later.\n\n- Area: Agents\n- Names: `pending_elicitation_requests`\n- Tier: Use it now\n- Useful: 4\/5\n- Signal: 2\/5\n- Scope: individual\n- Heads-up: no"}