Server Quality Checklist

Tool Scores

• collaborateC
  2.6/5.0
  Behavior2/5

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

  With no annotations, the description must carry the full burden of behavioral disclosure. It only states a basic send/receive flow and mentions 'guidance for comparison' without explaining what that entails. It doesn't disclose whether it is blocking, invokes an external service, requires permissions, or how it handles timeouts.

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

  Conciseness4/5

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

  Two sentences with no filler, but the second sentence is slightly clunky with 'provides guidance for comparison.' Overall, it's concise and front-loaded enough.

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

  Completeness2/5

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

  There is no output schema and no annotations, so the description must explain return values and usage context. It doesn't describe the response format, what 'guidance for comparison' looks like, or how optional context and timeout affect results, making it incomplete for a tool with this complexity.

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

  Parameters3/5

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

  The schema covers all parameters with descriptions (100% coverage), so the baseline is 3. The description adds no extra meaning about how 'agent', 'prompt', 'context', or 'timeout' interact, so it remains at baseline.

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

  Purpose3/5

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

  The description states it 'collaborates with an agent for analysis' and elaborates that it sends a prompt and gets a response, but 'provides guidance for comparison' is ambiguous. It doesn't clearly differentiate this from sibling tools like ask_agent, which also send a prompt and get a response.

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

  Usage Guidelines2/5

  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 ask_agent, ask_all, or delegate_task. There is no mention of conditions, prerequisites, or scenarios where this tool is preferred, leaving the agent to guess.

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

• refactor_withC
  2.9/5.0
  Behavior2/5

  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 the tool refactors code but does not disclose whether it returns the refactored code, modifies in place, requires authentication, or what side effects may occur. This is a significant gap for a code-transformation tool.

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

  Conciseness5/5

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

  The description is a single sentence, front-loaded with the action ('Refactor code'), and includes the optional goal parameter. Every word contributes meaning, with no redundancy or unnecessary detail. It is appropriately concise for the tool's simplicity.

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

  Completeness2/5

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

  The description is minimal and fails to explain the return value or behavior of the tool. With no output schema and no annotations, the description should clarify what the user receives after invoking the tool, but it does not. It also does not mention that an agent must be chosen, relying on the schema to convey this. The agent is left without essential context for a code-refactoring operation.

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

  Parameters3/5

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

  The input schema covers all parameters with descriptions and enums, achieving 100% coverage. The description adds no meaningful information beyond restating that a goal can be specified, which is already enumerated in the schema. The baseline of 3 applies because the schema handles parameter semantics completely.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: 'Refactor code using a specific agent.' This distinguishes it from sibling tools like debug_with and explain_with by the task type. However, it does not explicitly differentiate it from all siblings, such as delegate_task or review_code, so it lacks explicit sibling differentiation.

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

  Usage Guidelines2/5

  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 like delegate_task or ask_agent. It implies use for refactoring but does not mention when not to use it or mention alternative tools for related tasks, leaving the agent without strategic direction.

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

• review_codeC
  2.9/5.0
  Behavior2/5

  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 of behavioral disclosure. It only says 'analyzes' without revealing side effects, whether code is sent to external agents, permission requirements, read-only nature, or output/return behavior. This is insufficient for a tool that processes user-supplied code.

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

  Conciseness5/5

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

  The description is two sentences and 14 words, thoroughly front-loaded with the main action and resource. Every word adds value, and it avoids redundancy, making it highly efficient.

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

  Completeness2/5

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

  The tool has 5 parameters, no output schema, and no annotations. The description is too minimal to cover important context like return values, how to choose an agent, behavior on timeout, or error handling. It does not complete the picture for an agent deciding to invoke this tool.

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

  Parameters3/5

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

  Schema description coverage is 100%, so all parameters have documentation. The description's mention of 'bugs, security, performance, and clarity' maps to the focus enum, but it adds no additional meaning beyond the schema. The baseline of 3 is appropriate since the schema already handles parameter semantics.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: 'Review code using a specific agent. Analyzes for bugs, security, performance, and clarity.' It names the verb 'review' and the resource 'code', and specifies focus areas. However, it does not explicitly differentiate from sibling tools like debug_with or explain_with, which could also analyze code.

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

  Usage Guidelines2/5

  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, exclusions, or preferred scenarios. With siblings like debug_with, refactor_with, and ask_agent, the lack of usage context leaves the agent to guess when review_code is the best choice.

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

