Server Quality Checklist

Tool Scores

• get_patternA
  4.3/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds no new behavioral traits such as side effects, auth requirements, or rate limits. The field list (problem, solution, etc.) is return content, which is already covered by the output schema, so it does not add transparency beyond annotations. No contradiction exists.

  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 filler. It front-loads the action and resource, immediately states the key identifier, and packs the field list into a parenthetical. The second sentence provides essential workflow guidance. Every word earns its place.

  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 simple get-by-slug tool with 2 parameters, full schema coverage, output schema present, and strong annotations, the description is complete. It states what the tool does, when to use it, and what the return includes. The output schema handles return format details, and annotations handle safety. No critical information is missing.

  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?

  Schema description coverage is 100%, so the baseline is 3. The description adds extra meaning beyond the schema by explaining the provenance of the slug: it comes from search or list_patterns. This contextual usage note clarifies where the parameter value originates, which is not in the schema. Thus it earns a 4.

  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 ('Get') plus resource ('Enterprise AI pattern') and scope ('by slug'). It distinguishes from sibling tools like list_patterns and search by specifying it retrieves a single pattern, not a list or search results. The mention of included fields (problem, solution, KPIs, etc.) further clarifies what this tool uniquely returns.

  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 explicitly states when to use the tool: 'Use this once search or list_patterns has given you a slug.' This provides clear context for the appropriate workflow. However, it does not name alternative tools for when not to use it, such as get_architecture or get_governance, so it falls just 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.

• get_relatedA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds behavioral detail by specifying that it returns both outgoing and incoming edges with relationship types, which goes beyond the annotations. No contradictions with annotations exist.

  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 states the core behavior concisely, and the second gives concrete usage guidance. It is front-loaded with the most important information and contains no filler.

  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?

  Given the existing output schema, annotations, and sibling context, the description is complete. It covers what the tool does, when to use it, and differentiates it from siblings. The output schema handles return structure, so no additional return details are 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?

  Schema coverage is 67% (slug and locale are described; domain is not). The description does not elaborate on parameters, but the schema already provides meaningful descriptions for most parameters. Therefore the description adds little beyond the schema, 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 identifies the tool's purpose with a specific verb ('traverse') and resource ('knowledge graph'), and details that it returns both incoming and outgoing neighbors with relationship types. It distinguishes itself from the sibling get_* and list_* tools by focusing on relationships between units rather than retrieving a single unit or listing all units.

  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 explicitly says to use this after a get_* call to widen an answer with adjacent units, providing clear usage context. It does not explicitly state when not to use it, but the guidance is sufficiently specific to differentiate it from alternatives.

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

• list_architecturesA
  4.3/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds the fact that it returns the full set ('all') and the specific metadata fields, but it does not disclose other behavioral nuances like pagination or sorting. This adds some value but not rich behavioral context beyond the annotations.

  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 action and output, followed by usage guidance. Every word earns its place; there is zero redundancy or irrelevant detail.

  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?

  Given the tool's simplicity (one optional parameter, output schema present, strong annotations), the description is complete. It specifies what the tool returns, notes the 'all' scope, and tells when to use the search sibling instead. No critical information is missing for an agent to select and invoke the tool correctly.

  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 the single optional parameter (locale) with a full description, so schema coverage is 100%. The description adds no additional meaning about locale behavior or defaults, which is acceptable since the schema already documents it. Baseline 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 the tool lists all reference architectures and enumerates the exact fields returned (id, slug, category, name, summary, provenance). It uses a specific verb with a defined resource and distinguishes itself from the sibling search tool, 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.

  Usage Guidelines5/5

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

  The description explicitly tells the agent when to use this tool ('browse the blueprints') and when to use an alternative ('use `search` when you have a use case rather than a name'). This is precise guidance with a named alternative, fully satisfying usage direction.

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

