Sanity MCP Server Cursor IDE Setup (2026)

How do you set up the Sanity MCP server in Cursor? As of 2026, add a sanity entry pointing at the remote server https://mcp.sanity.io with "type": "http" to ~/.cursor/mcp.json, restart Cursor, and authorize via OAuth in the browser — no Node install, no API token to generate or paste anywhere. This is a genuine change worth knowing about: the older @sanity/mcp-server npm package that most existing tutorials describe is deprecated and its repository archived. If you're following a guide that has you running npx @sanity/mcp-server with SANITY_PROJECT_ID and SANITY_API_TOKEN environment variables, that's the legacy path — it may still function, but Sanity has moved development to the hosted server described here.

Sanity is a headless CMS — content lives in a structured dataset, and the actual website or app is a separate codebase that queries it via GROQ or GraphQL. That split is exactly why an MCP connection is useful: your AI can read and write real content in the dataset while you're working in the frontend codebase, instead of you switching to Sanity Studio to check what a field is actually called.

What Changed: Deprecated Local Package vs. Current Remote Server

| | Old (@sanity/mcp-server, deprecated) | Current (mcp.sanity.io) |
|---|---|---|
| Where it runs | Locally via npx, needs Node | Remote, hosted by Sanity |
| Auth | SANITY_API_TOKEN (env variable) | OAuth (browser authorization) |
| Setup | Install package, set SANITY_PROJECT_ID / SANITY_DATASET / SANITY_API_TOKEN / MCP_USER_ROLE | One url entry in mcp.json |
| Maintenance status | Archived, no longer maintained | Actively developed, "continuously updated tools" per Sanity's own docs |
| Transport | Local process (stdio) | Streamable HTTP |

If you copy a config from an older blog post or a cached search result and it doesn't work, this table is almost certainly why — Sanity replaced the whole integration pattern, not just a version number.

What You Can Do With Sanity MCP in Cursor

Prerequisites

Step 1: Add the Remote Server to mcp.json

Open ~/.cursor/mcp.json (or Settings → MCP in Cursor) and add:

{
  "mcpServers": {
    "sanity": {
      "url": "https://mcp.sanity.io",
      "type": "http"
    }
  }
}

That's the entire local configuration — there's no token field, no project ID, no dataset name in this block. Project and dataset selection happens after authorization, inside the OAuth flow and subsequent tool calls, not hardcoded into the config file.

Step 2: Authorize via OAuth

Restart Cursor. On the first tool call that touches Sanity, Cursor opens a browser window for Sanity's authorization screen. Sign in, select which project(s) the connection can access, and approve. Unlike the deprecated token-based setup, there's nothing to copy back into your config — the authorized session is what grants access.

Step 3: Verify the Connection

In Cursor chat, try:

List the document types in my Sanity schema

or

Show me the 5 most recently updated documents in my Sanity dataset

A response naming real document types or documents confirms the connection. If you're prompted to re-authorize repeatedly, check that your Cursor version fully supports HTTP-transport remote servers rather than just SSE — the two aren't identical under the hood, even though both are "remote."

Practical Workflows

Schema-aware content generation

Check the schema for the "post" document type, then draft 3 new blog post documents matching that exact field structure — don't invent fields that aren't in the schema

Pre-deploy content audit

Find all "product" documents where the price field is empty or the slug conflicts with another document

Cross-reference frontend and content

I'm editing the ProductCard component in /src/components/ — show me a real product document from Sanity so I can confirm the component handles every field that's actually populated, including optional ones

Migration prep

List every document type in the current schema along with a rough count of documents per type, so I can plan a migration to a new schema version

If You're Migrating Off the Deprecated Local Package

If your team has an existing @sanity/mcp-server config with SANITY_PROJECT_ID, SANITY_DATASET, and SANITY_API_TOKEN set as environment variables, moving to the hosted server means:

1. Removing the old env-based block from mcp.json entirely
2. Adding the url/type: "http" block from Step 1 above
3. Re-authorizing over OAuth instead of relying on the stored API token
4. Revoking the old API token in Sanity's project settings once you've confirmed the new connection works — a token that's no longer referenced in any config is still a live credential until you revoke it

There's no dataset or project ID to migrate over manually; that selection happens through the OAuth flow instead of being hardcoded.

Troubleshooting

Config from an older tutorial doesn't connect
Check whether it's using the deprecated @sanity/mcp-server npm package pattern (SANITY_API_TOKEN as an env variable). That package is archived — switch to the mcp.sanity.io remote server described above.

OAuth screen doesn't show the project I expect
The authorization is scoped to whatever Sanity account you signed in with in the browser popup. If you're a member of multiple Sanity organizations, confirm you authorized under the account that actually has access to the project you want — a different logged-in Sanity account in your browser is a common mismatch here.

"Type not recognized" or the server doesn't appear at all
Your Cursor version may not support "type": "http" remote entries yet. Update Cursor, or fall back to whatever remote-server format (often just url without an explicit type) your current version documents.

Generated document doesn't match my actual schema
Ask Cursor to inspect the schema for that document type before generating content, rather than assuming it remembers your schema correctly from earlier in the conversation — schemas change, and a stale assumption produces a document with fields that don't exist or are named slightly differently than what you actually defined.

Old local server references still show up when I search for setup help
This is expected right now — most existing Sanity MCP content on the web (blog posts, forum answers, cached tutorials) predates the deprecation and still describes the local package. Cross-check anything you find against Sanity's own current docs at sanity.io/docs/ai/mcp-server before trusting a specific env-variable name or package version.

Frequently Asked Questions

Q: Is the old @sanity/mcp-server npm package still usable, or fully broken?
A: It's deprecated and its repository archived, meaning no further updates or bug fixes — but a previously working install may continue to function since Sanity hasn't necessarily disabled the underlying API access it relied on. Don't build new setups against it; Sanity's own guidance points to the hosted mcp.sanity.io server for anything current.

Q: Why does the new setup not require a project ID or dataset name in the config?
A: Because authentication moved from a static API token (which the old package paired with explicit SANITY_PROJECT_ID/SANITY_DATASET env variables) to an OAuth session, where project and dataset selection happens as part of authorizing the connection and making tool calls, not as hardcoded config values.

Q: Do I need Node.js installed to use Sanity MCP now?
A: No, not for the current remote-server setup — that's one of the stated advantages of the hosted server over the deprecated local package, which did require a Node-based npx process.

Q: Can the Sanity MCP server write real content, or is it read-only?
A: It supports both reading and creating/updating documents, scoped to whatever access the authorizing Sanity account has for that project. Since write actions affect real content in your dataset, review what a prompt is about to create or change before confirming it, the same as you would with any other write-capable MCP server.

Q: I manage multiple Sanity projects — can one MCP connection reach all of them?
A: Project access is granted during the OAuth authorization step, and which projects you can select depends on what your Sanity account has access to. If a project isn't showing up, it's usually because the account you authorized with doesn't have access to it, not a limitation of the MCP connection itself.

Related Guides

---