CanaryGuard 402

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

Annotations already declare readOnlyHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context beyond the schema: this is a paid call costing 0.010 USDC and payable on Base or Solana, which affects whether an agent should invoke it. It does not mention rate limits or latency, but the payment disclosure is the key operational fact.

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, both front-loaded with the highest-value information: what is analyzed first, cost second. No filler, no repetition 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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. However, for a paid, multi-signal analysis tool, the description leaves gaps: it never states the chain_id semantics, nor when this should be chosen over cheaper single-purpose siblings, which is precisely the decision an agent faces here.

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 only 50%: wallet_address is documented in the schema, but chain_id has no description at all, only a default of 8453. The description says 'on Base', which does nothing to explain whether chain_id is configurable or what other chains are valid, and the mention of Solana for payment only deepens the ambiguity about chain scope. It does not compensate for the coverage gap.

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 resource (EVM wallet security profile) and enumerates the exact analyses performed: transaction velocity, approval exposure, drainer interaction risk, and smart-account state. The word 'Comprehensive' signals breadth versus the focused siblings like checkWalletDrainer, but no sibling is named explicitly, so differentiation is inferred 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?

There is no explicit when-to-use or when-not-to-use guidance and no alternative is named. The word 'Comprehensive' and the price line imply this is a heavier, paid option best used when a full risk picture is needed rather than a single check, but the agent must infer that.

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 already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true). The description's main added value is the pricing disclosure (0.010 USDC on Base or Solana), which is genuinely useful context not in the annotations. It does not describe what the audit returns or the checks performed, so the disclosure is partial.

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 core purpose, with pricing appended as a distinct operational fact. No filler, though the pricing sentence could be considered ancillary to the tool's function.

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-value detail is not required, and annotations carry the safety profile. However, the nested object with zero property descriptions leaves an agent without guidance on the expected domain/types/message contents, which the description does not fill.

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 0% for the single nested typed_data parameter, so the description must carry meaning. It does add value by naming the payload families (Permit, Permit2, transferWithAuthorization), which tells an agent what primaryType values are relevant, but it says nothing about the required domain/types/message structure.

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 (audits) and resource (EIP-712/EIP-3009 typed-data payloads), including concrete payload variants (Permit, Permit2, transferWithAuthorization). It stops short of distinguishing itself from the near-identically named sibling auditEip712SignaturePayload, so an agent cannot tell the two apart from 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?

The stated goal ('to block malicious spender approvals and phishing domains') implies a use case but gives no explicit when-to-use, when-not-to-use, or alternative. With a sibling named auditEip712SignaturePayload in the list, the absence of routing guidance is 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?

Annotations already cover the safety profile (readOnly, non-destructive, open-world), and the description adds real value beyond them: it discloses the detection scope (unauthorized approvals, replay attacks) and, unusually, the cost (0.02 USDC on Base or Solana), which an agent must know before invoking a paid tool. It does not mention latency or rate limits, keeping it 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, purpose first, commercial constraint second. No filler, nothing buried, and the enumeration of supported payload types is packed into the opening clause.

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 annotations cover safety. The description supplies scope, supported formats, and payment terms — enough for a confident call. The remaining gap is sibling disambiguation against auditEip712Signature.

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?

