MCP tool called without required "key" arg during Agent auto-call, manual call works

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

402e5aaf-9ff8-4eae-a895-22c05eaad91f

I’ve run into a limitation in how MCP tools work in Cursor that currently prevents full integration of our task system (TaskTime) with the agent.

What I’ve done
In my TaskTime MVP (vibe-code) project I run the backend on http://localhost:3000 and expose a task API.

I implemented an MCP server user-tasktime-issues (Node + @modelcontextprotocol/sdk) which:

via the get_issue_by_key tool calls TaskTime and returns a ticket by key (TTMP-81, LIVE-3, etc.),
via the update_issue_ai_flags and update_issue_ai_status tools updates AI-related flags for an issue,
via the list_mvp_livecode_active_issues tool returns active issues from the meta‑project.
The MCP server is successfully registered in Cursor (~/.cursor/mcp.json):

“mcpServers”: {
“tasktime-gatekeeper”: { … },
“user-tasktime-issues”: {
“command”: “node”,
“args”: [“/Users/pavelnovak/tasktime-mvp/mcps/tasktime-issues/dist/index.js”],
“env”: {
“TASKTIME_API_BASE_URL”: “http://localhost:3000”
}
}
}
In Tools & MCP the server appears as user-tasktime-issues, and all four tools work:

when I call get_issue_by_key manually with

{ “key”: “TTMP-81” }
the MCP server correctly returns the ticket JSON from TaskTime.

What I’m trying to achieve
I want the Cursor agent, given a user phrase like:

“возьми TTMP‑81” (“take TTMP‑81”)

to do the following:

Parse the issue key TTMP-81 using the regexp [A-Z]{2,10}-\d+.
Call the MCP tool get_issue_by_key with the argument { “key”: “TTMP-81” }.
Use the response to build a concrete plan for working on that issue.
The parsing logic and tool selection are already described in the tasktime-issues-gateway skill, so on the prompt/skill side everything is prepared.

What’s going wrong now
From the logs I can see that:

Cursor does find the MCP server user-tasktime-issues and the get_issue_by_key tool.
But when the tool is called automatically via CallMcpTool, no arguments are passed at all:

the MCP server receives a request with no key field;

on the Cursor side I see errors like:

{“error”: “MCP error -32603: Missing required "key" argument”}
If I call the same tool manually via the MCP panel with { “key”: “TTMP-81” }, everything works:

MCP calls TaskTime,
returns the correct ticket,
no errors.
From the agent’s reply it’s also clear that it is aware of some limitation: it mentions that the “CallMcpTool schema doesn’t support dynamic arguments, so it has to ask for the ticket text manually”.

So technically:

the MCP server and tools are implemented correctly,
but the current CallMcpTool behavior in Cursor/the agent does not pass dynamic arguments (in particular key), even though the skill explicitly says they should be provided.
What I’d like from the platform
Confirmation whether this is indeed a current limitation of CallMcpTool (arguments not supported / being ignored) for the agent I’m using.

Information on whether there is already a plan/timeline for:

allowing CallMcpTool to accept and forward arguments to MCP tools; or
providing another recommended way to pass parameters (e.g. a standard JSON argument format).
Ideally, a small example of the “correct” schema/usage for calling such tools, e.g.:

get_issue_by_key({ “key”: “TTMP-81” })
derived from user text.

It’s very important for me that the agent can pull tasks from our system by ticket key without manually copying the description. The MCP server and backend are already implemented and working; the only missing piece is the ability to safely pass arguments from CallMcpTool into the MCP tool.

Steps to Reproduce

Set up a simple MCP server (Node + @modelcontextprotocol/sdk) with a tool that has a required argument, e.g.:

{
“name”: “get_issue_by_key”,
“inputSchema”: {
“type”: “object”,
“properties”: {
“key”: { “type”: “string” }
},
“required”: [“key”],
“additionalProperties”: false
}
}
Register this server in ~/.cursor/mcp.json under mcpServers (in my case as user-tasktime-issues) and verify in Settings → Tools & MCP that:

the server is listed and green,
the tool get_issue_by_key can be called manually with:
{ “key”: “TTMP-81” }
and returns a JSON payload (any static JSON is fine to reproduce).

