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

No annotations provided, so description must carry full burden. Discloses grouping behavior and verbosity effect (compact vs full), but does not mention behavior on empty results, error handling, or performance expectations. Adequate but not rich.

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

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

Three sentences, front-loaded with purpose, includes example and usage advice. No redundant information, every sentence earns its place.

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

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

Given 3 parameters and no output schema or annotations, description covers main purpose and two parameters. Lacks mention of limit parameter, return format details, and error scenarios. Acceptable for simple search tool but leaves gaps.

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

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

Schema coverage is 0%, so description must compensate. Explains task parameter with example, and verbosity parameter with default and options. Does not explain limit parameter (integer 1-25). Adds value for two of three parameters but misses one.

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

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

Clearly states verb (return), resource (patterns grouped by suite), and input (natural-language task description). Distinguishes from sibling tools like search_patterns and get_requirement by specifying it's a starting point for cross-cutting design questions.

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

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

Explicitly instructs to use this as a starting point and follow up with get_requirement for specific pattern_ids. Also mentions verbosity defaults for cheap triage vs full for detailed output. Lacks explicit when-not-to-use scenarios, but context is clear.

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

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

With no annotations, description carries full burden. It discloses that inferred_adjacent currently returns only same-suite siblings, not semantic similarity, and warns about treating inferred entries as not endorsed. Adds valuable context beyond basic functionality.

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

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

Two sentences, front-loaded with main purpose, efficient and without unnecessary words. Each sentence earns its place.

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

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

Given complexity and no output schema, description explains both cross-reference types, provides usage warnings, and addresses key behavioral aspects. Lacks return format description but adequate for a simple tool with few parameters.

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

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

Schema coverage is 0%, so description partially compensates by explaining include_inferred's effect (returns inferred_adjacent) and its meaning. However, id parameter is not explained, and the default for include_inferred (true) is not mentioned. Adds some value but incomplete.

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

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

Description clearly states it returns outgoing adjacencies for a pattern, distinguishing between explicit_cross_references (author-asserted) and inferred_adjacent (same-suite siblings). This is specific and differentiates from siblings like get_reverse_references.

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

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

Provides guidance on when to use each type: explicit for author-asserted, inferred for same-suite siblings only, with a warning to not treat inferred as endorsed dependencies. Implicitly excludes semantic similarity use cases. Lacks explicit 'when not to use' for other siblings.

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

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

No annotations provided, so description carries full burden. It lists return fields, which is good for a read operation, but lacks detail on potential errors, permissions, or side effects.

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

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

Single, well-structured sentence with front-loaded purpose and concise listing of return fields, no waste.

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

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

Given no output schema, the description adequately details the return content; however, missing error scenarios or id constraints beyond maxLength.

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

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

Schema coverage is 0%, but the description adds meaning by providing an id format example, compensating for the lack of parameter description in the schema.

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

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

The description clearly states the action (retrieve), resource (single operational heuristic), and distinguishes from siblings like list_operational_heuristics by specifying retrieval by id.

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

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

Explicitly describes retrieval by id with an example, implying usage when id is known, but does not explicitly state when not to use or name alternatives.

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

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

No annotations provided, so description must carry full burden. It discloses the multiple-subgoal resolution for display_id and shared display IDs for underlined variants. Missing details on error handling (e.g., missing ID), read-only nature, or rate limits.

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

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

Two sentences, front-loaded with purpose and essential usage details. Every sentence provides value without redundancy or fluff.

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

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

Given no output schema and no annotations, description covers the main behavior but omits return format, error scenarios, and explicit comparison with sibling tools. Adequate for basic usage but not fully complete.

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

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

Schema coverage is 0%; description adds meaning for 'id' parameter by explaining acceptable formats (pattern_id or display_id) and behavior. However, 'include_pattern' boolean is not described, leaving the agent to guess its effect on output.

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

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

Description clearly states verb 'retrieve' and resource 'subgoal' with its components. It distinguishes two types of IDs but does not explicitly differentiate from sibling tools like 'find_patterns_for_task' or 'get_operational_heuristic' which are similar lookup operations.

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

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

