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

No annotations are provided, so the description carries the full burden, but for a zero-parameter read-only enumeration the burden is light. It does disclose the output shape ('grouped by category'), which is genuinely useful context, yet it omits any note on whether results are static/cached, how large the listing can get, or what the category values are.

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 with the action, domain, and result structure in order. No filler, no repetition of the tool name, nothing to trim.

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 and no annotations, the description is the only source of return-value information, and it partly supplies that ('grouped by category'). However, it leaves the agent guessing about the pattern identifiers returned, how many exist, and whether those identifiers map to anything the scan tools consume, which is the main use case for a list_patterns call.

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

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

The tool takes no parameters, so the schema cannot be improved by description text. Baseline of 4 applies; the description correctly implies a parameterless enumeration with no configurable filters.

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?

States a specific verb ('List') and resource ('A2A (Agent2Agent) protocol pattern') scoped to this auditor, and adds that results are grouped by category. The A2A qualifier separates it from the many sibling *__list_patterns tools (agent_graph, secret_scanner, etc.), so an agent can identify the domain without opening the schema.

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?

There is no when-to-use guidance, no mention of when to prefer this over the sibling a2a_auditor__scan_text/scan_file/scan_directory tools, and no statement of prerequisites. The purpose is self-evident for a list-style tool, but nothing in the text routes the agent or sets 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?

No annotations are provided, so the description carries the full disclosure burden. It conveys recursion but says nothing about permissions, read-only nature, expected runtime, file-count limits beyond the schema's maxFiles, or how findings are surfaced.

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 with no filler. It is lean but arguably too terse for a four-parameter scanner, leaving room that the description could have used productively.

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 and no annotations, the description should explain what a scan produces and what 'protocol anti-patterns' means. It never addresses return format, result grouping, or relationship to list_patterns, leaving the agent under-informed for a scanning 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 description coverage is 100%, so all four parameters (path, exclude, include, maxFiles) are already documented in the schema. The description adds no parameter syntax or semantics beyond the schema, which is the baseline expectation at full coverage.

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?

States a specific verb (scan), resource (directory of A2A agent source), and target (protocol anti-patterns), plus the recursive traversal scope. The 'directory' scope implicitly distinguishes it from a2a_auditor__scan_file and scan_text, though it never names those siblings explicitly.

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 pick this over a2a_auditor__scan_file, scan_text, or list_patterns. With many near-identical scan_* siblings across auditors, the agent gets no routing help beyond the name's 'directory' hint.

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 behavioral burden. It never states that the operation is read-only, what the scan produces (findings, severities, counts), whether it needs file access permissions, or how large files are handled. Only the target domain is disclosed.

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 states the action and scope with zero redundant phrasing. Nothing to trim and nothing buried.

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 annotations and no output schema, the description is the only place to learn what a scan returns, but it stops at the purpose. For a one-parameter scanning tool the gap is modest, yet an agent still cannot anticipate the result shape or any constraints before calling it.

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 a single required parameter with 100% schema description coverage, so the schema already explains that 'path' is an absolute or relative file path. The description adds nothing about the parameter beyond what the schema provides, which is the expected baseline for a fully documented 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 names a specific verb (Scan), the resource scope (a single file), and the domain (A2A Agent2Agent protocol anti-patterns). Combined with the name, an agent can distinguish it from scan_directory and scan_text by input granularity, but it never explicitly names those alternatives.

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?

'Scan a single file' implies the usage condition (you have one file rather than a directory or raw text), which is adequate routing context. However, there is no explicit when-to-use/when-not-to-use guidance and no mention of the sibling tools the agent should prefer for other input shapes.

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 detection semantics (what it looks for and why - e.g. SSRF, auth bypass, credential leakage in public Agent Cards), which is substantive. However, it says nothing about the output shape, severity levels, read-only nature, or whether it performs any network calls. This is a meaningful gap for a no-annotation 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 dense front-loaded sentence that names the target and enumerates the three pattern categories with parenthetical rationale. No filler, but the long enumerative clause stretches readability.

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 text-scanning tool with no output schema, the description sufficiently explains what will be flagged and why each pattern is dangerous. It lacks return-format detail and expected-input guidance, but is largely complete for an agent to invoke it 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 coverage is 100% - both parameters (label, content) are documented in the schema itself. The description adds no parameter-level semantics (e.g. expected content format, size limits). Baseline 3 is appropriate when the schema does the heavy lifting.

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?

States a specific verb (Scan) and resource (A2A protocol implementation code) and enumerates the exact anti-patterns it detects. Clearly distinguishes itself from sibling scanners (secret_scanner, mcp_server_auditor, etc.) by naming A2A-specific threats like SSRF via push-notification webhooks and literal credentials in publicly-served Agent Cards.

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 by listing what it detects for A2A code, but never says when to prefer scan_text over a2a_auditor__scan_file or scan_directory, nor when A2A scanning is inappropriate. Guidance is inferable from the enumerated patterns but not explicit.

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

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

With no annotations, the description carries the full burden. It usefully discloses scope ("at the end of a delegation path") and return shape ("grouped by category"), which implies a read-only, side-effect-free enumeration, but it never states that explicitly nor covers anything about ordering or volume.

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 with no filler, redundant restatement of the name, or hedging. Every clause (scope, grouping) adds information.

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

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

For a zero-parameter, no-annotation tool with no output schema, the description supplies the essential scope and the category-grouped result shape. It stops short of detailing the rule entry structure, which is the only material omission given no output schema exists to carry it.

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

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

The tool takes zero parameters, so per the baseline there is nothing for the description to clarify; the phrase "grouped by category" is a bonus. No parameter-related gap exists.

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?

States a specific verb ("List") and resource ("dangerous-capability rule this auditor looks for at the end of a delegation path"), with the qualifier "this auditor" cleanly separating it from the ~15 other list_patterns/list_* siblings. An agent can identify it without opening the empty schema.

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?

It names no explicit alternative and gives no when/when-not condition, but usage is strongly implied: call this to enumerate the agent-graph rules rather than the sibling scan_text/scan_file/scan_directory tools. Adequate but leaves the routing inference to the agent.

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 at all, the description carries the full behavioral burden, and it does disclose a genuinely important limitation: each file is analyzed independently and variable references do not resolve across files, so cross-file Crew/GroupChat assembly is not connected. That is exactly the kind of caveat an agent needs to interpret results correctly. It still omits read-only-ness, performance/scale behavior, and what the report looks like, so it falls short of a 5.

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. The core action is front-loaded and the second sentence is a non-obvious caveat that earns its place by preventing misreading of results.

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 4-parameter, no-annotation, no-output-schema scanning tool, the description tells the agent what is scanned, what is reported, and the key analytical limitation. It does not describe the shape of the report or pagination/truncation behavior, which is the main remaining gap.

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

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

Schema description coverage is 100%, with path, exclude, include and maxFiles all documented in the schema, so the baseline is 3. The description adds no extra meaning about path syntax, exclude/include matching semantics, or the default file cap beyond what the schema already says.

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?

States a specific verb (recursively scan), resource (a directory of Python files) and output (excessive-agency paths found in each). It is clearly the batch counterpart to the sibling scan_file/scan_text tools, but it never names them, so the differentiation is implied by the word 'directory' rather than stated.

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 word 'directory' and 'Recursively' imply the right usage context versus a single-file scan, but there is no explicit when-to-use statement, no mention of when to prefer scan_file or scan_text, and no prerequisites. Usage is inferable, not stated.

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. 'Scan' implies a non-mutating read, which is a useful signal, but nothing is said about the return shape, whether it needs auth or a specific Python environment, or how it handles non-matching files or syntax errors.

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-formed sentence that leads with the verb and resource and packs the domain scope without filler. Nothing is wasted and nothing essential is buried.

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 one-argument scanner this is largely adequate, but with no annotations and no output schema the description leaves the return format and file-handling behavior undocumented. It is sufficient to call correctly but not to anticipate results.

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 one parameter exists and schema description coverage is 100%, so the schema fully documents the 'path' argument. The description adds no format, scope, or constraint detail beyond what the schema already provides, matching the baseline for high coverage.

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?

States a specific verb (scan), resource (a single Python file), and the exact subject matter (excessive-agency paths in LangGraph/CrewAI/AutoGen constructs). The 'single ... file' qualifier implicitly distinguishes it from the directory/text variants, though it never names them explicitly.

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 'single Python file' phrasing implies the use case and partially separates it from scan_directory/scan_text siblings, but there is no explicit when-to-use, when-not-to-use, or named alternative. Guidance is inferable rather than stated.

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 does disclose the substantive analysis logic in detail — what the graph is checked for (an agent with no dangerous tool of its own that reaches shell/code-exec/file-write/network/credentials through a handoff). It omits return shape and performance traits, but the safety profile (a pure text read) is self-evident from 'Scan'.

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: the core action and target come first, and the em-dash clause economically explains the detection logic. It is somewhat long, but no sentence is filler. Slightly dense for one sentence, hence not a 5.

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 and no annotations, the description still gives an agent enough to call it correctly and understand what it checks. It stops short of describing the finding/return structure, which would be the main remaining gap for a scanner 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?

