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

No annotations are provided, so the description must cover behavioral aspects. It discloses that the suppression is written directly into the file as a structured comment in version control and that accepted risks resurface after expiry. However, it does not mention potential side effects like file modification permissions or whether a commit is needed.

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 structured in three short paragraphs and is front-loaded with the primary action. It is efficient without being overly verbose, though some sentences could be combined. It 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 7 parameters (5 required) and an output schema, the description covers the key behaviors: the two acceptance types, expiry handling, and version control integration. It does not detail the output or error handling, but the output schema likely covers that. Overall, it is sufficiently 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 100%, so the schema already describes each parameter thoroughly. The description does not add significant new meaning beyond the schema, but it provides overall context for the parameters. Baseline 3 is appropriate.

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: 'Insert a justified suppression comment into a skill file.' It further explains that it marks a finding as false positive or accepted risk with documentation. This differentiates it from sibling tools like scan_chain or list_ave, which are about scanning and listing respectively.

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 that the tool is used to suppress findings as false positives or accepted risks. It also details the behavior of expiry, but does not explicitly state when not to use it or compare to alternatives. However, its usage is well-defined within the context of the sibling 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?

No annotations are provided, so the description carries the full burden. It states the tool runs 18 checks and returns a grade, but does not disclose whether it is read-only, requires authentication, has destructive potential, or any error conditions. The conformance condition is mentioned, but overall behavioral traits are incomplete.

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 concise sentences that immediately convey purpose and key details (checks, tiers, grade). Every sentence adds value with no 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 tool's complexity (18 checks, 3 tiers, grading) and the presence of an output schema (not shown), the description covers all essential aspects for an agent to understand what the tool does and what it returns.

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 covers the single parameter (url_or_path) with a clear description. The tool description adds no further meaning beyond what the schema already provides. With 100% schema coverage, baseline of 3 is appropriate.

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 uses a specific verb ('score') and resource ('MCP server manifest'), clearly distinguishing from sibling tools that scan content or credentials. It explicitly mentions the number of checks (18), tiers (REQUIRED, RECOMMENDED, BEST PRACTICE), and grading scale (A+ to F).

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 the tool is for testing conformance but lacks explicit guidance on when to use it versus alternatives, when not to use it, or prerequisites. Sibling tools are different in purpose, but no comparative advice 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 burden. It explains that the tool compares hashes and reports changes, but does not disclose whether the tool is read-only or has any side effects. The presence of an output schema is mentioned but its specifics are not described.

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 brief and front-loaded with the main purpose. It includes necessary context (prerequisite CLI command) without extraneous detail. The structure is clear 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 the core functionality and a prerequisite, but does not detail the output format or return values (though output schema exists). It would benefit from explaining what the agent should expect upon invocation.

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% for the single parameter 'path', with a description and default value already provided. The description adds a CLI reference but does not significantly enhance understanding 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 tool checks a directory for skill file rug pull drift by comparing SHA-256 hashes against pinned values. It uses a specific verb ('check') and resource, and is distinct from sibling tools which focus on scanning, searching, or accepting findings.

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 mentions that an initial pin file must be created via CLI ('bawbel pin'), implying a prerequisite. However, it does not explicitly state when to use this tool versus alternatives like check_conformance or scan_chain, nor does it specify scenarios where it should not be used.

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. Only basic listing and filtering behavior disclosed. Missing details on pagination, sorting, read-only nature, or performance considerations. Incomplete for a list operation.

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 unnecessary words. Directly conveys purpose and usage. Excellent conciseness.

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?

Output schema exists (not shown) so return values are covered. Description is adequate but lacks details on sorting, pagination, or behavior with no filters. Some gaps for a comprehensive list tool.

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 clear descriptions for each parameter. Description adds minimal value beyond stating 'optional filters.' Baseline 3 applies.

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 'List AVE records with optional filters.' Specifies action and resource, and lists specific filterable attributes (severity, component type, OWASP MCP category). Differentiates from siblings like lookup_ave and search_ave.

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 for use ('browse the full AVE database or filter'), but lacks explicit when-not-to-use guidance or comparison with similar sibling tools. No mention of prerequisites or limitations.

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 discloses that the tool returns a complete record with specific fields (title, description, etc.), which is transparent for a read operation. However, it does not mention error handling or idempotency.

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: the first states the purpose, the second lists the output contents. It is front-loaded, concise, and contains no extraneous 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?

Given the presence of an output schema, the description need not explain return values. It does list the return fields, adding value. However, it could mention error cases (e.g., ID not found) for 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?

