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

With no annotations provided, the description carries the full burden. It explains the core behavior (listing and filtering) but does not disclose additional traits such as pagination, sorting, performance implications, or whether it is a read-only operation. For a simple listing tool, this is adequate but not exceptional.

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 concise sentences, front-loaded with the main action and followed by the optional filter explanation. No extra 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?

Given the tool's simplicity (one optional parameter, no required arguments, output schema existing), the description covers the essential behavior. It does not explain return format but that is likely handled by the output schema. Minor gap: no mention of the catalog source.

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, so the description adds value by explaining that the 'category' parameter is a keyword matched against name/intent. This clarifies the parameter's semantics beyond the schema's basic type definition.

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 anti-patterns from a catalog, using a specific verb ('List') and resource ('anti-patterns'). It distinguishes from siblings by focusing specifically on anti-patterns rather than patterns, frameworks, or recipes.

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 the optional category argument for narrowing results, implying when to use it (e.g., to get a subset). However, it does not explicitly contrast with sibling tools like 'find_pattern' or 'pattern_for_symptom', nor does it state when not to use 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?

No annotations provided; description only states retrieval of examples. It does not disclose potential behavioral traits such as response size, authentication needs, or that it is read-only. Minimal transparency beyond the obvious.

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 sentence, front-loaded with action, no unnecessary words. Efficiently conveys purpose and key 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?

Tool is simple with 2 parameters and output schema exists. Description covers the essential behavior; additional context about pattern IDs could be inferred from sibling tools.

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 0% description coverage. Description adds meaning by identifying pattern_id as the pattern identifier and framework as an optional filter with concrete examples ('langchain', 'dspy', etc.).

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 'Get code examples for a pattern' with optional framework filtering, using specific verb and resource. It distinguishes from sibling tools like get_pattern, get_recipe, etc., by focusing on examples.

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?

Description mentions optional filtering by framework and lists example frameworks, but does not explicitly state when to use this tool vs alternatives like get_pattern or get_recipe.

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 provides key behavioral details: returns top matches, case-insensitive substring ranking by field priority (id > name > alias > intent). This sufficiently informs an agent about the tool's behavior.

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 concise: two sentences. The first sentence states the purpose, the second explains ranking logic. No unnecessary words, and the key information 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?

Given the presence of an output schema and only two simple parameters, the description is largely complete. It covers search behavior and ranking, though it could mention error handling or pagination. The output schema likely covers return values.

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 description adds meaning to the query parameter by explaining it searches across multiple fields, but does not explain the limit parameter. Since schema has no descriptions, the description partially compensates.

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 searches patterns by id, name, alias, or intent, using a specific verb and resource. It distinguishes from siblings like get_pattern by indicating a flexible search across multiple fields.

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 does not explicitly state when to use this tool versus alternatives such as get_pattern or pattern_for_symptom. It implies use for fuzzy matching, but lacks direct guidance.

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 should disclose behavioral traits like read-only nature, but it does not mention any side effects or constraints, leaving a significant gap.

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 concise sentence with no wasted words, front-loading the action and resource effectively.

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 get-by-id with an output schema, the description is minimally adequate but omits details like the requirement of framework_id (though in schema) or any expected input format.

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 0% schema description coverage, the description adds no additional meaning beyond the schema's field name and type, failing to compensate for the lack of parameter documentation.

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 a framework by id, using specific verb 'Return' and resource 'framework (concrete composition)', distinguishing it from listing tools like list_frameworks.

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 like get_pattern or list_frameworks, but the 'by id' phrase implies it's for single entity lookup.

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 present, so the description carries the full burden. It only states 'return by id' but does not disclose any behavioral traits such as side effects, rate limits, or authentication needs. 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?

The description is one short sentence, which is concise. However, it is under-specified for a tool with no annotations and could benefit from more structure or front-loading of key details.

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 only one parameter and an output schema exists (not shown), the description lacks context about what a methodology entry is. It is incomplete for understanding the resource without additional knowledge.

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 adds no meaning beyond the schema. It only says 'by id', but the schema already shows 'methodology_id'. No additional semantics or format details are provided.

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 a methodology entry by ID. The verb 'return' and resource 'methodology entry' are specific, distinguishing it from sibling tools that deal with patterns, frameworks, or recipes.

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 provided on when to use this tool versus alternatives. There is no mention of when-not-to-use or any context about prerequisites or 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; description does not disclose behavioral traits such as whether it is read-only, permission requirements, or potential side effects. It only states it returns data but lacks further 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 extremely concise – a single sentence. It is front-loaded and to the point, but trades off completeness for brevity.

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 tool is simple with one parameter, but the description lacks usage guidelines, behavioral context, and parameter detail. Although an output schema exists, the description is incomplete for an AI agent to make informed decisions.

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% for the parameter 'pattern_id', and the description adds no additional meaning beyond 'by id'. It does not explain the format, source, or constraints of the pattern_id.

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 states 'Return the full body of a pattern by id' – verb 'return', resource 'full body of a pattern', method 'by id'. It distinguishes from siblings like 'get_pattern_context' (which returns context) and 'find_pattern' (which searches patterns). However, 'full body' could be more specific.

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 on when to use this tool vs alternatives like get_pattern_context or find_pattern. No exclusions or prerequisites 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 provided, the description carries the full burden. It explains the conceptual output but fails to disclose traits such as read-only nature, authentication requirements, or rate limits. The existence of an output schema partially compensates.

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 a single concise sentence that effectively uses bullet points to list output categories. It is front-loaded but could briefly mention the parameter without significant verbosity.

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 adequately explains the tool's core output but lacks usage guidelines and parameter semantics. Given the complexity and presence of an output schema, it is minimally complete but has 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 description coverage is 0%, and the description adds no meaning to the 'pattern_id' parameter beyond the schema's basic type and name. No guidance on how to obtain or format the parameter is given.

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's purpose: a reverse-index view of a pattern showing its implementations, uses, and related anti-patterns. This differentiates it from sibling tools like 'get_pattern' (which likely returns pattern details) and 'examples_for' (returns examples).

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 usage when context around a pattern is needed, but does not explicitly state when to use this tool versus alternatives like 'anti_patterns_in' or 'get_framework'. No prerequisites or exclusions are provided.

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 must disclose behavioral traits. It only indicates a read operation (Return) but omits side effects, permissions, rate limits, or output structure. The output schema exists but is not referenced.

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?