One parameter with 0% schema coverage, so the description must carry weight. Naming Permit/Permit2/transferWithAuthorization tells the agent which typed-data dialects are accepted, which is genuinely useful, but it never explains the typed_data object's required members (domain, types, primaryType, message) or their expected shapes.

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 (audits) and resource (EIP-712/EIP-3009 typed-data signature payloads) and enumerates the concrete formats handled (Permit, Permit2, transferWithAuthorization). It does not, however, distinguish itself from the near-identically named sibling auditEip712Signature, so an agent must guess which one applies.

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 'to prevent unauthorized token approvals and replay attacks' implies the usage context, but there is no explicit when-to-use vs when-not-to-use guidance and no pointer to auditEip712Signature as the alternative for the simpler case. Usage is inferable but not directed.

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 already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds a genuinely non-derivable behavioral fact: the call costs 0.02 USDC on Base or Solana, which matters for agent planning. It does not say what happens if payment fails or whether the audit blocks on chain confirmation.

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 purpose and threat model, with the cost disclosure as a compact trailing sentence. No filler and nothing redundant with the annotations.

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 not be explained, and the safety annotations are rich. But for a paid, open-world auditing tool with nested-object parameters, the description omits payment mechanics and any tie-break against auditMcpToolSchema, leaving real gaps an agent must resolve by guessing.

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 0%, so the description carries the burden. It partially compensates by naming the three artifacts inspected (name, description, JSON schema), which maps one-to-one onto tool_name, tool_description, and input_schema. It gives no format or size expectations for input_schema, and required-vs-optional intent 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 (inspects) and precise resource (MCP tool definitions, descriptions, JSON schemas) plus the exact threat classes it hunts for (prompt overrides, shadowing, exfiltration sinks). However, it never distinguishes itself from the very similar sibling auditMcpToolSchema, so an agent must guess between the two.

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 you call it to vet an MCP tool before trusting it. There is no explicit when-to-use, no when-not-to-use, and no routing guidance versus auditMcpToolSchema, guardAgentMemory, or runFullEnterpriseRiskAudit.

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 already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely new context — a per-call price of 0.010 USDC on Base or Solana — which is a meaningful operational constraint. It says nothing about what happens on a positive finding or whether the call is free vs paid for retries.

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 capability stated first and the pricing constraint appended. Nothing is redundant, though the price sentence mixes operational metadata into what is otherwise a pure-purpose statement.

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 annotations cover safety. But with a nested object parameter at 0% schema coverage and a same-domain sibling left unaddressed, the definition leaves real gaps for an agent deciding whether and how to call 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 description coverage is 0% and the description never mentions any of the three parameters. In particular it does not clarify the distinction or relationship between tool_name and tool_description, nor what input_schema should contain, so the agent must infer required payload shape entirely from field names.

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 and resource ('Inspects ... MCP tool definitions, JSON schemas, and server cards') and enumerates the threat classes it checks for (hidden instructions, tool shadowing, exfiltration). It never distinguishes itself from the near-identical sibling auditMcpToolPoisoning, so an agent cannot tell the two apart from this 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?

Usage is only implied by the 'when you have an MCP tool definition to inspect' framing; there is an explicit alternative (auditMcpToolPoisoning) sharing the same domain and the description gives no criteria for choosing between them. No exclusions or prerequisites are 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?

Annotations already declare readOnlyHint=true and non-destructive, so the safety profile is covered; the description adds genuinely non-redundant behavior by disclosing price and payment rails ("0.010 USDC on Base or Solana"), which is critical for a paid, open-world call. It stops short of explaining how payment is transacted or whether the call fails without funds.

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, both front-loaded and free of filler: capability first, commercial/payment terms second. Nothing here restates the tool name or wastes tokens.

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 an output schema present, the description needn't explain return values, and it adequately covers what is checked and what it costs. The gap is the payment mechanics (how the 0.010 USDC is collected, whether a wallet or x402 handshake is required) and any rate/access constraints for an open-world paid 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 0% on the single required parameter, so the description carries the burden; "any domain or URL" does add useful meaning by signaling that both bare domains and full URLs are accepted. However, no format examples, scheme expectations, or normalization rules are given, so compensation is only partial.

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 and resource ("Audits any domain or URL") and then enumerates exactly what is inspected: llms.txt, .well-known/x402, openapi.json, MCP server card, plus CSS/DOM prompt-injection traps. That level of enumeration makes it clearly distinguishable from siblings like inspectPhishingUrl or auditMcpToolPoisoning, which target different artifacts.

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 ("any domain or URL ... for AI agent readiness") implies when the tool applies, but there is no explicit when-to-use framing and no named alternative or exclusion, even though the sibling list contains several adjacent URL/security audit tools. The agent must infer that readiness auditing is distinct from phishing or contract inspection.

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 already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds genuinely useful non-annotation context: the call is paid at 0.010 USDC on Base or Solana, implying an on-chain payment step the agent must anticipate. It stops short of explaining how payment is authorized or what happens on payment failure.

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 core capability and followed by the cost line. No filler. Slightly awkward that pricing/payment details are tacked on in the same breath as the capability rather than structured separately, but nothing is wasted.

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 not be described. However, for a 'calculates costs' tool whose only parameter is a model name, the description leaves the critical question unanswered: where do the token counts come from, and which model identifiers are accepted? An agent cannot reliably construct a call from this.

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 0% for the single parameter, and the description never mentions it — the default model 'claude-3-7-sonnet' is documented nowhere except the schema's default field. It is also unclear how token counts enter the calculation given only a model name; the description does not compensate for that gap.

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: calculates input, cached-input, and output token costs across named providers, plus a routing recommendation. No sibling is close in function, so differentiation is implicit. The second half ('recommends optimal model routing') slightly dilates the purpose beyond pure pricing without explaining what routing means, keeping it just 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?