The input schema has 100% coverage with a description of the parameter (AVE ID format). The tool description does not add additional parameter semantics beyond that, so a baseline score of 3 is appropriate.

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 (Get) and resource (full AVE record) for a specific vulnerability ID. The name 'lookup_ave' paired with the description distinguishes it from sibling tools like 'list_ave' (which likely lists all records) and 'search_ave' (which 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?

The description implies usage when having a specific vulnerability ID and needing the complete record. It provides clear context but does not explicitly exclude other scenarios or mention 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 must carry the burden. It implies read-only analysis by using 'scan' and 'detects', but does not explicitly state that it does not modify data or disclose other behavioral traits like performance or authentication needs.

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 with the core purpose in the first sentence. Every sentence provides value—action, specific filter, and usage context—without any wasted 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 presence of an output schema and full parameter descriptions, the description covers the tool's purpose, filter criteria, and usage scenario. It lacks some behavioral specifics but is sufficient for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 100% with both parameters described. The description does not add extra meaning beyond what the schema provides, so the baseline score of 3 applies.

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 scans delegation chains of skill file content, filters to a specific CVE, and detects sub-agent spawning with inherited permissions and missing trust boundaries. This provides a specific verb-resource pair and distinguishes from siblings like scan_content.

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 ends with 'Use this when evaluating a skill that spawns sub-agents or delegates tasks to other agents,' providing clear when-to-use guidance. However, it does not mention when not to use it or explicitly compare to sibling 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?

No annotations provided, so description carries full burden. Discloses that it returns findings with AVE IDs, severity scores, OWASP categories, and remediation links, plus detects toxic flows. However, it doesn't mention whether scanning is read-only, idempotent, or any rate limits/auth requirements.

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 efficiently convey purpose, use cases, and output details. No wasted words, and the action verb 'Scan' is front-loaded, making it immediately clear what the tool does.

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?

Moderate complexity with 3 parameters and output schema. Description covers purpose, usage, return values, and even the additional capability of detecting toxic flows. Since an output schema exists, return value details are not required, but the description provides useful context. Minor gap: no mention of potential state changes or limitations.

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?

Input schema has 100% description coverage with clear descriptions for all three parameters. The description does not add extra information beyond what's in the schema, so baseline score of 3 is appropriate.

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 scans raw text for AVE security vulnerabilities and lists specific use cases like skill files, system prompts, and MCP tool descriptions. It distinguishes itself from sibling tools that focus on listing, searching, or specific scan types.

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 to use before using any agentic AI component, providing clear context. While it doesn't list when not to use or name specific alternatives, the sibling tools are named and the description implies this is the general content scanner.

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?

Describes what it does (scan for credentials) but does not indicate whether it is read-only, has side effects, or any safety traits. No annotations provided to supplement.

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 focused sentences: purpose, filter rule, and use case. No wasted 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?

Covers purpose, specific rule, and usage context. Output schema exists so return format not required. Could mention scope limitations but sufficient for the tool.

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%, so baseline is 3. Description adds no extra meaning beyond schema descriptions for 'content' and 'no_ignore'.

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 'credential-focused scan of skill file content', specifies the exact rule (AVE-2026-00047) and types of credentials detected. Distinguishes from broader sibling tools like 'scan_content'.

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 this when you specifically want to check whether a skill file contains hardcoded secrets before adding it to your agent config.' Provides clear context but does not mention when not to use 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 are provided, so the description carries the full burden. It discloses that the tool fetches a remote file and scans for AVE vulnerabilities, implying a read-only operation. However, it does not disclose potential side effects, network requirements, error behavior for unreachable URLs, or whether it modifies any state. The behavioral disclosure is adequate but not exhaustive.

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 with a clear first sentence and a second sentence adding necessary detail. The second paragraph could be slightly more compact, but overall it is well-structured and 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 (context signal), the description does not need to explain return values. It covers the purpose, usage context, and parameter semantics adequately. However, it fails to mention error handling (e.g., unreachable URL), and the acronym 'AVE' is not explained. It is sufficient but not fully comprehensive.

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 descriptions for both parameters. The description adds minor context (e.g., 'bypass all suppressions' for no_ignore) but does not significantly extend beyond the schema. Baseline 3 is appropriate as the schema already documents the parameters well.

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 'scan' and resource 'MCP server-card' with a specific purpose 'security vulnerabilities'. It also provides detail on what the scan involves (fetching .well-known/mcp.json and scanning descriptions/schemas), which distinguishes it from sibling tools like check_conformance or scan_content.

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 recommends this as 'the primary tool to run before adding any MCP server to your configuration,' providing clear when-to-use guidance. It does not mention when not to use or explicitly name alternatives, but the context makes the primary usage 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?

No annotations provided, but description clearly explains the search behavior: it searches across multiple fields and returns specific data. This sufficiently discloses the read-only nature and output content.

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: first states purpose, second details fields searched and return data. No waste, 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?

Output schema exists (mentioned in context), so return value details are not required. Description covers search scope and return fields. Minor omission: no mention of error handling or empty result behavior, but acceptable.

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 covers both parameters (query and limit) with descriptions. The description adds value by providing example query terms ('tool poisoning', 'credential', 'MCP01'), which goes beyond the schema's generic 'Search term'.

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 'Search AVE records by keyword' and lists specific fields searched (AVE ID, title, attack class, description, behavioral fingerprint). It also mentions return fields (severity, AIVSS score, link), making it distinct from sibling tools like list_ave and lookup_ave.

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 implies keyword search but doesn't specify exclusions or context. While search is implied, the description lacks comparative usage advice.

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