saferagenticai-mcp

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

No annotations provided, so the description carries the full burden. It discloses that default output is 'compact' (cheap triage) and 'full' inlines snippets and confidence flags. It implies a read-only operation (find/return) and does not suggest destructive behavior. However, it could mention potential cost of full verbosity or error conditions.

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 concise sentences with no fluff. Purpose, usage, and verbosity defaults are front-loaded. Every sentence adds value.

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 core purpose and usage but lacks explanation of the limit parameter and does not describe the output structure (e.g., how results are grouped by suite). Still adequate for a simple tool with good guidance, but incomplete.

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?

Description only explains 'task' and 'verbosity' parameters, but omits 'limit' entirely. Schema description coverage is 0%, so the description must compensate for all parameters. The limit parameter is left undocumented, making this a significant gap.

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 starts with a specific verb and resource: 'Given a natural-language task description... return the most relevant patterns grouped by suite.' It clearly states the tool's purpose and differentiates from siblings like get_requirement by positioning this as a starting point.

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?

Explicit usage guidance: 'Use this as a starting point for any cross-cutting design question; then follow up with get_requirement on specific pattern_ids.' Also explains when to use 'compact' vs 'full' verbosity, giving clear 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?

With no annotations, the description fully bears the transparency burden. It discloses that inferred entries are limited to same-suite siblings and lack semantic similarity, clarifying behavior beyond obvious read nature.

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 efficient sentences front-loaded with purpose, each earning its place with no redundant text.

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?

Lacks output format details (e.g., whether results are IDs or objects) and does not mention prerequisites or pagination, leaving some gaps for a tool with no output schema.

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

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

Despite 0% schema description coverage, the description explains the meaning of include_inferred and the nature of explicit_cross_references, adding significant context not present 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 it returns outgoing adjacencies for a pattern, with a specific verb and resource. It distinguishes two types (explicit and inferred), differentiating from sibling tools 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?

The description provides nuanced guidance on interpreting inferred entries as 'neighbours worth scanning' and not endorsed dependencies, but it does not explicitly contrast with alternative tools like get_reverse_references.

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 the description must convey behavioral traits. It implies a read-only retrieval but does not explicitly state side effects, permissions, or error behaviors. The description is adequate but not fully transparent.

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

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

A single, well-structured sentence that front-loads the action, includes an example, and lists return contents. No unnecessary words.

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 absence of an output schema, the description thoroughly explains the return structure. It lacks mention of error handling or id validation, but for a simple retrieval tool it is mostly complete.

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

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

The schema covers the 'id' parameter with only type and maxLength. The description adds a concrete example ('OH::geoffrey-pattern') and clarifies that it returns the full entry, significantly aiding correct invocation.

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 'Retrieve' and the resource 'operational heuristic by id', with an example ID format. It lists the return fields, distinguishing it from sibling tools like 'list_operational_heuristics'.

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 versus alternatives. It does not mention that 'list_operational_heuristics' is for retrieving multiple heuristics, or indicate prerequisites or excluded scenarios.

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. Explains retrieval and ID resolution but does not mention error handling or response format for multiple matches.

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 examples, no wasted words. Efficient and clear.

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?

Covers ID formats and subgoal content but omits return structure or error behavior. Without output schema, this is a notable gap, yet the tool is simple and context from siblings helps.

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 no descriptions for parameters (0% coverage). Description explains 'id' parameter well with examples but does not clarify 'include_pattern' (boolean, default true). Partial compensation.

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 retrieves one subgoal by specific IDs, with examples and content description. It implicitly distinguishes from sibling tools like search or list.

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 ID format examples and notes display_id may yield multiple results, giving clear context for usage. Does not explicitly exclude alternatives but context is sufficient.

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 states 'Return patterns' implying read-only, but doesn't disclose auth needs, rate limits, or side effects. Adequate for a simple read tool but lacks depth.

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

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

Two sentences with zero waste: first states action, second gives context. Perfectly sized and front-loaded with key info.

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?