No statement of when a caller should use this rather than another tool, no prerequisites, and no mention of what the caller must supply to get a cost (the schema exposes only a model name). The only contextual cue is the price line, which tells you it costs money but not when to spend 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?

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), and the description adds genuinely new context: determinism, that wallet-draining commands are actively blocked, and the payment requirement (0.010 USDC on Base or Solana). What it omits is what happens to blocked or scrubbed content — redaction, removal, or error — which matters for a tool that transforms text before the agent reads it.

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 capability and ending with the practical cost detail. The pricing sentence is useful for an agent that must decide whether to call a paid tool, though the description could have used that space for strict_mode instead.

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 not be explained, and the payment model is disclosed. Still missing is the semantics of strict_mode and the observable effect of a 'block' on the returned content — gaps an agent needs filled before invoking a sanitizer on untrusted input.

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 only 50%: 'content' is documented in the schema, but 'strict_mode' has no description in either the schema or the description text, despite defaulting to true and materially changing blocking behavior. The description's mention of blocking commands gestures at strictness but never explains the flag, leaving a required decision undocumented.

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 ('sanitizes untrusted text', 'blocks detected wallet-draining commands') plus the deployment point ('before context ingestion'). The framing as a prompt-injection firewall distinguishes it from siblings like inspectPhishingUrl, auditMcpToolPoisoning, and guardAgentMemory, which operate on URLs, tool definitions, or memory stores rather than raw untrusted 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?

'Before context ingestion' gives a clear trigger condition an agent can act on. However, it never states when not to use it, nor names an alternative for overlapping cases such as guardAgentMemory or auditMcpToolPoisoning, so routing between siblings is left partly 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?

Annotations already declare readOnlyHint/openWorldHint/destructiveHint, so the safety profile is covered; the description adds the genuinely non-obvious fact that the call is paid (0.02 USDC on Base or Solana), which is exactly the kind of auth/cost context annotations cannot express. It does not state what happens on missing payment or expected latency, keeping it below 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, front-loaded with the capability and followed by the cost constraint. Every clause carries signal; nothing is redundant.

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 an output schema present, return values need no explanation, and readOnly annotations cover safety. The description supplies the one thing structured fields cannot — the paid-call requirement — so an agent has what it needs to decide and invoke.

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 2 parameters at 50% schema coverage; 'contract_address' is documented in the schema, while 'chain_id' has no description and is never explained in prose. The description's repeated 'Base' scoping partially accounts for the 8453 default, but the mention of Solana payment muddies whether other chains are supported.

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?

A specific verb ('Audits') plus resource ('Base smart contracts') and an enumerated set of checks (transfer locks, blacklist modifiers, proxy upgrades, fee-on-transfer hooks) make the purpose unambiguous. It stops short of 5 because the sibling 'inspectContractInfo' plausibly overlaps and is never acknowledged or contrasted.

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 security-audit framing implies when to reach for it (vetting a token/contract before interaction), but there is no explicit when-not guidance and no routing to alternatives such as inspectContractInfo or runFullEnterpriseRiskAudit. 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?

Annotations already declare readOnly/openWorld/non-destructive, and the description adds genuinely new behavior: an explicit price (0.02 USDC on Base or Solana) and the concrete checks performed. It stops short of saying how payment is settled or whether results are cached/point-in-time, which would matter for a paid 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?

Two sentences, no filler, with the audited dimensions front-loaded and cost appended. Slightly under-specified rather than padded, so length is not the problem.

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

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

Output schema exists so return values need no explanation, and annotations cover the safety profile, but the unresolved chain_id semantics and lack of sibling differentiation leave real gaps for a paid, open-world audit tool.

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

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

Schema coverage is only 50% and the undocumented parameter is chain_id, whose existence is actively muddled by the description's claim that the audit is 'on Base' (default 8453). An agent cannot tell from either source whether non-Base chains are supported or what chain_id changes.

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 (audits) plus resource (EVM wallet/counterparty addresses) and three named audit dimensions (Permit2 drainer exposure, approval phishing history, OFAC sanctions). However, it does not distinguish this from close siblings like checkWalletSanctions or analyzeEvmWallet, and 'counterparty addresses' hints at scope the single wallet_address parameter cannot express.

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 statement of when to choose this over checkWalletSanctions (sanctions-only) or analyzeEvmWallet (general wallet analysis), which is the primary routing question an agent faces. The only contextual cue is the price line, which is not usage 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?

