Cursor is the product that connects to MCP servers, not one that serves them. What it exposes to other agents is a set of REST APIs, each with its own key type, plan requirement, and rate limit, plus community MCP wrappers around one of those APIs. This guide compares what each path lets an agent do with Cloud Agents, team spend, and analytics, the three key types and their blast radii, and how to hold Cursor keys for many customer teams in production.
Your agent needs to work with Cursor on your customers' behalf: kick off a Cloud Agent to fix a failing test, follow up on its pull request, report what each agent run cost, or pull a team's AI code share for an engineering dashboard. You go looking for a Cursor MCP server the way you would for Linear or Notion, and you find the reverse. Cursor is the product that connects to MCP servers. What it exposes to other agents is a set of REST APIs, each with its own key type, plan requirement, and rate limit. The MCP options that exist are community wrappers around one of those APIs. Here's how to pick, and what each path does to your credential model.
Cursor's MCP documentation describes Cursor as a Model Context Protocol (MCP) client. It supports three transports (stdio, SSE, and Streamable HTTP), runs the OAuth Authorization Code flow with PKCE for remote servers that require it, and reads server definitions from .cursor/mcp.json in a project or ~/.cursor/mcp.json globally. Cloud Agents can use team MCP servers configured under Dashboard > Plugins & MCPs. None of that lets your agent call into Cursor.
The one MCP server Cursor runs itself is the Origin MCP server at https://api.origin.cursor.com/mcp, with a read-only variant at /mcp/readonly. It gives agents access to repositories and pull requests hosted on Origin, Cursor's code forge, over stateless Streamable HTTP. Cursor marks Origin as Early Beta and says the Origin MCP server is currently available only in Cursor and Grok Bot. It does not cover Cloud Agents, team members, usage, or analytics.
For those, the MCP path is community-built. The most cited is cursor-cloud-agent-mcp, an MIT-licensed npm package from an individual developer's account. It runs locally over stdio or on localhost:3000/mcp, reads CURSOR_API_KEY from the environment, and exposes 9 tools: get_repos, get_me, get_models, create_task, list_tasks, get_task, add_followup, get_conversation, and delete_task. Other community servers wrap the same API with different tool sets. None of them is affiliated with Cursor.
Cursor's API overview lists several APIs on https://api.cursor.com, and the key type is what separates them:
Basic auth means the key is the username with an empty password (curl -u "$CURSOR_API_KEY:"). User API keys come from Cursor Dashboard > API Keys. Service account keys are created by admins under Settings > API Keys > Service Accounts and are Enterprise only. Team Admin keys are created by team administrators and are viewable by every admin in the organization.
The community MCP server is a thin, chat-friendly slice of the Cloud Agents API. Everything a team lead or platform engineer cares about, from spend to audit logs to how much of last week's code came from Composer, lives in APIs that no MCP server covers and that require a different key.
Launching and checking on a Cloud Agent is a natural chat interaction. "Start an agent on acme/web to fix the flaky checkout test, open a PR, and tell me when it's done" maps to create_task and a few get_task calls, and a developer in Claude Code gets that without writing tool definitions. For a single developer driving their own agents from another assistant, that is the right amount of surface.
The API makes you do the schema work. POST /v1/agents has mutually exclusive fields (repos versus a named cloud environment), PR-specific rules (pr_url overrides starting_ref, and the repository URL must still be set), model parameters that differ per model, and a 409 agent_busy when you send a follow-up while a run is active. An LLM needs a tool description that encodes those rules or it will fail on the second call. Writing the schema is the hard part. Not the API call.
Every community Cursor MCP server works the same way: it reads one CURSOR_API_KEY from the environment of the machine running it. There is no OAuth flow, no consent screen, and no per-user session. On a developer laptop that is acceptable. In a product, it means one key per server process, and every agent that connects to that process acts as that key's owner.
That owner matters. A user API key acts as one Cursor user: it can see that user's Cloud Agents, launch new ones against any repository the user reaches through Cursor's GitHub App, and spend that user's usage allowance. The community server's delete_task tool deletes agents with it.
The direct path is where Cursor's key model shows up in full, and the differences are not cosmetic.
User API keys authenticate the Cloud Agents API and the SDKs. They act as one user. This is the right credential for an agent that launches Cloud Agents on a specific developer's behalf. What the user can't do, the agent can't do: repositories outside the user's GitHub App reach return errors, and agents are listed per owning user.
Service account API keys also authenticate the Cloud Agents API, but act as a non-human account that draws from the team's usage pool with its own spend limit. Rotation in the dashboard invalidates the old key immediately and shows the new one once. An agent-scoped service account key can call POST /v1/sub-tokens with forUserEmail or forUserId to mint a one-hour token for a specific team member; the token cannot refresh itself, so the service account mints a new one when needed. That is Cursor's own answer to "act as this user without holding their key," and it is Enterprise only.
Team Admin keys are for the Admin, Analytics, and AI Code Tracking APIs. A read:* key reads members, usage, and audit logs. An admin:* key also sets spend limits, removes members, and edits model access policy and repository blocklists. Cursor's Python SDK docs state that Team Admin keys are not yet supported there, and the Cloud Agents API documents only user and service account keys. An admin key is an org-level credential, not a per-user one.
Cursor's own reference makes one more distinction you will hit: Origin uses neither. Cursor API keys are not valid Origin Bearer tokens; Origin apps sign a short-lived EdDSA JWT and exchange it for an installation token.
In a multi-tenant B2B agent, the MCP path gives you a credential per user and the direct API gives you a credential per user. In neither case does the path itself solve storage, rotation, or revocation; those are infrastructure problems regardless of which path you choose.
Cursor adds a classification problem. A customer's developers each hold a user API key, and the customer's admin holds a Team Admin key. A usage dashboard agent needs the admin key; a "fix this bug" agent needs the developer's key. If both land in the same table with the same lookup path, a bug in tenant or user resolution hands an admin:* key to an agent that was only supposed to open a PR.
Recommended reading: OAuth vs API keys for AI agents
You own the server. Community packages are not hosted by Cursor, carry no SLA, and track the Cloud Agents API only as fast as their maintainer does. The Cloud Agents API v1 is in public beta and Cursor says "APIs may change before general availability," so a community tool can break on a field rename with no warning. You also own the process that holds CURSOR_API_KEY, which in a multi-user deployment means one process per user or a shared key you should not have.
You own retries, pagination, and the token lifecycle, and the rate limits are low enough to shape your design. Most Admin API endpoints allow 20 requests per minute per team, /teams/filtered-usage-events allows 60, and a 429 carries Retry-After: 60 on some routes. Analytics allows 100 per minute on team endpoints, 50 on by-user endpoints, and 20 on conversation insights. AI Code Tracking allows 20 per minute per endpoint. Listing repositories on the Cloud Agents API is capped at 1 call per minute and 30 per hour per user, so an agent that calls it before every launch will stall.
Two details save rate budget. Analytics and AI Code Tracking responses carry an ETag and Cache-Control: public, max-age=900; send If-None-Match and a 304 costs nothing against the limit. Audit log and daily usage queries cap at 30 days per request, and daily usage is hourly data that Cursor recommends polling at most once per hour.
Agent completion is the other design decision. On v1 you poll GET /v1/agents/{id}/runs/{runId} until the run leaves CREATING, RUNNING, or WAITING_FOR_BACKGROUND_WORK, or you hold an SSE stream open. On the legacy v0 API, creating an agent with a webhook URL gets you a statusChange POST when the agent reaches FINISHED or ERROR, signed with HMAC-SHA256 in X-Webhook-Signature as sha256=<hex_digest> over the raw body, with X-Webhook-ID for dedupe. Cursor says deliveries "may be retried" on error responses and gives no schedule, so idempotency is on you.
The Admin API marks model access and bulk spend limit routes as preview. AI Code Tracking is alpha, and Cursor warns that response shapes may change and that commit hashes "are not unique or unchangeable." The Cloud Agents API moved from v0 to v1 with new resource names (agents and runs, not tasks). Every one of those changes lands on whoever owns the tool schema.
Both paths hand you a Cursor key per user. Neither hands you a vault. A multi-tenant agent serving 40 customer teams with 10 developers each is 400 user API keys, plus up to 40 Team Admin keys if the agent also reports on usage. Each user key is bound to one person's repository access and usage; each admin key can change spend limits for a whole team. Each must be stored encrypted, kept out of logs and LLM context, replaced when a user rotates it, and deleted when a developer leaves.
There is no refresh to automate here, which makes revocation the hard part. Cursor's API docs describe no expiry for these keys the way OAuth access tokens expire. A developer who leaves a customer company still has a valid key in your store until someone deletes it in the Cursor dashboard or your system. The tempting shortcut is one service account key per customer. It works on the Cloud Agents API, but it collapses every developer's agents into one non-human identity, and it requires Enterprise.
Scalekit's cursor connector stores each user's Cursor API key as their connected account in the token vault and sends it with every call, so the MCP vs API decision doesn't change your auth infrastructure. Your agent passes an identifier; the key never enters the agent runtime or the LLM context.
Recommended reading: why a token vault matters for AI agent workflows
Scalekit's cursor connector is an API-path connector with 24 tools over the Cloud Agents API v1: 19 read and 5 write, with no destructive tools. It covers agents, runs, artifacts, saved environments and builds, models, repositories, secrets metadata (never values), and API key info. It does not cover the Admin, Analytics, or AI Code Tracking APIs. It authenticates with a bearer token: each user enters their own Cursor user API key once through a Scalekit-hosted page, and Scalekit stores it as that user's connected account.
In the Scalekit dashboard, go to AgentKit > Connections and create a Cursor connection. The name you give it is the connection_name your code passes, and the string must match the dashboard exactly. This is the most common integration error. Copy SCALEKIT_ENVIRONMENT_URL, SCALEKIT_CLIENT_ID, and SCALEKIT_CLIENT_SECRET from Developers > API Credentials into .env.
Tell users which key to paste: a user API key from Cursor Dashboard > API Keys. A Team Admin key belongs to the Admin and Analytics APIs and is the wrong credential for Cloud Agents.
get_or_create_connected_account returns the user's connected account. If it is not ACTIVE, get_authorization_link returns a link to the page where the user enters their Cursor API key. There is no Cursor OAuth screen; the link replaces it. The agent never sees the key.
The cursor_me_get call is worth keeping. It returns the key's name and the owning user's email, which is how you catch a user who pasted a colleague's key or a service account key.
This is not a catalog load. The agent asks for the tools this user's connected account is authorized to call, then narrows them to the five a coding-delegation agent needs. Loading all 24 would put cursor_environment_update, which replaces an environment's entire configuration, and cursor_secrets_list in front of a model whose job is to start an agent and report on it. cursor_repositories_list is also left out on purpose: at 1 call per minute per user, a model that calls it on every turn will hit the limit.
The loop runs until the model stops requesting tools. Every call executes with this user's Cursor key, so every Cloud Agent it launches is owned by and billed to this user, against repositories this user can reach.
For pipelines, skip the model. execute_tool runs one tool with a fixed input and returns data plus an execution_id you can log. This job launches a Cloud Agent when a CI check fails, then polls the run until it reaches a terminal status. Passing your own agent_id makes the launch idempotent: a retried job gets 409 agent_id_conflict instead of a duplicate agent.
If the run finishes and needs another pass, cursor_run_create sends a follow-up to the same agent with a new prompt; it fails with 409 agent_busy while a run is active, and cursor_run_cancel clears a stuck one. The connector targets v1, which has no webhooks yet, so polling is the completion model. For Admin or Analytics endpoints, register a custom connector with the Team Admin key as its credential and make proxied calls through actions.request(), keeping it in a separate connection from developer keys.
The cursor connector has 24 tools. At roughly 200 tokens each, that is about 4,800 tokens of tool definitions before the agent does any work, and a model choosing between cursor_secrets_list, cursor_team_secrets_list, and cursor_environment_secrets_list has three ways to answer a question it should not be asking. Overreach is the second risk: a triage agent holding cursor_environment_update can rewrite the install commands every future Cloud Agent boots with. A Scalekit virtual MCP server declares exactly which tools an agent role can see, and session tokens keep each run bound to one user's connected accounts. Docs: set up a virtual MCP server.
It also fills the gap in Cursor's own lineup. Cursor has no MCP server your agents can call for Cloud Agents; a virtual MCP server gives you one that is hosted, per-user, and limited to the tools you choose.
One server definition serves every user. Before each run, check that the user's accounts are active and mint a short-lived session token scoped to them. Any MCP client that speaks Streamable HTTP can connect, including Cursor itself; this example uses langchain-mcp-adapters (pip install langchain-mcp-adapters) and passes the token as a Bearer header.
The agent sees four tools instead of 24. It can launch a Cloud Agent, follow up, check status, and post to Slack; it cannot touch environments or list secrets. The endpoint is static; the identity is per-user. Unlike a community MCP server, no process holds a CURSOR_API_KEY in its environment, and one definition serves every developer at every customer.
Every execute_tool call returns an execution_id, and every execution is attributed to a connected account, which maps to one of your users and one customer. When a customer asks which agent run launched 30 Cloud Agents overnight, or who opened the PR that rewrote their checkout flow, the answer is a lookup, not an investigation. Cursor's side lines up: the Cloud Agent is owned by the user whose key created it, and that user's usage appears in the team's analytics and billing.
A shared credential breaks that. If every developer's agent runs on one service account key, Cursor attributes every agent and every dollar to the service account, /teams/spend shows one line instead of ten, and your side can only prove that the shared key did it. Shared credentials are a single-user solution. They do not survive a second user.
Recommended reading: audit trails for agent auth
If you are one developer driving your own Cursor Cloud Agents from Claude Code or another MCP client, a community MCP server with your own key is fine, and it is the only MCP path that exists for Cloud Agents today. If your agent serves other people, launches agents from CI or issue trackers, reports spend and AI code share, or needs to cancel, steer, or stream runs, build against the Cursor API. Cloud Agents for per-user work on user keys; Admin and Analytics for team reporting on admin keys, kept apart. Either way, you hold a long-lived Cursor key per user, per customer, and some of those keys can change a team's spend limits. That's what needs production-grade infrastructure.
Not for its agents. Cursor is an MCP client that connects to servers over stdio, SSE, and Streamable HTTP. Its only first-party MCP server is for Origin, its code forge, which is in Early Beta and currently available only inside Cursor and Grok Bot. For Cloud Agents, usage, or team management, the MCP path today is a community server such as cursor-cloud-agent-mcp, which wraps the Cloud Agents API behind a single CURSOR_API_KEY.
It depends on the API. The Cloud Agents API takes a user API key or an Enterprise-only service account key. The Admin, Analytics, and AI Code Tracking APIs take a Team Admin key with read or admin permissions, and those three are Enterprise only. A user key acts as one person and spends that person's usage; an admin key can remove members and change spend limits for the whole team.
They differ per API and are low enough to shape a design: 20 requests per minute on most Admin endpoints, 100 per minute on team Analytics endpoints and 50 on by-user endpoints, 20 per endpoint on AI Code Tracking, and 1 call per minute on the Cloud Agents repository list. Analytics responses carry an ETag, and a 304 costs nothing against the limit.
Only on the legacy v0 API, which sends a statusChange POST signed with HMAC-SHA256 when an agent finishes or errors. The v1 Cloud Agents API says webhooks are coming soon, so on v1 the completion model is polling the run until it leaves a running state, or holding an SSE stream open.
When it serves other people, launches agents from CI or issue trackers, reports spend and AI code share, cancels, steers, or streams runs, or enforces policy such as spend limits. A community MCP server holds one key in one process, so it fits a single developer driving their own agents from another assistant.
The cursor connector exposes 24 tools over the Cloud Agents API v1 and stores each user's Cursor user API key as their connected account in the token vault. The agent passes an identifier, the key never enters the runtime or the model, a virtual MCP server narrows the tools per agent role, and every execution returns an execution_id attributed to that user. Admin and Analytics endpoints stay in a separate custom connector with the Team Admin key.
Browse the Scalekit Cursor connector and the Cursor connector docs with the full tool list. See Scalekit pricing, or talk to us.
.png)