Provides context on when to use pattern_id versus display_id and mentions the multiple-resolution behavior of display_id. However, no explicit guidance on when not to use this tool or alternatives like 'search_patterns' or 'resolve_id'.

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

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

No annotations are provided, so the description carries the full burden. It states the tool returns patterns but does not disclose any behavioral traits such as whether it is read-only, response format, pagination, or performance implications. It is adequate but not richly informative.

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

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

Two sentences, front-loaded with the action, no redundant words. Every sentence serves a purpose: first states function, second provides context and alternative.

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

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

Given no output schema and low complexity (one param), the description should explain what is returned. It says 'Return patterns' but does not describe the structure of the patterns (e.g., fields, pagination). It is missing details that would help an agent fully understand the output.

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

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

Schema has 1 parameter (id) with 0% description coverage. The description adds meaning by calling it 'given pattern_id' and linking it to cross_references, clarifying that it is a pattern identifier. However, it does not elaborate on format beyond the schema's maxLength constraint.

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

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

The description clearly states the tool returns patterns that reference a given pattern_id, and explicitly distinguishes it from the sibling get_cross_references by noting it shows incoming references vs outgoing. Verb is specific: 'return patterns' and resource is 'reverse references'.

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

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

The description explicitly says it is a complement to get_cross_references (outgoing) and this shows incoming, advising to 'Use to find all consumers of a given pattern.' This provides clear when-to-use and differentiates from the sibling.

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

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

The description is straightforward about the listing behavior but lacks details on potential pagination, response structure, or any side effects; since no annotations exist, the description should provide more behavioral context.

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

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

The description is succinct with two sentences and a bullet-like enumeration, front-loading the main action and clearly listing parameters without extraneous content.

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

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

The description omits details about output format, ordering, or potential empty results; given no output schema, this is a gap for a listing tool with optional filters.

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

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

Schema coverage is 100% with parameter descriptions; the tool description adds clarification that query searches across titles and principles, and suite_id filters heuristics relevant to a suite, adding slight value over the schema alone.

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

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

The description clearly states the tool lists operational heuristics from production deployments, specifies the type (cross-cutting safety principles), and distinguishes from the normative pattern layer, differentiating it from sibling tools like find_patterns_for_task.

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

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

The description explains optional filters (query, suite_id) for narrowing results, but does not explicitly suggest when not to use this tool or provide direct alternatives among siblings; the distinction from the pattern layer is implicit.

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

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

No annotations are provided, so the description carries full burden. It mentions a result cap and default limit, but lacks disclosure about read-only nature, authorization needs, rate limits, or side effects.

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

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

Two sentences with no filler. Could be more informative per sentence, but efficiently conveys core purpose and limit constraint.

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

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

With 7 parameters, no output schema, and no annotations, the description is insufficient. It does not define 'subgoals', explain return format, or clarify filter logic.

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

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

Schema coverage is 0%, so description must compensate. It only lists parameter names without explaining their meanings or enum values. Does not describe 'include_pattern' or how filters combine.

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

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

The description clearly states the action ('List') and resource ('subgoals'), and lists the filter parameters. However, it does not fully distinguish from siblings like 'search_patterns' or 'list_suites', and 'subgoals' is not defined.

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

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

The description implies use when filtering by specified criteria, but no explicit guidance on when to use this tool versus alternatives, nor any exclusions or when-not-to-use instructions.

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

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

No annotations are provided, so the description must carry the full burden. It clearly indicates this is a read-only operation listing suites with subgoal counts and titles. It does not describe any side effects or potential issues, but for a simple list operation, this is sufficient.

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

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

Two sentences only, with no unnecessary words. The purpose and usage are front-loaded, and every sentence earns its place.

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

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

Given the tool has no parameters, no output schema, and is simply listing fixed information, the description provides all necessary context: what is listed (16 suites, with counts and titles) and that it should be called first.

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

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

There are no parameters, so the description does not need to add meaning beyond the schema. The schema coverage is 100%, and the description appropriately focuses on the tool's output.

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

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

The description clearly states the verb 'list' and the resource 'all 16 suites in the SaferAgenticAI framework', including the breakdown of 9 drivers and 7 inhibitors. It also mentions subgoal counts and titles, which distinguishes it from sibling tools like find_patterns_for_task or list_requirements.

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

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