Annotations already declare readOnlyHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely non-obvious context beyond that: the tool is paid (0.010 USDC) with named accepted payment chains, and it discloses which external data sources drive the verdict. It does not mention rate limits, latency, or failure/payment 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?

Two sentences, zero filler: the capability and its data sources come first, and the cost/payment constraint follows. Every clause carries information an agent needs.

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 not be explained, and annotations cover side-effect safety; the description fills the remaining gaps that matter most for a paid, open-world lookup (data sources and cost). Missing only routing versus sibling wallet tools and any note on how a match is surfaced or charged.

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 and schema coverage is 100%, so the schema already fully documents 'address'. The description's 'EVM and Solana' phrasing reinforces accepted address families but adds no format, validation, or chain-detection detail beyond what the schema 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?

Names a specific verb ('screens') and resource ('EVM and Solana wallet addresses') and enumerates the exact watchlists consulted (OFAC SDN, Lazarus Group, DeFi exploit/drainer blacklists), so the agent knows precisely what check is performed. It stops short of distinguishing itself from close siblings like checkWalletDrainer or analyzeEvmWallet, even though drainer blacklists overlap with one of 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 statement of when to call this versus the siblings that also inspect wallets (checkWalletDrainer, analyzeEvmWallet, runFullEnterpriseRiskAudit). Usage is only implied by the word 'screens'; no exclusions, prerequisites, or alternative routing 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?

The annotations already establish that this is a non-destructive read-only operation. The description adds valuable behavioral context by disclosing the price of 0.010 USDC on Base or Solana, which is not captured in the annotations or 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?

The description is two sentences and front-loads the tool's core decoding capability before the pricing detail. Every phrase contributes useful scope or commercial context, with 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?

The combination of an output schema, annotations, and the description covers the main needs for a one-parameter paid decode tool. The description identifies the decoded data and price, though it could say more about tx_hash format or payment 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?

There is one required parameter, tx_hash, with 0% schema description coverage. The description partially compensates by implying the input is a Base Mainnet transaction hash, but it does not specify expected format or constraints such as a 0x-prefixed hash.

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, 'Decodes', and a specific resource, 'Base Mainnet transaction receipts', plus several decoded artifacts such as EIP-3009 settlements and gas fees. This is clear enough to distinguish the tool's function, though it does not explicitly contrast it with sibling 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?

The listed decoded artifacts imply when the tool is useful, e.g. for interpreting Base transaction receipts, ERC-20 logs, and finality details. However, there is no explicit when-to-use guidance, no exclusions, and no named alternatives among the many sibling audit and inspection 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?

Annotations already cover read-only/non-destructive/open-world semantics, and the description adds genuinely new behavioral context: a per-call cost of 0.010 USDC payable on Base or Solana, plus the tamper-resistant oracle sourcing. It omits failure modes (e.g., what happens on payment failure or unsupported symbol), so it stops 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, zero waste: the first front-loads what is returned and for which asset universe, the second adds the critical payment constraint. Nothing is repeated from the annotations.

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 needn't be explained, and the payment/oracle context is supplied. However, for a single-required-parameter tool with 0% schema coverage, leaving the symbol format unspecified is a material gap for 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?

Schema coverage is 0% and the single parameter 'symbol' is undocumented in both schema and description. An agent cannot tell whether it expects a ticker (ETH), a pair (ETH/USD), or a contract address, and the description does nothing to resolve that ambiguity.

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 resource and outputs: on-chain USD spot prices, 24h volatility, and Chainlink/TWAP oracle deviation for Base/EVM assets. It clearly distinguishes itself from siblings like analyzeEvmWallet or inspectBaseToken, though it doesn't name an explicit alternative for price lookups.

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 scope statement ('major Base and EVM assets'), but the description never states when to prefer this over getOndemandMarketSnapshot or getTokenHistoryAndSpread, nor does it state 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds meaningful context beyond annotations: it discloses the paid cost of 0.020 USDC and the specific market-data domains included, though it does not explain payment mechanics or rate limits.

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 packed sentences with no waste. The core purpose and data sources are front-loaded, and the price is appended as a secondary but important invocation detail.

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 and annotations cover read-only/open-world behavior, so return values and safety do not need explanation. However, for a paid open-world tool with two undocumented parameters, the description omits parameter meanings and payment/auth flow, leaving invocation details incomplete.

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 0% for both parameters. The description does not explain the `assets` array or the `include_polymarket` boolean, beyond indirectly mentioning Polymarket as part of the data mix. It leaves the agent to infer parameter behavior from the schema alone.

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-like purpose and resource: an on-demand institutional market intelligence snapshot. It lists the exact data sources combined, making the tool distinguishable from generic price or pool-inspection siblings, though it does not explicitly contrast 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?

