Connect Cursor to Any REST API via MCP

By Mark Kuhn · May 21, 2026 · 5 min read

How to give Cursor's agent access to your REST API through an MCP server — the mcp.json config, project vs global scope, and how to actually get the agent to use your tools.

Cursor's agent is already good at reading your codebase. What it can't do out of the box is reach the systems your code talks to — your API, your database behind an API, the third-party service you integrate with. MCP closes that gap. Wire an MCP server into Cursor and the agent can call your API while it works, which turns "help me write this integration" into "help me write this integration and test it against the real endpoint."

This is a short one because the setup genuinely is short. You'll need an MCP server URL and access token already in hand — if you don't have those, wrap an API into a server first, then come back. And if MCP itself is new, the fundamentals post is the better starting point.

Where Cursor keeps MCP config

Cursor reads MCP servers from a file called mcp.json, and you get to choose how widely it applies:

Global — ~/.cursor/mcp.json in your home directory. The server is available in every project you open.
Project — .cursor/mcp.json in a specific repo. The server only exists for that project, and you can commit it (without secrets — more on that below) so your teammates get the same tools.

The easiest way in is through the app: open Settings, find the MCP section, and there's an "Add new MCP server" button that opens the right file. Project scope is the one I reach for most, because "this repo can talk to this API" is usually exactly the boundary you want.

The configuration

The shape matches what you'd write for any MCP client:

{
  "mcpServers": {
    "my-api": {
      "url": "https://api.api2mcp.io/mcp/<your-server-id>",
      "headers": {
        "Authorization": "Bearer <your-access-token>"
      }
    }
  }
}

The url is the MCP server endpoint API2MCP gave you, and the Authorization header carries the server's access token. That token lets Cursor use the server — it is not your upstream API key, which stays encrypted on the server side and never touches this file. That's the point worth repeating: because the sensitive credential lives on the server, dropping this config into a project repo is reasonable. Still, treat the access token like any secret — if you commit .cursor/mcp.json, pull the token out into something like an environment reference rather than hardcoding it where it lands in git history.

Turn it on and check the dot

After saving, go back to the MCP settings panel. Your server should appear with a status indicator — a green dot means Cursor connected and pulled the tool list, and you'll see the tools enumerated under the server. If the dot is red or spinning, connection failed; skip to troubleshooting below.

Cursor also lets you toggle individual servers and even individual tools on and off from this panel. That's genuinely useful: if a server exposes forty endpoints and you only want the agent reaching for three of them in this project, disable the rest and keep the agent focused.

Getting the agent to actually use it

Here's the part people miss. MCP tools are used by Cursor's agent (Composer in Agent mode), not by inline autocomplete or a plain chat question. So open the agent, and either let it decide a tool is relevant or nudge it directly: "Use the my-api tools to look up order 4821 and tell me its status."

When the agent decides to call a tool, Cursor shows you the call and — depending on your settings — asks you to approve it before it runs. Approve it, and the agent calls through your MCP server to the live API, gets the response, and keeps going with real data in hand. You can set tools you trust to auto-run so you're not clicking approve on every read, but leaving approval on for anything that writes is a habit worth keeping.

When the dot is red

The failure modes are familiar if you've set up MCP anywhere else:

Connection fails immediately. Ninety percent of the time it's malformed JSON — a stray comma, curly quotes, a missing brace. Validate the file. The other ten percent is a bad URL; make sure it's the MCP server URL, not your API's base URL.

Connected, but calls come back unauthorized. The access token is wrong or has a leading/trailing space. Regenerate it and paste it clean. As with any MCP setup there are two auth layers — Cursor to the server (this token) and the server to your API (the upstream key you configured when registering the provider). Knowing which layer is which saves real time when you're staring at a 401.

Tools are there but the agent ignores them. It doesn't see them as relevant. Reference the tool or server by name in your prompt, and check that the tool descriptions in your source spec are specific enough for a model to match on. A tool called getData with no description is a tool the agent will never reach for on its own.

Why this is worth two minutes

Once it's wired up, Cursor's agent can develop against your API instead of just about it. Ask it to build a client for an endpoint and it can call that endpoint to check its assumptions. Ask it to debug a failing integration and it can reproduce the call live. The loop tightens because the agent isn't guessing at what your API returns — it can just ask.

If you've already set this up in Claude Desktop, you'll notice it's the same server, the same token, a near-identical config — that's the nice thing about MCP being a standard. One server, every client. If you haven't wrapped an API yet, start free and you'll have a server to point Cursor at in a few minutes.