Schema description coverage is 100%, so both parameters ('label', 'content') are already documented in the schema. The description's mention of the Python snippet aligns with the 'content' param but adds no syntax, format, or handling detail beyond what the schema provides. Baseline 3 applies when the schema does the heavy lifting.

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?

States a specific verb-resource pair ('Scan a Python snippet defining a multi-agent orchestration') plus the target frameworks (LangGraph, CrewAI, AutoGen/ag2) and the precise defect sought (excessive agency reachable via delegation/group membership). An agent can distinguish it from scan_file/scan_directory siblings and from other auditors like a2a_auditor or toxic_flow_auditor without opening the schema.

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 context (inline Python snippet for multi-agent frameworks) but never states when to use this over the sibling scan_file or scan_directory, nor any exclusion. The text-vs-file distinction is only inferable from the tool name, leaving usage implied rather than guided.

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 results are grouped by category and include custom rules from .guardbee/rules, which adds useful output context. However, it does not explicitly state that the operation is read-only or whether permissions are required, though 'List' strongly implies a safe read.

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 the core action and resource, then adds grouping and custom rules. No wasted words; every clause 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?

For a zero-parameter, read-only list tool with no output schema, the description covers what the tool does and how results are organized. It omits usage context and safety confirmation, but those are minor given the tool's simplicity. Adequate but not exhaustive.

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?

Zero parameters, so baseline is 4 per the rules. The schema is empty and the description does not need to add parameter semantics. No gap exists.

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?

States a specific verb 'List' and resource 'AI/LLM security patterns that the scanner can detect', plus grouping and custom rules. It does not explicitly differentiate from sibling list_patterns in other scanners, though the tool name prefix helps disambiguate. Clear but no sibling differentiation in description.

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, such as other list_patterns tools or scan_* tools. No prerequisites or exclusions mentioned. The implied use case is pattern discovery, but no explicit context is 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 carries the burden and does disclose meaningful behavior: recursive traversal and auto-skipping of node_modules, .git, dist, and binary files. The schema does not state these default exclusions, so this is genuine added context, though return format and large-directory behavior remain unstated.

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 tight sentences with the core purpose front-loaded and the auto-skip caveat immediately after. No filler or restated name/title.

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 read-only directory scanner with four fully documented parameters and no output schema, the description covers purpose, scope, and default exclusions adequately. It could note the output shape (findings list) but the absence of an output schema lowers the bar.

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%, so path, exclude, include, and maxFiles are already documented, including the default of 5000. The description adds no parameter-level detail beyond the schema, matching the baseline of 3.

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?

Specific verb (scan) + resource (directory) + scope (insecure AI/LLM integration patterns) with recursion noted. This clearly separates it from ai_code_scanner__scan_file and scan_text via the directory/recursive framing, though it never names those siblings explicitly.

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 directory-scoped, recursive wording implicitly tells an agent when this applies versus scan_file/scan_text, but there is no explicit when-to-use, when-not-to-use, or named alternative. Usage is inferable from the name and phrasing rather than stated.

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 the full behavioral burden, and it mostly does not. It never states that the operation is read-only/non-mutating, what the scan returns, whether findings are cached, or any auth/rate constraints. Only the detection domain is disclosed.

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 tight sentence with the action first and no filler; appropriately sized for a one-parameter tool. It sacrifices a little useful context for brevity, which keeps it just short of 5.

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 a low-complexity tool (one required param, no output schema, no nested objects), the description is minimally adequate: it tells the agent what is scanned but not what comes back (findings shape) or that it is a safe read. Adequate but with clear gaps.

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

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

Schema coverage is 100% and the sole 'path' parameter is already documented as 'Absolute or relative path to the file to scan'. The description adds no syntax, format, or constraint detail beyond the schema, so the baseline 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?

Specific verb ('Scan') plus a precise resource ('a single file') and a clear detection domain ('insecure AI/LLM integration patterns'). The word 'single' implicitly distinguishes it from the scan_directory sibling, though it never names scan_text or scan_directory explicitly.

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?

Usage is only implied by the singular 'a single file' – an agent can infer this is for one file rather than a directory or free text, but there is no explicit when-to-use or when-to-prefer-an-alternative statement, and no prerequisites 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 behavioral burden. It does not state that the operation is read-only, whether permissions are required, what the findings look like, or any rate limits—it only implies a read operation via "Scan."

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 front-loaded sentence with the verb first and a compact parenthetical list of pattern types. Every phrase contributes to defining the scan scope with 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?

With no annotations and no output schema, the description should ideally disclose that the tool is read-only and explain the shape of returned findings. It only lists pattern categories, leaving both safety behavior and return format undocumented for an agent that cannot rely on structured fields.

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

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

Schema description coverage is 100%, so both parameters (content, label) are fully documented in the schema. The description adds no parameter syntax, constraints, or examples, making the baseline score of 3 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?

States a specific verb ("Scan") and resource ("text string or code snippet") plus a clear scope with five named pattern categories. This distinguishes it from ai_code_scanner__scan_file and scan_directory by input type, but it does not explicitly differentiate from the many other *_scan_text siblings (e.g., a2a_auditor__scan_text, secret_scanner__scan_text) or name alternatives.

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 no explicit when-to-use, when-not-to-use, or alternative-tool guidance. The only usage cue is the implied distinction of scanning a text string rather than a file, which is not enough to route an agent among the many sibling scanners.

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

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

With no annotations, the description carries the full behavioral burden, and it does convey one useful trait: it returns every check (exhaustive, unfiltered listing). It says nothing about whether the operation is read-only, how results are shaped, or whether pagination applies, leaving meaningful gaps for a discovery 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 with no filler, and the scope word 'every' is placed early. It is appropriately sized, though terse enough that the missing routing information is noticeable.

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?

Invocation is trivial with zero parameters, but there is no output schema, so the description should describe the shape of a returned 'check' (id, name, description) and it does not. Combined with the absence of usage guidance, it is minimally viable rather than 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 tool takes no parameters, so the schema is empty and there is nothing for the description to explain. Baseline 4 applies for zero-parameter tools.

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 states a specific verb (List) and resource (OWASP MCP08 audit-gap checks run by this auditor), which separates it from the many other *__list_patterns siblings from different auditors. It stops short of explicitly naming or contrasting those siblings, but an agent can identify that it enumerates this auditor's own check catalog.

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?

