Server Quality Checklist

Tool Scores

• execute_serviceC
  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 carries the full burden of behavioral disclosure. It mentions only an authentication requirement (API key) but does not describe side effects (e.g., whether executing a service modifies state), idempotency, rate limits, or error conditions. The description is insufficient for an agent to understand what happens when the tool is invoked.

  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?

  The description is very concise at two sentences with no wasted words. However, it could be more informative within the same length by clarifying the service execution context or referencing the sibling tools. The front-loading is reasonable but the brevity sacrifices completeness.

  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 lack of annotations and output schema, the description is insufficiently complete. It does not explain return values, error handling, or how to properly use the api_key parameter. For a tool with nested objects and no output schema, more context is needed to guide the agent effectively.

  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% as all parameters have descriptions. The description adds minimal value: it notes 'service-specific input parameters' but does not elaborate on how to structure the 'input' object for different service IDs. The api_key parameter is described in the schema as 'BYOK: Your Anthropic API key', while the description mentions an 'AgentDesk API key', causing slight inconsistency. Overall, the description does little beyond what the schema already provides.

  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 action ('Execute a service') and the resource ('AgentDesk marketplace'), providing a specific verb+resource pair. However, it does not distinguish this tool from its siblings (list_services, review_dual, review_output), which could lead to confusion about when to use this generic service execution tool versus those specialized tools.

  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 mentions requiring an API key and passing service-specific input, but provides no guidance on when to use this tool versus alternatives like list_services or review_dual. There is no mention of prerequisites (e.g., selecting a service from list_services first) or when not to use this tool. The phrase 'service-specific input parameters' lacks detail on how to determine which parameters are appropriate for a given service_id.

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

• review_outputB
  3.3/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 full burden for behavioral transparency. It describes the output structure (verdict, score, issues) but does not disclose any potential side effects, destructive actions, authentication needs, or rate limits. The 'adversarial' nature is mentioned but not elaborated.

  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?

  The description is concise at two sentences, front-loading the core purpose and then detailing the output. Every sentence adds value; no redundant or verbose phrasing.

  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 no output schema, the description effectively explains the return values (verdict, score, issues, checklist). It covers the tool's broad applicability and key inputs. Minor omissions: it does not clarify that 'criteria' is optional or describe defaults for 'review_type' and 'model'.

  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%—all four parameters have descriptions in the schema. The description does not add additional meaning beyond the schema; it only summarizes the output format. Baseline score of 3 is appropriate.

  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 it performs an adversarial quality review of AI-generated output, using specific verbs ('review') and a resource type ('output'). It does not differentiate from the sibling tool 'review_dual', suggesting both may perform reviews, so it misses the top score for sibling distinction.

  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 for quality checking of any AI output, but provides no explicit guidance on when to use this tool versus alternatives (e.g., 'review_dual') or when not to use it. It lacks clear context for exclusion or alternative selection.

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

• list_servicesA
  3.7/5.0
  Behavior3/5

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

  No annotations are provided, so the description must disclose behaviors; it mentions returning service details but omits pagination, rate limits, or any restrictions. It is adequate but not thorough.

  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 with no wasted words: first sentence states purpose, second adds return content and filters. Extremely concise.

  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 simple listing tool with no output schema and no annotations, the description covers the basics but lacks details on pagination, error handling, or output structure, which might be needed.

  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?

  Input schema has 100% description coverage, and the description merely lists the filter names without adding meaning beyond what the schema already provides, so it meets the baseline.

  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 verb 'List' and resource 'available services on the AgentDesk marketplace', and distinguishes from siblings by focusing on browsing the catalog, while sibling tools execute or review services.

  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 for browsing services with filters, but does not explicitly state when to use this tool versus alternatives like execute_service or review tools, nor provides exclusions or conditions.

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

• review_dualA
  3.9/5.0
  Behavior3/5

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

  No annotations are provided, so the description must cover behavior. It explains the dual review process and the merge verdict logic, but omits details like side effects, authentication needs, or output structure, leaving gaps for an 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 sentences: the first explains the process, the second provides usage guidance and the verdict rule. No extraneous words, 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?

  Given 4 parameters, no output schema, and no annotations, the description adequately explains the core functionality but does not cover output format, error handling, or prerequisites, leaving room for improvement.

  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 schema already documents all parameters. The description adds no additional meaning beyond what is in the schema, so it does not improve understanding of parameter usage.

  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 explicitly states the tool performs a dual adversarial review with two independent reviewers and a merge agent. It clearly distinguishes itself from the sibling tool 'review_output' by being stricter and specifying the verdict rule.

  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 advises using this tool for high-stakes outputs and contrasts it with single review, but does not explicitly state when not to use it or list alternatives beyond the implied single review.

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