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 a key behavioral trait: 'No API key needed — Chat IS the vision layer,' meaning the tool itself does not perform vision processing but instead receives a textual description. However, it does not mention side effects, return value, or error handling, which is a significant gap given the absence of an output 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?

The description is two well-structured sentences. The first sentence states the core purpose, and the second explains the workflow and a critical constraint (no API key). Every sentence contributes value, making it concise and 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?

With 100% parameter schema coverage and no output schema, the description explains the workflow clearly but stops short of explicitly stating the return format. The phrase 'suggest actions' gives some indication of the output, but it's vague. Nevertheless, the mechanism is sufficiently described for an agent to invoke the tool correctly, meriting a 4.

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 minimal parameter information beyond what the schema already provides, though it clarifies that 'description' is the text representing what Chat sees in the image. This aligns with the schema and does not introduce conflicting 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: 'Interpret an image and suggest actions.' It goes beyond a generic verb by explaining the specific mechanism—Chat (Claude) provides the image description, and this tool processes that description. This differentiates it from sibling tools like implement_from_image or compare_screenshots, which likely operate on different inputs or outputs.

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 workflow: the user uploads an image, Chat describes it, and then calls this tool with the description. This implicitly tells when the tool is used (after vision analysis by Chat) but does not explicitly name alternatives or exclusions. It earns a 4 for clear context without 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 full burden, but it only vaguely mentions 'can trigger fixes' without explaining the nature, risk, or reversibility. It also doesn't clarify that the tool takes text descriptions, not images, which could mislead. The side-effect of triggering fixes is disclosed but under-specified.

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 short and efficient, but the first sentence is somewhat redundant and could be misleading. It could be restructured to prioritize the tool's actual role.

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 provides a basic workflow context but lacks detail on output, side effects, or prerequisites. With no output schema and no annotations, the description should explain more about what 'structures the findings' yields and what 'trigger fixes' entails.

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 minimal value beyond the schema, only indicating that the 'differences' field comes from Chat's comparison. It does not enrich parameter meaning.

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 identifies the tool as structuring findings from Chat's visual diff between expected and actual screenshots, and potentially triggering fixes. However, the opening 'Visual diff between expected and actual' is ambiguous about whether the tool performs the diff itself. It is distinguishable from siblings like analyze_image by focusing on structuring differences rather than image analysis.

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 clearly implies the tool is used after Chat has compared two images and described differences ('then this tool structures the findings'). It gives a clear workflow context but does not mention 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 carries the full burden of disclosing behavioral traits. It indicates a state-changing operation (setting model, effort, terminal mode) but does not explain side effects, persistence, scope (current session vs global), or reversibility. This lack of detail beyond the immediate action is a notable gap for a mutation-type tool without annotation support.

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 one concise sentence followed by examples. It is front-loaded with the primary purpose, and every element earns its place. There is no fluff or redundancy, making it optimally brief for an AI agent to parse quickly.

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 configuration tool with only one parameter and no output schema, the description is largely complete: it states the action, the outputs are not needed, and the instruction parameter is well-documented in the schema. The main gap is the lack of behavioral transparency (persistence/scope), but given the tool's simplicity, the overall completeness is strong. A slight deduction is warranted for the missing side-effect disclosure.

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 has a fully descriptive parameter ('instruction' with examples), giving 100% schema coverage. The description reinforces this with additional examples, but adds little beyond what the schema provides. The baseline of 3 is appropriate; the description adds marginal value only through extra example phrases.

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 action: 'Set model, effort level, and terminal mode.' This is a specific verb with concrete resources. The example phrases further clarify the scope (e.g., 'Use Opus for coding', 'Set high effort', 'Run in background mode'). This distinguishes it from sibling tools like configure_workers or execute_task, making the purpose unmistakable.

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 example natural language commands that demonstrate when to invoke the tool ('Say 'Use Opus for coding' or 'Set high effort'...'), establishing clear contexts for use. It does not explicitly list alternatives or exclusions, but the examples make usage evident. This ranks slightly below a perfect score because it lacks explicit 'when not to use' guidance, but the context is strong.

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?