The description explicitly advises 'Call this first to orient', providing clear guidance on when to use this tool. The sibling tools are all different in purpose, so no further disambiguation is needed.

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

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

Without annotations, the description adds value by explaining the sorting behavior (low-confidence first, then needs_human_review, then alpha) and confirms this is a read-only operation with no side effects mentioned.

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

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

Two sentences with no wasted words: first sentence states purpose and filter, second sentence adds sorting and usage guidance. Front-loaded with key information.

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

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

For a simple list tool with one optional parameter and no output schema, the description covers purpose, filter, sorting, and usage context, though it omits details about the limit parameter and return fields.

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

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

The input schema has one optional parameter 'limit' with 0% description coverage, and the description does not mention the parameter at all, failing to add meaning beyond the schema.

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

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

The description clearly states the verb 'Return' and the resource 'patterns that have not been human-reviewed yet', and distinguishes from siblings by specifying the unreviewed status and sorting criteria.

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

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

Explicitly says 'Use during Phase 3 review to pick the next pattern to examine' and explains the sorting order, providing clear context for when to use the tool, though no alternatives are mentioned.

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

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

With no annotations, the description carries the full burden. It discloses that the tool 'always returns candidates — never not found', which sets expectations. However, it does not address permissions, rate limits, or other behavioral traits.

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

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

Two sentences with no wasted words. The first sentence states the core function, the second adds usage guidance and a key behavioral trait. Front-loaded and efficient.

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

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

The description covers purpose and usage well but omits return format (structure of 'candidates') and does not explain the 'limit' parameter. Given no output schema, this is a gap.

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

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

The input schema has 0% description coverage. The description adds meaning to 'query' (types of loose references) but does not explain 'limit', leaving it partially undocumented.

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

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

The description clearly states it resolves loose references (partial id, display_id, slug fragment, or title keyword) to canonical pattern_id(s). It explicitly distinguishes itself from siblings like get_requirement by positioning as a preliminary step.

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

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

The description explicitly says 'Call this when you have a rough reference and need the exact id before calling get_requirement.' It gives clear when-to-use context but lacks explicit when-not-to-use or alternative tools.

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

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

With no annotations, the description partially discloses behavior by listing output components. However, it does not state whether the operation is read-only, non-destructive, or mention any side effects, performance implications, or permissions required.

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

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

The description is extremely concise—two sentences with no wasted words. It is front-loaded with the key purpose ('Coverage stats') and efficiently lists the metrics provided.

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

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

Given the tool has no parameters and no output schema, the description provides adequate context about the returned data. However, it could benefit from briefly noting the format (e.g., numbers or tables) or any default behavior like time scope.

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

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

The tool has no parameters, and the schema coverage is 100%. Per the rubric, baseline is 4 since no parameter documentation is needed. The description adds value by explaining what the output contains, which compensates for the lack of parameters.

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

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

The description clearly states the tool provides coverage statistics including total patterns, reviewed percentage, per-suite and per-confidence breakdowns, and load-time validation issue counts. It uses specific verbs and resources, effectively distinguishing it from sibling tools that focus on individual items or searches.

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

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

No explicit guidance on when to use this tool vs alternatives. While the description implies usage for aggregate statistics, it does not provide when-not-to-use instructions or mention alternative tools for specific needs like filtering or searching.

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

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

With no annotations, the description fully discloses substring match, lowercasing, field weights, matched_in reporting highest-weighted field, and the non-semantic nature of the search.

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

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

Two sentences, front-loaded with core behavior, second sentence adds a practical tip. Every word earns its place.

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

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

Given no output schema and no annotations, the description covers behavioral aspects and parameter usage adequately for an agent to invoke correctly, though return format is not mentioned.

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

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

The schema has 0% description coverage, but the description adds significant meaning for the query parameter (field-weighted substring match) and explains the effect of verbosity; however, limit receives no additional context beyond the schema.

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

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

The description clearly states 'Field-weighted keyword search across the framework' with specific verb and resource, and distinguishes from semantic search by noting 'No semantic / embedding search — known limitation'.

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

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

Provides explicit when-to-use context, excludes semantic search, and offers a concrete usage tip for compact mode to reduce payload when triaging.

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