Desktop MCP sync materializes about 30 tools for large HTTP MCP server while CLI mcp list-tools reports 261 (same config)

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

I use a remote HTTP MCP server with OAuth that exposes a large aggregated tool catalog (hundreds of tools). The Cursor desktop app only exposes a small subset to the agent through dynamic MCP discovery (GetDynamicTools and the on-disk mcps catalog under the project folder). The Cursor CLI using the same user MCP configuration lists the full tool set. In the IDE I see failures such as tool not found, and pattern search only finds tools that were written to disk. The CLI works for the same server and config.

Steps to Reproduce

  • Configure a remote HTTP MCP server with OAuth in user MCP config, with a large tool catalog.
  • Authenticate so the server is connected in both Cursor desktop and the CLI.
  • In the CLI run: cursor-agent mcp list-tools SERVER_NAME piped to wc -l. I get 261 tools (observed 2026-09-15).
  • In the desktop app, open a project and use Agent or wait for MCP sync.
  • Count files in .cursor/projects/PROJECT_ID/mcps/SANITIZED_SERVER_ID/tools/. I get 30 JSON files. The same 30 count appears across multiple projects.
  • In desktop Agent, search for or call a tool that appears in the CLI list but not in that on-disk folder. Result is tool not found or no match in GetDynamicTools pattern search.

Actual behavior:

CLI cursor-agent mcp list-tools for the same HTTP server: 261 tools.

Desktop on-disk catalog under mcps/SERVER/tools/: 30 JSON files.

GetDynamicTools for that namespace: about 31 entries, matching what is on disk (a small prefix of tools from one backend plus one vendor meta-tool described as searching tools by context when many are available).

Most tools visible in the CLI list are missing from the desktop catalog and from pattern search.

Other MCP servers in my config use local stdio transport and appear to sync their full tool counts to mcps. The problem is specific to this large HTTP server.

Expected Behavior

Desktop should expose the same MCP tool catalog as the CLI for the same server and configuration, including full tools/list handling and pagination if the server uses nextCursor. GetDynamicTools and CallDynamicTool should work for any tool the server advertises, not only the subset written under mcps.

Operating System

MacOS

Version Information

Version: 3.20.17
VS Code Extension API: 1.128.0
Commit: 0c32194e3fb5ffaced9fb36430b860ec301e1fc0
Date: 2026-09-12T03:16:10.634Z
Layout: Agent Window
Build Type: Stable
Release Track: Default
Electron: 42.10.0
Chromium: 148.0.7778.280
Node.js: 24.18.1
V8: 14.8.178.38-electron.0
xterm.js: 6.1.0-beta.291
OS: Darwin arm64 25.6.0

About Cursor CLI

CLI Version 2026.09.10-fd3934a
Latest 2026.09.10-fd3934a (up to date)
Model Composer 2.5 Fast
Subscription Tier Enterprise
OS darwin (arm64)
Terminal iterm2
Shell zsh

Does this stop you from using Cursor

Yes - Cursor is unusable

6

Hey @Marco_Stadler, thanks for the detailed report, and you have diagnosed it correctly.

Your gateway returns its tool catalog in pages (30 per page, with a nextCursor), and the Cursor desktop MCP client currently only reads the first page. The CLI follows nextCursor until the list is exhausted, which is why it sees all 261. This is a known issue we are already tracking and nd I have added your report to it. I’ll keep this thread updated!

Until then, two ways to get the full catalog on desktop:

  1. If you control the gateway, raise its tools/list page size above the total tool count so everything comes back in a single response without a nextCursor.
  2. If you cannot change its paging, front it with a thin MCP proxy that calls tools/list in a loop and returns one merged page. Cursor connects to the proxy instead of the gateway.

Cloud Agents and the CLI already handle paginated servers, so those are unaffected in the meantime.