Usage is implied by 'on-demand institutional market intelligence snapshot combining...' and the stated price, but there is no explicit guidance on when to choose this over siblings such as getCryptoPriceOnchain, inspectUniswapPoolState, or getTokenHistoryAndSpread.

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 already cover the read-only, non-destructive, open-world profile, and the description adds genuinely new behavioral context: results are pre-filtered through CanaryGuard zero-honeypot and prompt-injection gates, and each call costs 0.02 USDC on Base or Solana. It does not state sort order guarantees, truncation of the ranking, or what happens when liquidity thresholds exclude everything.

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, and the functional scope is front-loaded ahead of the pricing detail. The pricing sentence earns its place as a cost gate, though it could be shortened slightly.

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-value explanation is not required, and annotations cover safety semantics. The remaining gap is material: two undocumented parameters with non-obvious defaults and no guidance on how the ranking interacts with the liquidity filter. Adequate but incomplete for a discovery 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 0%, so the description carries the full burden and fails to explain either parameter. It never mentions that 'limit' caps the number of returned tokens (default 5) or that 'min_liquidity_usd' filters by liquidity floor (default 1,000,000), leaving an agent to infer both from the schema names alone.

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?

It states a specific verb and resource: 'Returns top Base Mainnet tokens by 24h DEX volume and liquidity velocity' filtered by named safety gates. This clearly separates it from single-token siblings such as inspectBaseToken or checkSmartContractHoneypot, though it never names an alternative 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 use case (discovering trending tokens that already passed honeypot and prompt-injection gates) is implied by the filtering language, but there is no explicit when-to-use or when-not guidance versus siblings like inspectBaseToken or getOndemandMarketSnapshot. The only hard routing signal is the price line, which tells the agent this is a paid endpoint.

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 already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, while the description adds substantive context: pre-screening for TVL depth and audit status, the source protocols, and the exact price and payment chains. That payment and screening information goes beyond structured metadata. It does not explain payment mechanics or rate limits, which would be needed for 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?

The definition is two tight sentences. The core purpose is front-loaded, and the price detail follows without unnecessary 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?

Given a read-only query with an output schema and safety annotations, the description supplies chain, assets, protocols, screening criteria, and price. This is nearly complete for invocation. Minor gaps remain around result freshness and explicit parameter-to-value mapping, but they do not block correct use.

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 0%, so the description must carry more weight. It lists supported assets USDC, EURC, and WETH, which partially compensates for the undocumented `asset` parameter. However, it never explicitly explains that `asset` selects among those values or what happens with unsupported inputs.

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 action (curating top risk-adjusted yield pools), the exact assets (USDC, EURC, WETH), the chain (Base), and named protocols. This is clear enough for an agent to know what the tool returns. It does not explicitly differentiate itself from sibling tools such as getSafeYieldAllocation, 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 description never says when to use this tool instead of alternatives such as getSafeYieldAllocation or getOndemandMarketSnapshot. Usage is only implied by the topic, with no exclusions or routing guidance. This is a significant gap for an agent choosing among many risk/yield-adjacent 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?

Annotations already cover the safety profile (readOnly, non-destructive, open-world), and the description adds genuinely non-obvious behavior: this is a paid endpoint costing 0.020 USDC payable on Base or Solana, and the model incorporates timelock and depeg stress factors. It stops short of explaining the payment flow or what happens if payment fails, which is the main residual gap.

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, purpose front-loaded before the cost disclosure, with no filler. The first sentence is dense with protocol jargon but every clause adds discriminative information about what the matrix covers.

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-shape explanation is not owed. However, for a 3-parameter tool with zero schema coverage, no enums, and no usage guidance, the description leaves the agent unable to populate risk_tolerance or understand how chains constrains the result — meaningful gaps for a paid 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?