The description does not disclose important behavioral aspects such as whether the configuration persists, whether it overwrites existing settings, or whether it affects the current session immediately. With no annotations, the description carries the full burden but only states the general purpose, leaving significant ambiguity for a state-changing configuration 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 sentence with embedded examples, no fluff or repetition. Every word earns its place, making it highly efficient 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 covers the core functionality and usage pattern adequately for a single-parameter tool with no output schema. It lacks details on side effects and scope of changes, but the overall purpose and interaction pattern are clear enough for basic 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 schema already provides 100% coverage with a clear description and an example. The tool description adds an additional example ('Set Aider as default') that enriches contextual understanding beyond the schema, providing extra clarity on the accepted instruction format.

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 'Configure' with a clear resource ('which CLI tools handle which tasks'). This clearly distinguishes it from the sibling configure_model, which targets model configuration rather than tool-task routing.

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 concrete natural language examples ('Use Claude for coding', 'Set Aider as default') that illustrate when and how to use the tool. It does not explicitly mention alternatives or exclusion criteria, but the examples are illustrative enough for an agent to infer usage.

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 burden of disclosing side effects. It merely says 'Define a new specialist agent' without mentioning that this is a write operation, whether it persists data, requires specific permissions, or what happens on success. The lack of behavioral detail is a significant gap for a creation 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 with no redundancy, earning its place. However, it is somewhat under-specified given the tool's 5 parameters, so while it is concise, it sacrifices necessary content for brevity.

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 creation tool with no output schema, the description is too thin. It does not explain what the tool returns (e.g., agent ID), the prerequisites such as a sessionId, or any follow-up actions. The description is inadequate for an agent to confidently invoke the tool in a real workflow.

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, so the schema already explains all five parameters. The description adds a marginal hint that the 'description' parameter uses natural language, but it does not enrich the meaning of other parameters like 'tools' or 'persona'. Baseline 3 is appropriate given the 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 'Define' with the resource 'a new specialist agent', clearly distinguishing it from sibling tools like update_agent and remove_agent. The phrase 'via natural language description' also clarifies the core creation method.

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 creating new agents, which is a clear context, but it does not explicitly state when to use it versus update_agent or list_agents. No exclusions or alternative guidance is provided, so the usage is only implied by the tool's name and sibling context.

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 only says 'create', which implies mutation, but does not explain side effects (e.g., filesystem changes, background processes) or any permissions or prerequisites.

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 no unnecessary words. It communicates the essential action and scope 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 tool is simple with 2 fully described parameters, but there is no output schema or annotations. The description hints at creating both a session and a workspace, yet does not clarify what that entails or what the agent should expect. It is adequate but could benefit from a sentence about preconditions or effects.

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 both parameters. The description adds minimal extra meaning by linking 'project workspace' to projectPath, but does not provide additional 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?

The description clearly states the tool's action: 'Create a new Cerebro session and project workspace'. It uses a specific verb and resource, distinguishing it from sibling tools like resume_session and end_session.

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 (creating a new session) but provides no explicit guidance on when to use it versus alternatives such as resume_session. No when-not scenarios or alternative tool names are mentioned.

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, and the description only states the core behavior (routing/overriding). It does not disclose potential side effects like terminal window closure (despite the autoCloseTerminal parameter), whether the call blocks, or what the result includes. With no annotations, this is insufficient.

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 sentence, zero wasted words, front-loaded with the action. Though under-specified, it is elegantly 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?

The tool has 4 parameters and no output schema, and no annotations. The description is too brief to cover usage context, side effects, or return behavior, especially given the many sibling tools. It leaves the agent to guess when to use it and what happens after delegation.

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 four parameters have schema descriptions, so schema coverage is 100%. The description adds no extra parameter context, but the baseline is 3 for full 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 'route' with 'task' and 'agent', and explicitly differentiates from auto-routing, making it distinct from sibling tools like execute_task or quick_task.

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 'overriding auto-routing' implies when to use, but it does not mention alternatives or when not to use. Clear context without 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 must carry the full burden. It states the high-level behavior (detecting installed/available tools) but does not mention specifics such as read-only nature, environment scope (PATH, system-level), or potential outcomes. The verb 'detect' mildly implies non-destructive behavior, but more context would help.

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 no redundant words. It efficiently communicates the tool's purpose without unnecessary 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?

