cursor-cloud-agents-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CURSOR_API_KEY | Yes | Your Cursor API key, minted at Cursor Dashboard → API Keys. Set in the MCP client's env block. | |
| CURSOR_TRANSPORT | No | Transport to use: rest (default) or sandbox (experimental). Select explicitly with CURSOR_TRANSPORT=sandbox to shell out to a cursor-agent CLI. | rest |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| cursor_launchA | Launch a Cursor cloud agent and enqueue its first run. Pass a complete task prompt: goal, constraints, and how to verify done — vague prompts produce vague agents. Repo-less launches (no repo_url) are for research, reviews, and writing; pass repo_url (a GitHub https URL) when the agent should write code. starting_ref is a branch or SHA; omit it to use the repo default (never assume "main"). Call cursor_models first and pass a model id verbatim — never guess ids, and never pass the literal string "Auto" (omit model instead). model_params is a list of {key, value} dicts for per-model options (only ids/params from cursor_models are accepted). mode is "agent" or "plan". Returns agent_id AND run_id: poll cursor_status with both. Launch can take minutes; if the tool reports status "unknown", the agent may still have been created — reconcile with cursor_list, or retry with the same idempotency_key (replays are safe and never duplicate). |
| cursor_statusA | Check a run's status. Run status is the source of truth — the agent's lifecycle status (ACTIVE/IDLE) is NOT "is it still working". If run_id is omitted, the agent's latest run is used. Poll this every 10-30 seconds; never sleep inside a tool call. When terminal=true, result holds the agent's final reply. |
| cursor_resultA | Wait for a run to finish (polling server-side) and return its result. Convenience wrapper over cursor_status for when you just want the final answer. Waits at most timeout_s seconds (clamped to 5 min) — on timeout, keep polling with cursor_status using the returned run_id. Large results are truncated with truncated=true. Transient API blips (429/5xx) are retried with backoff. |
| cursor_followupA | Send a follow-up prompt to an agent. Starts a NEW run — the returned run_id is what you poll with cursor_status (the old run_id is stale). Only call when the previous run is terminal; a follow-up during an active run fails with "agent is busy" — poll cursor_status first. |
| cursor_cancelA | Cancel the active run. Cancellation is terminal — to continue the conversation, send a follow-up (which starts a new run on the same agent). Does not archive the agent. Returns the run's actual post-cancel state. |
| cursor_listA | List your agents, newest first. Use this to reconcile after a launch reported status "unknown" (match by name/creation time), or to find an agent you lost track of. |
| cursor_modelsA | List available Cursor models with their ids, parameters, and variants. Call this before cursor_launch and pass the id verbatim — ids are not guessable. Each model may support params (e.g. reasoning effort); only valid id/params combinations from this list will be accepted. |
| cursor_whoamiA | Verify your API key works and see which identity it belongs to. Call this first if anything else fails with auth errors. |
| cursor_usageB | Token usage and cost for an agent (or one run). Costs real money — check this when a run felt expensive. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 9 tools
Tools map to distinct lifecycle actions (launch, poll status, wait for result, follow up, cancel, list, discover models, verify identity, check usage). The only real overlap is cursor_status vs cursor_result, but their descriptions clearly distinguish granular polling from a blocking final-answer wrapper.
All tools share a consistent cursor_ prefix and snake_case formatting, making the set easy to scan. The minor deviation is mixing verb-style names (launch, followup, cancel, list) with noun-style names (status, result, models, usage, whoami), but the convention remains predictable.
Nine tools is well-scoped for managing cloud agents, with each tool earning its place across the launch-monitor-followup-cancel lifecycle plus supporting discovery (models, identity, usage). There are no redundant or filler tools.
The surface covers the core lifecycle: launch, poll status, wait for result, follow up, cancel, and list agents, plus model discovery and usage checks. Missing are explicit agent archival/deletion and a dedicated get-agent-details tool, though these are minor gaps for most workflows.