• get_architectureA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds valuable context about the response content (request flow, reference scenario, KPIs, cost & scaling, patterns/knowledge) and imposes a requirement that a slug be obtained via search/list first. It does not contradict annotations.

  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 exactly two sentences: the first states purpose and content, the second provides the usage prerequisite. No filler, no redundancy, and the most important information is front-loaded. This is exemplary conciseness for a tool definition.

  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?

  The tool has an output schema (not shown but signaled) and strong annotations covering semantics. The description enumerates the major content categories returned and ties into the knowledge/pattern structure, making it clear what the user gets. Nothing critical is omitted for a simple get-by-slug operation.

  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?

  Schema coverage is 100% and both parameters have descriptions, so the baseline is 3. The description adds meaning by clarifying that the 'slug' parameter is derived from search or list_architectures, giving provenance and usage context beyond the schema's simple type definition. This raises the score to 4.

  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: 'Get one reference architecture by slug', and enumerates the payload components (request flow, KPIs, cost & scaling, etc.). This distinguishes it from sibling tools like 'list_architectures' (list vs get) and 'get_overview' (different resource focus). It leaves no ambiguity about 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.

  Usage Guidelines4/5

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

  The description explicitly tells the agent when to use this tool: 'Use this once search or list_architectures has given you a slug.' This is a clear precondition and directs the user to alternative discovery tools first. It does not, however, explicitly mention when not to use it or compare it with other 'get_*' tools, so it stops short of a full 5.

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

• get_governanceA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnly, idempotent, and non-destructive traits. The description adds useful context by detailing what the returned governance unit contains, but does not go beyond that (e.g., no error behavior or rate limits). Still, the added content composition is valuable.

  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 action and resource, no fluff. Every word contributes to clarity or usage guidance.

  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?

  With only 2 parameters, an existing output schema, and strong annotations, the description covers what the tool does, what it returns, and when to use it. This is complete for an agent to select and invoke correctly.

  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%, with both `slug` and `locale` clearly explained. The description adds minimal extra parameter context beyond the phrase 'by slug', which is already in the schema. Baseline 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 the tool gets a single AI governance unit by slug, listing the included contents (scope, key requirements, controls, checklist, pitfalls). This distinguishes it from siblings like list_governance (which lists all units) and search (which finds slugs).

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

  Usage Guidelines5/5

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

  Explicitly says to use this after `search` or `list_governance` has provided a slug, providing clear sequencing and implicit alternatives. This tells the agent exactly when to invoke this tool versus other list/search tools.

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

• get_handbookA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds useful behavioral context by stating it returns the full Markdown body plus provenance and related ids, which goes beyond the annotations. It does not mention auth or rate limits, but annotations lower the bar.

  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, front-loaded with the primary action and resource, and every sentence adds value. It avoids redundancy and is appropriately concise for a simple retrieval tool.

  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?

  Given the tool's low complexity, full schema parameter descriptions, output schema existence, and annotations covering safety, the description is complete. It covers what the tool returns, how to identify a chapter, and when to use it, leaving no critical gaps for an agent to select and invoke it.

  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% for both parameters, so the description need not compensate. The description reiterates the id example ('HRN-001') and slug behavior already present in the schema, adding no new meaning. The locale parameter is not mentioned in the description, but the schema fully covers it.

  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 identifies the verb ('Get') and resource ('Harness Engineering Handbook chapter'), and distinguishes from siblings by specifying retrieval by id or slug. It also explicitly differentiates itself from search/list_handbook by noting those are used to obtain the id.

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

  Usage Guidelines5/5

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

  The description provides explicit usage context: 'Use this once `search` or `list_handbook` has given you an id.' This tells the agent when to use the tool and names the alternative tools for discovery, serving as a clear sequencing guideline.

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

• get_knowledgeA
  4.5/5.0
  Behavior4/5

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

  Annotations already mark this as readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds the key behavioral detail that a locale parameter changes the response from a full entry to a single-locale body, which informs the agent's expectations. It does not mention error cases, but the simplicity of the read operation makes this acceptable.

  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 tight two sentences, front-loading the primary action and adding the essential workflow instruction. Every clause adds value, with no redundancy or filler.

  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 simple single-retrieval tool with complete schema coverage, an output schema, and informative annotations, this description covers the purpose, usage, and behavioral nuance. The workflow relationship to search/list is included, making the tool self-contained for an agent to select correctly.

  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 already provides complete descriptions for both `slug` and `locale`, including an example and enum values, so the parameter semantics are fully covered. The description only reiterates the locale behavior without adding new usage details, matching the baseline for high schema coverage.

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

  Purpose5/5

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

  The description states 'Get one knowledge unit by slug' with a specific verb and resource, and clarifies the return behavior ('full entry' vs 'single-locale body'), distinguishing it from list-like siblings. The second sentence explicitly ties it to the search/list workflow, reinforcing 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.

  Usage Guidelines5/5

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

  Explicitly directs the agent to use this tool after `search` or `list_knowledge` has provided a slug, establishing the prerequisite and workflow. This clearly differentiates when to invoke this tool versus its list/search counterparts, and implies not to use it for pattern/architecture retrieval.

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