• explain_withB
  3.2/5.0
  Behavior2/5

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

  No annotations are provided, so the description bears full responsibility for disclosing behavior. It mentions the ability to choose brief or detailed, but omits significant traits such as sending code to third-party agents, potential latency/cost, error behavior, or what the returned explanation contains. This is a meaningful gap for a tool that invokes external AI agents.

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

  Conciseness5/5

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

  The description is two sentences long, front-loaded with the primary purpose, and every word adds value. It is appropriately concise with no filler or redundancy.

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

  Completeness2/5

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

  Given 4 parameters and no output schema or annotations, the description is too spartan. It does not explain what 'detailed' means in terms of output, how timeout behaves, privacy implications, or how to choose among sibling tools. A tool that sends code to external agents should disclose more context.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline is 3. The description adds a little extra meaning by explaining that 'brief/detailed' maps to the detail parameter and 'specific agent' maps to agent, but it doesn't go beyond the schema. No compensation needed, but also no added depth.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: getting a code explanation from a specific agent. It also mentions the brief/detailed level, which helps differentiate it from broader ask-style tools. However, it does not explicitly differentiate from sibling tools like ask_agent, leaving some ambiguity.

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

  Usage Guidelines3/5

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

  The description implies usage context—when you need code explanation from a chosen agent at a chosen detail level. It does not provide explicit guidance on when to use this vs siblings like debug_with or review_code, nor any exclusions. The guidance is present but only implicit.

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

• debug_withB
  3.4/5.0
  Behavior2/5

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

  With no annotations, the description must carry the burden of behavioral disclosure. It merely states the action and gives no detail about side effects (e.g., external agent invocation), output format, or potential long-running behavior. This is insufficient for a tool that likely calls another agent.

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

  Conciseness5/5

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

  The description is two short sentences, front-loaded with the core purpose, and contains no empty filler. Every word contributes to understanding the tool's purpose.

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

  Completeness2/5

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

  Given the absence of an output schema and annotations, the description leaves critical questions unanswered: what does the tool return, how does the agent receive input, what does the timeout control, and what counts as 'code context'? For a 5-parameter tool, this is an under-specified description.

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

  Parameters3/5

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

  Schema coverage is 100%, so the schema already explains each parameter. The description's mention of 'error and optional code context' adds no extra meaning beyond the schema, aligning with the baseline of 3.

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

  Purpose5/5

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

  The description states a specific verb ('debug') and resource ('an error'), clearly distinguishing this from siblings like ask_agent or explain_with. The phrase 'using a specific agent' further clarifies the mechanism without being a tautology.

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

  Usage Guidelines3/5

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

  The description implies a use case—when you have an error to debug with a specific agent—but does not explicitly state when to prefer this tool over alternatives such as ask_all or delegate_task. No exclusions or comparisons are provided.

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

