A long agent run reaches a newly installed MCP server and appears to stall: the chat shows the tool name, no result arrives, and no error is logged. Which explanation best fits Cursor's default behaviour?

The principle — An MCP tool call is a real action taken on your behalf, so Cursor puts a human decision in front of it. By default Cursor asks for approval before using an MCP tool, and the run pauses until you answer.

Why the key is correct — A step showing a tool name with no result and no error is the signature of an unanswered prompt rather than a failure: a crashed or timed-out server produces an error in chat and a call marked failed, and other servers keep working. Clicking the arrow beside the tool name shows the arguments before you decide. The behaviour is configurable, because MCP follows the same run modes as terminal commands, but the shipped default is to ask.

Why the others are wrong — Assuming tool calls always proceed leads to restarting a perfectly healthy server and losing the run; the absent error message is the clue that nothing has actually failed. The enterprise allowlist governs which servers and tools a team may run and is administered from the dashboard, so it shapes what is available rather than silently swallowing a live call. And the prompt is not derived from whether a tool reads or writes, which is exactly why a harmless-looking query can hold up a long run.

Remember this — Silence with no error usually means a prompt is waiting, not that a server has died. Read the inverse too: relaxing the run mode so tools fire immediately is a deliberate trade, and it applies to write-capable tools as much as to read-only ones.

Sources — Cursor's MCP documentation.