Create a skill / rule that tells the agent:

to extract an issue key from the user message using regex [A-Z]{2,10}-\d+ (e.g. TTMP-81);
and then call MCP tool get_issue_by_key with arguments:
{“key”: “<extracted_key>”}.
Open a new chat in Cursor (with that skill active) and send a message like:

возьми TTMP‑81 (or take TTMP-81)

Observe in the MCP tool output and server logs that:

Cursor does select the MCP server and the get_issue_by_key tool,
but the actual CallMcpTool request is sent without the key argument, and the MCP server returns an error such as:
{“error”: “MCP error -32603: Missing required "key" argument”}
As a control, call the same tool manually via the MCP panel with:

{ “key”: “TTMP-81” }
and verify that it succeeds, which confirms the bug is specifically in the automatic CallMcpTool invocation not passing arguments.

Operating System

MacOS

Version Information

Version: 2.6.18 (Universal)
VSCode Version: 1.105.1
Commit: 68fbec5aed9da587d1c6a64172792f505bafa250
Date: 2026-03-10T02:01:17.430Z
Build Type: Stable
Release Track: Default
Electron: 39.6.0
Chromium: 142.0.7444.265
Node.js: 22.22.0
V8: 14.2.231.22-electron.0
OS: Darwin arm64 25.3.0

For AI issues: add Request ID with privacy disabled

402e5aaf-9ff8-4eae-a895-22c05eaad91f

Does this stop you from using Cursor

No - Cursor works, but with this issue

4

Hey, thanks for the detailed bug report.

This isn’t a CallMcpTool limitation. The infrastructure fully supports passing arguments (the arguments field is in the schema). The problem is that the model sometimes doesn’t fill that field when auto-calling the tool. When the agent says “CallMcpTool schema doesn’t support dynamic arguments,” that’s a model hallucination, not a real limitation.

This was reported before here: CallMcpTool schema omits arguments, but runtime accepts it.

I logged this for the team. I can’t share an ETA, but your report helps with prioritization.

As a possible workaround, try being very explicit in the skill or prompt about the call format, for example:

ALWAYS call get_issue_by_key with arguments: {"key": "<extracted_key>"}
NEVER call get_issue_by_key without the "key" argument.

You can also try a different model. Behavior varies across models.

Let me know if the workaround helps.

1 Like
7

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Product / feature

  • Cursor MCP integration
  • CallMcpTool tool used by agents

Description

There is a mismatch between the schema exposed to the agent for CallMcpTool and the actual runtime behavior.

  • The schema shown to the agent only exposes:
    {
  server: string;
  toolName: string;
}
  • In reality, the runtime also supports and requires an arguments payload for many MCP tools:
    CallMcpTool({ server, toolName, arguments: { ... } })

Because the arguments field is missing from the schema, agents assume they cannot pass any parameters and end up calling MCP tools without required inputs, which triggers input validation errors on the MCP server.

This is not a problem with the MCP server itself — the MCP tool descriptors correctly declare required fields. The problem is that the schema/signature presented to the agent is incomplete, so the agent makes systematically wrong calls.

Reproduction steps

Actual behavior

  • CallMcpTool schema exposed to the agent does not include an arguments field.

  • Agents therefore call MCP tools with no arguments, even when the tool’s input schema requires them.

  • MCP tools return validation errors like:

    Invalid arguments for tool X: expected string, received undefined, message: “Required”

  • Only when the agent (or user) manually adds an undocumented arguments field do the calls succeed.

Why this matters

  • MCP tools often have non-optional input fields (e.g. action, id, key, etc.).
  • As long as arguments is missing from the schema, agents will systematically under-supply inputs and generate noisy validation errors, even though the MCP server and descriptors are correct.
  • This affects any MCP server that relies on required parameters, including CloudBase MCP and custom servers.

