Can not see call args in mcp tool calls

[ddd1345 (Dennis De)]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

In the current Cursor version, the MCP view has been changed.

The original version over the past few months was such that the options, meaning the arguments used when the MCP tool was called, were still shown. I had already created a post at the time saying that they were not displayed completely and that you could only copy them.

Now it is even worse. You have changed it so that nothing can be seen anymore. This means that if you have custom MCP tools that move files or delete files, you can no longer see at all which arguments they were called with.

Steps to Reproduce

see desc

Operating System

Windows 10/11

Version Information

3.10

Does this stop you from using Cursor

Yes - Cursor is unusable

[ddd1345 (Dennis De)]

[elijahcarrelgrailbio (Elijah Carrel)]

When using a risky MCP server, I like to review the input values before approving the request to make sure it’s correct.

With the latest Cursor (I am on 3.10.20 although this change may have come earlier), this is no longer possible. All I see is this:

Could this still be made visible via progressive disclosure? I understand not wanting to clutter the UI, but users should still at least be able to see the MCP input if they choose via some disclosure toggle of some kind. Otherwise, the only options are:

1. Deny and demand the agent say what it’s going to do before it does it
2. Approve and pray

[mohitjain (Mohit)]

A recent change to how tool calls render stopped surfacing MCP arguments, and on the approval prompt they aren’t shown at all, so there’s currently no in-UI way to review the input before approving. I’ve reproduced it and reported it to the team.

Until it’s fixed, the safest approach for risky file-moving or deleting tools is to keep them off Always Run (so you keep the Skip option) and ask the agent to state the exact paths and arguments before it calls the tool. That’s essentially your option 1, and I know it isn’t the disclosure you’re after.

Your progressive-disclosure idea is exactly the right direction, and it’s on our radar. I’ll update here when there’s progress.

[Zack_Knopp]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Can’t click on a command an agent is running to see the SQL it plans to run. I can click on it after it has ran, to see the details. Just not when it is asking me if it can run it.
I used to be able to click on the command it was asking for permission and see the details.

Steps to Reproduce

I open up cursor and ask it to run SQL using my Supabase/Postgres MCP.
It says “running execute_sql in supabase” and asks for permission to run it.
I can’t click on it to show details.
I don’t want to give it permission to run SQL against my db that I can’t review first.

Screenshots / Screen Recordings

Operating System

Windows 10/11

Version Information

Version: 3.11.19 (user setup)
VS Code Extension API: 1.125.0
Commit: bf249e6efb5b097f23d7e21d7283429f0760b740
Date: 2026-07-12T21:39:24.175Z
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.256
OS: Windows_NT x64 10.0.26200

Does this stop you from using Cursor

Yes - Cursor is unusable

[khofo]

Where does the bug appear (feature/product)? MCP & tools

Describe the Bug In previous versions of Cursor I used to be able to read/expand the content of MCP tool calls. This was very useful to quickly audit Supabase MCP tool calls before pressing allow, especially when running execute_sql or other Supabase tools. Now I can only see the tool name and press allow/deny, so I am not able to review the command being executed to determine if I should allow it or not. Previously the command was shown in a code block and included the Cursor tool call guardrails.

Steps to Reproduce

1. Connect the Supabase MCP server (I have mine set to read only)
2. Trigger a tool call, e.g. execute_sql
3. Observe the allow/deny prompt: only the tool name is shown, with no way to expand and view the actual command/SQL being run

Expected Behavior The tool call prompt should show the command or SQL being run in a code block before I allow or deny it, the way it did in previous versions.

Screenshots / Screen Recordings

Operating System Windows 11

Version Information
Version: 3.12.17 (user setup)
VS Code Extension API: 1.128.0
Date: 2026-07-17T02:53:53.006Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
xterm.js: 6.1.0-beta.256
OS: Windows_NT x64 10.0.26200

For AI issues: which model did you use? N/A, this is a UI/display issue, not model specific

For AI issues: Request ID N/A

Additional Information I looked through the settings and could not see anywhere to re-enable this option, although I have the conversation density set to “Detailed,” which is described as “Choose how much detail Agent tool calls show in the conversation.”

I hope this is temporary and this feature is being improved and will show up again in new updates. Appreciate letting us know if this is in the pipeline, or I should set up my own tooling to ask the agent to write tool calls to a file before executing them so I can audit.

I currently have Supabase MCP set as read only, so this is mildly annoying. However, I cannot envisage setting up the MCP as read/write without having the ability to review tool call contents, which can be potentially destructive or alter my databases.

Does this stop you from using Cursor? Sometimes - I can sometimes use Cursor when mcp is setup to read-only and hoping it is running correct commands checking correct tables…

Edit: updated this post to follow the bug report template per the mod bot’s request above.

[bernaz7]

Same issue on Cursor 3.12.17 / macOS 26.5.2 (arm64).

What I see

• MCP approval card shows tool name (e.g. Upsert .....)
• Buttons: Skip / Always Run / Run (Allowlist mode)
• No expand arrow / chevron — cannot view tool arguments before approving
• Also reproduced under Auto-review - still no args

Expected (per docs)
MCP docs → Tool approval: “Click the arrow next to the tool name to see arguments.” That control is missing.

Not caused by

• Conversation Density (Detailed)
• Auto-review vs Allowlist
• Specific MCP server schema

Impact
Cannot safely review write MCP calls before Run.

[camball (Cameron Ball)]

Just want to +1 here, this is an extremely important part of my everyday Cursor usage, and impacts my workflow significantly.

[Dean2 (Dean)]

This regression is a serious safety issue, not a minor UI polish problem.

Per your own docs, users should be able to expand and review MCP tool arguments before approving. That control is completely missing in the approval dialog. The only options left are:

