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

Without annotations, the description carries full responsibility but only describes the basic action ('Detiene una sesión en ejecución'). It does not disclose whether the stop is graceful or forceful, irreversible, or what happens to child processes/state, so transparency is limited.

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, front-loaded with the action and followed by a usage condition. No wasted words.

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 simplicity, the description covers purpose and usage condition, but lacks behavioral details like irreversibility or side effects. With no annotations and no output schema, this is a noticeable gap for a mutating operation, though the schema fully documents parameters.

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 input schema already provides full descriptions for both parameters (directory and sessionId), with 100% coverage. The description adds no parameter-specific details, so the 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 'Detiene una sesión en ejecución' (stops a running session), clearly identifying the action and resource. This distinguishes it from sibling tools like opencode_run and opencode_fire which start sessions.

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 phrase 'Úsalo solo cuando el usuario lo solicite o exista un bloqueo claro' explicitly specifies when to use the tool (user request or clear blockage) and implies not to use it otherwise, giving strong usage 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 present, so the description carries the full burden. It implies read-only behavior by using 'devuelve' (returns), but does not explicitly state that it has no side effects, requires no special permissions, or how it handles missing directories. The behavior is relatively transparent for a listing tool, but the description adds little beyond the basic return values.

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 concise sentence, front-loaded with the main purpose, and contains no redundant information. It earns its place with direct wording.

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 list tool with one optional parameter, the description is sufficient: it states what is returned (agents, models, modes). With no output schema, it could provide a bit more detail about response structure, but the essential purpose is well covered.

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 input schema covers 100% of the parameter with a clear description of 'directory'. The tool description does not add any extra meaning beyond the schema, so a baseline of 3 is appropriate. No additional clarification about formats or defaults is given.

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 returns primary agents and subagents with their models and modes, which is a specific verb+resource+scope. It distinguishes from siblings like opencode_providers or opencode_sessions by focusing on agent listing.

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?

No guidance is provided about when to use this tool versus alternatives such as opencode_providers or opencode_status. It does not mention any prerequisites or scenarios where this is the appropriate choice.

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 states that the tool 'returns' status, TODO, diff, and recent messages, implying a read-only operation, but it does not mention preconditions (e.g., session existence), error behavior, or whether the session must be active. It adds some value by listing the content of the response, but lacks deeper behavioral context.

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, clear sentence that efficiently lists the key returned elements (status, TODO, diff, recent messages) with no redundancy or filler. It is front-loaded and easy to parse.

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 lists what is returned, which is helpful given there is no output schema. However, it lacks guidance on when to use this tool versus siblings and does not clarify the format or definition of 'recent' messages. Given the tool has only two well-documented parameters and a clear return summary, it is minimally complete but leaves room for more contextual information.

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%, with both parameters (directory and sessionId) fully documented in the schema. The tool description itself does not add any parameter semantics beyond what the schema already provides. The baseline of 3 is appropriate since the schema already covers the parameters effectively.

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 'Devuelve' and explicitly lists the resources: estado, TODO, diff, and mensajes recientes of a session. This clearly differentiates it from siblings like opencode_status (which likely returns only status) and opencode_messages (which likely returns only messages).

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 no guidance on when to use this tool versus alternatives. It does not mention appropriate contexts, exclusions, or suggest alternatives like opencode_status or opencode_messages. The usage is only implied from the tool name and description, but no explicit guidance is given.

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 adds useful context by specifying the source ('mediante Task') and purpose, but it does not detail the return format, potential limitations (e.g., recursion depth), or the fact that it is a read-only operation beyond the implied 'Devuelve'.

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 sentence that front-loads the main verb and object, with no redundant words. It is concise and well-structured for quick comprehension.

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 read-only tool with two well-described parameters, the description adequately covers purpose and use case. Without an output schema, it does not specify the exact return structure, but 'Devuelve las sesiones hijas' gives sufficient context for an agent to understand the expected result.

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 input schema provides 100% coverage of both parameters with meaningful descriptions, so the baseline is 3. The tool description adds no parameter-specific information beyond what the schema already states.

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 returns child sessions created by OpenCode via Task, using a specific verb ('Devuelve') and resource ('sesiones hijas'). It distinguishes this from sibling tools like opencode_sessions by focusing on child sessions rather than all sessions.

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 phrase 'útil para auditar la delegación interna' provides a clear use case, signaling when to use this tool. However, it does not explicitly name alternatives or state when not to use it, so it falls short of the 'explicit when/when-not' standard.

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 must carry the full burden. It implies a read-only listing operation, but doesn't explicitly state no side effects, permissions, or output format. However, the verb 'lista' and the scope clarification ('global o por el proyecto') provide some behavioral context.

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 sentence that is concise and front-loaded with the core action and resource. No redundant 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 simple list tool with one optional parameter and no output schema, the description is reasonably complete. It states the action, resource, and scope. It lacks details on output format or usage alternatives, but these are not critical for such a simple tool.

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 for the single parameter is 100%, with the parameter description already detailing when to include the directory. The tool description adds no additional parameter semantics, so the baseline score of 3 applies.

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 the specific verb 'Lista' (lists) and names the resource 'comandos y workflows' (commands and workflows). It also clarifies scope ('globalmente o por el proyecto'), distinguishing it from sibling tools like opencode_providers or opencode_agents.

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?

