Skip to main content
Glama
andreilungeanu

Cursor Delegate

by andreilungeanu
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Cursor Delegate

Stop burning your frontier agent's limits on boilerplate.

Delegate edits to Cursor's CLI agent — your agent writes the brief and reviews the diff.

npm version npm downloads MCP Registry cursor-delegate-mcp MCP server node license: MIT tests

Use your best coding agent where its judgment matters most: understanding the task, shaping the plan, and reviewing the result.

Cursor Delegate is the MCP bridge that lets Claude Code, ChatGPT/Codex, Copilot — or any MCP client — hand implementation to Cursor's CLI agent, then get a clean, structured result back for review.

Demo

🧠 Frontier quality, kept

Your assistant does what frontier models are for: understands the task, writes a precise brief, reviews the finished diff. Composer 2.5 runs the implementation loop under that brief. The bundled skill puts the review step in the loop — the agent that scoped the work reads the changed files back before reporting.

Related MCP server: cursor-mcp-server

⚡ Done faster

Composer 2.5 is built for throughput on multi-file edits. The whole delegation is one call — brief in, result out — so you review a finished diff instead of babysitting edits landing file by file.

🔋 Your limits stop being the bottleneck

Composer and Grok draw from the Cursor Models usage pool, separate from third-party model usage on supported Cursor plans. Your Claude or Codex subscription handles the brief and review while Cursor runs the implementation. If you pay per token on API, implementation moves onto the Cursor capacity you already have.

You and your agent plan and review; the MCP delegate tool hands the brief to cursor-agent (Composer 2.5), which implements and edits your workspace; a clean result comes back with what changed, which files, and the plan, for your agent to review

Delegate result payload

Features

  • 🤝 Native plugins — install into Claude Code, ChatGPT/Codex, or GitHub Copilot CLI and just say "delegate this to Cursor". The shared skill teaches your agent how to delegate well.

  • 💬 No stalled runs — if Cursor needs to clarify, it ends the turn and returns the question as a normal result. Your agent reads it and answers by resuming the same session — nothing blocks on a modal waiting for input.

  • 📦 Clean, named results — final answer, changed files, session id, and the plan, returned as one compact JSON payload. Nothing to scrape.

  • 📋 Plan first — plan mode: Cursor drafts a plan, you review it, then the same session implements it.

  • 🔍 Ask anything — ask mode: Q&A over your codebase.

  • 🩺 Self-diagnosing — a doctor tool that tells you exactly what's missing if setup isn't right.

  • 🔌 Portable — plain stdio MCP, so it runs anywhere: VS Code, JetBrains, Windsurf, Visual Studio, OpenCode, Antigravity, and more.

plan and ask are instructions to the agent, and workspace is its working directory — Security and the delegate reference spell out what the bridge enforces and what it reports back.

Install

You need Node.js 20+ and the Cursor CLI, logged in (cursor-agent login).

Claude Code

/plugin marketplace add andreilungeanu/cursor-delegate-mcp
/plugin install cursor-delegate@cursor-delegate-mcp

Then just ask:

Delegate to Cursor: migrate src/api from callbacks to async/await and update the tests, then walk me through what changed.

That's the whole loop — Claude writes the brief, Cursor grinds through the files, Claude walks you through the diff.

ChatGPT desktop / Codex

codex plugin marketplace add andreilungeanu/cursor-delegate-mcp
codex plugin add cursor-delegate@cursor-delegate-mcp

GitHub Copilot CLI

copilot plugin install andreilungeanu/cursor-delegate-mcp

Any other MCP client

{
  "mcpServers": {
    "cursor-delegate": {
      "command": "npx",
      "args": ["-y", "cursor-delegate-mcp"]
    }
  }
}

Client-specific config locations

Install in VS Code Install in VS Code Insiders

Or add it manually:

{
  "servers": {
    "cursor-delegate": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "cursor-delegate-mcp"]
    }
  }
}

Or run Chat: Install Plugin From Source with this repository's URL.

Under Settings → Tools → AI Assistant → Model Context Protocol (MCP), add a server with command npx and arguments -y cursor-delegate-mcp.

Same mcpServers block as the generic snippet above. Cascade caps you at 100 tools across all servers.

