When the Cursor Agent calls an MCP tool and the tool returns an error, the Agent immediately exits its execution loop instead of handling the error and trying a new plan or calling another tool. This results in the overall task failing prematurely whenever an MCP tool-call is unsuccessful.
Steps to Reproduce
Start a task with the Cursor Agent that requires calling a custom MCP tool.
Ensure the MCP tool-call fails and returns an error message. (e.g., provide invalid input that triggers a gitlab tool error).
Observe that the Agent stops its current operation (plan/execute loop) immediately after receiving the error.
Expected Behavior
The Agent should receive the MCP tool error, recognize it as an execution failure, and attempt to self-correct by:
Revising its plan.
Trying the tool again with corrected parameters.
Trying an alternative tool or approach.
(As a last resort) clearly stating the tool-call failed and asking the user for guidance.
Operating System
Linux
Current Cursor Version (Menu → About Cursor → Copy)
Hey, thanks for the report. This looks like a separate issue from the MCP STDIO transport bug the team is already working on.
Your request is specifically about error recovery, the agent should retry or adjust its plan when an MCP tool returns an error, rather than exiting immediately. I’ll pass this to the team.
Thanks for the quick response and for clarifying that this is a distinct issue regarding error recovery!
To provide more context: the specific MCP server I was using when I encountered this bug is the GitLab MCP Server available here: Florian Forster / gitlab-mcp · GitLab via STDIO mode.
Since the team is already working on an MCP STDIO transport bug, could you please share the link to the thread or issue where that is being discussed? I’d like to check if there is any temporary workaround mentioned there that might help me avoid the immediate exit/loop-break issue in the meantime.
On a separate but related note regarding MCP usage in automation: I’ve also run into issues with MCP tool authentication in headless/CLI mode.
Currently, even if I configure an MCP tool in ~/.cursor/mcp.json, the agent in headless mode cannot access it without an initial interactive “Trust Workspace” approval. Are there any plans or existing workarounds to simplify MCP tool access/trust in headless (CLI) environments for CI/CD workflows?
Any insight would be greatly appreciated! Thanks again for your support.