No guidance is given on when to use this tool versus alternatives. The parameter schema mentions 'aggregate queries' vs 'tasks and sessions', but that concerns the directory parameter, not tool selection. No exclusions or alternative tool references are provided.

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 full burden of disclosing safety and side effects. It does not mention that the tool is read-only, whether it modifies any state, or any permission requirements. It only describes what it aggregates, not its behavioral characteristics.

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 that efficiently enumerates the components included, 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?

The description lists the aggregated components and the purpose for planning, but it does not describe the output format or how the context is presented, which is important given there is no output schema. This leaves some ambiguity about what exactly the agent receives.

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 schema covers the single parameter with a helpful description (absolute path, optional for aggregate queries, required for tasks/sessions), and the tool description adds no additional parameter semantics. Since schema coverage is 100%, the baseline of 3 applies.

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 the verb 'Agrega' (adds) and lists specific resources (project, agents, providers, sessions, commands, MCP, file status), clearly distinguishing it from the individual sibling tools by presenting an aggregated context for planning.

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 case ('para que ChatGPT pueda planear correctamente'), indicating that it should be used when planning is needed. However, it does not explicitly contrast with alternatives or give exclusions, so it's clear but not fully explicit.

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 burden of behavioral disclosure. The verb 'obtiene' (gets) implies a non-destructive read operation, and the purpose of checking changes makes the tool's behavior apparent. However, it does not describe return format, whether a running OpenCode instance is required, or any side effects. Adequate for a simple read tool but not rich in detail.

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 that states the verb and resource first, then provides the purpose. Every word earns its place with no filler or repetition. Excellent conciseness.

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 with one well-documented parameter and no output schema, the description is largely complete: it states the function, the scope, and the intended use case. The main gap is not describing what the returned file status contains (e.g., list of modified files, diff summaries), but this is a minor omission given the tool's simplicity.

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 schema already provides a thorough description of the directory parameter (absolute existing path, mandatory for tasks/sessions/file operations), covering 100% of the parameter semantics. The tool description adds value by linking this parameter to the task of checking changes before/after a task, giving additional contextual 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 gets file status ('Obtiene el estado de archivos') and adds the scope 'que OpenCode ve en el proyecto' (that OpenCode sees in the project), which distinguishes it from sibling tools like opencode_status or opencode_check. The stated purpose of checking changes before/after a task further clarifies its role.

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 explicitly provides a usage context: 'para comprobar cambios antes y después de una tarea' (to check changes before and after a task). This tells the agent when to use the tool, though it does not mention alternatives or exclusion cases. Clear context, but no 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?