The tool is simple with zero parameters and no output schema, so the description should explain what the result looks like. It provides a high-level idea but does not specify the output format (e.g., list of names, paths, versions). This is a minor gap for a detection 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?

The tool has zero parameters, so the baseline is 4. The description correctly implies no inputs are required, and the empty schema confirms this. No parameter descriptions are needed.

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 ('Detect') and the specific resource ('CLI coding tools installed and available on this system'). It is distinct from all sibling tools, which focus on sessions, tasks, agents, or configuration rather than environment discovery.

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?

Usage is implied: run this tool to see which coding tools are present before using provider-specific capabilities. However, there is no explicit when-to-use, when-not-to-use, or alternative naming, though no sibling tool appears to duplicate this function.

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 must disclose behavioral traits. It mentions archiving but does not state whether the action is irreversible, what permissions are required, or what happens to associated data/tasks. This is a significant gap for a session-ending action.

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 with no extraneous words. It efficiently communicates the core action without being under-specified to the point of tautology.

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 description should explain the outcome and side effects. It only says 'complete and archive', leaving the return value and consequences unspecified, which is incomplete for an action that likely has permanent effects.

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 fully documents the only parameter, 'sessionId', with the description 'Session ID to end'. The tool description adds no additional meaning beyond the schema, so the baseline score 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 'Complete and archive a session' clearly specifies both the action (complete and archive) and the resource (a session). It distinguishes from siblings like pause_session or create_session by adding the archiving behavior, which implies finality.

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 vs. alternatives like pause_session or resume_session. The word 'archive' hints at finality, but there is no explicit statement about when to choose this over other session-related 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?

With no annotations, the description carries the full behavioral disclosure burden. It only says 'send a task... for execution' but does not disclose whether execution is asynchronous, what side effects occur, how results are returned, or error handling 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?

The description is a single, concise sentence with no wasted words. It is appropriately front-loaded with the action and object.

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 is too thin to be complete. It fails to explain the execution flow, how results are surfaced, or how this tool fits with siblings, leaving substantial gaps 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 coverage is 100%, with each parameter already described in the schema. The description adds the concept of 'appropriate worker or agent' but does not provide additional semantic detail beyond the schema, so 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 a clear verb ('Send') and identifies the resource ('a task to the appropriate worker or agent for execution'). However, it does not distinguish this tool from closely related siblings like 'delegate_to_agent' or 'quick_task', leaving some ambiguity about its specific 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?

No guidance is provided on when to use this tool versus alternatives. It does not mention when 'targetAgent' should be set, how routing decisions are made, or when 'quick_task' or 'delegate_to_agent' would be more appropriate.

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 must disclose behavioral traits itself. It merely states 'Get' which implies a read operation, but doesn't mention whether the call is read-only (beyond inference), what errors might occur, if any special permissions are needed, or what the response contains beyond generic 'status and history'. This lack of detail is a gap given zero annotation coverage.

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 of eight words, front-loading the verb and resource. No fluff or repetition of schema details, making it maximally efficient.

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 getter with no output schema, the description gives a high-level purpose but omits what 'detailed' entails or the shape of the history data. It doesn't indicate any prerequisites or usage caveats, so while not disastrous, it leaves the agent guessing about response structure and 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?

The schema already fully documents the only parameter (agentId, string, 'Agent ID') with 100% coverage, so the baseline is 3. The description's phrase 'for a specific agent' merely echoes the schema without adding new semantic information.

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 'Get' with resource 'detailed status and history' and scope 'specific agent', clearly distinguishing it from siblings like list_agents (which lists all agents) and get_status (which likely returns general status). The mention of 'history' adds 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?