• list_governanceA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description's read-only listing is aligned. The description adds behavioral context by specifying the return fields ('id, slug, category, name and summary') and the scope ('all'), which goes beyond the annotations.

  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 accomplish the task: the first defines the tool's output and content, the second provides usage guidance. No wasted words; information is front-loaded.

  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 simple list tool with one optional parameter, full schema documentation, and an output schema, the description covers the essential points: scope, contents, and when to use it. The tool's simplicity means the description is sufficiently 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?

  The input schema fully documents the single optional `locale` parameter with a description and enum, so the description adds no additional parameter semantics. Schema coverage is 100%, warranting the baseline score 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 uses 'List all AI governance units' with a specific verb and resource, and enumerates examples (EU AI Act, ISO 42001) and return fields. It also distinguishes from sibling `search` by stating when to browse vs. search for obligations/controls.

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

  Usage Guidelines5/5

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

  Explicitly states when to use the tool: 'Use this to browse the regulations and standards; use `search` for an obligation or control.' This provides clear usage context and an alternative, fulfilling the dimension.

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

• list_handbookA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnly, idempotent, and non-destructive. The description adds that this returns the 'chapter map' (a high-level listing, not full chapter content) and specifies the chapter range 'HRN-001…' and the corpus scope. This clarifies output granularity beyond the annotations.

  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: the first states the action and scope, the second provides usage direction. No redundant phrases; every clause adds distinctive detail (chapter prefix, corpus topics, alternative tool). Highly efficient.

  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 simple list tool with optional locale, the description covers purpose, usage, and alternatives. An output schema exists, so return format is already specified. The chapter content list in the description gives enough context for an agent to decide when to use it.

  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% — the lone `locale` parameter is fully described in the schema with enum values and default. The description adds no parameter-specific detail, which is acceptable because the schema carries the full burden. Baseline 3 applies.

  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 opens with 'List the Harness Engineering Handbook chapters (HRN-001…)' — a specific verb+resource. It distinguishes from sibling list_* tools by identifying this as the handbook chapter map and names the corpus content. The sibling list tools for knowledge/patterns/architectures/governance make the resource unique.

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

  Usage Guidelines5/5

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

  Explicitly says 'Use this to see the chapter map; use `search` when you have a topic rather than a chapter.' This gives a clear when-to-use and an alternative. Also identifies the tool as listing the canonical long-form corpus, differentiating from other list tools.

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

• list_knowledgeA
  4.5/5.0
  Behavior4/5

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

  Annotations already disclose the read-only, non-destructive, idempotent nature. The description adds that it lists 'all' knowledge units, indicating a broad browse operation with no filtering. It does not contradict annotations and provides context beyond the metadata.

  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 redundancy. It front-loads the action and resource, then directly adds usage guidance and an alternative. Every sentence contributes value.

  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 simple list tool with one optional parameter, an output schema, and comprehensive annotations, the description covers the purpose, use case, and alternative. It is sufficiently complete for an agent to select and invoke correctly.

  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 fully documents the only parameter (`locale`) with an enum and description, so schema description coverage is 100%. The tool description does not add extra parameter semantics, relying on the schema as 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 identifies the verb ('List') and resource ('all knowledge units'), and specifies the fields returned. It distinguishes from siblings by naming the `search` tool as the alternative for question-based lookups, making the purpose specific and unambiguous.

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

  Usage Guidelines5/5

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

  The description explicitly states when to use this tool ('to browse the domain') and provides a clear alternative ('use `search` when you have a question rather than a slug'). This gives the agent direct guidance on tool selection relative to at least one sibling.

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