One concise sentence, front-loaded with verb, resource, and mechanism. No wasted words, though could expand slightly without losing efficiency.

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 context (1 required param, output schema exists, sibling tools), the description is too terse. It fails to define what a recipe is, any prerequisites, or how to interpret results, leaving significant ambiguity.

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%, yet the description adds no meaning beyond the parameter name 'recipe_id'. The phrase 'by id' confirms it's an identifier but doesn't explain format or constraints.

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 (Return) and the resource (recipe, abstract composition) with the means (by id). It distinguishes from siblings like get_pattern or get_framework by using the unique resource 'recipe', but could be more explicit about what a recipe is.

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 on when to use this tool versus alternatives like get_pattern or recommend_recipe. The description only implies usage from the name and context, but does not explicitly state conditions or exclusions.

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 full burden. It discloses that category values are from a set (orchestration-framework, etc.), which adds value. However, it does not mention any behavioral traits such as read-only nature, pagination, or authentication requirements, so transparency is moderate.

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 a single sentence that conveys the core functionality and parameter usage without extraneous text. It is front-loaded and efficiently structured.

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's low complexity (single optional parameter) and existence of an output schema, the description is adequate. It explains the main purpose and filter functionality. Minor missing details like default behavior or ordering do not significantly hinder understanding.

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 the description compensates by providing specific examples of valid category values ('orchestration-framework, agent-sdk, ...'). This adds meaningful context beyond the schema's bare type definition.

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 frameworks with an optional category filter. The verb 'List' and resource 'frameworks' are specific. While it does not explicitly distinguish from siblings like 'get_framework' or 'list_patterns', the name and short description make the purpose clear enough.

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 provided on when to use this tool versus alternatives like 'get_framework' or 'find_pattern'. There is no mention of when-not-to-use or prerequisites, leaving the agent with no contextual decision support.

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 behavioral burden. It only states 'List patterns' with no mention of side effects, authentication, rate limits, or return format. Since output schema exists, return format is partially covered, but the description adds little behavioral context beyond the action.

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 a single, well-structured sentence that front-loads the action. No redundant information, every word serves a purpose.

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 operation with one optional parameter and an output schema, the description is mostly complete. However, without usage guidelines relative to siblings, it is slightly lacking in full completeness.

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 is one parameter 'category' with schema description coverage at 0%. The description provides an example value ('tool-use-environment'), adding meaning beyond the schema's bare 'Category' title. However, it does not specify allowed values or format, so only moderate value is added.

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 patterns' with optional filtering by category, using a specific verb and resource. It also provides an example category, distinguishing it 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?

The description implies use for listing patterns with optional filtering but does not explicitly state when to use it versus alternatives like 'find_pattern' or 'get_pattern'. No exclusion criteria or context provided.

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, so description carries full burden. Discloses keyword search fallback and its limitations. Missing details on output format (but output schema exists) or side effects (none expected).

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, no filler. First sentence states purpose, second covers implementation detail. Well-structured and to the point.

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 the essential details for a simple one-parameter tool with output schema. Explains fallback behavior. Could briefly mention expected output structure, but output schema compensates.

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?

Only parameter 'symptom' has schema coverage 0%, but description provides explicit examples and explains input purpose, adding meaning beyond the simple string type.

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 the verb ('return'), resource ('likely anti-patterns and the positive patterns that fix them'), and input ('observed symptom'). Distinguishes from sibling tools which are ID/name-based lookups.

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 current fallback behavior (keyword search) and explicit note about upcoming structured field. Does not explicitly state when not to use, but purpose implies use case.

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 discloses that it uses a heuristic mapping and mentions future plans, which is helpful. However, it does not explain the role of the 'scale' and 'regulated' parameters, nor any side effects or auth requirements. Since no annotations are present, the description carries the full burden and is insufficient.

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 pragraphs. The first sentence gives a clear purpose. The second adds technical detail and context. It is relatively concise, though the list of composition categories inside the description could be moved to a more structured location.

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 existence of an output schema, the description does not need to explain the return format. However, it fails to clarify how the 'scale' and 'regulated' inputs affect recommendations. The mapping logic is partially explained, but the overall completeness is adequate for a heuristic tool but not excellent.

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 0% schema description coverage, the description must compensate. It mentions 'constraints' generically but does not detail the 'scale' or 'regulated' parameters, their possible values, or their impact on recommendations. This is 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?

The description clearly states the tool recommends recipes and frameworks for a use case with constraints, explicitly listing the composition categories it maps to. It distinguishes from sibling tools like get_recipe (single lookup) and list_frameworks (list only) by offering combined recommendations.

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 versus alternatives is provided. The mention of 'heuristic v1' and 'proper facet-based recommender' implies it is a temporary solution, but there is no direct comparison to siblings like get_recipe or examples_for.

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