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

With no annotations, the description carries the full burden, and it delivers: it states the exact mechanism (`git apply`), what it does NOT do (merge/rebase), and its failure behavior (leaves everything untouched and returns the raw git error). It also mentions the `stage` behavior indirectly via the description. This is highly transparent and exceeds typical expectations.

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

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

The description is a single, front-loaded sentence with the core action first, followed by a crucial warning, a short checklist, and a safety guarantee. Every clause adds value with no filler. It is concise, well-structured, and immediately conveys the essential information.

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

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

For a tool that moves changes between worktrees, the description covers what it does, how it does it, what it avoids, the recommended pre-check (`diff`), and the failure mode. It adequately explains the tool's behavior, and since there is no output schema, the lack of return-value details is acceptable. Nothing critical is missing for an agent to invoke it correctly.

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

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

Schema coverage is 75%, so the schema already documents most parameters. The description adds marginal context: it clarifies the overall purpose (moving diff) and mentions 'para que vos decidás qué stagear' which relates to the `stage` parameter, but it does not add significant new meaning for individual parameters beyond what the schema states. Baseline of 3 is appropriate.

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

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

The description states a specific verb and resource: it applies uncommitted changes from a worktree to the target repo's working tree via `git apply`. It explicitly distinguishes itself from operations that merge or rebase history, which sets it apart from potential sibling tools like `diff` or `run`. This is unambiguous and action-oriented.

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

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

It gives clear guidance: check with `diff` first, and explains that it only moves the diff, never merges/rebase. While it doesn't explicitly name alternative tools or state when NOT to use it (e.g., when a merge is needed), it implies the appropriate context and advises a prerequisite step. This is strong but not exhaustive.

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

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

No annotations are provided, so the description carries the full burden. It describes the checks performed but does not explicitly state whether the tool is read-only or what its output format is. However, the verb 'verifica' implies a non-destructive check, and the context of a diagnostic tool suggests no side effects. Missing explicit statement of output behavior.

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

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

Two sentences, front-loaded with 'Diagnóstico', and every word earns its place. It states the checks and the usage condition without redundancy.

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

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

For a simple diagnostic tool with no parameters and no output schema, the description covers what it does and when to use it. It could mention what the output looks like, but the lack of an output schema makes that less critical. Overall, sufficient for an agent to invoke it.

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

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

The tool has zero parameters, so the description has nothing to add beyond the empty schema. The baseline for 0 params is 4.

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

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

The description clearly states the tool's purpose: a diagnostic that verifies three specific things (CLI installation, version, and CURSOR_API_KEY availability). The verb 'verifica' and the resource 'cursor-agent' make it specific. It distinguishes from siblings by being the only diagnostic tool among them.

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

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

It explicitly advises to run this first when something fails unexpectedly ('Corré esto primero si algo falla raro'), providing a clear when-to-use condition. It doesn't mention alternatives, but no sibling serves a diagnostic purpose, so this is adequate.

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

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

No annotations are provided, so the description carries the full behavioral burden. It clearly discloses the non-mutating nature ('no trae nada al repo, solo muestra') and that new files are included. It could add details about output shape or edge cases, but the core behavior is transparent.

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

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

The description is two short sentences with the purpose front-loaded and workflow guidance in the second sentence. There is no filler or repetition of schema details.

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

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

For a simple diff tool, the description covers what it operates on, what it includes, and how it fits into the bring_changes workflow. It does not explicitly describe the return format or the required worktree_path parameter, but the schema supplies the remaining call details.

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

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

Schema coverage is 67%: paths and stat_only already have descriptions, while the required worktree_path is the only undocumented parameter. The description itself adds no parameter-level guidance, so it does not meaningfully exceed what the schema already provides.

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

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

The description names a specific verb-resource pair: diffing what cursor-agent changed in a worktree, including new files. It clearly differentiates itself from bring_changes by stating it does not bring anything into the repo and only shows changes.

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

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

It explicitly instructs the agent to use this tool 'para REVISAR antes de bring_changes', giving a precise workflow trigger. It also states the key exclusion: it does not bring changes to the repo, only displays them, so the agent knows when this tool is appropriate versus its sibling.

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

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