There is no statement of when to call this versus the sibling scan_text/scan_file/scan_directory tools, nor any prerequisite or ordering guidance. The discovery-then-scan workflow is only inferable from the tool family convention, which is weak 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 are supplied, so the description carries the full behavioral burden. 'Recursively' usefully discloses that subdirectories are traversed, but it says nothing about whether this is a read-only operation, how loaded directories are handled, default exclusions (the schema's default maxFiles of 5000 is unmentioned), or what a 'gap' finding actually represents.

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 with zero padding – the action, the input type, and the analysis target all appear before any filler. Nothing could be removed without losing 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?

Because no output schema exists, the description should convey something about the shape of results (findings, severities, counts), and it does not. Similarly it omits when to prefer it over scan_file. It is adequate for identifying the tool but leaves the return contract and usage context unstated.

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%, so path, exclude, include, and maxFiles are already documented with their semantics and defaults. The description adds no extra meaning beyond the schema (e.g., no guidance on how exclude/include interact or typical patterns worth filtering), so the 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?

The description states a specific verb ('Recursively scan'), resource ('directory of MCP server source'), and a precise target of analysis ('OWASP MCP08 audit/telemetry gaps'). The 'directory' scope inherently separates it from the same-namespace siblings scan_file and scan_text, though no sibling is named explicitly.

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?

Usage is only implied by the word 'directory' – an agent can infer this is the tool for scanning a whole tree rather than a single file, but there is no explicit when-to-use statement, no prerequisite (e.g., source must be an MCP server project), and no routing against the adjacent scan_file/scan_text/list_patterns 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 says nothing about whether the scan is read-only, whether it executes or resolves the file's contents, what happens on binary/unreadable input, or how results are surfaced. 'Audit/telemetry gaps' hints at what it looks for but discloses no operational 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?

A single front-loaded sentence with zero filler; the scope qualifier ('single file') precedes the purpose clause. Nothing to trim.

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 one-parameter read tool with no output schema, the description is minimal but mostly sufficient on intent. It omits the expected output shape (findings list? pass/fail?) and any coverage caveats about what MCP08 checks are performed, which an agent would need to interpret results.

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% – the single 'path' parameter is already documented as an absolute or relative file path. The description adds nothing about path handling (globs, symlinks, size limits), so baseline 3 applies with the schema doing the heavy lifting.

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?

States a specific verb ('Scan'), a precise resource ('a single file'), and a well-defined target domain ('OWASP MCP08 audit/telemetry gaps'). It implicitly separates itself from audit_gap_auditor__scan_directory and scan_text by scoping to one file, though it never names those siblings explicitly.

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 word 'single file' implies when this tool applies versus the directory/text variants, but there is no explicit when-to-use statement, no prerequisite (e.g. file must be readable/text-based), and no named alternative. Usage must be inferred from the scope noun alone.

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 behavioral burden. It discloses the detection categories and indirectly that results are surfaced as 'findings', but says nothing about whether the scan is read-only, whether it has side effects, rate limits, or execution cost for a code-analysis 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 with a colon-delimited list of detected gaps. It is dense but every clause contributes a distinct detection category, so little is wasted; the list slightly hurts readability but not enough to penalize heavily.

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 annotations and no output schema, the description should ideally describe the shape of the returned findings (severity, location, remediation). It thoroughly covers what is detected but leaves the return format unaddressed, which is a gap for a scanner whose output the agent must interpret.

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% for both parameters (label, content), so the schema already documents their meaning. The description adds no parameter-level detail beyond what the schema states, giving the standard baseline.

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?

States a specific verb (Scan) and resource (MCP server source) and enumerates the exact gap categories it detects (no audit trail, raw args/results logged, audit hard-disabled, silent catch blocks, missing session/request id). However, it never explicitly distinguishes itself from the sibling scan_file/scan_directory variants, leaving the input-form distinction to be inferred from the name and schema.

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 scope implies usage (scanning source for audit/telemetry gaps), but there is no explicit 'use this when...' guidance and no mention of the alternative scan_file/scan_directory tools or when one should be preferred over another. Usage is inferable from the description but never stated.

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

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

With no annotations, the description carries the full burden. It discloses one genuine behavioral trait, that no API key is required, and fetch/analyze implies a read-only network operation. It says nothing about return format, analysis depth, rate limits, or failure behavior for a non-existent/unreachable URL.

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 short sentences, zero filler, with the core action and scope front-loaded ahead of the secondary access note. Every clause 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?

There is no output schema and no annotations, so the description is the only place to learn what the analysis yields (findings, gap list, score, framework breakdown). It never describes the return value, which is a material gap for an analysis tool whose output shape is otherwise unknowable.

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% and the single url parameter is fully documented in the schema, including the homepage auto-detect behavior. The description adds no parameter syntax or format detail beyond that, so the baseline 3 for schema-documented parameters 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 names a specific verb pair (fetch and analyze) and a specific resource (privacy policy page) scoped to GDPR/KVKK completeness, which is concrete enough for an agent to know exactly what it produces. It does not, however, differentiate itself from the sibling compliance_checker__check_compliance, so the agent cannot tell the two apart from the text alone.

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?

There is no when-to-use or when-not-to-use guidance and no mention of the sibling alternatives (check_compliance, list_requirements, compare_frameworks). 'Works without an API key' is an access hint, not usage guidance, leaving the selection decision to inference.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the return shape (gap analysis plus action plan) and names the underlying GuardBee engine, but says nothing about whether the scan is long-running, what happens when wait=false, network egress implications, or rate/cost limits — all material for an unbounded web scan.

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 tight sentences (~30 words) with the action and target front-loaded and the return value second. No filler, no redundancy, and the return-value sentence is valuable given the absence of an output schema.

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 3-parameter, no-annotation, no-output-schema tool, the description covers purpose, frameworks, and return shape, which is the minimum viable set. It still omits execution semantics (sync vs async, expected duration, whether a separate findings call is required), which an agent would need before invoking it on a live URL.

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%, so url, wait, and the framework enum are already documented in the schema; baseline 3 applies. The description repeats the framework values but never mentions the wait parameter or its async implications, so it adds essentially no parameter meaning beyond the schema.

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

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

States a specific verb and resource (scan a URL for regulatory compliance) and names the three supported frameworks, so the agent knows exactly what is produced. It does not, however, distinguish itself from close siblings such as get_compliance_findings or analyze_privacy_policy, leaving the agent to infer that this is the entry-point scan.

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 word 'full' hints that this is the comprehensive scan, but there is no explicit when-to-use, when-not-to-use, or named alternative. Nothing tells the agent whether to call this first and then get_compliance_findings, or how it relates to compare_frameworks/list_requirements.

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 behavioral burden, yet it says nothing about whether the operation is read-only, whether it requires any inputs, or what the comparison output looks like. It does not contradict anything, but it discloses no traits beyond the bare purpose.

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 states the action, the subjects, and the goal with no filler. It is efficient, though the one sentence is the entirety of the definition.

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 zero-parameter tool with no output schema, the description is minimal but serviceable — it conveys what is compared and why. However, with no annotations and no output schema, it does not tell the agent enough about the result shape or scope to be fully self-sufficient.

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

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

The tool takes zero parameters and the schema is empty, so the baseline of 4 applies. There is no parameter syntax or meaning for the description to add.

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 names a specific verb (compare) and concrete resources (KVKK, GDPR, CCPA requirements), plus the goal of surfacing overlaps and gaps. It is clearly distinguishable in intent from siblings like check_compliance or analyze_privacy_policy, though it does not explicitly contrast itself with them.

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?

There is no explicit when-to-use or when-not-to-use guidance, and no sibling alternative is named. The comparison scenario is only implied by the verb 'compare', leaving the agent to infer when this tool beats check_compliance or list_requirements.

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

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

With no annotations, the description carries the full burden. The verb 'Get' implies a read-only retrieval and the description discloses the precondition that a scan must be completed, which is genuine behavioral context. It omits any details on pagination, result size, or behavior when findings are absent.

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 with the core action first and the optional filter trailing. No wasted words, though the brevity contributes to the coverage gaps noted elsewhere rather than being optimally informative.

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?

Three parameters, no output schema, and no annotations means the description must do more work. It conveys the retrieval purpose and the scan prerequisite, but says nothing about the shape of returned findings and drops the framework filter, leaving an agent to infer the response and one of the filter dimensions.

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%, so the baseline is 3. The description only mentions the severity filter and entirely omits the framework parameter, so it adds no meaning beyond the schema and even under-describes the available filters.

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?

States a specific verb ('Get') and resource ('compliance findings') and names the source ('a completed GuardBee scan'), so it is distinguishable from siblings like check_compliance, which runs a scan. However, it does not explicitly contrast itself with check_compliance/list_requirements, so sibling differentiation is only implicit.

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 phrase 'from a completed GuardBee scan' plus the schema note that scanId comes from check_compliance implies the prerequisite workflow (run check_compliance first). But there is no explicit when-to-use/when-not-to-use or statement of alternatives among the compliance_checker siblings.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses that results include legal basis references, and 'List all' implies a read-only operation, but it says nothing about pagination, volume of results, or whether the catalog is static versus evaluated per call.

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 with no filler; the resource and its scope come first and every word carries information.

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

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

For a trivial two-parameter read-only lookup with no output schema, the description is nearly sufficient: it states the resource, the scoping key, and one attribute of the return value (legal basis references). It could say more about result shape, but nothing required to invoke it correctly is missing.

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 documented and enum'd, so the schema carries parameter meaning. The description only echoes the framework scoping and adds no format or default guidance beyond it, matching the baseline for high-coverage schemas.

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?

States a specific verb (List) plus resource (compliance requirements) scoped to a framework, which distinguishes it from the sibling compliance_checker__check_compliance and get_compliance_findings tools. It does not explicitly name those siblings, so it stops short of a 5.

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 framework-scoped catalog framing implies when to reach for it (enumerating requirements for a given regulation rather than running a check or comparing frameworks), but there is no explicit when-to-use or when-not-to-use guidance and no alternatives named.

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, but this is a zero-parameter, read-only enumeration tool, so the safety burden is minimal and the 'List' verb conveys the non-mutating nature. It still omits any note on output shape, whether the catalog covers all MCP10 checks or a subset, or whether the list is static.

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 with no filler, though 'this auditor runs' is slightly indirect phrasing that could be tightened.

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 listing tool with no output schema, the description tells the agent what will be listed, which is the essential information. However, with no output schema to define the return, the description could have sketched the shape of the returned check entries and it does not.

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

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

The tool takes zero parameters, so there is nothing to disambiguate; the baseline for a parameterless tool is 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?

States a specific verb ('List') and a specific resource ('every OWASP MCP10 context-oversharing check this auditor runs'), naming the domain that separates it from the many sibling list_patterns tools. It stops short of explicitly contrasting itself with context_oversharing_auditor__scan_text/scan_file, so it is clear but not fully sibling-differentiated.

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?

Usage is only implied: an agent can infer this is a discovery call to see which checks exist before invoking a scan, but the description never says when to use it, when not to, or that scan_text/scan_file are the alternatives for actually running the checks.

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 behavioral burden but discloses only that traversal is recursive. It never states the operation is read-only/non-destructive, says nothing about permissions needed, and does not mention that scanning is bounded by maxFiles — all relevant for a recursive filesystem walk.

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 tight sentence with the action and scope front-loaded and zero filler. It is efficient, though the extreme brevity is precisely what leaves the behavioral gaps noted elsewhere.

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 4-parameter recursive scan with no annotations and no output schema, the description covers purpose but omits safety profile, side effects, and any hint of what findings are produced. Adequate to invoke, incomplete to invoke confidently.

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%, so path, exclude, include, and maxFiles are already fully documented in the schema (including the 5000 default). The description adds no parameter meaning beyond that, so the 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?

States a specific verb (scan), resource (directory), traversal mode (recursively), and target domain (OWASP MCP10 context-oversharing issues). This implicitly separates it from scan_file/scan_text siblings, but it never names or contrasts those alternatives explicitly.

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 no when-to-use context, prerequisites, or alternative tools. The agent must infer from the word 'directory' that this is the folder-level variant of scan_file/scan_text — pure inference, not 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 are provided, so the description carries the full behavioral burden, and it discloses almost nothing beyond the basic action. It does not state that the operation is read-only, whether it mutates or caches anything, what the findings look like, or how severity is reported for a scanner 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 with zero filler; the identifying information (action, scope, detected issue class) arrives immediately.

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 and no annotations, the description is the only place to explain what a scan returns (finding format, severity, location) and whether the call is safe, and it covers none of that. It is minimally sufficient for a one-parameter tool but leaves real 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?

There is a single parameter and schema description coverage is 100%, so the 'path' semantics are fully documented in the schema. The description adds no format detail (e.g., file-vs-directory expectations, extension handling) beyond what structured data already supplies, making the baseline 3 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?

States a specific verb (Scan) and resource (a single file) plus the target domain (OWASP MCP10 context-oversharing issues), so the agent knows exactly what it does. The word 'single' implicitly distinguishes it from the sibling scan_text and scan_directory tools, but it never names those alternatives explicitly.

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?

Usage is only implied through 'single file' and the OWASP MCP10 framing; the description never states when to prefer this over context_oversharing_auditor__scan_text or scan_directory. No prerequisites, no exclusion conditions.

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

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

With no annotations, the description carries the full behavioral burden, and it only describes what patterns are detected — not what is returned, whether findings carry severities/locations, whether scanning is read-only, or any limits. The pattern list is useful scope information but not behavioral disclosure.

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: the action and target lead, and the pattern enumeration trails as qualification. No filler sentences and nothing to trim without losing detection scope.

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 two-parameter text scanner with no output schema, the description is adequate on scope but silent on result shape and on how it differs operationally from scan_file/scan_directory. It is the minimum viable definition rather than a complete one.

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%, so both 'content' and 'label' are already documented in the schema. The description adds no syntax, format, or constraint detail beyond that, so the baseline of 3 for high-coverage schemas 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?

States a specific verb (Scan), a resource (agent/MCP source), and a named standard (OWASP MCP10:2025 context oversharing), then enumerates the exact defect classes it hunts (conversation dumps, unscoped memory tools, session-store leaks, prompt leaks, tool-result bleed, unfiltered vector queries). The enumeration lets an agent distinguish this from the sibling scan_file/scan_directory tools without opening a schema.

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?

Nothing says when to reach for scan_text over the sibling scan_file or scan_directory variants, nor what input shape it expects (inline text vs path). Usage is only inferable from the tool name. No prerequisites, no exclusions, no alternatives are named.

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 the full burden. It usefully discloses that output includes a gateway masking policy — non-obvious behavioral context that tells the agent some columns may be restricted — but says nothing about read-only safety, behavior for unknown/missing tables, or permission 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?

One tight sentence with the core action front-loaded ahead of the rationale. Nothing is wasted, though the final clause restates the value proposition rather than adding new information.

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

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

For a one-parameter read tool with no output schema, the description adequately conveys what comes back (column names plus masking policy). Minor gaps remain around error behavior and whether the table argument needs a schema/qualifier.

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% for the single 'table' parameter, so the baseline is 3. The description adds no extra detail (naming conventions, qualified vs unqualified names, case sensitivity) beyond what the schema already provides.

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?

States a specific verb (get/describe) and resource (a table's column names and gateway masking policy), which distinguishes it from list_tables and query_table without naming them. The masked-data framing makes the purpose concrete rather than a generic 'describe'.

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 trailing clause 'helps the LLM understand what data it can access' implies the intended workflow (inspect a table before querying it), but there is no explicit when-to-use statement, no mention of query_table as the alternative, and no stated prerequisites.

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

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

With no annotations, the description carries the full burden. 'Show ... active configuration' implies a non-mutating read, and it names the categories of data returned (masking rules, table policies, audit settings). However it says nothing about permissions required, whether any state changes, or sensitivity of the exposed config, leaving real behavioral gaps.

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 sentence that front-loads the verb and resource and then enumerates the returned content categories. No filler, 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?

For a zero-parameter status tool with no output schema, the description adequately tells the agent what it will see. It could be more complete by noting read-only semantics or any access requirements, but nothing essential to invoking it correctly is missing.

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

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

The tool takes zero parameters, so there is no parameter semantics to document; baseline 4 applies. The description correctly avoids inventing input arguments.

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?

States a specific verb ('Show') and resource ('active gateway configuration') and enumerates the contents (field masking rules, table policies, audit settings), which distinguishes it from data-query siblings like query_table/list_tables. It does not explicitly contrast with query_audit_log, which touches the same 'audit' domain, so it stops short of full sibling differentiation.

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?

Usage is implied — a status tool is used to inspect current configuration — but the description never says when to call it versus alternatives such as describe_table or query_audit_log, and lists no prerequisites or trigger conditions.

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

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

With no annotations, the description carries the full burden. It discloses a non-obvious behavioral trait: tables marked 'deny' in gateway policy are omitted. This is valuable context an agent would not otherwise know. It does not mention authentication or return format, but for a zero-parameter read-only list operation the main behavioral nuance is covered.

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 short sentences, front-loaded with the primary purpose and followed by a single useful constraint. Every sentence earns its place 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?

For a simple zero-parameter list tool with no output schema and no annotations, the description is largely complete: it states what is listed and what is excluded. It could optionally mention the return shape (e.g., table names), but that is not required without an 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?

The tool takes zero parameters, so there are no parameter semantics to document. The baseline for zero parameters is 4, and the description appropriately does not introduce unnecessary parameter information.

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 states a specific verb and resource: 'List all available database tables.' It is unambiguous what the tool does, but it does not explicitly differentiate itself from siblings like db_gateway__describe_table or db_gateway__query_table, which would be needed for a 5.

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?

There is no when-to-use or when-not-to-use guidance. It does not mention alternatives (e.g., describe_table, query_table) or any prerequisite context, leaving the agent to infer usage entirely.

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

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

With no annotations, the description carries the full behavioral burden and does disclose two important constraints: results are limited to events since this server process started, and the count is capped by audit.bufferSize (default 200). It does not state whether the call is read-only/side-effect free, permission requirements, or how results behave past the cap, so it falls short of complete disclosure.

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 dense sentences with zero filler: the primary purpose and queryable dimensions come first, and the retention/cap caveats follow. Every clause carries information an agent needs before calling.

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 no-annotation, no-output-schema read tool with six fully documented optional params, the description covers purpose, filters, and retention limits well. It could go further by sketching the returned event shape or empty-result behavior, which is the one remaining gap given there is 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?

Schema coverage is 100%, so the baseline is 3; the description earns above baseline by mapping the queryable dimensions (tool, table, allow/deny, redaction/write) directly onto the filter parameters, giving the agent a conceptual model of what each filter selects. It adds no syntax or format details beyond the schema, so it stays short of 5.

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?

States a specific verb and resource ('Query the gateway's own audit log') and immediately enumerates what is inspectable: tool calls, tables, allow/deny outcomes with reasons, and redacted/written fields. This clearly separates it from siblings like query_table and gateway_status, which read data or server state rather than the gateway's own event log.

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 useful scope context (events since process start, capped by audit.bufferSize, default 200) but never states when to reach for this tool versus alternatives, nor any exclusions or prerequisites. Usage is implied by the scope statement rather than explicitly framed.

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 disclosure burden, and it does deliver a meaningful behavioral trait: all results are routed through the KVKK/GDPR gateway and sensitive fields are automatically masked. That is genuinely useful output-transformation context the schema cannot convey. It still omits read-only confirmation, failure modes, and whether the gateway can further truncate results.

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 tightly written sentences, front-loaded with purpose and followed by the one non-obvious behavioral fact. Nothing is wasted and nothing is buried.

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?

There is no output schema, so the description's masking note usefully pre-empts questions about returned field values, and the schema fully documents the three parameters including the limit cap. Given low tool complexity, this is close to complete, though a note on read-only safety and gateway-imposed limits would fully close the gap.

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

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

Schema description coverage is 100%, covering table, filter, and the limit cap, so the schema already does the heavy lifting. The description's "optional filters" phrasing adds no syntax or semantics beyond what the schema states, so the 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?

States a specific verb and resource ("Query rows from a database table") plus scope ("with optional filters"), which clearly separates it from read-only metadata siblings like describe_table and list_tables. It stops short of explicitly naming those siblings, so the differentiation is inferable rather than stated.

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?

Usage is only implied: the agent can infer you call this when you need row data from a named table. There is no explicit when-to-use vs. describe_table/list_tables routing, no stated prerequisites (e.g., table must exist, permissions), and no 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?

No annotations are provided, so the description carries the full behavioral burden, and it does not discharge it. It discloses nothing about network egress (KEV/EPSS lookups), performance cost on large trees, how unsupported or ambiguous projects are handled, or whether the scan is read-only.

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 front-loaded sentence with a clean ecosystem list; every clause earns its place. It is slightly list-heavy and omits any second sentence that could carry usage or behavioral context.

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 and no annotations, the description should carry more of the load for this multi-ecosystem scanner. It covers scope well but leaves behavior, egress, and result shape entirely undisclosed, so it is adequate but with clear 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 100%, so all three parameters (directory, exploitData, includeDevDeps) are already fully documented in the schema; the description adds no parameter-level meaning beyond that. Baseline 3 applies when the schema does the heavy lifting.

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?

States a specific verb+resource ('Auto-detect and audit every supported project in a directory') and enumerates the exact ecosystems and lockfiles covered. This clearly distinguishes it from the single-ecosystem siblings audit_npm, audit_pip, and audit_package without the agent needing to open any schema.

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?

Usage is implied by the directory-vs-single-package framing and by the sibling names, but the description never explicitly says 'use this for multi-project/mixed-ecosystem directories; use audit_npm/audit_pip for a single manifest.' No when-not or prerequisite guidance 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 behavioral burden. It usefully discloses that versions are read from lockfiles with a documented fallback to package.json ranges (implying ranges yield less accurate results) and that OSV is an external lookup, but it never states read-only nature, network/privacy implications of sending dependency data, or rate limits. Adequate but incomplete for a no-annotation 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?

Two dense sentences, front-loaded with the action and data source; the lockfile enumeration earns its length by telling the agent exactly which inputs are honored without needing to consult external docs.

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 annotations and no output schema, the description should cover more of the call contract. It fully explains input resolution but says nothing about the shape of findings, severity ordering (only hinted via the exploitData schema field), or that the tool performs an external lookup. Enough to invoke, not enough to be confident about results.

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%, so the schema already documents directory, exploitData, and includeDevDeps thoroughly, including defaults. The description adds no parameter-level meaning beyond the lockfile resolution behavior, so the 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?

States a specific verb (Audit) and resource (npm dependencies) plus the mechanism (OSV database), and enumerates the exact lockfile formats resolved (package-lock.json, pnpm-lock.yaml, yarn.lock v1/berry, bun.lock). This is clearly distinguishable from the sibling ecosystem tools audit_pip and from slopsquat_scanner__scan_npm, which targets hallucinated packages rather than CVEs.

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 context of use (an npm project with a lockfile) is implied, but there is no explicit when-to-use vs the siblings audit_package / audit_directory, nor any exclusion or prerequisite guidance. An agent must infer which of the four dependency_auditor tools to pick from scope alone.

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

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

With no annotations, the description carries the full behavioral burden but only says 'audit'. It never discloses that the result is vulnerability/exploit analysis, whether the call is read-only, what the response contains, or how the exploitData flag changes behavior. The safety-relevant context lives entirely in the schema, not the description.

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 with zero filler and no redundancy against the schema. It is efficient, though its brevity borders on under-specification rather than true economy.

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?

A four-parameter tool with no annotations and no output schema gets only one sentence of description. Nothing explains what an 'audit' produces, how findings are ordered, or how this differs from the ecosystem-specific siblings, leaving the agent under-informed for correct selection.

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%, so all four parameters (including the enum values and the exploitData default) are already documented structurally. The description adds no format, ordering, or semantics beyond restating the field names, so the 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?

States a specific verb (audit) and resource (single package) with the identifying dimensions (name, version, ecosystem). The word 'single' implicitly separates it from the directory-scoped sibling, but it never names audit_npm/audit_pip/audit_directory, so the agent must infer the boundary itself.

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 when-to-use, when-not-to-use, or alternatives are given, even though sibling tools audit_npm and audit_pip are direct shortcuts for specific ecosystems. The 'by name, version, and ecosystem' phrasing only weakly implies this is the generic cross-ecosystem entry point.

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

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

With no annotations, the description carries the full burden. It usefully discloses the version-resolution strategy (exact versions from lock files, falling back to requirements.txt/pyproject.toml) and the OSV data source, but says nothing about network/auth requirements, rate limits, or result format.

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 tight sentences with the core purpose front-loaded and the resolution fallback trailing as supporting detail. No filler, though the manifest list slightly blurs into schema territory.

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 3-parameter tool with no annotations and no output schema, the description covers what it does and how it resolves versions but omits any sense of the return shape or the read-only nature of the operation. Adequate for selection, incomplete for invocation expectations.

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%, so the baseline is 3. The description adds no parameter-level detail: it never mentions exploitData (CISA KEV/EPSS enrichment) or includeDevDeps, leaving the schema to carry all three 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 pairs a specific verb ('Audit') with a specific resource ('Python dependencies') and states the threat model ('known CVEs using the OSV database'). The Python-specific lock-file list implicitly separates it from sibling audit_npm, though it never explicitly names a sibling.

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?

Usage is only implied: an agent can infer this is for Python projects because the description enumerates the Python manifests it reads. It never says when to prefer this over audit_package, audit_directory, or slopsquat_scanner__scan_pip, and offers no exclusions or prerequisites.

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

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

With no annotations the description carries the full burden, and it does disclose the analysis composition (DNS, email, DNSSEC, CAA, nameserver checks) and output shape. However it says nothing about latency/cost of running live DNS checks across up to 20 domains, partial-failure behavior per domain, or whether results are cached — operational traits an agent planning a call would want.

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; the batch scope comes first and the output preview follows via a colon-list. It is dense but every clause earns its place, with no restatement of the name or filler.

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?

There is no output schema and no annotations, so the description must cover both the action and the return; it does describe the return (per-domain grade plus top findings). What is missing is only the edge-case behavior (partial results, failures on individual domains), which is a modest gap for a two-parameter 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 description coverage is 100% and both parameters are documented there, so the baseline is 3. The description reinforces the array/batch semantics of 'domains' but adds no format or constraint detail beyond what the schema already provides.

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?

States a specific verb and resource ('Audit several domains at once') plus the batch scope, which is what separates it from the single-target siblings like lookup_dns, enumerate_dns, check_email_security and check_takeover. It also previews the deliverable ('A–F grade per domain ... plus each domain's most serious findings'), so an agent knows exactly what comes back.

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 parenthetical 'e.g. every brand or country domain' implies the batch use case, but there is no explicit when-to-use/when-not, no named alternative for single-domain lookups, and no guidance on when the more targeted checks are preferable. Usage is inferable rather than stated.

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 behavioral burden. It discloses the scope of checks and that remediation advice is included, and 'Check' implies a read-only operation. However, it does not state safety, permissions, rate limits, timeouts, or output format, leaving meaningful behavioral context unaddressed.

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 with a clean colon-separated list of checks. Every element is informative and there is no filler 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?

For a domain-based read-only security check with a simple input schema and no output schema, the description does well by listing all record types examined and mentioning remediation advice. It still omits any indication of output format, limits, or execution characteristics, but is largely complete for the tool's 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?

Schema description coverage is 100%, so both parameters (domain and dkimSelectors) are already fully documented in the input schema. The description adds no further parameter meaning beyond the schema, making the baseline of 3 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 ('Check') and resource ('a domain's email security') and enumerates exactly what is inspected: MX, SPF nested lookup count, DMARC, DKIM key strength, MTA-STS, TLS-RPT, plus remediation advice. This clearly distinguishes it from sibling DNS tools like enumerate_dns or lookup_dns.

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 states what the tool does but gives no explicit guidance on when to use it versus alternatives, nor any prerequisites or exclusions. Usage is only implied by the purpose itself, which is a gap for an agent choosing between this and the other dns_intelligence 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 behavioral burden. It says nothing about whether checks perform network requests, how long they take, rate/permission requirements, or that only the 200-host cap applies; the httpProbe fetching behavior is disclosed only in the schema, not here.

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 with no filler; the parenthetical example earns its place. It is short but could have absorbed one more clause of substance at negligible length cost.

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 annotations and no output schema, the description must carry the operational context, yet it omits what a result contains, whether checks are safe/read-only, the batch limit, and any latency implications of HTTP probing. For a 2-parameter security-scan tool this leaves real 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 100%, so the baseline is 3. The description adds only that the hostnames are 'specific' and come from DNS zones or certificate logs; it never mentions the httpProbe toggle or the 1-200 host bounds, so it does not go 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?

States a specific verb and resource: 'Check specific hostnames ... for subdomain takeover'. The security intent (subdomain takeover) is distinctive and separates it from sibling lookup/enumeration tools, though no sibling is named explicitly.

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 parenthetical '(e.g. from your DNS zone or certificate logs)' implies where the host list comes from, which hints at when to use it. However, it never states when to prefer this over enumerate_subdomains, lookup_dns, or audit_domains, nor any exclusion conditions.

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 the description carries the full burden. It discloses active probing behaviors (lame delegation, anonymous zone transfer/AXFR, open recursion) and the DNSSEC state model (signed/broken/weak), which is useful. But it does not state the safety profile, expected query volume, or whether probes are intrusive or time-consuming.

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 with the verb and resource first, followed by a dense but purposeful detection list. Every clause names a distinct record type or misconfiguration, so little is wasted despite the length.

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 2-param tool with no annotations and no output schema, the description adequately states what is enumerated but leaves the operator without guidance on cost, intrusiveness, or how it differs from sibling DNS 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 coverage is 100%, so both parameters are already documented in the schema. The description's mention of zone transfer, open recursion, and lame delegation loosely maps to nameserverProbe but adds no syntax or format detail beyond the schema. 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?

States a specific verb (enumerate) and resource (DNS records) plus an explicit inventory of what it inspects: SPF, DMARC, DKIM, MTA-STS/TLS-RPT, MX, DNSSEC, CAA, nameservers. However, it does not differentiate itself from siblings like check_email_security (which also covers SPF/DMARC/DKIM) or lookup_dns, so the agent cannot tell which to pick without opening the schemas.

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?

There is no explicit when-to-use statement, no prerequisites, and no mention of alternatives. The overlap with check_email_security and lookup_dns makes the absence of routing guidance a real gap.

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

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

With no annotations, the description carries the full burden. It usefully discloses the method and that takeovers are confirmed via 'verified fingerprints', but says nothing about network dependence, rate limits, runtime, third-party exposure, or return format — gaps for a multi-source network enumeration 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?

One dense but front-loaded sentence that leads with the primary purpose before the takeover-detection secondary function. No filler, though the tail listing of providers is somewhat verbose.

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 3-param enumeration tool with no output schema and no annotations, the description covers inputs and behavior reasonably. It omits output shape and operational constraints, but the core capability set is conveyed.

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%, so all three parameters are fully documented in the schema. The description's mention of CT logs and provider CNAMEs loosely maps to the params but adds no syntax or format details beyond what the schema provides; 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?

States a specific verb and resource ('Find subdomains') and details its two data sources plus takeover detection. However, it does not distinguish itself from the sibling check_takeover, which appears to cover the same takeover capability, leaving some ambiguity about which tool to pick.

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?

There is no explicit when-to-use, when-not-to-use, or alternative guidance. The description never mentions enumerate_dns, lookup_dns, or check_takeover, so an agent must infer routing from the sibling names alone.

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

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

With no annotations, the description carries the full behavioral burden and discloses almost nothing: no mention of network access, rate limits, timeouts, error behavior for non-existent domains, or caching. Only the intent of the operation is conveyed.

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 with zero filler. The verb and scope appear immediately, which is exactly what an agent needs for scanning.

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 parameters are fully documented in the schema, but there is no output schema and no annotation coverage, so the agent gets no signal about what the lookup returns (records, TTLs, error shapes) or how it relates to the sibling DNS tools. Adequate but with clear 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 100%, and the enum on 'type' already enumerates all supported record types, so the baseline is 3. The description's 'specific record types on a domain' merely restates the two parameters without adding format or interpretation guidance.

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?

States a specific verb (lookup) and resource (DNS records) plus the scope (specific record types on a domain). The word 'targeted' hints at a contrast with bulk enumeration, but no sibling such as enumerate_dns is named, so the agent must infer the boundary.

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 when-to-use or when-not-to-use guidance, and no alternative tools are mentioned. Siblings like enumerate_dns, enumerate_subdomains, check_email_security and check_takeover clearly overlap in the DNS space, yet the description gives the agent nothing to route between them.

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 disclosure burden. 'List' implies a safe read-only operation, but the description does not state the return shape, whether the list is static or dynamically discovered, or what detector identifiers look like. It conveys only that detectors exist to be enumerated.

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 with no filler, scoping the resource precisely. Nothing could be removed without losing information.

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

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

For a parameterless read-only enumerator with no output schema, the description adequately conveys what the tool returns (the scanner's PII and credential detectors). It is slightly thin on the form of the returned items, but nothing blocks correct 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?

The tool has zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool is 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?

States a specific verb ('List'), resource ('detectors'), and the scope of that resource ('PII and credential detectors this scanner runs'). This cleanly distinguishes it from the sibling storage tools like document_scanner__scan_document and scan_base64, which perform scans rather than enumerate detectors.

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?

Usage is implied by the verb 'list' — an agent would call it when it wants to know what detectors are available. However, there is no explicit when-to-use guidance, no statement of when not to call it, and no named alternative such as scan_document for actually running a scan.

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

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

With no annotations, the description carries the full behavioral burden. It does add one real trait — 'the type is detected from the bytes' — clarifying that no explicit document-type argument is needed. But it says nothing about whether scanning is read-only, how large inputs are handled, or rate limits, leaving substantial behavioral gaps.

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 tight sentences with the core purpose front-loaded and the auto-detection note second. There is no filler and the examples earn their place by clarifying the input format.

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 5-parameter tool with no annotations and no output schema, the description is on the thin side: it never explains the shape of findings, whether it is safe/read-only, or how the opt-in detectors interact with the default scan. Adequate but with clear 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 80%, so the schema already documents data, ocr, include, and languages. The description adds no parameter-level detail beyond confirming base64 input, which the schema already states. 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?

States a specific verb+resource ('Scan a document given as base64') and the target ('PII and credentials'). The 'as base64' qualifier implicitly separates it from the sibling document_scanner__scan_document, which presumably takes a path, but it never names that sibling explicitly.

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 parenthetical 'an attachment, an image a tool returned' gives concrete scenarios where base64 input arises, which is useful routing context. However it offers no explicit when-not guidance and never compares itself to scan_document or the other scan_* siblings, leaving the choice to inference.

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

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

With no annotations, the description carries the full behavioral burden and does disclose non-obvious mechanics: PDFs are read from the text layer, images/scanned pages go through OCR, OCR languages default to Turkish and English. It omits whether the operation is read-only/non-mutating, whether tesseract.js must be installed, and what happens on unreadable files.

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 detector scope and file types, followed by the parsing mechanics. No filler, no repetition, and each clause contributes distinct 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?

There is no output schema and no annotations, so the description should also orient the agent on what a scan returns (finding shape, severity, counts, error handling). It covers inputs and detection coverage well but says nothing about results, leaving the agent to invoke blind.

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%, so the baseline is 3; every parameter (path, ocr, include, languages) already has a description in the schema. The prose restates and lightly contextualizes the OCR/language behavior but adds no syntax, format, or default information the schema does not already carry.

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?

Specific verb ('Find PII... and credentials') plus concrete resource types (PDF, image, text file on disk) and a clear motivating context ('before it is given to an LLM'). The phrase 'on disk' implicitly separates it from document_scanner__scan_base64, but that sibling is never named, so differentiation is inferential rather than explicit.

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?

Usage context is implied by 'before it is given to an LLM', which tells the agent the intent, but there is no explicit when/when-not guidance and no routing to scan_base64 (for in-memory/base64 input) or list_detectors (to enumerate what can be found). The agent must infer the boundary.

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 the description carries the full burden, and it does convey that the listing is exhaustive ("every ... check") for this auditor only. It says nothing about side effects, permissions, ordering, or what a listed check looks like, so a read-only, low-risk profile must be assumed rather than stated.

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 clause with the verb and scope front-loaded and no filler. Nothing to trim.

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 and no annotations, the description is the only source of information, and it omits the shape of a returned check (name, ID, severity, category) that an agent would need to chain into a scan call. Adequate for a trivial zero-arg lister, but not 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 tool takes zero parameters, so per the baseline there is nothing for the description to disambiguate. No missing parameter documentation exists to compensate for.

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?

Specific verb ("List") plus a bounded resource ("every elicitation check this auditor runs"). The domain noun "elicitation" separates it from the many sibling list_patterns tools belonging to other auditors, though it never explicitly contrasts itself with elicitation_auditor__scan_text/file/directory.

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 when-to-use guidance at all: nothing says to call this before running a scan, or that it is a discovery/introspection aid. The family naming convention lets a careful agent infer the scan-vs-list split, but the description itself provides none of it.

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 mentions recursion but does not disclose read-only status, side effects, output format, rate limits, or error behavior for a scanner that may process large directory trees.

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 with no redundant clauses. It communicates the core action, scope, and target efficiently.

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 has no annotations and no output schema, so the description should explain return values and behavior. It only states what is scanned, not what findings look like or how results are returned, leaving an important gap for an agent.

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% and all four parameters (path, exclude, include, maxFiles) have clear schema descriptions. The description adds no parameter-level information beyond the schema, so the baseline 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?

States a specific verb ('scan'), resource ('directory of MCP server source'), scope ('recursively'), and target ('elicitation anti-patterns'). It does not explicitly name sibling tools like scan_file or scan_text, but the directory scope distinguishes it from single-file or text scanners.

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 choose this over scan_file or scan_text, nor any prerequisites or exclusions. The description only states what the tool does, leaving the agent to infer usage from the tool name and schema.

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 behavioral burden, and it discloses almost nothing. It does not say the scan is read-only/non-mutating, does not describe what findings or severity output looks like, and gives no indication of cost, rate limits, or file-size constraints.

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 short sentence with the target (single file) front-loaded and zero padding. It is efficient, though its brevity borders on under-specification rather than tightness.

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 one-parameter scanner with no annotations and no output schema, an agent still lacks a description of what the scan returns (findings? pattern matches? severity?) and whether the operation is safe/read-only. The definition is minimally workable but not complete given the structural metadata present.

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%, and the single 'path' parameter is already documented as 'Absolute or relative path to the file to scan' in the schema. The description adds only the confirmation that the path targets a single file, so the 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?

Names a specific verb (scan), a specific resource (a single file), and the target domain (elicitation anti-patterns). The word 'single file' implicitly separates it from the sibling scan_text and scan_directory tools, but it never names them explicitly.

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?

Usage is only implied: an agent can infer this is for when the content already lives on disk rather than in a string. There is no explicit when-to-use guidance, no prerequisites, and no routing to scanner vs list_patterns or directory 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 does useful behavioral work by enumerating the five anti-pattern categories that constitute a finding, but says nothing about severity levels, finding output shape, or limits, which matters for a scanner with no output schema.

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 whose colon-delimited list consists entirely of distinct, load-bearing pattern descriptions rather than filler. Slightly dense, but every clause maps to a real detection category.

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 scanner with an empty annotation set and no output schema, the description covers the detection scope adequately but leaves the return contract unspecified — an agent cannot tell what a finding looks like or how 'label' surfaces in results. That is a meaningful gap given the absence of structured coverage.

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% and both parameters ('label', 'content') are documented in the schema itself, so the description need not restate them. It adds no extra syntax or format guidance for either parameter, so the baseline 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?

States a specific verb and resource ('Scan MCP server source') and enumerates the exact elicitation anti-pattern classes it detects, which clearly sets it apart from other auditors' scan_text tools. It does not, however, distinguish itself from its own siblings scan_file/scan_directory beyond the word 'text' in the name and the 'content' parameter.

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 establishes the domain context (elicitation anti-patterns from the 2026-07-28 spec) but gives no explicit when-to-use vs when-not guidance, and never mentions the sibling alternatives scan_file, scan_directory, or list_patterns. Usage is only implied by the tool name and the requirement for a 'content' string.

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 carry the full behavioral burden. It usefully discloses that every probe is canary-based and safe, which is key context. However, it does not explicitly state that this listing call has no side effects or that it does not execute any probes against a target.

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 tightly written sentences with zero waste. The primary action and return format are front-loaded, and the safety caveat follows naturally.

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 zero-parameter listing tool with no output schema, the description is largely sufficient: it says what is listed and how it is grouped. It could go slightly further by noting that each probe entry includes identifying metadata, but the low complexity makes this a minor gap.

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

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

The tool takes zero parameters, and schema coverage is 100% (empty object). Per the baseline rule for zero-param tools, a 4 is appropriate; the description adds no parameter detail because none is needed.

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 states a specific verb (List) and resource (red-team probes), and specifies the return grouping (by category). It implicitly distinguishes itself from the sibling run_probe_suite by being a listing tool, but the phrase 'this tool can run' is slightly ambiguous about which tool actually executes probes.

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?

Usage is only implied: an agent can infer this is for discovering available probes, likely before invoking run_probe_suite. There is no explicit when-to-use statement, no mention of the sibling run tool, and no exclusions or prerequisites.

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?

Adds meaningful context beyond the annotations: every probe consumes API quota on the target, probes never request genuinely harmful content, and success is measured by reproduction of a random one-time token. The annotations declare openWorldHint/readOnlyHint=false, but the description supplies the cost and mechanism detail those hints cannot.

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

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

Three sentences, front-loaded with the action, followed by the safety constraint and then the mechanism. Every sentence carries distinct 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?

For a tool with a complex nested target config and no output schema, the description covers what is being tested and how success is judged (canary token). It omits the shape of the returned findings, but the safety, cost, and success-criterion context make it largely 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 description coverage is 75%, with the target oneOf variants and probeIds/maxProbes/categories all documented in-schema. The description adds no parameter-level detail (e.g., how probeIds and categories interact or what maxProbes defaults to), so the 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?

States a specific verb (run) and resource (canary-based red-team probes) against a named target type (live LLM endpoint or chatbot). An agent can distinguish this from the sibling llm_redteam__list_probes without opening either schema, since it clearly describes active probing rather than enumeration.

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?

Gives strong context: test whether jailbreak/extraction/obfuscation techniques bypass guardrails, with an explicit authorization boundary ('ONLY point this at an endpoint you own or are explicitly authorized to test'). It does not explicitly name list_probes as the discovery alternative, but the when-to-use condition is unambiguous.

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 behavioral burden. It usefully discloses that it does not start any MCP server, but it does not state whether it modifies files, whether it only reads config contents, or what permissions or side effects are involved.

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

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

Two sentences with no wasted words: the first front-loads the OWASP category, action, scope, hosts, and flagging logic; the second adds a key safety constraint. The structure is appropriately sized for a discovery tool.

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 explains the tool's purpose and a key safety behavior, but with no output schema and no annotations, it leaves the return shape and behavioral boundaries unexplained. An agent can tell what the tool does but not exactly what findings it produces or how they are structured.

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%, so all three parameters (home, allowlist, includeContentAudit) are already documented in the input schema. The description references the organization allowlist at a high level but adds no syntax or format details beyond what the schema provides, making the baseline 3 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?

States a specific verb (discover), resource (MCP client configs), scope (well-known host paths with named hosts), and outcome (flag non-allowlisted servers as Shadow MCP). This clearly distinguishes it from siblings like scan_file and list_host_config_paths, which cover narrower or different actions.

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 OWASP MCP09:2025 reference and 'Shadow MCP' framing imply the use case (auditing MCP client configs against an allowlist), but the description never states when to choose this tool over siblings such as scan_inventory, scan_directory, or list_host_config_paths. No explicit exclusions or alternatives are 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 behavioral burden. 'List' implies a read-only, non-destructive operation and it discloses the OS-scoped, MCP09-relevant nature of the paths, but it does not clarify whether it returns only paths that exist on disk or the canonical candidate list, nor any return/format 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?

A single front-loaded sentence with zero waste; the verb and resource come first and the qualifier follows. Nothing needs trimming or reordering.

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 no-annotation, no-output-schema, one-parameter tool the description covers the essentials of what it lists, but it leaves the return shape and the distinction between 'checked' vs 'existing' paths unstated. Adequate but with visible 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 100%, so the single 'home' parameter ('Override home directory') is already fully documented in the schema. The description adds no further meaning about the parameter, so the baseline 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?

States a specific verb (List) and resource (well-known MCP client config paths), with scope qualifiers ('on the current OS') and ties itself to shadow MCP09 discovery. It is clearly a discovery/listing tool, distinguishable from scan_* siblings, though it does not name which sibling it complements (e.g., discover_shadow_mcp).

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?

Usage context is implied by 'this auditor checks during shadow (MCP09) discovery,' which suggests it is a reconnaissance step before scanning, but there is no explicit when-to-use, when-not-to-use, or named alternative. An agent must infer its place in the workflow.

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 return content (each check carries its OWASP MCP Top 10 tags), which is useful, but it does not state that the call is read-only, requires no auth, or has side effects, and there is no output schema to fall back on.

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 names the verb first, then the four check categories, then the tagging detail. No filler and nothing buried.

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 zero-parameter enumeration tool with no annotations or output schema, the description conveys what will be listed and that results are OWASP-tagged. Only the exact fields returned (e.g., pattern IDs vs. human-readable names) are left unspecified, a minor gap.

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

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

The tool takes zero parameters, so the baseline of 4 applies; there is nothing for the description to document beyond what the empty schema already shows.

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?

States the verb (List) and the specific resource: the MCP config, agent skill, shadow-MCP discovery, and cross-server shadowing checks for this auditor, plus the OWASP tagging. It is clearer than a bare 'list patterns', though it never names a sibling to distinguish itself from the many other *_list_patterns 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?

No when-to-use, when-not-to-use, or alternative is given. With roughly thirty sibling list_patterns tools in the environment, the description leaves the agent to infer from the tool name alone that this enumerates this auditor's checks rather than another auditor's.

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 usefully discloses the detection taxonomy the agent will get back, and 'Scan ... for' strongly implies a non-destructive read. However it says nothing about whether the content is executed, network access, auth needs, or result shape, leaving real behavioral gaps for an unaided 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?

One front-loaded sentence with the verb and input first and the check list after. Every listed item (unpinned packages, secrets, wildcard auto-approve, unauthenticated endpoints, typosquats) earns its place as distinct scope 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?

No output schema exists, so the enumerated detection categories usefully stand in for describing what findings are produced. With no annotations and a trivial two-parameter schema, the description is nearly sufficient; only return format, severity, and pagination are left unspecified.

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%, so both 'label' and 'content' are already documented. The description's 'JSON string' phrasing loosely corroborates the content parameter but adds no format, size, or parsing constraints beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

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?

States a specific verb (scan) and resource (an MCP client config JSON string), naming the concrete client formats it accepts (Cursor mcp.json, Claude Desktop, Windsurf, VS Code) and enumerating the defect classes it targets. The 'JSON string' input hint implicitly separates it from the sibling scan_file/scan_directory tools without needing to open a schema.

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 list of detection categories implies when the tool is useful (auditing MCP client configs), but there is no explicit when-to-use statement, no prerequisites, and no routing to alternatives such as scan_file for a path or scan_directory for a tree. Usage is inferable but not stated.

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, and it does disclose two useful traits: it only reads/audits (no server startup) and a directory scan additionally compares skill names. It omits other behavioral facts an agent would want — whether scanning is recursive, what happens on huge trees (it caps at maxFiles), and whether anything is mutated.

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 short sentences, front-loaded with the core action and target file list, with zero filler. The 'compares skill names' clause is slightly abrupt but still earns its place as a behavioral note.

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 no-annotation, no-output-schema scan tool with a fully documented 3-param schema, the description covers what it targets and that it does not execute servers. It leaves gaps around recursion scope and what an audit returns, which matters for an agent deciding between this and the file/inventory variants.

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% and all three parameters (path, exclude, maxFiles) are documented in the schema. The description adds no parameter-level detail such as recursion behavior or how exclude/maxFiles interact with the scan, so this is the baseline case where the schema does the work.

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 gives a specific verb-plus-resource: find named config files (mcp.json, mcp_config.json, claude_desktop_config.json, SKILL.md) under a directory and audit each one, plus an extra behavior (comparing skill names). This clearly distinguishes it from sibling file/text scanners in the same family, but it does not explicitly contrast itself with mcp_config_auditor__scan_file or scan_inventory, so it stops short of full sibling routing.

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?

Usage is implied (call it when you have a directory rather than a single file), and the negative clause 'Does not start any MCP server' rules out an expected-but-unwanted behavior. However, it never states when to prefer this over scan_file, scan_text, or scan_inventory for the same config content.

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, and it does disclose one genuinely behavioral trait beyond the schema: the tool switches to skill-scanning mode based on the filename (SKILL.md). However, it omits the read-only nature, what the scan produces, and any error/permission 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?

A single, dense sentence with zero filler, and the primary purpose ('Scan one MCP client config file') is front-loaded ahead of the qualifying clause about SKILL.md.

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?

There is no output schema and no annotations, so the description would ideally explain what the scan returns or detects (e.g., risky MCP config patterns). It fully covers the simple one-argument call signature but leaves the result semantics unstated, making it minimum viable rather than 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 description coverage is 100% with a single documented 'path' parameter, so the baseline is 3. The description hints that the path may point either to a config file or to a SKILL.md, but adds no format, extension, or path-resolution detail 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 gives a specific verb ('Scan') and a specific resource ('one MCP client config file'), and further clarifies the alternate target ('a SKILL.md agent skill'). This distinguishes it from scan_directory, which implies scanning many files, but it does not explicitly name the sibling alternatives (scan_config_text, scan_skill_text).

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?

Usage is only implied: 'one ... file' suggests this is the single-file entry point versus the directory variant, but the description never states when to choose this over mcp_config_auditor__scan_config_text or scan_skill_text, nor any prerequisites. Adequate but leaves the agent to infer selection.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that the tool 'does not connect to those servers', i.e. it is a pure offline computation with no network side effects, but it says nothing about determinism, cost, or what the analysis produces.

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 short sentences, front-loaded with the detection goal, then the input expectation, then the non-connection caveat. No filler.

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, required input provenance, and the key behavioral caveat for a one-parameter tool. With no output schema, a sentence on the shape of the shadowing findings would have closed the remaining gap.

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

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

Schema description coverage is 100% and the single parameter carries an inline JSON example, so the schema already fully defines the input. The description reinforces what belongs in the inventory (tool names and descriptions per server) but adds no syntax or format detail beyond it. Baseline 3.

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?

States a specific verb+resource: 'Detect cross-server tool shadowing from an inventory of tool catalogs.' The input mode (pre-collected inventory rather than live servers) distinguishes it from the many scan_file/scan_directory siblings and from discover_shadow_mcp, but it never names those alternatives explicitly.

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?

Gives a clear precondition ('Pass the tool names and descriptions already collected from each installed server'), which implies you must have already gathered the catalogs. However, it names no alternative tools and states no explicit when-not, leaving the routing decision between this and discover_shadow_mcp or scan_file to inference.

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

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

With no annotations, the description carries the full burden. It discloses the four detection categories, which is useful behavioral context, but says nothing about output/findings structure, whether the scan is purely read-only, or any safety/authorization profile. For a scanner this is adequate but not rich.

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

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

Two tight sentences. The first front-loads what is scanned and what is detected; the second immediately handles the alternative routing 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?

The description is complete for selecting and invoking the tool: it names the input type and the detection targets. Because there is no output schema, it could say more about the findings format, but the label parameter's schema note ('shown in findings') partially covers that gap.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema. The description adds no parameter-specific syntax or format details beyond implying that 'content' is raw SKILL.md text, making the baseline 3 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?

States a specific verb and resource: 'Scan one agent SKILL.md (YAML frontmatter plus body)'. It also enumerates the exact issue classes it detects, and its closing sentence distinguishes it from the directory-scan sibling by noting when name collisions require the latter.

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 clearly frames this as a single-file text scan and explicitly names the alternative for cross-skill name collisions: 'Name collisions across skills require a directory scan.' It does not explicitly contrast with scan_file or scan_config_text, but the single-SKILL.md scope is clear enough to guide selection.

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

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

With no annotations, the description carries the full burden, but it does disclose that results are 'grouped by category' and that this is a pure enumeration of detectable patterns rather than a scan. It omits any return format, pattern ID scheme, or severity/confidence metadata an agent would want before building on the output.

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 compact sentence with no filler, front-loading the verb and resource and closing with the grouping behavior. Every clause 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?

There is no output schema, so the description is the only source of return-value information, and 'grouped by category' is a thin hint about shape. It does not say what fields each pattern entry carries, which limits how confidently an agent can consume the result.

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

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

The tool takes zero parameters, so there is nothing for the description to clarify; the schema itself is trivially complete. Baseline 4 applies for a parameterless tool.

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 states a specific verb ('List') and resource ('MCP server security patterns that the auditor can detect'), scoped to this auditor's domain. This distinguishes it from the numerous sibling scan_* tools, though it does not explicitly contrast itself with mcp_server_auditor__scan_file/scan_directory.

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?

There is no when-to-use guidance, no mention of alternatives, and no stated workflow (e.g., 'call this first to learn pattern IDs before scanning'). Usage is only implied by the verb 'List'.

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 usefully discloses an automatic behavior (skipping node_modules, .git, dist, binaries), which an agent could not learn from the schema. It leaves unstated whether it is a read-only operation, any resource/time limits, and what the scan emits.

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 tight sentences with the core purpose front-loaded and the skip behavior appended as useful detail. No filler; slightly under-developed for the tool's complexity.

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