The description provides no explicit guidance on when to use this tool versus alternatives like get_status or list_agents. There are no preconditions, exclusions, or alternative tool references, leaving the agent to infer usage from the name and parameter alone.

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?

The verb 'Report' suggests a read-only operation, and 'current' implies a snapshot, but the description does not disclose additional behavioral details such as return format, error handling, or whether it has side effects. With no annotations, the description carries the full burden but only minimally satisfies 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, front-loaded sentence without any unnecessary words. Every word contributes meaning, and it is appropriately sized for a simple read-only tool.

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 (one parameter, no output schema, no annotations), the description covers the core purpose but leaves ambiguity around what 'handover readiness' specifically entails and the structure of the report. It is adequate but not fully explanatory.

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%—the only parameter, sessionId, is described as 'Session ID.' The tool description does not elaborate on how sessionId is used or provide any additional context, so it adds no value beyond the schema, yielding the baseline score.

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 with a specific verb ('Report') and resource ('current context window usage and handover readiness'). This distinguishes it from siblings like prepare_handover (which likely initiates a handover) and get_status (which is more generic).

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 such as get_status or prepare_handover. There are no exclusions, preconditions, or scenarios described, leaving the agent to infer usage from the name.

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 full responsibility for disclosing behavioral traits. It indicates a read-only 'get' operation, but does not mention whether it modifies state, requires specific permissions, or what side effects (if any) occur. It also does not explain how sessionId is used or what the response contains, leaving the agent with incomplete behavioral 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 that efficiently conveys the core purpose. It is concise without being wasteful, though it could be slightly more informative without harming 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?

The tool has a simple interface (one parameter, no output schema), so the description need not be elaborate. However, it lacks context about what the expected output looks like, how sessionId factors into status retrieval, and when this tool is most useful. Given the sibling tools in a session-management context, some additional 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?

The input schema provides full coverage of the single parameter (sessionId) with a description ('Session ID'). The tool description does not add any additional meaning beyond what the schema already provides, but since schema coverage is 100%, the baseline score 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 clearly states a specific verb ('Get') and resource ('current project progress and task status'), which distinguishes it from sibling tools like get_agent_status and get_context_health. However, it does not explicitly differentiate from all siblings, and the name 'get_status' is somewhat generic without the description.

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?

There is no guidance on when to use this tool versus alternatives such as get_agent_status, get_context_health, or read_project. The description simply states what the tool does, with no mention of context, prerequisites, 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, the description discloses a key behavioral trait—it delegates to a CLI worker rather than operating directly. However, it does not mention side effects, permissions, reversibility, or response behavior, leaving important gaps for a tool that likely modifies code.

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 short sentences, front-loaded with the core purpose, then the mechanism and use cases. Every sentence earns its place without 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 covers purpose, mechanism, and concrete use cases, which is sufficient for a tool with three well-documented parameters. However, it omits any mention of return behavior or error handling, which would be valuable given the lack of an 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?

Schema description coverage is 100%, so the baseline is 3. The description does not add any parameter-specific meaning beyond what the schema already states; for example, the 'description' parameter is described identically in both places.

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?

Clearly states the verb ('Build or fix code') and the resource ('based on an image'). Explains the mechanism (Chat describes image, tool sends description to CLI worker) and distinguishes it from analysis-focused siblings like analyze_image by emphasizing implementation.

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?

Provides explicit use cases: 'screenshots of bugs to fix, mockups to build, error messages to resolve.' This gives clear context for when to use the tool, but it does not mention alternatives or when not to use it, 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 provided, the description must disclose behavioral traits, but it only states the action without mentioning side effects, permissions, or return behavior. Installing templates could overwrite existing configurations or have other consequences, which are not disclosed.

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 with no filler or repetition. It is front-loaded with the key action and resource, making it 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 tool is simple with two well-described parameters, so the description covers the basic purpose. However, without an output schema, it does not hint at what happens after installation (e.g., success message, installation progress), leaving some gap in 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?

