agents

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

No annotations provided, so description carries full burden. It explains the hybrid approach (deterministic engine + LLM classifier with one-way risk escalation), details all returned fields (risk level, spans, obfuscation, sanitized copy), and explicitly states limitations ('not a proof of safety').

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 well-structured and front-loaded with the main purpose. It includes multiple details but each sentence is informative. Could be slightly more concise, but not 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?

Given the tool's complexity (multi-class detection, sanitization, security context) and no output schema, the description comprehensively covers return values, behavior, and limitations. It also includes cost and a security disclaimer.

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. The description does not add information beyond what is already in the schema's parameter descriptions. Baseline 3 is appropriate.

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

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

The description clearly states the tool scans untrusted content for prompt injections, jailbreaks, etc., and returns a verdict. It distinguishes from sibling tools like secret-scan and sign-guard by specifying its guardrail role for LLM input.

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 explicitly says to use 'before you feed [content] to your own LLM' and lists sources like scraped web content or tool results. It doesn't detail when not to use, but the context and sibling differentiation imply appropriate scenarios.

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

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

No annotations are provided, so the description carries full burden. It mentions generating a summary from a diff but doesn't disclose output format, side effects, or limitations (e.g., diff size).

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 efficient sentence with a brief pricing hint, no redundancy, and all words earn their place.

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

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

Given the tool's simplicity (2 params, no output schema), the description is mostly complete but could mention the output format or constraints like max diff size.

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 description adds value by providing examples for the style parameter (e.g., conventional, changelog, executive), which goes beyond the schema description.

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 'turn' and clearly identifies the input (git diff) and output (PR description or release notes). It inherently distinguishes from sibling tools which are security-focused.

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 for creating PR descriptions or release notes but does not explicitly state when to use versus alternatives or any 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?