No hay annotations, así que la descripción asume la carga. 'Cheatsheet compacto' deja claro que es una operación de solo lectura que devuelve información, sin efectos secundarios. Aunque no detalla el formato de salida ni el tamaño, para un tool de ayuda eso es razonable y la descripción ofrece suficiente contexto.

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

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

Dos frases breves y directas. La primera define el contenido ('flujo típico, todas las herramientas y para qué sirve cada una') y la segunda da la instrucción de uso. No hay palabras de relleno; todo aporta valor.

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

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

Para un tool con cero parámetros, sin annotations y sin output schema, la descripción es completa: indica qué hace, qué contiene y cuándo invocarlo. No falta información que un agente necesite para decidir correctamente.

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

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

El tool no tiene parámetros y la cobertura del schema es 100%, por lo que el baseline es 4. La descripción no necesita agregar nada sobre parámetros; el schema ya lo cubre al ser un objeto vacío. No se pierde información en esta dimensión.

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

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

El verbo 'Llamá' + recurso 'cheatsheet compacto de este MCP' define exactamente qué hace: provee un resumen del flujo típico, todas las herramientas y su propósito. Se distingue claramente de los tools operativos (check, run, list_models, etc.) al ser un meta-tool de ayuda.

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

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

Indica explícitamente cuándo usarlo: 'si no te acordás cómo se usa'. También menciona la alternativa (leer el README completo) y la ventaja de usar help en su lugar ('más barato'). No hay ambigüedad sobre el contexto de invocación.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly discloses that the tool kills a running process via SIGTERM and explains the in-memory session-scoped limitation. It doesn't state what happens for non-running or foreign jobs, but the key destructive behavior and its precondition are explicit.

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

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

Two short sentences with no filler. The core action and signal are front-loaded, and the critical usage limitation is stated immediately after. Every sentence earns its place.

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

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

For a one-parameter tool with no output schema, the description covers the essential facts: what it kills, how it kills, and when it is valid. It omits error/return behavior, but the scoping constraint is the most important contextual detail and is clearly provided.

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

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

Schema description coverage is 0%, so the description should compensate by explaining job_id semantics. It does not mention the format, origin, or how to obtain the job_id, leaving the agent to infer it from the tool name and context. For a single required parameter this is a modest but real gap.

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

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

The description states a specific verb and resource ('Mata el proceso de un job') and even specifies the signal used (SIGTERM). This clearly identifies the tool's purpose and distinguishes it from read-only siblings like job_status, job_log, and job_list.

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

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

It gives a clear, explicit constraint on when the tool works: only for jobs launched by the current server session, because the process handle lives in memory. It does not name an alternative tool for other cases, but it does provide a decisive condition for whether this tool is usable.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the output is compact (no log, only metadata), which is useful. But it doesn't mention pagination, whether the list is read-only (likely safe), or what happens with filters applied. The read-only nature is implied but not explicit, and there's no contradiction.

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

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

The description is two sentences, front-loaded with the core purpose (list jobs, newest first) and filters. The compact note adds value without waste. Highly concise.

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

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

For a list tool with no output schema, the description explains the filter parameters and the compact nature, but lacks details on pagination, default limits, and return format specifics (e.g., fields returned). It's adequate for basic use but incomplete for advanced queries.

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

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

Schema coverage is 0%, so the description must compensate. It mentions repo_path and status as filters, covering two of three parameters. The limit parameter is not mentioned, but has a default and is common. The description clarifies that filtering is optional, which adds meaning beyond the schema.

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

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

The description clearly states the tool lists jobs, sorted newest first, with optional filters. It distinguishes from siblings like job_status (which likely targets a specific job) by indicating it's a list operation. However, it doesn't explicitly name the sibling alternatives, so it's clear but not fully differentiated.

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

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

The description implies usage: use this to list jobs, optionally filtered. It doesn't explicitly state when NOT to use it or mention alternatives like job_status for specific job details. The compact mention hints at a trade-off but lacks explicit routing.

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

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

With no annotations, the description carries the behavioral burden. It discloses that the tool paginates by lines and consumes more tokens than job_status, which is useful operational context. It doesn't explicitly state read-only/no side effects, but 'trae' (fetches) strongly implies a non-mutating read.

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

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