With no annotations, the description carries the burden. It discloses the asynchronous behavior and sessionId return, which are key traits, but it omits failure behavior, permission requirements, or how to follow up (e.g., with opencode_check/status). It does not contradict the schema.

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 succinct sentences, front-loaded with the core action and return value. No wasted words, and the structure is easy to scan.

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 primary purpose and return value (sessionId), but given no output schema and 6 parameters, it could mention how to use the sessionId with sibling tools or handle errors. It is adequate but leaves gaps for a background task tool.

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 baseline is 3. The description does not add meaning beyond the schema—it describes the tool's behavior rather than parameter details, and the schema already documents all 6 parameters adequately.

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 ('dispara') and resource (tarea/sesión), and clearly conveys the asynchronous fire-and-forget nature ('sin esperar'), which distinguishes it from siblings like opencode_run or opencode_wait. It also mentions the sessionId return value, reinforcing its unique scope.

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 says to use it for independent tasks ('Úsalo para tareas independientes'), providing clear context. However, it does not name specific alternative tools or state when not to use it, leaving some ambiguity vs. siblings like opencode_parallel or opencode_wait.

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 full burden. It discloses the core behavior (creates a child session, preserves original context) but does not address side effects, permissions, or what happens to the original session. The phrase 'sin perder el contexto original' is useful, but missing details like prerequisites or return value limit transparency.

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 main verb and resource. Every word earns its place, with no filler or 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?

The tool has 4 parameters and no output schema, so the description should explain return behavior or prerequisites. It explains the core purpose but does not mention what the tool returns (e.g., new session ID) or any required preconditions beyond the schema fields. This leaves gaps for an agent trying 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 description coverage is 75% (title lacks description). The schema already documents directory, sessionId, and messageId. The description adds no parameter-specific details beyond what the schema provides, so it neither compensates for the 25% gap nor significantly enriches semantics.

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 ('Crea' = creates) and resource ('una sesión hija desde una sesión existente'), clearly defining the action. It also differentiates from sibling tools like opencode_run or opencode_children by emphasizing the child-session fork behavior and context preservation.

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 clear context for when to use: 'para explorar una alternativa sin perder el contexto original' (to explore an alternative without losing original context). It implies a use case but stops short of naming alternatives or providing explicit exclusions (e.g., when to use opencode_run instead).

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 transparency burden. It explicitly states 'sin modificar configuración' (without modifying configuration), which is a key read-only behavioral trait. However, it does not disclose other aspects like return format, error behavior, or prerequisites, so it is not fully 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 a single, concise sentence that directly states the tool's purpose and key constraint. It is front-loaded with the action and resource, containing no unnecessary 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 simple status-check tool, the description is quite complete: it states the action, scope, and non-mutating nature. The schema covers the parameter, and no output schema exists, so the description does not need to detail return values. Missing is any mention of what 'estados' includes, but overall it is adequate.

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%, meaning the only parameter (directory) is well-described in the schema. The tool description itself adds no parameter semantics, so the baseline score of 3 applies.

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 queries MCPs connected to OpenCode and their states, with a specific verb ('Consulta') and resource. It also emphasizes it does not modify configuration, distinguishing it from potential mutation tools. This differentiates it from sibling tools like opencode_status by focusing specifically on MCPs.

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 by stating it queries MCP status without modifying configuration, but it does not explicitly mention when to use this tool versus alternatives or provide exclusions. No alternative tools are named, so the guidance is implicit rather than explicit.

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 the read-like nature by saying 'Devuelve' but doesn't specify ordering, format, or whether it includes all message types. It adds context (recent messages for specific purposes) but not deep behavioral detail. This is adequate for a simple retrieval tool.

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 that efficiently conveys purpose and use cases. No wasted words or redundant 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 simple 3-parameter tool with no output schema, the description explains its purpose and why it would be used, complementing sibling tools like opencode_run and opencode_fire. It could mention return structure, but 'recent messages' gives a reasonable expectation. The coverage is concise and adequate.

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 100%, with all three parameters described. The description adds no extra parameter-specific semantics beyond the schema; the word 'recentes' loosely relates to the limit parameter but doesn't add syntax or format details. 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?

Description clearly states it returns recent messages from a session, with a specific verb-resource pair. It distinguishes from siblings like opencode_sessions (which likely lists sessions) and opencode_summarize (which summarizes), and adds scope ('recentes') and intended purposes (continuity, diagnosis, evidence).

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 usage context: it is meant for continuity, diagnosis, and evidence. It implies when to use the tool, though it does not explicitly name alternatives or exclusion criteria. This matches 'clear context, no exclusions'.

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. It discloses that concurrent writes are rejected by default, the max task count of 12, and how to permit shared directory writes. This is valuable behavioral context beyond input schema.

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 capability, and every phrase provides useful information: max tasks, independence, write-conflict behavior, and resolution options. 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?