No output schema, so description should explain return format. It says 'Return patterns' but doesn't specify structure of returned data (e.g., single object, list, fields). Adequate for basic use but incomplete.

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 maps parameter 'id' to 'pattern_id', adding domain meaning. However, no format, constraints, or error handling details beyond schema's maxLength.

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 referencing a given pattern_id, using the verb 'Return' with specific resource. It distinguishes from sibling get_cross_references by noting outgoing vs incoming.

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 'Complement to get_cross_references (outgoing); this shows incoming' and 'Use to find all consumers of a given pattern', providing clear when-to-use and alternative.

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

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

With no annotations provided, the description carries full burden. It discloses the nature and source of the heuristics but does not mention behavioral traits like pagination, rate limits, or authorization. The description adds value by explaining the content is 'cross-cutting safety principles' but lacks operational details.

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 three sentences, front-loaded with purpose, and every sentence adds value. No wasted words, and the structure is logical: purpose, source, filters, differentiation.

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 explains the type of content (heuristics from production deployment) and available filters. It lacks explicit return format but provides sufficient context for an agent to understand the tool's purpose and usage. The sibling tool get_operational_heuristic likely provides details.

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 both parameters described. The description restates the filter options but does not add significant new meaning beyond the schema. For example, it mentions 'query (keyword search across titles and principles)' which is similar to the schema's description.

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 'List operational heuristics' with specific verb and resource. It distinguishes from sibling tools by explicitly noting 'Separate from the normative pattern layer — different category of knowledge.'

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

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

The description provides clear context for use, including optional filters for suite_id and keyword search. It implies when to use this tool vs. pattern-related tools by stating it's a different category, but does not explicitly list when not to use or provide direct 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 are provided, so the description carries full burden. It does not disclose behavioral traits like read-only, idempotency, authentication requirements, or side effects. The description only states the operation (list) and constraints, lacking transparency about the tool's impact or preconditions.

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 core purpose ('List subgoals matching filters'), followed by filter enumeration and limit clarification. No redundant words; every sentence adds value.

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

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

The description covers the primary action, filters, and limit, but lacks context about what a 'subgoal' is, the expected output format (no output schema), and any prerequisites or error scenarios. Given the complexity (7 params, no output schema), the description provides a basic but incomplete picture.

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

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

Schema description coverage is 0%, so the description must compensate. It lists most key filters (suite_id, suite_type, content_type, min_confidence, missing_pattern_only) and explains the limit behavior (default 50, max 100). However, it omits the 'include_pattern' parameter entirely, and does not explain the meaning of each filter in depth, leaving some parameters with no semantic addition.

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 'subgoals' with specific filters (suite_id, suite_type, content_type, min_confidence, missing_pattern_only) and a result cap. While it uses a specific resource term ('subgoals'), it does not explicitly differentiate from sibling tools like list_suites or list_operational_heuristics, 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.

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 versus alternatives. The description only lists filters and limit behavior, implying usage for filtered subgoal queries, but no exclusions or context about when not to use it (e.g., for broader listing use list_suites).

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 exist, so the description carries full burden; it fully discloses the read-only nature, expected output (suites with counts and titles), and its role as an initial orientation tool.

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

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

A single, front-loaded sentence that conveys all essential information without extraneous words.

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 parameters, no output schema, and no annotations, the description is fully complete, covering what, why, and when to use.

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?

With zero parameters and 100% schema coverage, the description adds meaning by explaining the return content and purpose, exceeding the baseline of 4.

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

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

The description specifies the exact content (16 suites, 9 drivers, 7 inhibitors) and includes subgoal counts and titles, clearly differentiating from sibling tools.

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 'Call this first to orient,' providing clear guidance on when to use the tool, though no when-not-to-use is given.

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 discloses the filtering condition (not human-reviewed) and sorting order, which is helpful. However, it does not discuss whether it is read-only, any potential rate limits, or how the limit parameter affects behavior—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.

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

