Skip to main content
Glama
jguevara0923

cursor-agent-mcp

by jguevara0923
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

run

Execute cursor-agent tasks in a specified directory using a prompt or plan file. Start asynchronously for parallel jobs, or wait to receive the direct result.

Instructions

Lanza cursor-agent con un prompt/plan en un directorio dado. Por DEFAULT es asíncrono: devuelve un job_id al toque y sigue corriendo en segundo plano (usá job_status/job_wait para seguirlo) — así podés lanzar varios en paralelo sin bloquear. Pasá wait:true si preferís esperar a que termine y recibir el resultado directo.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cwdYesDirectorio donde corre cursor-agent (normalmente un worktree_path de worktree_create).
modeNo"agent" (default) lee y escribe. "plan"/"ask" son de SOLO LECTURA — para pedir un análisis/plan sin que toque archivos.agent
waitNoSi true, bloquea hasta que termine (o timeout_seconds) y devuelve el resultado final.
forceNoAgrega --force (default: true).
labelNoEtiqueta legible para identificar el job en job_list.
modelNoModelo a usar (si se omite, usa el default de cursor-agent).
trustNoAgrega --trust (default: true, requerido para correr sin confirmar cada acción).
branchNoSolo metadata: qué rama es este trabajo (para job_list).
promptNoEl plan/instrucción para cursor-agent. Alternativa a plan_file.
plan_fileNoRuta a un archivo de texto con el plan — mejor que `prompt` para planes largos (ahorra tokens en la llamada).
repo_pathNoSolo metadata: repo dueño (para filtrar en job_list).
output_formatNo--output-format de cursor-agent (default: text).text
resume_chat_idNoContinuar una sesión previa específica de cursor-agent (--resume <chatId>) en vez de arrancar una nueva.
timeout_secondsNoSolo si wait:true — máximo a esperar antes de devolver igual (el job sigue corriendo).
continue_sessionNoContinuar la última sesión de cursor-agent en este cwd (--continue). Ignorado si se pasa resume_chat_id.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the burden of behavioral disclosure. It clearly explains asynchronous background execution, immediate job_id return, parallel launching, and the wait:true blocking alternative. It could more explicitly warn that the default agent mode may modify files, though the schema's mode parameter documents that.

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?

The description is compact and well-structured: first sentence states the action, second explains the default async behavior, and third gives the synchronous alternative. Every sentence adds necessary information with no filler.

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?

Given the high parameter count (15) and no output schema or annotations, the description covers the most critical execution context: async vs sync, job_id, background execution, and follow-up via job_status/job_wait. It could be more complete by naming when to prefer this over plan_run/plan_run_parallel, but the schema fills parameter-level gaps.

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 description coverage is 100%, so the schema already documents all 15 parameters in detail. The description reinforces the async-vs-wait relationship and mentions prompt/plan and directory, but adds no substantial parameter semantics beyond the schema. A baseline 3 is appropriate.

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?

The description states a clear verb and resource: 'Lanza cursor-agent' with a prompt/plan in a given directory. It makes the tool's core action immediately obvious. It does not explicitly differentiate from sibling tools like plan_run or plan_run_parallel, so it does not earn a 5.

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?

The description gives concrete usage guidance: by default it is asynchronous, returns a job_id, and can run in parallel; wait:true switches to synchronous operation. It also points to job_status/job_wait as follow-up tools. It does not provide explicit when-not-to-use or alternative-selection rules against sibling tools, so it misses a 5.

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

Deploy Server

Other Tools