Schema description coverage is 0% across three parameters, so the description carries the full burden and largely drops it — chains, capital_usdc (default 50000), and risk_tolerance (default CONSERVATIVE) are never mentioned. Critically, risk_tolerance has no enum and the description gives no hint of valid values, so an agent must guess whether it accepts 'CONSERVATIVE' vs 'conservative' vs 'LOW'.

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 artifact — 'Computes an institutional risk-adjusted DeFi capital allocation matrix' — plus the venues (Base/Arbitrum, Morpho Blue, Aave V3, Moonwell, Aerodrome) and the scoring inputs (timelock, depeg stress). This is clearly an allocation-optimization tool rather than a yield lister like getSafeDefiYields, though the description never names that sibling to sharpen the contrast.

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 phrase 'institutional risk-adjusted ... allocation,' which signals the audience and scenario but never states when to pick this over getSafeDefiYields, getOndemandMarketSnapshot, or runFullEnterpriseRiskAudit. The payment sentence adds a prerequisite (paid call) but not a use/avoid condition.

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 already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds genuinely new behavioral context: this is a paid endpoint costing 0.020 USDC payable on Base or Solana, which an agent must know before invoking. It does not disclose latency, rate limits, or failure modes, keeping it below 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?

A single front-loaded sentence that packs the three output categories first and the payment terms last, with no filler. It is dense but every clause carries information an agent needs; a short clause on window/quote would have been a better use of space than nothing.

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-shape detail is rightly omitted, and the payment requirement is a valuable addition. However, with 3 parameters at 33% schema coverage and no required fields, the description leaves the semantics of 'window' and 'quote' (and their defaults) unclear, which is a real gap for a parameterized tool.

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

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

Schema coverage is only 33% — only 'token' is documented ('symbol or Base contract address'), and the description reinforces the Base-token scope. The four timeframes (1h/24h/7d/30d) hint at the 'window' parameter's accepted values but also read as returned data, leaving it ambiguous whether window selects a timeframe or the response always contains all four; 'quote' is never explained.

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 ('Returns') and enumerates the exact resources produced: multi-timeframe Base token OHLCV, Chainlink vs. Uniswap V3/Aerodrome spread in bps, and realized volatility skew. This is detailed enough to separate it from siblings like getCryptoPriceOnchain (single price) or inspectBaseToken (token metadata) without opening 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?

There is no explicit when-to-use statement and no named alternative, so the agent must infer from the output inventory that this is the tool for spread/volatility analysis on Base. The listed outputs imply the use case but no exclusions or routing guidance 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, which matches the 'scans' framing, so no contradiction. The description adds genuinely non-obvious behavioral context: the tool is paid, costing 0.02 USDC on Base or Solana, which an agent must know before calling. It doesn't say what happens on a positive detection or whether scanning is rate-limited.

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, threat scope front-loaded, pricing second. No filler and no 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?

An output schema exists so return values need not be described, and the payment model plus detection scope are covered. The remaining gap is session_id semantics and what the agent should do on a flagged result, which keeps it short of complete.

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

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

Schema coverage is only 50%, and the uncovered parameter is session_id (default 'default'), which the description never explains at all — its role in cross-session poisoning detection is exactly the kind of semantics an agent needs. The description adds nothing beyond what the memory_chunk schema description 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 (scans) and a specific set of resources (RAG chunks, vector DB retrievals, persistent agent memory), plus the exact threat class (delayed sleeper-agent instructions, cross-session poisoning). This clearly separates it from sibling auditMcpToolPoisoning, which targets tool definitions rather than memory payloads.

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 'verify before persistence' on the memory_chunk parameter implies the invocation point, but the main description never says when to call this versus auditMcpToolPoisoning or canary_sanitize, and gives no exclusions or prerequisites. Usage has to be inferred.

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 already cover the safety profile (readOnly, non-destructive, openWorld), but the description adds the crucial non-annotation fact that this is a paid call costing 0.010 USDC, plus the fact that it inspects untrusted token metadata for prompt injection. It does not mention rate limits, failure modes, or what happens if the address is not a Base contract, which keeps it 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 tight sentences, zero filler: the first front-loads the scope and checks, the second immediately flags cost and payment chains. 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?