The description is two sentences, front-loaded with the action, and every word adds value. No fluff or redundancy.

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 complexity is low (one optional param, no output schema), the description covers usage and sorting but omits the return structure or field details. Without an output schema, the agent lacks information on what properties the returned patterns contain, which is necessary for downstream processing.

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

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

Schema description coverage is 0% and the description does not mention the 'limit' parameter at all. It provides no additional meaning beyond the raw schema, so the agent must infer parameter usage from other sources.

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 not yet human-reviewed, specifies the sorting order (low-confidence first, then needs_human_review, then alpha), and explicitly says it's used during Phase 3 review to pick the next pattern. This is a specific verb+resource that distinguishes it from siblings like search_patterns or 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 gives explicit context: 'Use during Phase 3 review to pick the next pattern to examine.' This tells the agent when to use it, but it does not mention when not to use it or provide alternatives, so it falls short of a 5.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool always returns candidates (never 'not found'), which is useful. However, it omits details on response format, error handling, or side effects. For a simple lookup tool, this is adequate but not comprehensive.

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 redundancy. The first sentence defines the core action, and the second adds usage guidance and a behavioral note. Every sentence adds value.

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 does not specify the return structure (e.g., list of IDs, matching metadata). It mentions 'candidates' but lacks detail on format. For a tool with two parameters and simple output, the completeness is moderate but leaves the agent guessing about response shape.

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

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

Schema description coverage is 0%, so the description compensates by explaining the query parameter: 'loose reference (partial id, display_id, slug fragment, or title keyword).' However, the limit parameter is not mentioned, leaving its purpose and constraints 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 explicitly states the tool resolves a loose reference to canonical pattern_id(s), listing specific input types (partial id, display_id, slug fragment, title keyword). It distinguishes from siblings by mentioning its role as a prerequisite for get_requirement.

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

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

The description gives clear context: 'Call this when you have a rough reference and need the exact id before calling get_requirement.' It does not explicitly state when not to use, but the context is sufficient for selecting this tool.

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

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

With no annotations provided, the description carries full burden. It only mentions what is surfaced, but does not disclose behavioral traits such as whether it is read-only, potential side effects, or how load-time issues are defined. Minimal transparency.

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 key concepts. No wasted words, efficient and clear.

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?

While the description covers the high-level purpose, it lacks specifics about output format, aggregation level, or interpretation of 'load-time validation issue count.' For a tool with no output schema, more detail would be helpful, but it is minimally 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?

There are no parameters, so schema coverage is 100%. The description adds meaning by detailing the output content, which is sufficient given zero 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 what the tool provides: coverage stats including total patterns, reviewed percentage, per-suite and per-confidence breakdown, and load-time validation issue count. It is specific and distinct from sibling tools which focus on listing or searching.

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

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

No guidance is given on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or context for when to use it over siblings like list_unreviewed or search_patterns.

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

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

With no annotations, the description discloses substring matching, lowercasing, field weights, the 'matched_in' behavior, and the known limitation. Lacks explicit mention of being read-only or authentication needs, but provides substantial 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?

Four sentences with no fluff: first sentence states purpose, second details matching, third notes limitation, fourth gives usage tip. Every sentence adds value and is front-loaded.

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

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

With no output schema, the description mentions 'matched_in' field and effect of verbosity on payload, providing partial return structure. Could detail full response format, but sufficient for a search tool with limited complexity.

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?

Despite 0% schema description coverage, the description explains query behavior (substring, lowercased), verbosity effect ('compact' drops snippets/confidence flags, ~70% smaller payload), and implies limit's purpose. Doesn't describe limit explicitly, but overall adds significant meaning.

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

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

The description clearly states 'field-weighted keyword search across the framework', specifying verb (search), resource (patterns), and key characteristics (substring match, lowercased, field weights). It also mentions 'matched_in' field, distinguishing it from siblings 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?

Explicitly notes the limitation 'No semantic / embedding search — known limitation, see /mcp.html', guiding when not to use it. Provides performance advice for verbosity='compact'. Could improve by mentioning alternative tools for semantic search, but overall clear.

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