No annotations provided, so description carries full burden. It discloses that it never fetches external data, is deterministic, sub-second, returns masked locators and redacted copies, and detects known secret formats (not proof of cleanliness). Also mentions rate limits (200c/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?

Description is comprehensive but somewhat long; however, every sentence adds value. It front-loads the main purpose and key details. Could be slightly more concise, but overall well-structured.

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

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

Given the tool has only one parameter, no output schema, and no annotations, the description fully explains the input, behavior, and return structure (risk level, detected classes with masked locators, redacted copy). No 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?

Only one parameter 'content' with schema description 'The text to scan...'. The tool description adds context by listing example types (diff, config, .env, log line, LLM output), which helps an agent understand the expected input format 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?

Clearly states it's a leaked-credential guardrail for agents, describes target inputs (diffs, configs, .env, etc.) and what it detects (cloud keys, tokens, API keys, etc.). Distinguishes itself from sibling tools like inject-guard, secure-code-review, etc., which focus on other security aspects.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says to use before committing, logging, posting, or handing data to another tool. Mentions it's deterministic and sub-second. Does not explicitly state when not to use or list alternatives, but the context is clear.

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

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

No annotations provided, so the description carries full burden. It discloses that it returns structured findings and mentions cost, but does not state whether it is read-only, requires authentication, or other behavioral traits. Some transparency is present, but gaps remain.

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 redundant words. Front-loaded with purpose and output, followed by cost. Every sentence 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 no output schema and moderate complexity, the description adequately explains return structure (severity, CWE, location, remediation). However, it lacks details on format or pagination, but is largely complete for a review 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 baseline is 3. The description does not add meaning beyond schema: 'code' is source code/diff, 'context' optional, 'language' hint, all already defined in schema.

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

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

The description clearly states the tool's purpose: security review of code snippets or diffs, and specifies the output includes severity, CWE, location, and remediation. This distinguishes it from siblings like secret-scan (secrets) and inject-guard (injection), though not 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 use this tool vs alternatives. The description does not specify prerequisites, when not to use, or mention sibling tools for comparison.

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

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

With no annotations, the description carries full disclosure. It explains decoding of calldata/typed-data, detection of drainer patterns, binding to stated intent, deterministic and sub-second execution, and failure modes (cautioned/blocked). It also mentions cost (up to 200c/call), which is beyond what annotations typically cover.

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 dense paragraph that front-loads the core purpose. Every sentence adds value, covering behavior, constraints, and limitations. It could be slightly more structured (e.g., bullet points for failure modes) but remains concise and informative without 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?

The description explains what the tool does and its outcomes (auto-sign-safe, cautioned, blocked) but does not specify the structure of the verdict return value. Given no output schema, the agent is left to infer the response format. Additional details on the verdict object would improve completeness.

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

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

Schema coverage is 100%, and the description adds significant context beyond parameter names and basic types. For example, it explains the purpose of `expected.maxAmount` (required for auto-sign allowance) and `expected.from` (for transferFrom), and describes `typedData` as the off-chain drainer surface, enhancing agent understanding.

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

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

The description clearly states the tool's purpose: a pre-sign safety oracle that submits transactions or EIP-712 messages and returns a machine-enforceable verdict. It specifies the resource (transactions/messages) and verb (submit + get verdict), and distinguishes itself from siblings by focusing on pre-sign safety for wallets.

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 indicates when to use the tool (before signing EVM transactions or EIP-712 messages) and provides context like failing closed and not vouching for counterparty trustworthiness. However, it does not explicitly compare to sibling tools or provide alternatives, though the sibling list suggests different security roles.

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

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

The description thoroughly discloses behavior: hybrid deterministic+LLM classifier, fails closed, never executes the call, detects known-dangerous patterns, and pricing. No annotations are provided, so the description carries the full burden and meets it excellently.

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 front-loaded with the main purpose and then details. It is dense but every sentence adds context. Could be slightly more concise, but overall well-structured.

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

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

Given the tool's complexity with nested objects and no output schema, the description adequately explains the workflow and constraints. It misses explicit return format, but the use case is clear. Slightly better than baseline.

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

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

Schema coverage is 100% with each parameter described. The description adds value by explaining how 'intent' and 'expected' bind the call for auto-exec safety, and how the verdict works. This goes beyond the schema's isolated field descriptions.

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

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

The description clearly states the tool is a pre-execution safety oracle that evaluates tool calls and returns a verdict. It specifies the types of calls (shell, http, sql, file, code, env) and the output (machine-enforceable verdict). This distinct purpose is not confused with siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use the tool: before executing a tool call to check safety. It implies usage in security-critical contexts but does not explicitly state when not to use it or mention alternatives among siblings. Context is clear though.

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?

Without annotations, the description carries the full burden of explaining behavior. It discloses important traits: 'No endpoint fetch' (no external calls), cost ('up to 200c/call'), and the consequences of omitting the payment payload. It also describes the return value components, providing transparency about what the verdict contains.

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-organized paragraph that front-loads the core purpose and then details return values and parameter context. It is concise (no redundant sentences) and all information is relevant, though it could benefit from bullet points for 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?

Given the complexity (8 parameters, nested objects, no output schema), the description covers the main functionality and key parameter aspects. However, it lacks detailed return value structure (only lists components without types), and does not address error handling or edge cases (e.g., invalid requirements). This leaves some gaps for an AI 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 coverage is 100% (all 8 parameters documented). The description adds meaning beyond the schema by explaining that 'endpointUrl' is 'context only; never fetched', that 'paymentPayload' enables binding the menu to the actual charge, and that 'selectedOptionIndex' defaults to 0. This additional context justifies a score above 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 explicitly states the tool's purpose: 'Vet an x402 counterparty before settling USDC'. It clearly identifies the resource ('x402 counterparty') and action ('vet'), and distinguishes from siblings like 'sign-guard' or 'tool-call-guard' which serve different security functions.

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 provides clear context for when to use the tool ('before settling USDC') and notes that omitting the payment payload results in a verdict that is 'never auto-settle-safe'. However, it does not explicitly mention when not to use it or list alternative tools for different trust scenarios.

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