Same servers + type: "stdio" shape as VS Code. Requires Visual Studio 2026, or 2022 17.14+. Note the top-level key is servers, not mcpServers. Visual Studio also discovers .mcp.json next to the solution, plus .vscode/mcp.json.

OpenCode does not use mcpServers. Local servers go under mcp, with type: "local" and command as one array:

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "cursor-delegate": {
      "type": "local",
      "command": ["npx", "-y", "cursor-delegate-mcp"],
      "enabled": true
    }
  }
}

Same mcpServers block as the generic snippet above. In the IDE: … on the agent panel → MCP Servers → Manage MCP Servers → View raw config. Antigravity 2.0, IDE, and CLI share the Gemini config file. You may need to approve the server's tools on first run.

Same mcpServers block as the generic snippet above. Workspace file wins when both exist.

Same shape as OpenCode: type: "local" and command as one array. In the VS Code extension: Settings → MCP → Add Server → Local (stdio). On Windows, if npx is not found, use command cmd with arguments /c, npx, -y, cursor-delegate-mcp.

{
  "context_servers": {
    "cursor-delegate": {
      "command": "npx",
      "args": ["-y", "cursor-delegate-mcp"],
      "env": {}
    }
  }
}

Zed's native agent uses this. External ACP agents in Zed read their own MCP config unless you forward Zed's servers.

License

MIT © Andrei Lungeanu

Technical reference · Security · Privacy · Terms · Changelog

Available Tools

3 tools
cancelA
DestructiveIdempotent

Best-effort cancel of an in-flight delegation by sessionId. session/cancel is advisory — the agent may finish the turn anyway, and the delegate result then carries cancelRequested. Status: cancelled, killed (agent process observed to exit), not-running (turn already ended, still resumable), not-found (id not in this process's recent session history).

ParametersJSON Schema
NameRequiredDescriptionDefault
forceNoKill the agent process if the turn is still running after a short grace period.
sessionIdYes

TDQS

A4.4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations by disclosing the advisory nature of session/cancel (the agent may finish the turn anyway), what the delegate result then carries (cancelRequested), and the full meaning of each outcome status (cancelled/killed/not-running/not-found). This is exactly the rich behavioral context a destructive, idempotent cancel needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, front-loaded with purpose, then semantics, then outcomes. The status enumeration is compact and every clause carries information; nothing is padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description correctly carries the burden of explaining return statuses and the advisory/interruptible behavior of the operation, plus the force-kill outcome. For a 2-parameter destructive cancel tool this is complete enough to call correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 50% (sessionId is undocumented in the schema), but the description compensates by defining sessionId's domain ('this process's recent session history') via the not-found status, and by linking 'killed' to the force-kill behavior. This adds real meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Best-effort cancel of an in-flight delegation by sessionId'), which is inherently distinct from the 'delegate' and 'doctor' siblings. However, it never explicitly names or contrasts against those siblings, so it stops just short of full differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear context for when this applies: cancelling an in-flight delegation, scoped to a session. It does not state exclusions or name alternatives (delegate/doctor), but the scenario is unambiguous enough that an agent knows when to reach for it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

delegateA
Destructive

Delegate a coding task to cursor-agent over ACP. Never shell out to cursor-agent — use this tool only. Auto-approves every permission the agent requests, in any mode and anywhere on disk. Clarifying questions arrive as prose in result — resume with resumeSessionId to answer. Keep model (composer-2.5), fast and effort at their defaults unless the user explicitly asks. See the delegate skill.

