Power Strip Security

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

Adds behavior the annotations cannot express: 'Costs US$0.005 in USDC on Base (x402)' discloses a payment/auth prerequisite that would otherwise fail silently, and 'nothing is executed' preempts the obvious fear about submitting malicious code to a security scanner. Consistent with readOnlyHint=true, destructiveHint=false, openWorldHint=true (fetches a 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?

One front-loaded sentence: purpose, then threat list, then input modes, then cost and safety. Dense but every clause carries information; the run-on structure with parentheticals is slightly cramped but not wasteful.

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

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

Covers the operation, invocation modes, cost, and the no-execution guarantee, and limits (max 50 files, 256 KB) live in the schema. What is missing is any hint of the response shape — verdict, findings, severity — which matters because there is no output schema to fall back on.

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 little extra. 'Paste the files or give one URL' does convey that files and url are mutually exclusive input modes, which the schema does not state, but the pinned/fingerprinting parameter is left entirely to 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 ('Check') against precisely enumerated resources (SKILL.md with scripts and references, AGENTS.md, CLAUDE.md, .cursorrules) and enumerates what it looks for: prompt injection, curl | bash, encoded commands, credential theft, exfiltration, hardcoded keys, persistence. The resource scoping alone differentiates it from audit_mcp_server, and the detection list goes well beyond a restatement of the name.

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?

'before loading it' gives a clear trigger moment, and 'Paste the files or give one URL' tells the agent how to invoke it. It stops short of naming siblings (audit_mcp_server, check_prompt_injection) or stating when not to use it, so the agent must infer routing from the target file type.

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?

Goes well beyond the annotations: it confirms the URL path lists tools read-only, discloses a concrete cost (US$0.01 USDC on Base via x402) with the payment rail, and states the failure-billing rule ('servers that cannot be listed are not charged'). It also explains that pinned fingerprints are for detecting changed tools (rug pulls), which is behavioral context the readOnlyHint/openWorldHint annotations do not convey.

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 tight sentences, front-loaded with the purpose and threat model before the input modes and pricing. Every clause (including the pricing and no-charge rule) carries decision-relevant information; nothing is padding.

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 input modes, cost, failure billing and the detection scope for a 4-parameter tool with no required fields. It never says what the audit result contains (verdict shape, per-finding detail), which matters somewhat since there is no output schema to fall back on.

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 real meaning: it establishes the either/or relationship between url and tools (mutually exclusive input modes, which the flat schema does not express) and explains what 'pinned' is for. It does not clarify how 'instructions' interacts with the pasted-tools path.

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 an MCP server for tool poisoning') and enumerates the concrete classes of problems it detects: hidden instructions, secrecy, sensitive-file access, cross-tool shadowing and rug pulls. The resource (an MCP server) is inherently distinct from siblings audit_skill, read_url and scan_content, so an agent can route correctly 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?

'before you connect' gives explicit timing context, and 'Pass its URL ... or paste its tools' tells the agent which input modes are valid. It stops short of naming when to prefer audit_skill or scan_content instead, so no exclusion guidance is present.

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?

Annotations only cover safety (readOnly, openWorld, not destructive); the description adds substantial operational context beyond them: the exact return payload (risk report plus cleaned text wrapped as untrusted data), a hard size ceiling of 256 KB, and a paid-call requirement of US$0.002 in USDC on Base via x402. Payment and size constraints are exactly the kind of hidden behavior an agent must know before invoking.

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: what it scans, what it returns, then cost and size limit. Each sentence carries distinct information and the most decision-relevant constraint (only scan content you already have) is front-loaded.

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

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

With no output schema, the description takes on the burden of describing the return value and does so (risk report plus cleaned text marked untrusted). Combined with the payment and size disclosures, an agent has everything needed to decide and correctly invoke 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?

Schema coverage is 75%, so most parameters are already documented in the schema. The description reinforces the content parameter's accepted types and adds a 256 KB limit, but says nothing about the optional url provenance field, the html/text format enum, or the return_text toggle. 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 (scan) and resource (HTML or text) and scopes it to content the agent already holds, which implicitly sets it apart from the fetching sibling read_url. An agent can tell what this does 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?

Parenthetical examples (an email, a document, a tool result) and the phrase 'you already have' give clear context on when this applies, implying read_url should be used first to obtain content. It never names the alternative explicitly or states when not to use it, 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.

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

Goes well beyond the readOnly/openWorld annotations: it discloses the sanitization steps (hidden text, invisible characters, exfiltration links stripped), that a prompt-injection risk report is included, that robots.txt is honored, and — critically — the exact cost (US$0.005 USDC on Base via x402) with the no-charge-on-failure guarantee. That payment and billing behavior is unavailable anywhere in the structured fields.

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 clauses, each load-bearing: capability and return shape first, then safety/sanitization behavior, then cost. No filler or restatement of the tool name.

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

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

With no output schema, the description carries the return-value burden and does so (markdown plus risk report). It also covers billing and robots.txt, leaving only minor gaps such as failure modes or what the risk report contains.

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 only adds the 'public page or PDF' scope for the url parameter and never mentions the format enum (markdown vs. text), so it contributes little beyond what the schema already documents.

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+resource pair (fetch a public web page or PDF) and states the returned artifact (clean markdown plus a prompt-injection risk report), which no sibling tool (scan_content, audit_mcp_server, audit_skill) does. An agent can tell exactly what this produces 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 word 'public' plus 'respects robots.txt' sets a clear precondition, and the sanitization framing implies it is the right choice when the content will be passed to a model. It never names an alternative or states when not to use it (e.g. vs. scan_content for untrusted local content), so it stops short of explicit routing.

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