• list_patternsA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is known. The description adds behavioral context by specifying that it lists all patterns and which attributes are returned, which is useful beyond the structured annotations. However, it doesn't mention pagination or ordering, though the presence of an output schema reduces the burden.

  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, front-loaded with the action and output fields, and then provides usage guidance. Every sentence 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.

  Completeness5/5

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

  For a simple list tool with one optional parameter and a rich output schema, the description fully covers the tool's purpose, what it returns, and when to use it. It also names an alternative tool, making it contextually 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?

  The single parameter `locale` is fully described in the schema with an enum and default value, achieving 100% schema coverage. The description does not add further parameter details, but the schema carries the full semantic load, 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 uses a specific verb and resource ('List all Enterprise AI patterns') and enumerates the returned fields (slug, category, name, summary, provenance), making the tool's purpose unmistakable. It also distinguishes this tool from siblings like search and get_pattern by framing it as a catalogue browsing tool.

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

  Usage Guidelines5/5

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

  It explicitly states when to use the tool ('Use this to browse the catalogue') and provides a clear alternative ('use `search` when you are looking for a pattern that solves a problem'). This gives the agent actionable guidance for tool selection.

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

• get_overviewA
  4.7/5.0
  Behavior4/5

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

  Annotations already establish safe read-only, idempotent behavior. The description adds value beyond this by detailing the contents of the response (domains, categories, tool pointers, identifiers, bulk-ingest URLs), giving the agent a clear picture of what the 'map' includes. No contradictions or hidden caveats.

  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 with dense, relevant information. The key directive 'start here' is front-loaded, and every detail describes the returned content without filler. This is exemplary conciseness for a complex structural overview.

  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 zero-parameter tool with an output schema, the description is fully self-contained. It explains what domains are covered, what categories are inside, how to select retrieval tools, and what auxiliary data is included. The agent can correctly decide to invoke this tool and know exactly what to do with the result.

  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 no parameters, and the schema covers 100% (vacuous). Per the rubric, 0 params warrants a baseline of 4. The description adds no parameter information because none exists, which 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 the tool's purpose: 'Get the corpus map' and enumerates exactly what it returns (domains, categories, pointer to retrieval tools with expected identifiers, languages, licence, bulk-ingest URLs). It also explicitly labels it as the starting point, distinguishing it from sibling list/get tools.

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

  Usage Guidelines5/5

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

  The phrase 'start here' gives explicit usage timing, and 'One call is enough to know exactly where to go next' explains how to use the tool to navigate to other tools. It indirectly differentiates from siblings by explaining that it tells you which tool retrieves a unit.

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

• searchA
  4.9/5.0
  Behavior5/5

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

  Annotations already declare readOnlyHint, idempotentHint, destructiveHint, and the description adds genuinely useful behavioral context: ranked results, accent-insensitive matching, language coverage, and the composition of each hit (relevance score and matched fields). This goes beyond what the structured annotations communicate.

  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?

  Three sentences, front-loaded with the core purpose, and each sentence earns its place: scope, behavior, output composition, and usage guidance. No filler or redundant restating of structured fields.

  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?

  The description covers the search use case, behavior, result format, and follow-up action while the output schema covers return details. Given the tool's moderate complexity and strong annotations, this is complete and leaves no obvious gap for an agent to misuse it.

  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?

  Schema covers 100% of parameters with clear descriptions, so the baseline is 3. The description adds a meaningful semantic nuance for the query parameter by explaining that it matches 'every language' and 'ignores accents,' so the user can query in their own words—extending beyond the schema's simple 'in any of en/es/pt'.

  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?

  Description states a specific verb+resource: 'Ranked keyword search across the whole corpus' and names the domains covered. It clearly distinguishes itself from sibling get_* and list_* tools by positioning search as the entry point for question-like queries.

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

  Usage Guidelines5/5

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

  Explicitly says to use this tool 'before any get_* tool whenever you have a question rather than an identifier' and to follow up with the matching get_* tool for full detail. This provides direct when-to-use guidance and names the alternative tool category.

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