ParametersJSON Schema
NameRequiredDescriptionDefault
fastNoFast tier; higher cost — only when the user asks.
modeNoagent implements; plan and ask are instructions to the agent, not limits.agent
specYesTask brief: goal, scope, fixed decisions quoted exactly, acceptance criteria. Sent as written. Point at files to read rather than pasting code, or attach them with contextFiles.
modelNoBare ACP family id, version included: composer-2.5, grok-4.5, claude-opus-5, gpt-5.6-sol. doctor deep:true lists every id.composer-2.5
effortNoExact Cursor thinking-effort value for the selected model. Values differ per model and some expose no effort option; invalid values fail before the prompt and name the accepted set. Pass only when the user asks for Cursor effort — the host's own reasoning setting is unrelated.
contextNoContext window size; gpt-5.x accepts 272k and 1m. Do not pass speculatively.
workspaceYesThe agent's working directory, not a limit. Smallest directory holding the task's files; with no such directory the project root is the floor. Must already exist; never create one for the call.
contextFilesNoPaths to attach instead of pasting contents into spec. Text becomes references the agent may open; images (png/jpg/gif/webp, <5MB) are sent inline. Relative paths resolve against workspace but are not limited to it. Skips are reported in protocolWarnings, never fatal.
resumeSessionIdNoContinue an existing ACP session.

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the destructive/openWorld annotations by disclosing that it auto-approves every permission request in any mode and anywhere on disk, and that clarifying questions surface as prose in the result with a documented resume path. These are the exact behavioral traits an agent needs before firing a destructive, non-idempotent call.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Five dense sentences with no filler, and the most critical constraint (never shell out) is placed second. Slightly packed, but every sentence carries an operating rule the agent could otherwise get wrong.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With nine parameters but full schema coverage, no output schema, and destructive/openWorld annotations, the description supplies the missing pieces: permission auto-approval, result-shape expectations (clarifications as prose), session resumption, and safe defaults for the optional knobs.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds policy the schema does not express: leave model/fast/effort at defaults unless the user asks, and do not pass context speculatively. That is genuine decision guidance rather than a restatement of field types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — 'Delegate a coding task to cursor-agent over ACP' — and immediately rules out the wrong mechanism ('Never shell out to cursor-agent — use this tool only'). An agent can tell this apart from cancel and doctor at a glance.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-use routing ('use this tool only'), explicit constraint on optional params ('keep model, fast and effort at their defaults unless the user explicitly asks'), and an explicit follow-up path ('resume with resumeSessionId'). Also points at the delegate skill for depth.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

doctorA
Read-onlyIdempotent

Setup diagnostics: plugin version, MCP client capabilities, cursor-agent launcher resolution. Run when delegation fails or agent.found is false.