Blindly approve operations that may modify production data

Skip every time and manually ask the agent to restate what it’s about to do

This makes Cursor unusable for any write-capable MCP workflow — database writes, file moves, deletions, and more. A tool approval flow that hides what you’re approving defeats the entire purpose of having approval in the first place.

[AMORE]

Couldn’t agree more. Auto-review’s result doesn’t give enough detail—the MCP call is almost a black box, which makes it hard to review properly.

wish cursor stuff can see and reply this thread soon

[AMORE]

After upgrading to cursor 3.11.x, When the Auto-review classifier blocks an MCP tool call and Cursor shows an approval prompt, the review UI currently shows only the Agent’s review text. It does not surface the MCP tool’s arguments.

This makes manual approval difficult. Without the concrete arguments, it is hard to verify that the call is appropriate—or that the content in the tool arguments (for example, the document body, fields, or other payload) matches what the user expects—before approving or rejecting.

As shown in the screenshot: I want to review the exact document content in the create-doc call’s arguments—and give feedback so the Agent can revise it if needed. But now I only see Auto-review’s summary that this is a create-doc operation with a side effect, which is not enough.

Request: Please show the MCP tool arguments in the Auto-review approval prompt (and the tool result when available)—or restore the previous design that made these details visible when reviewing MCP calls like:

[Der_Simon (Simon)]

I am still seeing this issue in the current stable version:

Version: 3.13.25 (Universal)
VS Code Extension API: 1.128.0
Commit: 31e8d61c448c7472e371505838a0fe34083dad50
Date: 2026-07-28T06:17:45.069Z
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.256
OS: Darwin arm64 25.6.0

I fully agree with @dean2: this should not be treated as a minor UI regression. It is a serious security issue.

The purpose of requiring manual approval for an MCP tool call is to allow the user to understand and evaluate the exact action the agent intends to perform. The tool name alone is not sufficient for that. The relevant risk usually depends on the parameters, such as the file path, URL, SQL statement, command, issue identifier, or data being submitted.

Without access to those parameters, the approval is not informed. The user is effectively asked to approve an unknown operation.

It is difficult to understand how such a regression could be introduced in a security-relevant approval flow without being detected before release. It is even more concerning that the issue has remained unresolved for this long, especially considering Cursor’s otherwise frequent release cycle.

For security-conscious users, this currently makes it practically impossible to use MCP tools with manual approval in a responsible way. The alternatives are either to approve calls without knowing what they will do or to stop using MCP tools altogether.

In my view, restoring the complete tool-call parameters in the approval UI should be treated as a high-priority security fix rather than a normal interface improvement.

[Der_Simon (Simon)]

Still occurs in

Version: 3.14.7 (Universal)
VS Code Extension API: 1.128.0
Commit: a758f2241ca99fecf380180b6cbdbbce0f1f42c0
Date: 2026-07-30T06:41:34.009Z
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

[Tobi042]

I can also confirm that this issue is still present in Cursor version 3.14.7 (Ubuntu 24.04).

This is a real issue for us and makes the review dialog essentially useless.

[ddd1345 (Dennis De)]

Yes, the entire development team behind Cursor is very questionable, to put it mildly. They keep promising that they will change things, but nothing happens.

It is exactly the same with the text size. Months ago, they said they wanted to add a specific change that would allow users to set a custom font size in the editor window on the right, but this still has not happened. You can still only choose between Medium, Large, and so on, even though they said they would change it.

I strongly assume that they are using AI to generate some responses, possibly putting the issues into the backlog, and then not even working through them. At the end of the day, it is incredibly frustrating to work with Cursor as soon as a truly blocking issue arises.

I have been working with Cursor for around two years now, and there are still issues that have not been fixed and probably never will be.

The only reason I use Cursor is that my company provides me with the account. I would never use it privately.

I find it very frustrating that, given the amount of resources behind Cursor, issues like this are possible at all—especially today, when AI-agent-based approaches could resolve such matters within an hour.

If you look at this post, a huge number of people have the same problem. The fact alone that arguments can no longer be viewed in an MCP call, even though MCP is an essential part of the functional chain, and that this still has not been fixed, already shows how Cursor operates in terms of agile processes and how it sets its priorities.

[mohitjain (Mohit)]

Thanks for the continued reports, and sorry this has dragged on. To confirm: it’s still an issue we’re tracking, not yet resolved on 3.14.x, and you’re right that the docs still describe an expand control that isn’t showing. I’ve made sure the team has the ongoing reports and the security/auditability angle; no timeline yet, but I’ll post here when there’s something concrete.

Interim, for write-capable MCP tools (SQL, file moves/deletes): keep them off Always Run so every call stops at approval (Skip stays available), have the agent state the exact command/args before it calls, and scope the server to read-only where it’s supported. It’s a stopgap, not the argument preview you’re after - restoring that is the actual fix, and it’s what we’re tracking.

[Der_Simon (Simon)]

Still occurs in

Version: 3.15.6 (Universal)
VS Code Extension API: 1.128.0
Commit: a1f686545fd0ce8917bbd2449f733551a9bce420
Date: 2026-08-06T01:41:03.876Z
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

[camball (Cameron Ball)]

Just bumping again for support to keep the thread alive (I know the team is already aware of this issue; thanks guys!). Hope to see this get implemented ASAP.

[AMORE]

BREAKING NEWS!!! After a MONTH of chaos and SO. MANY. VERSIONS… it’s FINALLY, FINALLY FIXED in Version: 3.15.12

VS Code Extension API: 1.128.0
Commit: 2f47c0cbe4292d2a709c7eba7eee0a91e1aa0cf0
Date: 2026-08-07T21:42:07.548Z
Layout: IDE
Build Type: Stable
Release Track: Nightly
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.5.0