Feature: Support MCP elicitation (human-in-the-loop approval for write operations)

[ericchansen]

Problem

MCP servers that perform write operations (e.g., updating a CRM, creating records in Dataverse, posting to external APIs) use MCP elicitation to get human approval before executing destructive or irreversible changes. This is a security-critical pattern -- the agent builds a preview of the change and the MCP server pauses until the human explicitly approves or rejects it.

Currently, the GitHub Copilot app (desktop) does not advertise the elicitation capability to MCP servers. This means any MCP tool that requires human-in-the-loop confirmation silently fails with an error like:

dataverse_write requires a client that supports MCP elicitation so a human can approve the change before it executes -- this MCP client does not advertise the elicitation capability.

This affects both chat sessions and project sessions.

Expected Behavior

When an MCP server requests elicitation, the app should present an inline approval UI (similar to how ask_user works for the agent) showing:

1. A preview of the proposed action (provided by the MCP server)
2. Accept / Reject buttons
3. The MCP server response is held until the user decides

This is the same pattern GitHub Copilot CLI supports in its interactive terminal mode.

Use Case

Any MCP server that writes to external systems benefits from this:

• CRM/Dataverse writes (creating tasks, updating records)
• Database mutations
• Cloud resource provisioning
• File system writes on remote systems
• Any action where "undo" is expensive or impossible

Suggested Implementation

The MCP spec defines elicitation as a client capability. The app would need to:

1. Advertise elicitation in its MCP client capabilities during initialization
2. Render the elicitation request (typically a JSON schema form or a confirmation dialog) in the chat/session UI
3. Return the user's response to the MCP server so it can proceed or abort

References

• MCP Elicitation Spec
• GitHub Copilot CLI already supports this in interactive terminal mode (issues #1863, #1872, #1873 were UX fixes for it)

[rpelevin]

Good issue. I think the important implementation boundary is that the Copilot app should advertise MCP elicitation only when it can keep the original tool call pending and bind the user's decision back to that same call.

That means the UI is not just an approval dialog. It is part of the client-side authority path. The request should carry enough stable context for the user and for later debugging: server/tool identity, the pending call id, the proposed action preview, a digest or exact snapshot of the arguments the server intends to execute, the decision actor, the decision id, and the terminal outcome.

A few regression cases seem worth making explicit:

• if elicitation UI is unavailable, do not advertise the capability
• accept resumes only the pending call that produced the prompt
• reject, cancel, timeout, reload, or session loss returns a terminal negative result to the MCP server
• late or duplicate decisions cannot resume a newer call
• chat sessions and project sessions have the same capability and terminal-state behavior

The dangerous failure mode is approve-A / execute-B, or a prompt that visually dismisses without producing a terminal result for the held MCP call. I would bias the app behavior toward fail-closed whenever the prompt, session, or pending call identity cannot be matched exactly.