• list_modelsB
  3.4/5.0
  Behavior2/5

  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 restates the listing action without adding context about return format, side-effect freedom, permissions, or rate limits. The word 'list' implies read-only, but the description does not explicitly confirm safety or describe behavior beyond the literal action.

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

  Conciseness5/5

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

  The description is two short sentences, completely front-loaded with the main purpose and an optional qualifier. Every word earns its place; there is no redundancy or filler. It is an exemplary model of conciseness.

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

  Completeness4/5

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

  The tool has a single, well-documented optional parameter, and the description covers the core operation. While there is no output schema, the phrase 'List available models' sufficiently communicates the return concept for a simple list tool, though it omits details like sorting or scope permissions.

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

  Parameters3/5

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

  The schema already provides a full description for the agent parameter (including that omission means all agents). The description's phrasing 'Optionally filter by specific agent' mirrors the schema and adds little new semantic value. With 100% schema coverage, a baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description uses the specific verb 'List' and clearly identifies the resource ('available models for agents'). It distinguishes from sibling tool list_agents by focusing on models rather than agents, and the optional filter adds precision about the operation's scope.

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

  Usage Guidelines2/5

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

  The description offers no guidance on when to choose this tool over alternatives such as list_agents or ask_agent. It simply states the action and optional filter, but does not explain common use cases, prerequisites, or exclusions. For a tool with many siblings, this is a clear gap.

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

• generate_testA
  3.5/5.0
  Behavior2/5

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

  With no annotations, the description carries the full behavioral disclosure burden, but it only mentions framework auto-detection, which is already documented in the schema. It does not disclose output format, side effects, or any operational constraints, leaving a transparency gap for a generation tool.

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

  Conciseness5/5

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

  The description is a single sentence that front-loads the core purpose and includes a useful feature note. Every word contributes, with no filler or redundancy, making it highly efficient.

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

  Completeness3/5

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

  For a moderate-complexity tool with no output schema or annotations, the description covers purpose and a key feature but omits important context such as the return value of the tool and any behavioral expectations beyond generation. It is minimally viable but has clear gaps.

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

  Parameters3/5

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

  All four parameters have schema descriptions (100% coverage), so the schema already handles parameter semantics. The description adds no extra meaning beyond referencing framework auto-detection and agent usage, both of which are already in the schema.

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

  Purpose5/5

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

  The description clearly states a specific verb and resource ('Generate tests for code') and distinguishes this tool from sibling code-related tools like debug_with, refactor_with, and explain_with. It also clarifies the agent-driven nature, making its purpose unmistakable.

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

  Usage Guidelines3/5

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

  Usage is implied (if you need tests, use this tool) but not explicitly stated. It does not mention when to prefer it over alternatives like ask_agent or delegate_task, nor any exclusions or preconditions.

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

• ask_agentA
  3.7/5.0
  Behavior2/5

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

  No annotations are provided, so the description bears the full burden of behavioral disclosure. It only states the basic action and target, omitting any details about response format, side effects, permissions, rate limits, or error behavior. The description adds minimal context beyond what is self-evident from the name.

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

  Conciseness5/5

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

  The description is a single sentence with an immediate action verb and a usage example. Every word earns its place, and the key information is front-loaded. It is concise without sacrificing clarity.

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

  Completeness3/5

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

  The tool has 6 parameters and no output schema, so the description should ideally explain what the tool returns or any caveats. It is adequate for a simple ask tool but lacks guidance on response handling and edge cases. The schema covers parameters, but the description fails to address missing output expectations.

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

  Parameters3/5

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

  The schema has 100% description coverage for all 6 parameters, so the baseline is 3. The description itself does not add any parameter-specific meaning, but it also doesn't need to because the schema already documents each parameter clearly (e.g., 'agent' enum, 'timeout' default, 'analysisLevel' for codex only).

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

  Purpose5/5

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

  The description clearly states the tool's action ('Ask a specific AI agent a question') and explicitly distinguishes it from siblings by contrasting with 'ask codex'/'ask gemini' and implying a single target versus 'ask_all'. This meets the criteria of a specific verb+resource with sibling differentiation.

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

  Usage Guidelines4/5

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

  The description provides clear context for when to use the tool ('when targeting a single agent') and gives concrete examples. It does not explicitly exclude alternatives like 'ask_all' or 'delegate_task', but the guidance is sufficient for most scenarios, so it earns a 4.

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

