MCP Agent always returns Internal Error on Windows

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Somewhere else…

Describe the Bug

MCP server is configured and working correctly (tested manually via CLI).
But Agent always returns “Internal Error” when trying to call MCP tools.
All modes fail: Agent, Debug, Plan, Opus 4.8, Sonnet 4.6.
OS: Windows 11

Steps to Reproduce

  1. Configure MCP server in ~/.cursor/mcp.json
  2. Verify MCP shows “2 tools enabled” (green)
  3. Open Agent and type: 統合辞書DBで「東京」を検索して
  4. Agent returns Internal Error immediately

Expected Behavior

Agent should call MCP tool and return search results from the database

Operating System

MacOS

Version Information

3.6.31
81cf2931d7687b4ff3f3017858d0c6dee7e2a60
x64

For AI issues: which model did you use?

Sonnet 4.6, Opus 4.8 (both fail)

For AI issues: add Request ID with privacy disabled

3c71741c-6f6d-4f72-b45a-6a1fcfe2f558
991db5c3-cf6f-4efd-b233-6ca7ca1f4644
d2b4049b-5950-4e75-9132-aaf1372bc827

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey, thanks for the detailed report. “Internal Error” in this kind of setup (tools show as green, the handshake succeeds, but the call fails right away) usually means the MCP server itself is returning an error when the tool is invoked, and the agent is just passing it through. Let’s narrow down the cause.

First, a few things:

  1. Update Cursor. You’re on 3.6.31, which is a few releases behind, and there have been a lot of MCP fixes since then. The issue might already be fixed.

  2. The fact that MCP “works via CLI” but not in the IDE is important. The IDE agent starts the stdio server with a different working directory and a different set of env vars than your manual CLI run. Make sure the DB path and any required env vars are set directly in ~/.cursor/mcp.json, not pulled from your shell environment.

  3. Your prompt includes Japanese text and full-width characters (「東京」). It’s worth checking whether the server handles non-ASCII arguments correctly. That’s a common place where a handler crashes even when the tools list looks fine.

To dig deeper, please share:

  • The MCP server logs: Output panel → select your MCP server channel. It usually shows the real error (stderr).
  • A fresh Request ID with Privacy Mode turned off (repeat a simple tool call).

That should be enough to see exactly where it’s failing. Let me know how it goes after the update.

6

Thanks for the quick response!

  1. I checked the MCP logs (Output > MCP: user-multilingual-dict).
    It only shows connection logs, no tool call errors:

    • Successfully connected to stdio server
    • CreateClient completed, connected: true
      The Internal Error happens before any tool is actually called.

  2. New Request ID (Privacy Mode off): 9a5171c4-9774-44f3-b1fc-2817c0a754ef

  3. The MCP server works correctly via CLI (tested with Japanese keywords
    like 鹿児島, returns correct results).

It seems the error is happening on Cursor’s cloud side before
reaching the MCP server. Could this be related to Cursor version 3.6.31?

7

Hi Dean,

Here’s an update after further testing:

What I’ve tried:

  1. Added full Python path and env vars to mcp.json (PYTHONIOENCODING, SSH_ASKPASS, etc.)
  2. Added “timeout”: 30 to mcp.json
  3. Tested SSH without terminal → works fine, returns OK in ~3 seconds
  4. Tested MCP server manually via CLI → works perfectly, Japanese keywords (東京、鹿児島) return correct results

What the logs show:

  • MCP connects successfully every time (“connected: true, statusType: connected”)
  • But every tool call returns Internal Error immediately
  • No tool call errors appear in the MCP logs at all — the error seems to happen on Cursor cloud side before reaching the MCP server

New Request IDs (Privacy Mode off):

  • 0b6397cf-fd…
  • 2ac21aa0-8c…

Environment:

  • Cursor version: 3.6.31 (x64)
  • OS: Windows 11
  • Model: Opus 4.8 MAX

Is there any way to see server-side logs for these Request IDs?
Also, should I try updating Cursor to the latest version first?

Thanks!

8

Thanks for the detailed update, it really helps.

On your two questions:

  1. Update first. 3.6.31 is a few releases behind, and we shipped a bunch of MCP fixes since then. The fact that the server connects (connected: true), but any tool call instantly fails with “Internal Error” before anything shows up in the server logs, looks like a client-side issue that may already be fixed. So please update Cursor and rerun the test before doing any more debugging.

  2. About server-side logs for a Request ID, unfortunately users don’t have access to those, and we don’t provide per-Request ID logs. The best way forward is to remove variables, update and test in a clean environment.

If “Internal Error” still happens after updating, please send:

  • A fresh Request ID with Privacy Mode turned off, captured on the new version.
  • The exact error text from the agent UI (including any expanded details), not only the MCP Output panel.

Also please double-check that the IDE agent starts the stdio server with the same cwd and env as your CLI run. They can differ, and that’s a common reason why it works via CLI but not in the IDE. Put all required paths and env vars directly in ~/.cursor/mcp.json instead of relying on your shell environment.

Let me know how it goes after the update.