Two sentences, front-loaded with the core function and followed by cost/usage caveats. Every clause earns its place, with no repetition of schema information.

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

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

The definition covers purpose, pagination, cost tradeoff, and sibling differentiation, which is enough for an agent to decide when to call it. A minor gap is that it doesn't describe the return format or ordering, but that is largely inferable for a log tool and no output schema is expected.

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

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

Schema description coverage is 75%, and the description adds little about parameter semantics beyond saying the log is paginated by lines. The schema already documents from_end, limit_lines, and offset_lines, so the description doesn't need to repeat them; baseline 3 is appropriate.

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

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

The description clearly states it retrieves a line-paginated portion of a job's full log, and it explicitly differentiates itself from job_status by referencing the 'tail de job_status' that isn't enough for diagnosis. The operation and resource are specific and unambiguous.

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

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

It gives explicit when-to-use guidance: only when job_status's tail is insufficient, and only when more detail is genuinely needed. It also warns against default use by noting higher token consumption, effectively specifying when-not-to-use.

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

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

With no annotations present, the description carries the full behavioral disclosure burden. It does well by listing the exact status set (running/done/failed/cancelled), the fields returned (exit code, duration, log tail), and the default tail behavior. It does not explicitly state whether the call is non-blocking or read-only, but 'current status' strongly implies it.

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

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

The description is a single compact sentence that front-loads the core purpose and output, then adds the default-tail caveat and alternative tool. Every clause adds useful information with no repetition or filler.

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

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

Given the tool's low complexity, no output schema, and no annotations, the description is nearly complete: it explains what the response contains, names the default behavior, and points to job_log for extended logs. It does not cover error cases like an unknown job_id or contrast with job_wait, but these are minor for a read-only status check.

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

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

Schema description coverage is 50%: tail_lines is documented in the schema, and the description reinforces it by noting the small default tail and routing to job_log for more. job_id, however, is only a parameter name with no additional semantic guidance beyond 'job', which is a partial gap at this coverage level.

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

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

The description states a specific action and resource: getting the current status of a job, and enumerates the exact contents returned (status values, exit code, duration, last log lines). It explicitly differentiates itself from job_log by noting that the log tail is small and that job_log should be used for more.

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

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

The description provides clear context for when to use the tool: to retrieve the current status of a job. It also names an alternative, job_log, for cases where more log output is needed. However, it does not contrast with sibling tools like job_wait or job_list, so the when-not-to-use guidance is incomplete.

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

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

With no annotations provided, the description carries the full burden. It discloses that the tool blocks, but fails to mention what happens on timeout (does it return partial results or throw?), whether it can be cancelled, or any rate-limiting or re-entrancy behavior. The only behavioral hint beyond 'blocks' is returning a log/tail, which is insufficient for a potentially long-running operation.

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

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

The description is a single, well-structured sentence that front-loads the core behavior and then provides usage context. It avoids unnecessary detail, though it could be slightly more explicit about the parameter semantics without becoming verbose.

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

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

Given the tool's complexity (blocking operation with three parameters, no output schema), the description is incomplete. It tells the agent the tool waits and returns a result, but leaves out crucial details: exact return format, behavior on timeout, how `tail_lines` modifies the log, and whether the tool can be called multiple times. The agent likely won't know how to interpret the result or handle edge cases.

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

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

Schema description coverage is 0%, and the description adds almost no parameter-level meaning. It mentions `timeout_seconds` in passing ('se cumpla timeout_seconds') but does not explain its semantics beyond existence, and `tail_lines` is completely ignored. The agent is left without guidance on how these parameters affect behavior, forcing reliance on defaults or guessing.

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

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

The description clearly states a specific action (block until job finishes) and a distinct outcome (returns final result with full log or tail). It explicitly differentiates from sibling tools by tying usage to `run`/`plan_run` with `wait:false`, making it unmistakable which tool to pick.

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

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

It explicitly states when to use it: after `run`/`plan_run` with `wait:false` when you want the result. This is clear context, though it does not mention alternatives like `job_status` or `job_log` for non-blocking checks. It provides a strong precondition but omits explicit 'when not to use' guidance.

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

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