Input schema coverage is 100% and provides descriptions for both parameters. The tool description adds minimal extra meaning beyond the schema, though it helps contextualize that packName refers to marketplace templates.

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 ('Install') and resource ('pre-built agent templates') with a source ('marketplace'), clearly distinguishing it from sibling tools like create_agent or list_agents. It precisely conveys what the tool does.

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 when to use the tool (when you want to install pre-built templates) but does not provide explicit guidance on when not to use it or mention alternatives like create_agent for custom agents. No exclusions or comparison with siblings.

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, yet it only says 'Show all agents'. It does not state that this is a read-only operation, describe the return format, or explain what happens if the session does not exist or has no agents. The phrase 'current session' also introduces ambiguity about whether the required sessionId parameter is actually needed.

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, 11-word sentence that front-loads the action and resource without any filler. Every word contributes to meaning.

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 parameter and no output schema, the description is minimally viable but incomplete. It lacks details about the response structure, the meaning of 'status', and any error cases, leaving clear gaps that an agent would need to infer.

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 fully documents the single parameter sessionId, so baseline is 3. The description's mention of 'current session' adds no new information about the parameter and could be slightly confusing, but it does not contradict the schema, so a baseline score 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 a specific verb ('Show') and resource ('all agents'), and specifies the scope ('in the current session') and the included detail ('with their status'). This distinguishes it from sibling tools like get_agent_status, which targets a single agent.

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 a clear use case—listing all agents in a session—but does not explicitly discuss when to use it over alternatives or mention any exclusions. For example, it does not direct users to get_agent_status for single-agent details, so guidance is only implied.

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 communicates the read-only nature ('List') and the categories of sessions covered, but it does not clarify details like sorting order, pagination, or what qualifies as 'recent.' This is adequate for a simple listing tool but lacks depth.

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 with no filler. It front-loads the verb and resource, making it immediately actionable and 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?

Given zero parameters, no annotations, and no output schema, the description provides enough context for basic usage. However, it leaves the term 'recent' undefined and does not describe the return format, which could be a minor gap for an agent needing precise expectations.

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 baseline is 4. The description does not need to explain parameter meanings. It does add conceptual context by naming the session categories, which helps the agent understand the implicit selection criteria.

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 ('List') and resource ('sessions') and clarifies the scope with categories ('active, paused, and recent'). It clearly differentiates from sibling tools like create_session, pause_session, and end_session, which are mutate operations.

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 use for viewing existing sessions, but it does not explicitly state when to use this tool versus alternatives like get_status. There is no mention of exclusions or preferred scenarios, leaving the usage guidance 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 full burden of behavioral disclosure. It only says 'Pause an active session' without describing side effects, state changes, idempotency, or error conditions. The phrase 'for later resumption' hints at resumability but omits key behavioral traits.

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, concise sentence that is front-loaded with the action and resource. No redundant words or filler, earning a high score for 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 simple one-parameter tool, the description is minimally adequate but lacks context about session state requirements, side effects, or how it fits into the session lifecycle. Since there is no output schema, return behavior is not explained, but this is not required for such a simple 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 100% with the only parameter sessionId described as 'Session ID to pause'. The description adds no additional context beyond the schema, but the schema is fully self-explanatory. 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 clearly states the action ('Pause') and the resource ('an active session') with a purpose ('for later resumption'). This distinguishes it from sibling tools like resume_session and end_session, which perform different lifecycle operations.

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 explicit guidance is given on when to use this tool versus alternatives. The description implies use on an active session but does not explain differences from end_session or how to later resume. There is no mention of prerequisites 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 behavioral disclosure. It mentions the token is 'signed', hinting at a security property, but does not disclose side effects, permissions needed, token validity, or whether this operation is read-only or mutating. For a token-generation tool, this is a significant gap.

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 conveys the tool's primary function without any filler. Every word contributes meaning, making it highly efficient.

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 (one parameter, no output schema, no annotations), the description explains the core function but omits details about the returned token's format, usage, or lifespan. It is sufficient for a basic understanding but not fully complete for an agent to invoke it confidently in all scenarios.

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% (the only parameter sessionId is described as 'Session ID'), so the baseline is 3. The description adds no additional meaning for the parameter beyond what the schema provides, which is adequate but not enhanced.

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 ('Generate') and the resource ('signed handover token'), including its purpose ('for session continuity across chats'). This distinguishes it from sibling tools like create_session or resume_session, which are about session lifecycle rather than producing a continuity token.

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 the use case: when session continuity across chats is needed. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. It gives enough context to infer the purpose but lacks explicit 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 provided, the description carries the full transparency burden. It discloses that the tool auto-creates a session, picks a provider, executes, and asks for projectPath if missing. However, it does not mention potential side effects of execution (e.g., that it may modify files, run builds, or make changes), which is important for a tool that executes tasks.

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 efficient: three sentences covering purpose, usage guidance, and a key behavioral note. It is front-loaded with the core value proposition and contains 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?