For a dispatch tool, the description covers the key operational constraint. It does not specify whether results require waiting/polling, but sibling tools like opencode_wait and opencode_status likely cover that. With no output schema, it could be more explicit, but it is sufficient for basic usage.

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 100%, so baseline is 3. The description adds meaning by explaining the default write-conflict behavior, which clarifies why `allowSharedDirectory` exists and what 'independent tasks' implies for the `tasks` array.

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 dispatches up to 12 independent OpenCode tasks in parallel, with a specific verb and resource ('Despacha ... tareas independientes'). The behavior of rejecting concurrent writes further distinguishes it from sibling run/fire tools.

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: tasks should be independent, and if they involve writes, use separate directories/worktrees or explicitly allow shared directory. It does not explicitly mention alternatives like serial execution, but the constraint is actionable.

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 indicates a read-only query operation via 'consulta' and mentions 'eventos recientes', but it does not disclose potential side effects, authentication requirements, rate limits, or what happens when no permissions are pending.

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 concise sentence that front-loads the action and includes the purpose. Every word earns its place, with no unnecessary 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?

For a simple query tool with one optional parameter and no output schema, the description provides sufficient context to understand its use. However, it could be improved by clarifying the relationship with opencode_respond_permission and what 'eventos recientes' includes.

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 input schema has 100% coverage with a clear description for the 'directory' parameter, explaining when it may be omitted. The tool description adds no additional semantic meaning beyond the schema, so baseline 3 applies.

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 queries pending permission requests and recent events, with a specific purpose to resolve headless session pauses. It differentiates from siblings like opencode_respond_permission by focusing on querying rather than responding.

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: use this when needing to resolve pauses in a headless session. However, it does not explicitly exclude alternatives or mention when to use other tools like opencode_status or opencode_wait, and no comparison to opencode_respond_permission is given.

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?

Without annotations, the description carries the burden of behavioral disclosure. It states the tool lists known projects and implies a read-only operation, but does not explicitly mention side effects, permissions, or output format. The basic nature of the operation makes this adequate, though not detailed.

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 concise sentences: the first states the core function, the second gives a usage tip. No wasted words, and the essential information is front-loaded.

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 tool is simple with one optional parameter and no output schema. The description covers purpose and usage but does not specify the return format or behavior when no directories are found, which would be useful for a complete picture.

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 input schema covers the only parameter (directory) with a complete description (100% coverage). The tool description adds no additional meaning beyond the schema, so the baseline score of 3 applies.

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 projects known to OpenCode ('Lista los proyectos que OpenCode conoce'), with a specific verb and resource. It provides a use case ('orientar una tarea cuando no se tenga claro el directorio') but does not explicitly differentiate from sibling tools like opencode_sessions or opencode_status.

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 clear guidance on when to use the tool: to orient a task when the directory is unclear. It lacks explicit exclusions or alternatives, so it doesn't fully meet the 5-level criteria.

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 of behavioral disclosure. It states that the tool lists providers/models and mentions OpenCode Go, but it does not specify side effects (e.g., whether it is read-only), required permissions, rate limits, or what 'con evidencia' (with evidence) really means. This is a significant gap for a tool that queries data.

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, focused sentence that front-loads the main action ('Lista proveedores y modelos disponibles') and includes the purpose. There is no fluff or redundant 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?

As a simple listing tool with no annotations or output schema, the description provides the core functionality but omits return format details and any behavioral caveats. It is adequate for a basic read/list tool but leaves the agent without expectations about what the output will look like or any restrictions.

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 schema already documents the single parameter 'directory' with a clear description of what it is and when it may be omitted. The description adds no parameter-level information, so per the scoring guidance, the baseline of 3 applies due to high schema coverage.

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 the specific verb 'Lista' (lists) and resource 'proveedores y modelos disponibles' (available providers and models), clearly distinguishing it from sibling tools like opencode_status or opencode_context. It also adds the purpose 'para seleccionar Flash o Pro con evidencia' (to select Flash or Pro with evidence), making the tool's intent explicit.

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 phrase 'para seleccionar Flash o Pro con evidencia' indicates when to use this tool: when the agent needs to choose between Flash and Pro models based on available providers. While it does not explicitly mention exclusions or alternative tools, none of the sibling tools appear to target model selection, so the context is clear enough.

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 present, so the description carries the full burden of disclosing behavior. It mentions the core action and the return payload (response, status, updated diff), but it does not explain execution semantics such as whether the call blocks until completion, whether it modifies project files, or how it relates to companion tools like opencode_wait.

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?