No annotations are provided, so the description carries the full burden. It implies a read-only action (listing) but does not explicitly state side-effect freedom, output format, or pagination. For a zero-parameter list tool, the disclosure is minimal but not misleading.

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

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

The description is a single, front-loaded sentence with an example. Every word earns its place, and it is immediately clear what the tool does. No redundancy or filler.

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

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

Given the tool has no parameters, no output schema, and a simple purpose, the description is nearly complete. It tells the user what will be returned (the list of models). It could mention whether the list includes deprecated or experimental models, but such detail is not critical for correct invocation.

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

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

The tool has zero parameters, and the schema has 100% coverage (with no properties). The description adds value by explaining that the output is the set of models usable with --model, which is beyond the empty schema. Per the baseline for 0 parameters, a score of 4 is appropriate.

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

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

The description states a clear verb ('Lista') and a specific resource ('modelos disponibles para --model'), and includes concrete examples (gpt-5, sonnet-4-thinking). It unambiguously conveys the function and is distinct from sibling tools, which are unrelated (worktree, run, etc.).

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

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

The description specifies the intended use: to see which models can be passed to the --model option. This gives clear context for when to invoke the tool. It does not explicitly mention when not to use it, but there is no obvious alternative among siblings, so the guidance is sufficient.

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

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

With no annotations provided, the description carries the full disclosure burden. It does disclose async-by-default behavior (wait:false) and the return shape (worktree + job_id), which is genuinely useful. However, for a mutation tool that creates worktrees and launches agents, it omits side effects, permission requirements, and implications of worktree creation — notable gaps for a write-heavy operation.

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

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

Three sentences with the core purpose front-loaded and no filler. The async/return info is placed efficiently. Minor colloquial flavor ('al toque') adds no functional value but doesn't harm clarity.

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

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

For a complex tool with 12 parameters, no annotations, and no output schema, three sentences are inadequate. It fails to cover the plan/plan_file mutual exclusivity, the read-only mode option for analysis-first workflows, branch auto-generation, worktree path behavior, or how this compares to plan_run_parallel — all decision-relevant for an agent.

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

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

Schema description coverage is only 25% (3 of 12 params documented: mode, plan, branch), so the description must compensate. It only hints at the wait parameter's default behavior and adds nothing about plan vs plan_file, label, model, worktree_path, link_node_modules, timeout_seconds, base, or repo_path — leaving 9 params effectively undocumented across both schema and description.

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

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

The description states a specific combined action (crea el worktree Y lanza cursor-agent) in a single call, which is a clear verb+resource pairing. It positions itself as the recommended all-in-one flow, which distinguishes it from worktree_create and run. However, it doesn't explicitly differentiate from the sibling plan_run_parallel, leaving a minor ambiguity about when each combined flow is preferred.

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

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

The description names the recommended usage context ('el flujo recomendado para dale este plan a Cursor'), giving a clear when-to-use signal. But it provides no explicit exclusions or alternatives — it never says when to use run alone, worktree_create alone, or plan_run_parallel instead, leaving the agent to infer routing from the name and sibling list.

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

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

With no annotations provided, the description carries the full behavioral burden. It discloses the core trait of parallel execution in isolated worktrees/branches, which is valuable. However, it does not mention side effects, cleanup behavior, how results are returned, or error handling, leaving significant behavioral gaps.

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

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

The description is compact and front-loads the most important behavioral information: parallel execution, isolation, and independence. Every sentence contributes: the main verb and resource, the use case with examples, and the relationship to plan_run.

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

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

This is a fairly complex tool with nested task objects, multiple settings, and no output schema or annotations. The description covers the high-level purpose but omits important context such as return behavior, job tracking, failure handling, cleanup of worktrees/branches, and how to interpret results. An agent would likely need additional exploration or documentation to use it reliably.

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

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

Schema description coverage is 67%, and the description adds useful context by indicating that each task entry is like a plan_run. It does not meaningfully expand on the wait or timeout_seconds parameters, which are already partially self-explanatory and documented in the schema. Overall, the description adds some value but does not fully compensate for the undocumented timeout parameter.

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

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