The description covers the main purpose and usage context, but considering the tool executes tasks and has no annotations or output schema, it lacks critical context about side effects, confirmation steps, or what happens after execution. For a high-level action tool, more detail is needed to fully inform the 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 coverage is 100%, so the baseline is 3. The description adds extra meaning by clarifying that projectPath may prompt the user if omitted, and that the provider is auto-picked. This goes beyond the plain schema descriptions, justifying a 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: it's an easy way to use Cerebro by describing what to build or fix, and it auto-creates a session, picks a CLI provider, and executes. It distinguishes itself from sibling tools like create_session and execute_task by targeting cases where the user doesn't specify sessions or 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?

The description explicitly says when to use this tool: when the user gives natural language instructions like 'build me a website' or 'fix this bug' without specifying sessions or agents. It also provides a practical guideline to ask for projectPath if omitted. However, it does not name specific alternative tools to use in other cases, though the 'without specifying sessions or agents' clause implies them.

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 explicitly states that it 'Returns directory tree and optionally file contents for specified files or all files,' which gives the agent a clear expectation of the output and its optional nature. It does not mention any side effects, but for a read-only operation, this is adequate.

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, consisting of two sentences that front-load the main action and then provide usage context and output details. Every sentence earns its place without redundancy, making it easy to parse quickly.

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 moderately complex with five parameters and no output schema, so the description must cover key behavioral aspects. It does explain the return value (directory tree and optionally file contents) and the core use case. It does not elaborate on edge cases like invalid paths or large file handling, but those are not essential for initial understanding.

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% description coverage for all five parameters, so the schema already explains each parameter's meaning. The description adds little beyond the schema except a hint that 'specified files' relates to path/includeContents, but it does not elaborate on parameter formats or defaults. This matches the baseline expectation for well-documented schemas.

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 with a specific verb and resource: 'Read the project folder structure and file contents.' It also provides context ('understand a codebase before making changes') that implies its role, but it does not explicitly distinguish itself from sibling tools like review_code or get_status. Overall, it is clear and specific enough to understand what the tool does.

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 context: 'Use this to understand a codebase before making changes.' This tells the agent when to use it, but it does not mention when not to use it or offer alternatives, such as search tools. Still, the guidance is direct and practical.

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 disclose behavioral traits itself. 'Delete' implies destructive action, but it does not state whether deletion is permanent, whether it affects running tasks or associated data, or any permission requirements. The lack of detail leaves the agent to infer side effects.

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, front-loaded sentence. Every word earns its place with 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?