• fetch_pageA
  3.7/5.0
  Behavior2/5

  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 only states the basic fetch action and native browsing capability, but doesn't disclose behavioral details such as rendering, output format, error handling, or potential 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.

  Conciseness5/5

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

  Two sentences, front-loaded with the core purpose. No wasted words; every sentence contributes to understanding the tool's function.

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

  Completeness3/5

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

  The description is adequate for a simple fetch tool, but with no annotations or output schema, it could provide more context about the return format or how the instruction parameter affects extraction. The schema covers parameters well, so it is not severely incomplete.

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

  Parameters3/5

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

  Schema coverage is 100%, so the baseline is 3. The description adds minimal value beyond the schema; it mentions 'extract content' which aligns with the instruction parameter, but doesn't elaborate on url, model, or timeout parameters.

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

  Purpose5/5

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

  The description clearly states the tool fetches web page content via Gemini CLI, with a specific verb and resource. It differentiates from sibling tools which focus on agent collaboration, code review, and testing.

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

  Usage Guidelines4/5

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

  Provides clear context that this tool is for retrieving and extracting content from URLs, leveraging Gemini's native web browsing. It does not explicitly mention when not to use it or list alternatives, but the usage scenario is evident.

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

• verifyA
  3.7/5.0
  Behavior3/5

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

  The description discloses that the tool runs the same prompt across multiple models and compares results for consistency. However, it does not reveal whether the operation is read-only, what a consistency mismatch results in, or any side effects or permission requirements. Since no annotations are provided, more detail would be beneficial.

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

  Conciseness5/5

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

  Two sentences, no waste. The first sentence states the action, the second the purpose. Ideal conciseness.

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

  Completeness3/5

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

  The description covers the core concept but omits critical details such as the return format (what does a consistency comparison produce?), error handling, and behavior when models disagree. Without an output schema or annotations, this leaves uncertainty, but the high-level purpose is clearly communicated, so it is minimally complete.

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

  Parameters3/5

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

  With 100% schema description coverage, the description adds only a small semantic layer by connecting 'agent' to 'multiple models' and implying the prompt is run across them. This matches the schema but doesn't introduce new parameter meaning, 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.

  Purpose5/5

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

  The description uses a specific verb 'Cross-verify' and identifies the resource (one agent's multiple models) and the action (running the same prompt and comparing). This clearly differentiates it from sibling tools like ask_all, which suggest querying rather than verification.

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

  Usage Guidelines3/5

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

  The description implies the tool is for verification purposes but provides no explicit guidance on when to choose it over alternatives like ask_all or ask_agent. There are no stated exclusions or scenarios, so usage is understood only from the tool's name and description.

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

• delegate_taskA
  3.8/5.0
  Behavior3/5

  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 does reveal the key behavior of automatically analyzing complexity and routing to single or parallel execution, which is useful. However, it omits details such as timeout handling, default agent selection behavior, or failure modes, leaving gaps in transparency.

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

  Conciseness5/5

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

  The description is two concise sentences, each earning its place. It front-loads the core action ('Delegate a task to agent(s)') and immediately provides the key differentiator (automatic complexity analysis and routing). No redundancy or wasted words.

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

  Completeness4/5

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

  Given the tool has one required parameter, no output schema, and no annotations, the description provides a sufficient high-level understanding of its purpose and key routing behavior. It lacks details about return values or edge cases, but for a tool with auto-routing, the description is fairly complete and actionable.

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

  Parameters3/5

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

  Schema coverage is 100%, so the baseline is 3. The description adds minimal parameter-specific meaning beyond noting parallel execution capability, which is already partially reflected in the allowParallel parameter. The schema itself provides clear descriptions for all parameters, so no extra semantics are needed.

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

  Purpose5/5

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

  The description uses a specific verb ('Delegate') and resource ('task to agent(s)'), and immediately adds the distinguishing behavior of automatically analyzing complexity and routing to single or parallel execution. This clearly differentiates it from siblings like ask_agent or collaborate by emphasizing the auto-routing functionality.

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

  Usage Guidelines3/5

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

  The description implies a use case for tasks that may benefit from automatic complexity-based routing, but it does not explicitly state when to prefer this over alternatives like ask_agent or collaborate, nor does it mention any exclusions. The guidance is indirect and not fully developed.

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

• agent_healthA
  4/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It discloses the key health dimensions (availability, authentication, latency), which implies a read-only status check. However, it does not mention potential side effects, permission requirements, or error behavior. This is sufficient for a simple health check 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.

  Conciseness5/5

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

  The description is a single, front-loaded sentence that states the purpose and key aspects without any filler or redundant words. It is appropriately sized and immediately allows an agent to understand the core function.

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

  Completeness4/5

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

  Given the tool's simplicity (one optional parameter, no output schema), the description covers the essential context. It explains what will be checked (availability, auth, latency) and that all agents are checked if no agent is specified. While it doesn't detail return format, this is not critical for a simple health-check tool.

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

  Parameters3/5

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

  The input schema provides full coverage (100%) for the single parameter 'agent', including its description and allowed enum values. The tool description adds no additional parameter semantics, but the schema is self-explanatory, so a baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states a specific action ('Check') and a specific resource ('agent health status'), with concrete aspects ('availability, authentication, latency'). This distinguishes it from sibling tools like ask_agent, list_agents, and review_code, which serve different purposes.

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

  Usage Guidelines4/5

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

  The description implies when to use this tool: whenever an agent's health needs to be checked. However, it does not explicitly mention alternatives or exclusions, such as 'for listing agents use list_agents'. The context is clear but lacks explicit guidance on when not to use it.

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

• ask_allA
  4/5.0
  Behavior3/5

  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 adds the key trait of parallel execution, which goes beyond the name. However, it does not mention result format, failure handling, or the effect of the timeout parameter, leaving some behavioral aspects unspecified.

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

  Conciseness5/5

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

  Two sentences, zero waste. The first sentence states the action, the second gives the usage context. Information is front-loaded and every word earns its place.

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

  Completeness4/5

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

  The tool is simple with four parameters and no output schema. The description covers purpose and usage. However, it does not describe how results are returned (e.g., per-agent responses), 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.

  Parameters3/5

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

  The input schema provides complete descriptions for all parameters (100% coverage), so the baseline is 3. The description does not add any additional parameter-specific semantics beyond what the schema already provides.

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

  Purpose5/5

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

  The description clearly states the tool's function: 'Ask multiple agents the same question in parallel.' This specifies a verb, resource, and core behavior, and distinguishes it from sibling tools like ask_agent (single agent) and collaborate (agents working together). The multi-agent comparison use case is explicit.

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

  Usage Guidelines4/5

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

  The description provides a clear use case: 'Use for explicit multi-agent comparison.' It gives clear context for when to use the tool, but does not explicitly name alternatives or state when not to use it, which would push it to a 5.

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

• list_agentsA
  4.1/5.0
  Behavior4/5

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

  With no annotations, the description carries the full disclosure burden. It clearly conveys a read-only list operation, the scope ('all detected agents'), and the result ('availability status'). While it doesn't mention authentication or rate limits, the verb 'list' implies a safe query, and the simplicity of the tool limits the need for additional behavioral disclaimers.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence with no filler. Every word adds meaning: 'all detected' sets the scope, 'agents' defines the resource, and 'availability status' specifies the output.

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

  Completeness5/5

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

  For a parameter-free listing tool with no output schema, the description is complete. It states the input (none), the operation (list all), and the output (agents with availability status). No additional context is necessary for correct invocation.

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

  Parameters4/5

  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 as per the rubric. The description correctly omits parameter details because there are none to document.

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

  Purpose5/5

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

  The description uses a specific verb ('List') with a clear resource ('detected agents') and specifies the output content ('availability status'). It distinguishes from sibling tools like 'agent_health' (health status) and 'ask_all' (querying) by focusing on listing and availability.

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

  Usage Guidelines2/5

  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. There is no mention of exclusions or scenarios where another tool like 'agent_health' or 'ask_all' 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.