An output schema exists, so return values need no explanation, and the description discloses the paid nature and analytical scope. What remains missing is how this relates to the overlapping honeypot and contract-inspection siblings, which matters for a toolset this dense.

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, token_address, and schema coverage is 100% with a 'Base ERC-20 contract address' description. The tool description adds no meaning beyond that — no note on address format, checksum, or behavior for non-contract addresses — 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 ('Audits') and resource ('Base ERC-20 token contracts') and enumerates the checks performed: honeypot risk, buy/sell taxes, liquidity depth, metadata prompt injection. This is far more specific than the sibling 'checkSmartContractHoneypot', but the description never names that sibling or explains how the two overlap, so discrimination requires inference.

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 enumerated risk categories — an agent can infer this is for pre-trade token due diligence. There is no explicit when-to-use/when-not statement and no routing versus checkSmartContractHoneypot, inspectContractInfo, or runFullEnterpriseRiskAudit, which appear to overlap.

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 already establish read-only, non-destructive, open-world behavior, so the description does not need to repeat that. It adds important behavioral context by disclosing a price (0.010 USDC on Base or Solana), which is critical for an agent to know before invoking a paid tool. However, it omits payment mechanics, rate limits, and failure behavior when payment is insufficient.

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 inspection scope and followed by the price. Every sentence carries useful information with 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?

An output schema exists, so return-value details need not be explained. However, for a paid inspection tool with an undocumented chain_id parameter, the description omits payment mechanics and parameter semantics that an agent needs 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 only 50%: contract_address is described, but chain_id is undocumented in both schema and description. The description scopes inspection to 'Base EVM' but does not explain what chain_id controls or whether values other than the default 8453 are valid, so it fails to compensate for the schema gap.

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 and resource (inspect contract bytecode/proxy/selectors) and enumerates the exact inspection outputs: bytecode size, EIP-1967/UUPS implementation slots, EIP-7702 delegation designators, and verified selectors. This clearly distinguishes it from sibling tools like checkSmartContractHoneypot and inspectBaseToken without needing 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 implies the tool is for on-chain contract inspection but gives no explicit when-to-use, when-not-to-use, or sibling alternative guidance. It also mentions pricing but not payment prerequisites or conditions, leaving the agent to infer invocation context.

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 already cover read-only/open-world/non-destructive, so the bar is lower, and the description still adds a genuinely new behavioral fact: it costs 0.02 USDC on Base or Solana. What it omits is the mechanics of that payment (wallet/auth requirement, when the charge is triggered), which matters for an agent deciding whether it can call it.

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 filler: the first defines what is audited and against what, the second front-loads the cost before the agent commits. Nothing is redundant with the schema or annotations.

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 threat coverage is well specified for a single-parameter tool. The remaining gap is how the paid-call flow works (when payment is required, what happens on failure), which an agent needs to invoke reliably.

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 a single documented 'url' parameter, so the baseline is 3. The description adds only a mild hint that domains and API endpoints are acceptable inputs, not just full URLs, but gives no formatting or normalization 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?

Names a specific verb (audits) and resource (URLs, API endpoints, Web3 dApp domains) and enumerates the exact threat classes it detects (IDN homograph spoofing, Angel/Pink/Inferno drainers, hidden DOM prompt injections). That makes the function unmistakable, though it never names its nearest sibling (auditUrlAgentReadiness) or checkWalletDrainer to draw 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?

The description never states when to call this versus the adjacent URL/wallet-audit siblings, nor any prerequisite for use. The only usage-adjacent information is a price line, which tells cost but not selection criteria or 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?

Annotations already declare read-only, non-destructive, and open-world behavior. The description adds useful beyond-annotation context: the returned analytics and a per-call price of 0.010 USDC, though it does not explain payment mechanics or rate limits.

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-load the purpose and outputs, then append pricing. There is no filler or repetition.

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

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