For a destructive operation with no annotations or output schema, the description is too thin. It does not explain the outcome of a successful deletion, potential errors, or irreversible consequences, leaving the agent without sufficient context to use the tool safely.

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 fully describes the single parameter 'agentId' with 'Agent ID to remove', so schema coverage is 100%. The description adds no additional meaning beyond what the schema already provides, 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 'Delete an agent from the swarm' uses a specific verb ('Delete') and resource ('agent'), with clear scope ('from the swarm'). It unambiguously distinguishes this from sibling tools like create_agent, update_agent, and list_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 provided on when to use this tool versus alternatives such as update_agent or get_agent_status. The description simply states the action without context about prerequisites, sequencing, or situations where deletion is appropriate.

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 simply says 'Resume an existing session' but does not explain side effects, whether the session must be paused, what happens with invalid tokens, or the return value. This is a significant 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, concise sentence that is front-loaded with the action and resource. Every word earns its place, with no redundancy or fluff.

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 tool, the description provides enough to understand the basic purpose. However, it lacks information about return values, error conditions, and how this relates to the sibling tools (e.g., prepare_handover). The absence of an output schema and annotations increases the burden, which is only partially met.

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%: the 'token' parameter is well-described as 'Base64url-encoded handover token'. The description adds no additional meaning beyond referencing the handover token, so the baseline 3 for full schema coverage 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 is specific with a verb ('Resume') and a resource ('existing session'), and it adds the key detail 'using a handover token'. This distinguishes it from sibling tools like create_session, pause_session, and end_session.

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 does not explicitly state when to use this tool versus alternatives or mention any prerequisites. It only says 'using a handover token', which implies a condition but does not offer clear guidance on when to prefer this tool over create_session or validate_token.

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 must disclose behavioral traits but only states the output intent. It does not indicate whether the tool is read-only, whether it requires existing code changes, or what happens if no changes are found.

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 with no filler words, directly stating the core function. It is appropriately concise for the simplicity of the tool.

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 no output schema and no annotations, so the description needs to explain return values and usage context. It only mentions 'human-friendly explanation' without detailing the output format, what code changes are covered, or the role of the session. This is inadequate for a tool that likely needs session context.

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 descriptions for both filePath and sessionId (100% coverage), so the schema already documents the parameters. The tool description adds no additional meaning beyond the schema, warranting the baseline score of 3.

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 the tool's purpose as 'Get a human-friendly explanation of code changes', which clearly identifies the action and resource. It is distinct from sibling tools like read_project or run_tests, though it could be more specific about what 'code changes' means in the context of a session.

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 prerequisites such as an active session, nor does it explain scenarios where a human-friendly explanation is preferred over other 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'return results' without revealing side effects, permissions, synchronous/asynchronous behavior, or what the results mean. This is insufficient for a build trigger.

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 no redundant words. It effectively communicates the core action and outcome, making it highly 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?

Given the simplicity of the tool (one parameter, no output schema), the description is still incomplete. It does not specify the return format, potential errors, or side effects of a build. This is a notable gap for an action that could be long-running or produce artifacts.

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%, though the parameter description 'Session ID' adds little meaning beyond the parameter name. The tool description does not provide additional context about the session parameter, so 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 'Trigger a project build and return results' clearly states the action (trigger) and resource (project build) with an expected outcome. However, it does not explicitly distinguish from sibling tools like run_tests or execute_task, so it misses the top score for differentiation.

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?

There is no guidance on when to use this tool versus alternatives. It neither mentions prerequisites nor excludes any scenarios. The description only states the function, leaving the agent without context for selection.

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 full responsibility for behavioral disclosure. It only says 'Run the test suite and return results' without detailing side effects, required session state, error behavior, or output format. This is minimal disclosure.

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 no wasted words. Every word contributes meaning.

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?

Although the tool is simple, the description omits essential context such as what the 'test suite' refers to, what 'results' include, and any need for an active session. There is no output schema, so the description must explain return values, which it fails to do.

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% for the single required parameter 'sessionId', so the schema already documents it. The description adds no additional meaning beyond the schema, matching the baseline score of 3.

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 'Run' with resource 'the test suite' and states it returns results, which clearly identifies the tool's function. It does not distinguish from sibling tools like run_build or execute_task, so it doesn't fully 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 provides no guidance on when to use this tool versus alternatives. It merely states what it does, with no mention of prerequisites (e.g., active session) 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, the description discloses the key side effect of opening a persistent terminal, which is an important behavior. It also explains tracking behavior and handover recommendation. However, it doesn't mention configurable options like noTerminal, which changes the behavioral profile, though those are covered in 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?