A single sentence front-loads the verb and object, clearly stating the action, target, and return values with no filler. Every phrase contributes necessary information, making it concise and well-structured.

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?

Without annotations or an output schema, the description provides a reasonable overview but omits operational details such as whether the call is synchronous, what 'estado' and 'diff actualizado' contain, and what optional parameters do. Given the large number of sibling session tools, slightly more context would improve completeness.

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 only 20% — only 'directory' has a description. The description helps map 'instrucción' to prompt and 'sesión existente' to sessionId, but it gives no guidance on the optional 'agent' and 'model' parameters, leaving those underdocumented in both the schema and the 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 clearly states the action ('Envía una nueva instrucción') and the resource ('una sesión existente'), matching the tool's purpose. It also specifies the return values (respuesta, estado, diff actualizado), which helps distinguish it from session-creation or execution tools like opencode_run.

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 phrase 'a una sesión existente' establishes a clear usage context: this tool is for continuing an already-open session rather than starting a new one. However, it does not explicitly name alternatives or state when not to use it, so it does not fully satisfy the 'when not to use' criterion.

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 of disclosing side effects and behavior. It only states the response options and the prerequisite review step, but does not explain what happens after responding, whether the action is reversible, or any security implications.

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 concise, with two sentences that front-load the core action and then provide a specific usage note. No filler or redundant 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?

Given the lack of annotations and output schema, the description gives enough to understand the basic action but omits details about response consequences, error handling, or relationship to other tools like opencode_permissions. It is minimally sufficient but has clear 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 only 25% (only 'directory' has a description). The tool description adds minimal parameter meaning—it repeats the 'response' enum values already present in the schema and does not clarify how to obtain or use 'sessionId' or 'permissionId'.

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 function: responding to a headless request with 'once', 'always', or 'reject'. It identifies the specific action and the resource (permission request), but does not explicitly distinguish it from sibling tools like opencode_reply or opencode_fire.

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 a clear usage condition: 'Úsalo solo después de revisar el título y patrón del permiso' (use only after reviewing the title and pattern of the permission). This gives context for when to invoke the tool, though it does not mention alternatives or exclusions.

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 disclosing behavior. It states that the tool retrieves session, diff, and file status, which implicitly reads data without modification, but it does not explicitly state non-destructiveness, permissions, or potential side effects. Some useful context is given (the review purpose), but more explicit transparency about safety and limitations would be needed for a higher score.

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 sentence that efficiently conveys the core function, the data retrieved, and the purpose. Every word earns its place, and the most important information (what it gets) is front-loaded. 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?