Output schema covers return values and annotations cover safety, so the description is close to sufficient for basic invocation. However, it omits 'quote_token' semantics and does not clarify token-address handling, leaving key calling context incomplete.

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 only 50%, and the description does not compensate by explaining 'quote_token' or how a token address is resolved to a pool. It only restates that the address is on Base, adding little parameter clarity 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 ('Audits') and resource scope: Uniswap V3/V4 and Aerodrome liquidity pools on Base, plus enumerated returned metrics. This distinguishes it from wallet-, token-, and yield-focused siblings, though it does not explicitly name an alternative.

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 guidance or named alternative is provided. The pool-specific scope implies use for liquidity-pool audits, but overlap with token-inspection siblings through 'pool_or_token_address' is left unaddressed.

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 already cover safety (readOnly, non-destructive) and open-world scope; the description adds real value on top by disclosing that repair is deterministic, enumerating the failure classes it handles, noting the injection-scrubbing behavior, and stating the cost (0.010 USDC on Base or Solana). It does not say what happens when the payload is unrepairable or how payment is settled, which keeps it 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 front-loaded sentences: capability and grammar first, commercial term last. Every clause carries information, and the list of defects is packed parenthetically rather than sprawling.

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?

Return values are covered by the output schema and safety by the annotations, and the single-parameter surface is fully described. The remaining unstated piece is failure behavior on irreparable input and the mechanics of the paid call, which matters given this is a paid, open-world 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?

The single parameter has 0% schema description coverage, so the description must carry the meaning. By naming the failure classes and markdown fences, it makes clear that raw_json is the arbitrary malformed text blob to be repaired rather than strict JSON, which meaningfully compensates for the empty 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 and resource: it repairs malformed or truncated LLM JSON payloads and scrubs prompt-injection content. That is concrete enough for an agent to identify the operation, but it never distinguishes itself from the overlapping sibling canary_sanitize, which also suggests scrubbing/sanitizing behavior.

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 input domain (LLM JSON output with missing quotes, trailing commas, markdown fences) implies when to reach for this tool, but there is no explicit when-to-use/when-not statement and no routing to or away from canary_sanitize. The pricing sentence is the only additional selection signal.

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 already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely non-obvious behavior: this is a paid call (0.020 USDC on Base or Solana), which an agent must know before invoking. It does not disclose latency, whether payment is per-call or how it is settled, or whether partial results are returned on failure.

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, front-loaded with the purpose statement and closing with the cost fact that matters for invocation decisions. Every clause is load-bearing (either a check type or the price), though the run-on enumeration makes it harder to scan than a two-sentence structure would.

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 not be explained, and annotations cover the read-only/open-world profile. However, for a high-complexity, paid, multi-check audit tool, the description omits how the aggregate verdict is shaped (does it fail fast or report per-check?) and gives no pointer to when the narrower sibling tools are preferable.

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 67% and the description adds no direct parameter explanation beyond the passing mention that payment happens 'on Base or Solana,' which only loosely hints that chain_id is meaningful (the schema gives it a default of 8453 with no description). With the schema already documenting target_address and counterparty_wallet, baseline 3 is appropriate, but the undocumented chain_id remains a gap.

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+resource ('Enterprise 360-degree security audit bundle') and enumerates the five constituent checks (bytecode/proxy, DEX rug-risk, sanctions screening, EIP-712 permits, prompt-injection firewalling). It is clearly a superset of several siblings (checkWalletSanctions, inspectBaseToken, auditEip712Signature), so an agent can infer the bundle relationship, though the description never explicitly says it replaces those calls.

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 rather than stated: framing it as a 'bundle combining' five checks, plus the explicit 0.020 USDC price, signals a one-call-versus-many-calls tradeoff without ever saying 'use this instead of the individual audit tools' or when not to use it. There is no explicit when/when-not guidance or named alternative.

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 already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context by disclosing the price (0.020 USDC) and the supported chains (Base or Solana), but it does not explain required signatures, payment mechanics, or what the report 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?

Two sentences with no wasted text, front-loading the core verification scope before the pricing detail. The structure is efficient and easy to scan.

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 not be explained. However, for a paid, open-world verification tool with five required parameters and no schema descriptions, the definition omits critical details: parameter semantics, signature requirements, and how the USDC payment is supplied.

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 0%, so the description must carry parameter meaning, but it does not explain any of the five required parameters. It only loosely implies that an agent wallet and cryptographic verification are involved; service_domain, message, signature, and signed_at are entirely undocumented.

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 action ('Generates a cryptographic attestation report') and lists the verification dimensions: agent wallet, x402 EIP-3009 capability, counterparty reputation, and zero-drainer history on Base. It is clear what the tool does, but it does not distinguish itself from nearby siblings such as checkWalletDrainer, analyzeEvmWallet, or auditEip712Signature.

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 guidance on when to use this tool versus alternatives, nor any stated prerequisites or exclusions. Usage is only implied by the purpose statement, so an agent must infer the appropriate context.

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