The description is two sentences with no wasted words. It front-loads the main action ('Open a persistent terminal') and efficiently states what the tool tracks.

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 tool's purpose, side effect, and tracking scope. It is adequate for a tool with a complete schema, though it lacks explicit usage guidance that would make it more complete.

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 complete descriptions for all three parameters (sessionId, noTerminal, autoCloseTerminal), so the description does not need to add param details. It adds no extra meaning beyond what the schema already explains.

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 action ('Open a persistent terminal') and its purpose ('real-time token usage'). It also specifies what it tracks ('every Cerebro tool call with estimated tokens and handover recommendation'), distinguishing it from sibling tools like stop_context_watcher and get_context_health.

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 the tool is for watching token usage in real-time, but does not explicitly state when to use it over alternatives like get_context_health or prepare_handover. No exclusions or conditions 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 burden of behavioral disclosure. It adds useful context by noting 'Tracking data preserved', implying a non-destructive stop, and 'close terminal' as a side effect. However, it doesn't mention idempotency or behavior when the watcher isn't running, leaving some 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?

A single sentence that front-loads the verb 'Stop' and the target, includes the key side effect, and the data preservation note. Every word 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 zero-parameter, no-output-schema tool, the description addresses the main action, side effect, and data preservation, which is sufficient for the tool's simplicity. It could add idempotency details, but the core usage is clear.

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 schema covers everything. The description doesn't need to compensate, and the baseline of 4 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 action ('Stop the Context Watcher') and a side effect ('close terminal'), specifying the exact resource ('Context Watcher'). This distinguishes it from sibling tools like start_context_watcher or pause_session, which involve different actions on different resources.

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 such as pause_session or end_session. It only states what it does, leaving the user to infer usage context from the tool name and siblings.

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 only states 'Modify' without explaining whether updates are partial or full replacements, what happens to unspecified fields, or why sessionId is required. This leaves significant behavioral ambiguity for a mutation 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 front-loads the verb and resource. It wastes no words, but it could be slightly more structured to include key usage context 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?

For a mutation tool with 6 parameters, no output schema, and no annotations, the description is incomplete. It does not clarify update semantics (partial vs. full), the role of the required sessionId, or any error/return behavior, which are essential for safe 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?

Schema description coverage is 100%, as every parameter has a clear description (e.g., 'New name', 'New tool list', 'New persona'). The tool description adds only a high-level mapping to 'definition, skills, or preferences' but no additional syntax or format details, so it meets the baseline for schema-backed 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 'Modify' with the resource 'existing agent' and scopes it to 'definition, skills, or preferences', clearly distinguishing it from sibling tools like create_agent and remove_agent. This is a precise and unambiguous statement of the tool's purpose.

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 such as create_agent or remove_agent. It does not mention prerequisites (e.g., the agent must already exist), nor does it exclude cases where other tools would be more appropriate.

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 only says 'check if valid'—it does not explain whether an invalid token returns a boolean, throws an error, or what side effects (if any) occur. It does not even clarify the meaning of 'valid' (e.g., expiry, format), which is critical for a validation 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, concise sentence that is front-loaded with the core action and resource. It contains no fluff or redundancy, earning full marks for brevity and structure.

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?

There is no output schema, so the description should explain what the tool returns (e.g., boolean, error message) and any conditions for validity. Without this, an agent cannot reliably interpret the result. Given the tool's simplicity, the description is still incomplete in critical behavioral aspects.

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 100% coverage of the single `token` parameter with a description ('Base64url-encoded token to validate'). The tool description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate—the schema does all the work.

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 ('Check if a handover token is valid') and identifies the resource ('handover token'). It is specific enough to distinguish from sibling tools like prepare_handover, which creates or prepares the token, though it does not explicitly mention that distinction.

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 no guidance on when to use this tool versus alternatives. It does not mention that this should be called before proceeding with a handover or what to do with the result, leaving the agent to infer usage entirely from the name and context.

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