SecurityScan

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 the tool works offline with no external service, implying that the config content is not sent elsewhere, and describes exactly what categories of risks it scans for. It does not explicitly say 'read-only' or describe side effects, but 'Audit' plus offline behavior strongly implies a read-only analysis.

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 compact and front-loaded: it states core behavior first, then the offline guarantee, then the detection list. Every sentence contributes meaningful selection information. The bullet-style list of risk categories is dense but not padded.

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 single-parameter tool with a 100% documented schema, this description provides enough to understand what the tool does, what input it expects, and which security concerns it covers. The presence of an output schema means the return-value explanation is not required. No critical operational fact, such as the 'no external service' guarantee, 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 input schema already documents the only parameter, config_json, fully, including that the full JSON content should be pasted and not the file path. Since schema description coverage is 100%, the description does not need to add parameter details. The tool description does not add new parameter-level nuance, which is acceptable under 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?

The description clearly states a specific action ('Audit an MCP client configuration') with a well-defined purpose: identifying security risks. It also lists concrete risk categories (tool poisoning, hardcoded credentials, unpinned packages, etc.), making the tool's scope easy to grasp. It slightly misses the fifth-star criterion because it does not name or distinguish itself from sibling tools like full_stack_audit or scan_secrets.

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 'works offline, no external service required' gives a clear usage constraint and hints at when this tool is appropriate. The detection list helps an agent decide if the config audit covers the relevant risk area. However, it does not explicitly state when NOT to use it or which sibling tools are better alternatives for narrower 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 burden of behavioral disclosure. It names the checks performed and the trust-score output, which is helpful. However, it does not explicitly mention that the tool will make network requests to the supplied endpoints, nor does it describe failure/availability behavior or consequences of the check.

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

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

The description is a single, well-formed sentence with the verb and resource first, followed by a compact list of concrete outputs. Every phrase adds information; nothing is redundant 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?

The tool is simple, has a single required parameter, fully covered schema, and an output schema, so the description covers the essential invocation context. The main gap is that it does not explain how this tool relates to the sibling scanning/auditing tools, which could lead to suboptimal tool 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?

