Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

No arguments

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

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
checkA

Diagnóstico: verifica que el CLI cursor-agent esté instalado, su versión, y si CURSOR_API_KEY está disponible en el entorno de login shell. Corré esto primero si algo falla raro.

list_modelsA

Lista los modelos disponibles para --model (ej. gpt-5, sonnet-4-thinking, claude-opus-4-8[...]).

worktree_createA

Crea un git worktree aislado (+ rama nueva) para que cursor-agent trabaje sin tocar tu working directory actual. Hace git fetch del remoto de base primero. Si el repo es Node/TS, symlinkea node_modules del repo original (no reinstala nada).

worktree_listA

Lista los worktrees activos de un repo (rutas + rama + HEAD).

worktree_removeA

Elimina un worktree (y opcionalmente su rama). Usalo para limpiar después de traer los cambios con bring_changes, o para descartar un intento que no sirvió.

runA

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.

plan_runB

Atajo todo-en-uno: crea el worktree Y lanza cursor-agent con el plan, en una sola llamada. Es el flujo recomendado para "dale este plan a Cursor". Async por default (wait:false) — devuelve worktree + job_id al toque.

plan_run_parallelA

Despliega VARIOS agentes de cursor-agent en paralelo, cada uno en su propio worktree/rama. Ideal para tareas independientes (ej. "arreglar bug A" y "agregar feature B" al mismo tiempo, sin que se pisen). Cada tarea es como un plan_run individual.

job_statusA

Estado actual de un job: running/done/failed/cancelled, exit code, duración, y las últimas líneas del log (tail chico por default — para más, usá job_log).

job_waitB

Bloquea hasta que un job termine (o se cumpla timeout_seconds) y devuelve el resultado final con el log completo (o su tail). Usalo después de run/plan_run con wait:false cuando ya querés el resultado.

job_logA

Trae una porción del log completo de un job, paginado por líneas — usalo cuando el tail de job_status no alcanza para diagnosticar algo. No devuelvas esto por default; solo cuando de verdad haga falta más detalle (consume más tokens que job_status).

job_listA

Lista jobs (más nuevos primero), opcionalmente filtrados por repo_path o status. Compacto — sin log, solo metadata.

job_cancelA

Mata el proceso de un job que sigue corriendo (SIGTERM). Solo funciona si el job fue lanzado por ESTA sesión del server (el handle del proceso es en memoria).

diffA

Diff de lo que cursor-agent cambió en un worktree (incluye archivos nuevos). Usalo para REVISAR antes de bring_changes — no trae nada al repo, solo muestra.

bring_changesA

Aplica los cambios (sin commitear) de un worktree al working tree de tu repo real, vía git apply — NUNCA hace merge/rebase de historia, solo mueve el diff. Revisá con diff primero. Si algo no aplica limpio, no toca nada y te devuelve el error de git tal cual.

helpA

Cheatsheet compacto de este MCP: flujo típico, todas las herramientas y para qué sirve cada una. Llamá esto si no te acordás cómo se usa — más barato que leer el README completo.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.9/5.0

Scored across 16 tools

Disambiguation5/5

Each tool has a clear, distinct purpose: environment checks, model listing, worktree management, running tasks (including combined and parallel variants), applying changes, diffing, and job lifecycle management. While some tools like job_status, job_wait, and job_log overlap in domain, their descriptions clearly differentiate status, blocking wait, and log retrieval.

Naming Consistency3/5

Naming is mixed: some tools use verb_noun (list_models, bring_changes), others use noun_verb (worktree_create, job_status), and a few are simple verbs (check, run, help, diff). The pattern is not consistent, though the names remain readable and domain-appropriate.

Tool Count5/5

16 tools is well-scoped for the purpose of orchestrating cursor-agent tasks in isolated worktrees with job management. Each tool serves a distinct role without redundancy, fitting comfortably within the 3-15 tool range.

Completeness5/5

The tool set covers the full lifecycle: environment verification, model selection, worktree creation/listing/removal, task execution (single, combined, parallel), change review (diff), change application (bring_changes), and comprehensive job management (status, wait, log, list, cancel). There are no obvious gaps that would hinder the workflow.

Maintenance

ActivityMaintained
ResponsivenessNo issues