The description adequately covers the tool's main purpose and output (session, diff, file status) for a simple two-parameter tool. It lacks an output schema, but the description itself lists what is returned. It could be more complete by mentioning whether it is read-only or how to interpret the diff, but it is sufficient for the tool's simplicity.

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%, and both parameters (directory and sessionId) have detailed descriptions in the schema itself. The tool description adds no parameter-specific meaning beyond the schema, so the baseline of 3 is appropriate. It does not need to compensate for missing schema coverage.

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 'Obtiene la sesión, diff y estado de archivos' (gets the session, diff, and file status) with a specific purpose 'para revisar el resultado antes de aceptarlo' (to review the result before accepting it). This distinguishes it from siblings like opencode_status or opencode_check by focusing on review before acceptance, and the verb 'obtiene' (gets) clearly identifies it as a retrieval operation.

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: use this tool to review the result before accepting it. It implies the appropriate timing (pre-acceptance) and the type of operation (review), but it doesn't explicitly name alternatives or exclusions. Since this guidance is clear and helpful, it earns a 4 rather than 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 full burden. It discloses that a session is created, the tool waits for the agent's response, and evidence includes a diff. However, it does not mention potential file modifications (despite writeIntent), blocking duration, error handling, or side effects beyond session creation, leaving significant behavioral aspects undisclosed.

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, dense sentence that efficiently conveys the tool's workflow and output without redundancy. Every clause contributes value, and the most important aspects (session creation, delegation, waiting, evidence with diff) are front-loaded and clear.

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 with 6 parameters, no output schema, and 25 siblings, the description is somewhat thin. It explains the high-level workflow but omits return format details (beyond 'diff'), error behavior, blocking semantics, and explicit differentiation from other run-family tools. It is adequate but leaves clear 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 coverage is 100%, so the baseline is 3. The description adds only marginal context beyond the schema, such as the idea of delegating to a chosen agent and the evidence including a diff. It does not explain parameter nuances like the interaction between writeIntent and parallel execution, which the schema already covers.

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 function: it creates a session, delegates a task to a chosen agent, waits for the response, and returns evidence including a diff. The verb 'ejecutar' is implicit in the workflow sequence, and the mention of creating a session and managing delegation distinguishes it from sibling tools like opencode_reply or opencode_wait.

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 context through the workflow (delegating tasks to an agent and getting a diff), but it does not explicitly state when to use this tool versus alternatives like opencode_fire, opencode_parallel, or opencode_review. No exclusions or when-not-to-use guidance is provided, which is notable given the large sibling set.

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 burden of behavioral disclosure. The word 'Lista' implies a read-only operation, and 'sesiones recientes' adds context about scope. However, it does not clarify what 'recientes' means, whether sessions are active/archived, or any prerequisites beyond what the schema already states.

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: it names the action and resource first, then states the use cases. At roughly 15 words, every word earns its place 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 list tool with no output schema, the description is adequate: it states the tool returns recent project sessions and gives use contexts. It does not detail the exact return shape, but the verb 'Lista' implies a list of sessions, and the schema covers the parameters, so it is reasonably complete for its low complexity.

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 input schema has 100% parameter description coverage for both 'limit' and 'directory', so the schema already documents parameter semantics. The description does not add any parameter-level detail beyond the schema, matching the baseline for high schema coverage.

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: 'Lista sesiones recientes del proyecto' (lists recent project sessions). This clearly identifies the operation, but it does not explicitly distinguish itself from sibling tools like opencode_status or opencode_agents, so it falls short of 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 phrase 'útil para retomar trabajo o auditar tareas en segundo plano' clearly states when to use the tool: to resume work or audit background tasks. It provides concrete use cases but does not mention when to avoid it or name alternatives, so it lacks explicit exclusions.

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. 'Comprueba' implies a read-only health check, which is implicitly non-destructive, but it doesn't disclose potential side effects, prerequisites (like being in a Git repo), or error conditions. The listed scope (health, agents, providers, etc.) adds some transparency, but key behavioral details are omitted.

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 first sentence front-loading the core action and the second providing usage guidance. Every word earns its place; no redundant 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 only one optional parameter, no output schema, and no annotations, the description provides a reasonable amount of context: it lists what is checked and when to use it. It could further explain the output format or the exact behavior of the directory parameter, but the schema partially covers that, making the description adequate for most uses.

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 input schema already documents the 'directory' parameter well. The tool description itself does not mention parameters, so it adds no meaning beyond the schema. The baseline of 3 applies since the schema handles the semantic load adequately.

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 'Comprueba' (checks) and enumerates the resources checked: salud, agentes, proveedores, proyecto, Git y sesiones activas. This gives a clear purpose, though it overlaps with sibling tools like opencode_check and opencode_status, so it doesn't strongly distinguish itself.

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 explicitly says 'Úsalo antes de delegar una tarea nueva', providing a clear when-to-use context. However, it does not mention when not to use it or name alternative tools, so it stops short of the full 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?

No annotations are provided, so the description carries the burden. It does list the behaviors (health, occupied sessions, MCP, Git status), which is useful, but it does not explicitly state whether the operation is read-only, mention authentication requirements, or describe the return format. For a status/health tool, the information is adequate but incomplete.

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 that directly states the purpose. No wasted words; every part contributes meaning. It is appropriately sized for the tool's simplicity.

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?

With no output schema and no annotations, the agent relies on the description to know what to expect. The description lists the status categories but does not clarify the response structure, such as whether it returns a textual summary, structured data, or separate results per category. For a status tool, this leaves some ambiguity, though the listed categories provide a reasonable starting point.

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 schema already covers the single parameter (directory) with a clear description. The tool description adds extra meaning by explaining when the parameter is optional (aggregated queries) and when it is required (tasks/sessions), which is not present in the schema. This goes beyond the schema baseline.

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 checks multiple status aspects: health, occupied sessions, MCP, and project Git status. The verb 'Consulta' (query) is specific, and the listed resources distinguish it from more focused siblings like opencode_mcp_status. It could be more explicit about how it differs from opencode_check, but the scope is clear.

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?