ParametersJSON Schema
NameRequiredDescriptionDefault
deepNoRun an ACP handshake (start → initialize → newSession) to verify the agent is usable; adds models, modes and the current model's options.

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is fully covered by structured data. The description adds the failure-triage framing but says nothing about cost, side effects of the deep handshake, or output shape beyond the schema-documented parameter.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no filler: the first says what is checked, the second says when to run it. The scoping and trigger are front-loaded and nothing is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only, single-optional-parameter diagnostic with no output schema, the description covers what is inspected and the invocation trigger. It is slightly thin on what the agent should do with the result, but nothing needed to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the sole optional 'deep' parameter is thoroughly documented in the schema itself (ACP handshake, added models/modes/options). The description contributes no additional parameter meaning, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Names a concrete diagnostic resource and enumerates exactly what it inspects: plugin version, MCP client capabilities, cursor-agent launcher resolution. It is clearly not a delegation tool, so siblings delegate/cancel are implicitly distinguished, though no sibling is named explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a concrete trigger condition: 'Run when delegation fails or agent.found is false.' That tells the agent when to reach for this tool rather than delegate. No explicit when-not or alternative routing, but the trigger is unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updatesv2.5.0
    • Changedcancel1 field changed
      • removedInput schema / additionalProperties
        Removed value: -false
    • Changeddelegate1 field changed
      • removedInput schema / additionalProperties
        Removed value: -false
    • Changeddoctor1 field changed
      • removedInput schema / additionalProperties
        Removed value: -false
  2. 3 tool updatesv2.0.0
    • Changedcancel1 field changed
      • changedInput schema / properties / force / description
        Previous value: -"After the cancel notify, wait a short grace period and kill the agent process if the delegation is still running"New value: +"Kill the agent process if the turn is still running after a short grace period."
    • Changeddelegate12 fields changed
      • changedInput schema / properties / context / description
        Previous value: -"Context window size. Not offered by every model; gpt-5.x accepts 272k and 1m."New value: +"Context window size; gpt-5.x accepts 272k and 1m. Do not pass speculatively."
      • changedInput schema / properties / contextFiles / description
        Previous value: -"Paths to attach instead of pasting file contents into spec. Text files are passed as references the agent may open; images (png, jpg, gif, webp, under 5MB) are sent inline. Relative paths resolve against workspace, and paths outside it are allowed — attach only files the agent should read. Anything skipped is reported in protocolWarnings, never fatal."New value: +"Paths to attach instead of pasting contents into spec. Text becomes references the agent may open; images (png/jpg/gif/webp, <5MB) are sent inline. Relative paths resolve against workspace but are not limited to it. Skips are reported in protocolWarnings, never fatal."
      • addedInput schema / properties / effort
        Added value: +{
+  "description": "Exact Cursor thinking-effort value for the selected model. Values differ per model and some expose no effort option; invalid values fail before the prompt and name the accepted set. Pass only when the user asks for Cursor effort — the host's own reasoning setting is unrelated.",
+  "minLength": 1,
+  "type": "string"
+}
      • changedInput schema / properties / fast / description
        Previous value: -"Fast speed tier — higher cost; enable only when the user asks"New value: +"Fast tier; higher cost — only when the user asks."
      • changedInput schema / properties / mode / description
        Previous value: -"Requested agent mode. plan and ask are passed to the agent as instructions, not enforced by the bridge — the agent may write in any of them, so review the git diff after every run. ask held on every model tested while plan compliance varies by model, so prefer ask when you need the stricter read-only instruction."New value: +"agent implements; plan and ask are instructions to the agent, not limits."
      • addedInput schema / properties / model / description
        Added value: +"Bare ACP family id, version included: composer-2.5, grok-4.5, claude-opus-5, gpt-5.6-sol. doctor deep:true lists every id."
      • removedInput schema / properties / reasoning
        Removed value: -{
-  "description": "Reasoning effort. Not offered by every model; gpt-5.x accepts none, low, medium, high, extra-high.",
-  "minLength": 1,
-  "type": "string"
-}
      • changedInput schema / properties / resumeSessionId / description
        Previous value: -"Resume an existing ACP session instead of a new one"New value: +"Continue an existing ACP session."
      • changedInput schema / properties / spec / description
        Previous value: -"Inline task brief (default): goal, scope, decisions already made (constraints and fixed choices — quote the user's exact values verbatim), acceptance criteria. Point at files to read or mimic rather than pasting code. Optional file path if the user wants a persisted spec."New value: +"Task brief: goal, scope, fixed decisions quoted exactly, acceptance criteria. Sent as written. Point at files to read rather than pasting code, or attach them with contextFiles."
      • changedInput schema / properties / workspace / description
        Previous value: -"Working directory for the agent (defaults to cwd). Must be an existing directory; the call fails rather than creating it."New value: +"The agent's working directory, not a limit. Smallest directory holding the task's files; with no such directory the project root is the floor. Must already exist; never create one for the call."
      • addedInput schema / properties / workspace / minLength
        Added value: +1
      • changedInput schema / required
        Previous value: -[
-  "spec"
-]New value: +[
+  "spec",
+  "workspace"
+]
    • Changeddoctor1 field changed
      • changedInput schema / properties / deep / description
        Previous value: -"When true, run a lightweight ACP handshake (start → initialize → newSession) to verify the agent is usable"New value: +"Run an ACP handshake (start → initialize → newSession) to verify the agent is usable; adds models, modes and the current model's options."
  3. 3 tool updatesv1.18.0
    • First observedcancel
    • First observeddelegate
    • First observeddoctor
Deploy Server
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

A4.2/5.0

Scored across 3 tools

Disambiguation5/5

delegate, cancel, and doctor each target a clearly distinct purpose: starting/resuming work, aborting it, and diagnosing setup. There is no overlap between initiating a delegation, cancelling one, and running diagnostics, so an agent can select unambiguously.

Naming Consistency5/5

All three tools use a single lowercase verb-style command (delegate, cancel, doctor) with no camelCase or underscore mixing. The pattern is predictable and readable throughout.

Tool Count4/5

Three tools is on the slim side but well-matched to a focused delegation wrapper: one action tool, one control tool, one diagnostic. Nothing feels redundant or missing for the core scope, though it sits at the low end of the 3-15 range.

Completeness4/5

The lifecycle is largely covered: delegate handles start and resume (via resumeSessionId), cancel handles termination with rich status codes, and doctor handles setup failures. The main gap is the lack of a session-listing or status-introspection tool, which agents must work around via the delegate result fields.

Maintenance

ActivityActive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers