Sanity MCP Server Error

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Sanity Remote MCP intermittently becomes unusable in Cursor due to aggressive MCP discovery and resource prefetching.

After OAuth succeeds, Cursor repeatedly calls MCP discovery endpoints (ListOfferings, ListToolsRaw) and aggressively prefetches MCP resources (sanity://rules/*). This triggers Sanity MCP rate limiting (429 Too Many Requests). Cursor ignores the retryAfter value and immediately retries, causing the MCP server to enter a degraded state where 0 tools / 0 resources are reported until Cursor is fully restarted.

This is a regression. The same Sanity MCP setup worked reliably in previous Cursor versions.

Steps to Reproduce

  1. On Windows 10/11, add Sanity Remote MCP in Cursor using OAuth (https://mcp.sanity.io).
  2. Enable the Sanity MCP server.
  3. OAuth completes successfully and tools initially appear.
  4. Cursor immediately issues repeated ListToolsRaw and ReadResource calls (sanity://rules/*) in parallel.
  5. Sanity MCP responds with 429 Too Many Requests.
  6. Cursor ignores retryAfter and continues retrying.
  7. MCP tools/resources intermittently drop to 0 and remain unusable until Cursor is fully restarted.

Toggling the Sanity MCP server off/on increases the likelihood of triggering the issue.

Expected Behavior

Cursor should cache MCP tool and resource discovery per session and respect retryAfter on 429 responses. After successful OAuth and initial discovery, the MCP server should remain stable and usable.

Operating System

Windows 10/11

Version Information

Version: 2.4.22 (user setup)
VSCode Version: 1.105.1
Commit: 618c607a249dd7fd2ffc662c6531143833bebd40
Date: 2026-01-26T22:51:47.692Z
Build Type: Stable
Release Track: Default
Electron: 39.2.7
Chromium: 142.0.7444.235
Node.js: 22.21.1
V8: 14.2.231.21-electron.0
OS: Windows_NT x64 10.0.26200

Does this stop you from using Cursor

No - Cursor works, but with this issue

3

Hey, thanks for the report.

This looks like a regression in the MCP client implementation. We fixed similar spamming before v2.4, but you’re on 2.4.22, and the retryAfter issue is a separate story.

Could you clarify:

  • What was the last Cursor version that worked fine?
  • Do you see any errors in the logs? (Help > Toggle Developer Tools > Console tab, when the issue happens)

For now, the only workaround is a full restart of Cursor, like you already found. Toggling the server off and on seems to trigger the issue more often.

I’ll pass this to the team. Ignoring retryAfter on 429 responses isn’t good API practice. Let me know the version and logs, and a screenshot would help if you can grab one.