The endpoint parameter is fully described in the schema with an example and a clear list-of-URLs type. The description adds only the relational context ('your agent's external dependencies') but does not need to restate the schema, so the baseline of 3 is appropriate.

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

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

The description clearly identifies the action ('Check'), the target ('health of your agent's external dependencies'), and the specific outputs it produces ('uptime, SSL validity, blacklist status, and a trust score 0-100'). It is more specific than the tool name, but it does not explicitly differentiate itself from sibling tools such as network_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?

No guidance is given about when to use this tool versus alternatives like network_scan, scan_skill, or audit_mcp_server_config. The description implies a context—checking dependencies your agent relies on—but provides no exclusions or selection criteria.

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 more behavioral weight and it delivers useful details: it correlates results, produces one prioritized report, and degrades gracefully when inputs or services are missing. It does not explicitly disclose side effects of network scanning, but the network_authorized parameter schema already enforces the consent gate.

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 carry all the necessary content: the first sentence enumerates both the capability and the final output, and the second explains guardrails around missing inputs. There is no filler, no fluff, and no repetition of schema details.

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

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

For a complex composite tool with six optional parameters and five sibling tools, the description covers the modular behavior, the output artifact, and the graceful degradation well. The output schema covers the return shape, and the remaining gap is only the explicit relationship to the sibling single-purpose 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 the baseline is 3, but the description adds meaning beyond param descriptions by saying that any subset of optional inputs is acceptable and each missing section is skipped gracefully. This reduces ambiguity about composing the optional parameters and tolerates empty/partial calls.

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 composite operation and enumerates five concrete sections: MCP config auditing, dependency health, untrusted skill analysis, network gateway scanning, and secrets/PII payload scanning. It clearly distinguishes this tool from the single-focus siblings because it explicitly promises to correlate all results into one prioritized report.

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 says to use this tool for a complete security posture check in one call and explains that partial input is fine because missing sections are skipped gracefully. It stops just short of explicitly stating when to prefer a sibling tool for a single-purpose check, so it has context but no explicit exclusion.

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?

There are no annotations, so the description carries the full behavioral disclosure burden. It meaningfully reveals that the scan is active, that an autonomous AI agent decides follow-up probes, and that only authorized targets should be scanned. This provides useful transparency beyond the literal parameter names, even if potential side effects like generated traffic or triggering alerts are not mentioned.

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

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

The description is two short sentences with no filler. It front-loads the core purpose, adds the defining autonomous behavior in the same sentence, and closes with a necessary legal/safety caveat. Every part earns its place.

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

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

Given the presence of output schema, full parameter schema coverage, and the description's inclusion of purpose, autonomy, and authorization, the definition is nearly complete. The main minor gap is not explicitly explaining when to use this scan tool instead of sibling security-scanner 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 description coverage is 100%, so the baseline is 3. The description does not need to restate parameter meanings; the schema already documents target, scan_type, and authorized. The parenthetical ActiveScanner context indirectly supports the scan_type parameter but does not add essential missing semantics.

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 purpose: performing an active security scan of a device or host, with an autonomous AI agent deciding follow-up probes. It clearly identifies the target resource and the operational concept, though it does not explicitly contrast itself with sibling tools like scan_secrets or scan_skill.

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 this tool is for active network scanning and firmly imposes an authorization prerequisite. However, it does not explicitly state when this tool should be chosen over alternatives, nor does it mention which sibling tools would be better for non-network security 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, the description carries the full behavioral disclosure burden and delivers strongly. It states the detection runs in-process offline with no API key (pure regex + Luhn check, no network), discloses that a configured SecretScan backend reroutes the scan and 'persists an audit record,' and describes the redaction token format. This gives an agent accurate expectations about execution mode, side effects, and network dependency.

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 bulk of the description is operational and worthwhile, with the core purpose front-loaded in the first sentence. All-caps emphasis like 'WORKS OFFLINE with NO API key' and 'BEFORE' adds assertiveness rather than information, and the sentence 'Catches the #1 real-world agent incident' is context rather than instruction — minor redundancy that keeps it from a perfect score.

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?

An output schema exists, so return values need no explanation, and the description covers the essential operational context: detection approach, execution mode (offline vs backend-routed), backend auditing, and the redact toggle's effect. Minor gaps remain, such as what happens when no secrets are found or how report-only output is structured, but these are partially covered by the output schema and the tool's simple two-parameter surface.

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% — text and redact are already documented in the input schema, including the redaction token examples. The description reinforces that behavior ('return a redacted copy', token names) but adds no new parameter semantics beyond the schema, so the baseline 3 is appropriate.

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

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

The description states a specific verb and resource: 'Scan a text payload (a prompt, an outbound API body, a file's contents) for secrets and PII ... and return a redacted copy.' This makes the operation's intent and scope unmistakable. It also positions the tool against its siblings by naming the exact incident class — content leaking to an LLM or external API — which differentiates it from network_scan and scan_skill without opening their 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?

The description gives a clear, actionable 'when to use': any payload 'before it leaves for an LLM or external API,' framing it as the guardrail for the #1 real-world agent incident. It does not, however, explicitly state when not to use it or name alternative sibling tools, so it stops short of a complete 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 responsibility of conveying behavior. It indicates that this is an analysis/scan rather than an installation, and names the categories checked, but it does not explicitly state whether the tool downloads the skill, executes it, or only inspects it, nor what limitations apply.

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

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

The description is one tight sentence that front-loads the action and key security concerns. Every element contributes: the subject, the danger categories, and the timing advisory. There is no filler or redundant phrasing.

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 only one well-documented parameter and an output schema, so the description does not need to explain return values. It covers the essential context, including the security concerns and the pre-install timing, though a brief note on non-execution or side-effect-free behavior would make it fully complete.

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

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

The single parameter skill_url is already fully documented in the input schema with an example, giving 100% schema description coverage. The description repeats the concept of analyzing a skill but adds no material semantic detail beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb (Analyze), a clear resource (AI agent skill), and concrete objectives (prompt injection, malware patterns, OWASP LLM Top 10). It also adds the important context of running it before installation, which clearly distinguishes it from sibling scanning tools like network_scan, scan_secrets, or audit_mcp_server_config.

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 'BEFORE installing it' gives a clear when-to-use signal, and the threat categories make it evident this is a skill-safety pre-flight check. It implicitly differentiates itself from sibling tools that target other artifact types, but it does not explicitly list exclusions or when to prefer a sibling tool.

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

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

With no annotations, the description carries the behavioral disclosure burden and does so well: it states that the tool returns a payment URL and a PENDING API key that activates automatically after payment clears. It does not cover edge cases like repeated checkouts or failed payments, but the core transaction flow is transparent.

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

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

The description is two compact, front-loaded sentences: the first states the action and purpose, and the second explains the return values and activation behavior. There is no filler, redundancy, or unnecessary restating of schema fields.

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 full schema coverage and an output schema, the description covers the purchase flow, return contract, and post-payment activation. A more explicit reference to securityscan_pricing for users only checking prices would make it fully complete.

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

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

Schema description coverage is 100%, so the schema already documents tier, email, and existing_key. The description adds no parameter-level meaning beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description opens with a specific verb and object: 'Start a Stripe checkout to buy a SecurityScan tier' and clearly frames this as agent-native sales. It is easily distinguished from sibling scanning/audit tools because it is the only one focused on checkout and purchase.

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 implies the trigger context: use this when the user wants to buy or upgrade a SecurityScan tier, and it emphasizes 'no other setup step.' It does not explicitly name securityscan_pricing as the alternative for pricing-only questions, so it stops short of full routing 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 burden and delivers: 'Fully offline, no API key required' discloses network and authentication behavior, and the Returns clause discloses the payload shape. For a zero-parameter read-only catalog this is strong disclosure. It does not state data freshness or explicitly assert zero side effects, but nothing in the text implies mutation.

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 tightly written and front-loaded: purpose and audience in the first sentence, behavioral constraints in the second, return contents in the third. The Returns clause is slightly redundant given the existing output schema, but it adds the 'how to buy' pointer and keeps the description scannable. 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?

For a tool of minimal complexity (0 params, no annotations, output schema present), the description is complete: it states what the tool is, who it serves, its connectivity/auth posture, and the shape of what it returns, and it hints at the next step ('how to buy') toward the checkout sibling. Nothing an agent needs in order to call 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 and schema description coverage is trivially 100%, so the rubric's 0-param baseline of 4 applies. The description reinforces that no input is needed by presenting the tool as a self-contained static fact sheet ('Fully offline, no API key required'). A 5 would be unwarranted since there are no parameters for the description to actually document.

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 defines a specific resource and scope: 'SecurityScan catalog: tiers, prices, quotas and the evidence behind the product'. It frames the audience and use ('the fact sheet an agent needs to evaluate or recommend a purchase'), and implicitly distinguishes from sibling securityscan_checkout by situating this tool at the evaluation stage. The 'Returns: JSON with...' clause makes the retrieval semantics unambiguous even without an imperative verb.

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 'the fact sheet an agent needs to evaluate or recommend a purchase to its user' gives an explicit when-to-use context: purchase evaluation and recommendation. The mention of 'how to buy' in the return payload hints that actual purchasing belongs elsewhere, namely the sibling securityscan_checkout. However, it never names an alternative explicitly or states when not to use this tool, so it stops short of a 5.

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