The description clearly states a specific verb ('Despliega'), a resource (cursor-agent agents), and the distinctive parallel execution model with isolated worktrees/branches. It differentiates itself from plan_run by explaining that each task behaves like an individual plan_run done in parallel.

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

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

It provides clear guidance on when to use the tool: for independent tasks that should run simultaneously without conflicting. It gives concrete examples and implies it should not be used for dependent or conflicting work, though it does not explicitly name alternative tools to use in those cases.

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

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.

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.

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.

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.

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.

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.

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

With no annotations, the description carries the behavioral burden and does disclose important traits: it performs git fetch first, creates a new branch/worktree, symlinks node_modules for Node/TS, and explicitly avoids reinstalling. It does not mention output, failure modes, or cleanup, but the core side effects are clear.

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

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

Two concise sentences front-load the purpose and then add the two most important behavioral details (fetch and node_modules symlink). No filler or repetition of schema fields.

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

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

The description covers the operation's purpose, primary side effects, and the isolation benefit, while the schema covers all parameter defaults. It does not describe return values or conflict behavior (e.g., if the branch already exists), but that is a minor gap for a creation tool with no output schema.

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

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

All 6 parameters are documented in the schema (100% coverage), so the baseline is 3. The description adds value by clarifying that 'fetch' runs before creation, 'base' supplies the remote to fetch, and 'link_node_modules' symlinks the original node_modules instead of reinstalling.

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

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

The description uses a specific verb and resource: it creates an isolated git worktree plus a new branch so an agent can work without touching the current working directory. This clearly separates it from siblings like worktree_list and worktree_remove.

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

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

It states the intended use ('para que cursor-agent trabaje sin tocar tu working directory actual') and key preconditions such as fetching base and symlinking node_modules for Node/TS repos. It does not explicitly name alternatives or edge cases where this tool should not be used, so it stops short of a 5.

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

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 states it is a listing operation and names the output fields, but does not explicitly confirm that it is read-only, behavior on invalid repo_path, or whether it includes the main worktree. These are minor gaps for a simple list command.

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

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

One concise sentence, front-loaded with the action and resource, with no redundant or filler content.

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

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

For a simple one-parameter listing tool, the description covers the action, the resource, and the returned fields, which is most of what an agent needs. It stops short of stating preconditions (valid repo path) and error behavior, but these are minor for this operation.

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

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

Schema description coverage is 0%, so the description must compensate for the lone repo_path parameter. The phrase 'de un repo' ties the parameter to the repository but does not specify the expected format (absolute/relative path, git URL) or constraints. The parameter name is self-explanatory, but the description adds minimal semantic value.

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

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

The description uses a specific verb ('Lista') and identifies a clear resource ('worktrees activos de un repo'), with parenthetical detail on the returned fields (paths, branch, HEAD). This differentiates it from sibling tools like worktree_create and worktree_remove.

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

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

The description implies usage: call it when you need to inspect active worktrees in a repo. However, it offers no explicit comparison or exclusion against sibling tools, so routing is left to inference.

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

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

No annotations are provided, so the description carries the burden. It discloses that force defaults to false for safety and that delete_branch uses `git branch -D` (a destructive force-delete). However, it doesn't mention what happens to the worktree's branch if delete_branch is not passed, or whether the operation is reversible.

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

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

Two sentences, front-loaded with the action and purpose, with no wasted words. The usage guidance is integrated efficiently.

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

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

The description covers the core purpose and usage context, but with no annotations and no output schema, it could disclose more about side effects (e.g., what happens to the branch if delete_branch is omitted, whether force affects the branch deletion). It's adequate but not fully complete for a destructive operation.

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

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

Schema coverage is 75%, and the description adds meaning to the force parameter ('más seguro') and delete_branch ('borra esta rama con git branch -D'). The worktree_path parameter lacks a description in the schema, but the tool name and description make its purpose clear.

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

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

The description clearly states the verb ('Elimina') and resource ('worktree'), and adds optional branch deletion. It distinguishes itself from siblings by mentioning cleanup after bring_changes, though it doesn't explicitly name a sibling alternative.

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

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

The description gives explicit usage context: use it to clean up after bring_changes or to discard a failed attempt. It doesn't explicitly state when not to use it or name alternatives, but the context is clear enough for an agent to select it.

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