No guidance is provided on when to use this tool versus alternatives. The only usage hint is about the directory parameter (aggregated queries may omit it; tasks/sessions must include it), which is parameter guidance, not tool-selection guidance. There is no mention of exclusions or alternative tools.

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 alone must disclose behavior. It mentions using an explicit model and freeing context, but it does not reveal whether the session is modified in place, whether the compaction is irreversible, or what the return value is. This is a significant transparency gap for a state-changing 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, front-loaded sentence that conveys the action, method, and purpose with no redundant language. It is appropriately sized.

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?

With no annotations and no output schema, the description must explain the consequences of compacting a session. It only states the intent, leaving unclear whether the operation is destructive, reversible, or what result is returned, making it incomplete for a tool that appears to alter session state.

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 schema already documents all three parameters completely, including the model format, the required absolute directory, and the session ID source. The description only reinforces the idea of an explicit model, adding no new parameter-level meaning beyond the schema baseline.

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, summarizing/compacting a long session, plus the mechanism of using an explicit model and the goal of preserving continuity and freeing context. This clear verb-plus-resource pattern distinguishes it from sibling tools such as opencode_context and opencode_run.

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 defines the use case: it is for a long session where continuity should be preserved and context freed. However, it does not mention alternative tools or explicit when-not-to-use conditions, so it provides a clear context but no exclusions.

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 transparency burden. It explicitly discloses the blocking wait behavior, the timeout condition, and that evidence is returned. It omits details like polling mechanics or error handling for missing/invalid sessions, 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 a single concise sentence that front-loads the action and result. Every phrase earns its place, and there is no redundant 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 wait tool with a fully described schema, the description covers the main purpose, timeout, and return value. However, without an output schema, 'evidencia' is vague, and the prerequisite of an existing session is only implied; the schema's sessionId description partially fills that gap.

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 baseline is 3. The description does not add meaningful parameter-specific semantics beyond what the schema already provides; it only echoes the timeout concept and the notion of evidence.

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 ('Espera') and names the resource ('sesión asíncrona'), clarifying the blocking behavior until completion or timeout and the returned evidence. It differentiates from sibling tools like opencode_run/opencode_fire and the singular 'una sesión' distinguishes it from opencode_wait_many.

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 this tool is for waiting on an asynchronous session, but it does not explicitly state when to use it over alternatives such as opencode_wait_many or opencode_status, nor does it mention that it should follow opencode_run or opencode_fire. The context is clear but not fully elaborated.

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 full burden of behavioral disclosure. It states that it waits in parallel and returns results, which are important traits. However, it does not mention potential blocking behavior, timeouts, error handling, or what happens if some sessions fail, leaving notable gaps for a wait 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, concise sentence that efficiently communicates the core functionality without any filler or redundant information. It is appropriately sized for the tool's simplicity, despite other dimensions lacking detail.

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 complexity of a multi-session wait with configurable polling and timeouts, and the absence of an output schema and annotations, the description is too sparse. It does not explain return value details, failure behavior, or how to interpret results, leaving the agent with significant uncertainty about how to invoke and use the tool effectively.

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 does not compensate by explaining the parameter structure. It mentions 'sesiones' but does not specify that the parameter is an array of objects with directory, sessionId, pollIntervalMs, and timeoutSeconds. The schema provides some help for 'directory', but other nested fields like 'sessionId' lack description, and the tool description adds no parameter-level semantics.

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 function: it waits in parallel for multiple previously dispatched sessions and returns each result. It includes a specific verb ('Espera') and resource ('varias sesiones previamente despachadas'), and the name 'wait_many' reinforces the multi-session scope, distinguishing it from the singular 'opencode_wait' sibling.

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 context: it is for sessions that have already been dispatched ('previamente despachadas') and handles multiple sessions in parallel. It does not explicitly mention alternatives or exclusions, but the context is clear enough to guide an agent toward using this for multi-session waiting versus a singular wait tool.

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