Steps to Reproduce

  1. Configure a standard MCP server with a tool that has a required input field.
    Example: CloudBase MCP envQuery:

    type EnvQueryInput = {
  action: 'list' | 'info' | 'domains' | 'hosting'; // required
};

  2. Let the agent call this tool via CallMcpTool using only the schema it sees (no arguments field):

    {"server":"user-cloudbase","toolName":"envQuery"}

  3. The MCP server returns an error similar to:

    {
  "error": "MCP error -32602: MCP error -32602: Invalid arguments for tool envQuery: [
    {
      \"expected\": \"'list' | 'info' | 'domains' | 'hosting'\",
      \"received\": \"undefined\",
      \"code\": \"invalid_type\",
      \"path\": [\"action\"],
      \"message\": \"Required\"
    }
  ]"
}

  4. Now manually call CallMcpTool with an arguments payload, even though it is not in the schema:

    {
  "server": "user-cloudbase",
  "toolName": "envQuery",
  "arguments": { "action": "info" }
}

  5. This time the MCP tool works as expected and returns a valid response (in CloudBase’s case, an AUTH_REQUIRED with a suggested auth flow, then a device-code login challenge, etc.).

This proves that:

  • The runtime does support and forward arguments.
  • The schema shown to the agent is simply incomplete, leading it to omit required parameters.

Expected Behavior

  • The CallMcpTool tool signature exposed to the agent should include an arguments field, e.g.:

    {
  server: string;
  toolName: string;
  arguments?: Record<string, unknown>;
}

  • The schema presented to the agent and the runtime behavior should be consistent, so that agents can correctly infer how to call MCP tools with required inputs.

Operating System

MacOS

Version Information

Version: 2.6.19 (Universal)
VSCode Version: 1.105.1
Commit: 224838f96445be37e3db643a163a817c15b36060
Date: 2026-03-12T04:07:27.435Z
Build Type: Stable
Release Track: Default
Electron: 39.4.0
Chromium: 142.0.7444.265
Node.js: 22.22.0
V8: 14.2.231.22-electron.0
OS: Darwin arm64 24.6.0

For AI issues: which model did you use?

Auto

For AI issues: add Request ID with privacy disabled

4f814b68-79ad-4e44-8d5a-a0c915c23a4c

Does this stop you from using Cursor

Yes - Cursor is unusable

9

I just pasted your message and asked “Try again accounting this info”, and it helped!)

1 Like
10

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

With Linear MCP connected, read-only Linear tools work (e.g. fetch issue, user, teams). Creating an issue via the agent fails. Failures include: (1) title is required when creating an issue even when the assistant intends to pass title and team, suggesting arguments are missing or not forwarded; (2) JSON parse errors mentioning tokens like F and corrupted/truncated field names (e.g. arentId instead of parentId) when parameters such as parentId: “FND-34” or assignee: “me” are used—consistent with invalid JSON (unquoted strings) or mangled serialization of tool arguments. Result: automated flows that create a Linear ticket (e.g. PR setup) cannot complete without manual ticket creation.

Steps to Reproduce

  1. Enable Linear MCP in Cursor and confirm reads work (e.g. get issue FND-34, list teams).
  2. In Chat, use Model: Auto.
  3. Ask the agent to create a Linear issue with fields such as: title (string), team (e.g. Foundation), state (e.g. In Review), assignee (me or explicit user), parentId (e.g. FND-34), and a short markdown description.
  4. Observe tool result: either title is required or a JSON parse error referencing invalid tokens / broken parentId in the error text.

Expected Behavior

save_issue should receive a complete, valid JSON argument object (all string values properly quoted). Linear should create the issue and return success (issue id/URL), same as when creating via the Linear UI or a correctly formed API request.

Operating System

MacOS

Version Information

Cursor: 2.6.20
VS Code: 1.105.1
Commit: b29eb4ee5f9f6d1cb2afbc09070198d3ea6ad760
Date: 2026-03-17T01:50:02.404Z
Build type: Stable
Release track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
OS: macOS (Darwin arm64 24.6.0)

For AI issues: which model did you use?

Auto

Additional Information

Read operations succeeded in the same session; create did not—points to argument serialization or MCP handling for save_issue, not total loss of Linear access.
If helpful for debugging, compare MCP logs for a successful read tool vs save_issue in one session.
Optional: attach a screenshot of the exact error string from the chat tool output if you still have it.

Does this stop you from using Cursor

No - Cursor works, but with this issue