CP tool-call arguments corrupted above a size threshold → "Unexpected non-whitespace character after JSON at position N"

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Environment: Cursor 3.9.16, macOS 15 (darwin 25.3.0)
MCP server: Atlassian plugin (cursor-public/atlassian), tool editJiraIssue (also reproduces content-independently)

Symptom
Calling an MCP tool with a large arguments object fails before reaching the server with:
“Failed to parse arguments string as JSON object: Unexpected non-whitespace character after JSON at position N”
The position N is always at/near the END of the args, i.e. valid JSON is parsed and then extra characters follow.

Key characteristics (point to client-side serialization, not the server)

  • Size-thresholded: small args always succeed; large args always fail. Threshold MOVED between builds (~256 bytes on a prior build → ~2900 bytes on 3.9.16), so it was raised but not fixed.
  • Content-independent: reproduces with plain filler text of sufficient size.
  • A/B proof it is client-side: the IDENTICAL payload (same Atlassian MCP server, same cloudId, same issue, same JSON) SUCCEEDS from claude.ai’s Atlassian integration and FAILS from Cursor. Only the client differs.

Hypothesis (matches a known analysis)
Cumulative args_text_delta snapshots being concatenated rather than replaced, producing garbled JSON like {"a":1{"a":1,"b":2... that a streaming parser reads as valid-then-trailing-garbage. See third-party write-up/fix:

Repro

  1. Configure any MCP server with a tool that accepts a string field.
  2. Call it with a small string value → succeeds.
  3. Call it with a large string value (a few KB) → fails with the parse error at position ≈ end-of-args.

Impact
Any MCP tool call with a moderately large argument is unusable from Cursor (e.g. writing a full Jira description), forcing fallbacks like raw REST.

Suggested fix
Use “latest cumulative snapshot wins” (or a merge) instead of concatenating args_text_delta; and/or add a tolerant parse/repair step before strict JSON.parse().

Steps to Reproduce

  1. Connect an MCP server that has a tool accepting a string field (repro’d with the Atlassian plugin’s editJiraIssue, but it is content-independent).
  2. In Agent chat, invoke the MCP tool with a SMALL arguments object (e.g. a short description string) → succeeds.
  3. Invoke the same tool with a LARGE arguments object (a few KB, e.g. a full multi-section Jira description) → fails before reaching the server with:
    “Failed to parse arguments string as JSON object: Unexpected non-whitespace character after JSON at position N”
    where N is at/near the END of the arguments (valid JSON parsed, then trailing characters).

Notes that isolate it to Cursor (client-side), not the MCP server:

  • Size-thresholded: small args always succeed, large always fail. The threshold MOVED across builds (~256 bytes previously → ~2900 bytes on 3.9.16), so it was raised but not eliminated.
  • Content-independent: reproduces with plain filler text of sufficient length.
  • A/B proof: the IDENTICAL payload (same Atlassian MCP server, same cloudId, same issue, same JSON) SUCCEEDS from claude.ai’s Atlassian integration and FAILS from Cursor. Only the client differs.

Expected Behavior

The MCP tool call should serialize the full arguments object as valid JSON and reach the MCP server, succeeding regardless of argument size (just as small arguments do, and just as the identical payload does from another MCP client). Large arguments should not be corrupted/truncated during the agent’s tool-call serialization.

Likely root cause (matches a known analysis): cumulative args_text_delta snapshots are concatenated instead of replaced, producing garbled JSON (valid object followed by trailing characters) that the parser rejects. A “latest cumulative snapshot wins”/merge strategy, and/or a tolerant parse-repair step before strict JSON.parse(), would fix it.

Operating System

MacOS

Version Information

IDE:
Version: 3.9.16
Commit:
Date:
Electron/Chromium/Node/V8:
OS: Darwin arm64 25.3.0

For AI issues: which model did you use?

Opus 4.8 Medium context

Additional Information

Severity/threshold detail: the failing position scales with argument size and lands at the END of the args (valid JSON parsed, then unexpected trailing characters) - classic symptom of cumulative arg snapshots being concatenated rather than replaced. The byte threshold increased between builds (~256B → ~2900B on 3.9.16) but the bug was not eliminated, so it will keep resurfacing as payloads grow.

Strongest evidence it is client-side (Cursor), not the MCP server or model:

  • The IDENTICAL payload (same Atlassian MCP server, same cloudId, same Jira issue, same JSON) SUCCEEDS from claude.ai’s Atlassian integration and FAILS from Cursor. Only the client differs.
  • Content-independent: reproduces with plain filler text of sufficient length.
  • Small args always succeed; large always fail.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

6

Thanks for the write-up - the A/B against claude.ai, the size-threshold data, and the content-independence evidence all point the same direction, and the code path you’re hitting is real (client-side, before the request reaches the MCP server). This is a known class of bug on our side.

We’ve seen a narrower variant of this before (array-type parameters getting mis-serialized) and your report confirms it extends to any large argument regardless of content. I’ve flagged this to the team.

While it’s being addressed, the most reliable workaround is to keep each MCP tool-call argument small and build up in steps. For the Jira case: create/edit the issue with a short description first, then append the rest in follow-up calls. Anything well under a couple of KB should go through cleanly.

Let me know if things improve on the next stable update, or if the step-wise approach still gives you trouble at smaller sizes.

7

Thanks, Mohit. I didn’t experience this issue yesterday, but it returned for me again today in one of my chats. I struggle to work around it, the model often tries to work around it by cutting out critical content for the jira description instead of incremental appends. It also seems to be costing significantly more tokens to work through this issue vs. success on the first request.

Is there any rough ETA on when a fix for this might be expected?

8

No timeline we can share yet. The intermittent pattern (fine one day, broken the next on the same kind of flow) is real, and it also explains why the step-wise workaround is costly: when a call fails, the model often retries by dropping sections instead of appending them, so tokens and critical content both suffer.

While this is still open, what tends to hold up best:

  1. Start a fresh chat for the Jira write (long-running threads seem more likely to trigger it).
  2. Explicit instruction: never drop or summarize sections — if an editJiraIssue call fails, retry the same content as-is.
  3. Keep each field update under ~1–2 KB, one section at a time.

If you can share a Request ID from one of today’s failing calls (chat menu → Copy Request ID) and confirm whether you’re still on 3.9.16 or a newer build, that helps us catch the intermittent path.