MCP elicitation - Allow/Deny is often not visible unless MCP tool row is expanded

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Tier-1 MCP form elicitation during a single tools/call
Server sends elicitation correctly; on Cursor Editor (not only Agents window), Allow/Deny is often not visible in the main transcript — only after expanding the in-flight MCP tool row.
If User doesn’t expand, the call appears stuck and may hit ~60s REQUEST_TIMEOUT while the server is still waiting.

Steps to Reproduce

  1. Add MCP server in Cursor (mcp.json or Settings → MCP) with Streamable HTTP URL and Accept header above.
  2. In Agent/Chat, send a message that triggers a gated MCP tool path (e.g. “Run a command That triggers approval” / action requiring explicit approval).
  3. Observe the thread while tools/call is in progress without expanding the tool section.

Expected Behavior

When the server sends form elicitation during an active MCP tools/call, Cursor should surface Allow/Deny prominently — e.g. top-level banner/modal or inline interrupt in the main transcript — so the user can approve or deny without hunting in nested UI.

The client should not treat the call as failed while elicitation is pending (or should use a longer / elicitation-aware timeout).

Operating System

MacOS

Version Information

Version: 3.15.19
VS Code Extension API: 1.128.0
Commit: de07bee81cefe43461ebf4f40c3d2d78d15052a0
Date: 2026-08-11T05:22:54.627Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.291
OS: Darwin arm64 25.6.0

Does this stop you from using Cursor

No - Cursor works, but with this issue

7

Hey @chandram, thanks for the report!

This is a known issue we’re already tracking, and I’ve added your report to it. When an MCP tool call is grouped into a collapsed activity section in the chat (for example, “Exploring · 1 tool”), the Allow/Deny form stays inside that section. If a tool call looks stuck, expanding that section will show the form.

On the timeout, could you tell us where it appears? Is it an error in the Cursor tool result, such as “MCP error -32001: Request timed out,” or only in your server logs?

8

Re: where the timeout appears

It shows in Cursor’s tool result / chat error UI, not as primary signal in server logs. On the failing attempt I did not see my MCP abort the gated action early; the backend was still waiting on elicitation while the client gave up after ~60s.
Captured the below structured tool error in Cursor (Agent / tool execution):
{
"message": "Request timed out",
"domain": "TOOL",
"category": "USER",
"code": "TOOL_EXECUTION_FAILED",
"details": {
"errorMessage": "SdkError: Request timed out",
"argsJson": "{"message":"<REDACTED: gated network action request>"}"
},
"cause": {
"message": "Request timed out",
"name": "SdkError",
"code": "REQUEST_TIMEOUT",
"data": {
"timeout": 60000
}
}
}

Context: First attempt with no visible Allow/Deny (activity grouped under something like “Exploring · 1 tool” until expanded). After ~60s, my_mcp failed with the above. A retry (with UI visible after expanding) completed the gated action in ~2s on the same MCP config.