Web3 Systemic Agent

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

With no annotations, the description carries the full burden. It does disclose the important behavioral trait that analysis is purely static bytecode inspection (no on-chain simulation), which implies false negatives are possible, and it flags the tool as free. It does not state what the response contains, whether results are cached, or any rate/quota constraints.

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

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

A single dense sentence with the tool class front-loaded and the detection categories following. No filler, though the list of check names (isBlacklisted, setBlacklist) is compact jargon that could be trimmed.

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

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

No output schema and no annotations, so the description must cover return semantics, and it does not: an agent cannot tell whether it receives a boolean, a risk score, or matched findings. What it checks and its position as a first stage are clear, but the result shape is left entirely unspecified.

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

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

Schema coverage is 100%, so every parameter (chain_id with default 8453, token_address, bytecode_override) is already documented in the schema. The description adds no syntax or interplay guidance, such as how bytecode_override relates to token_address. 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+resource ('static bytecode scanner for honeypot indicators on DEX tokens') and enumerates the exact detection classes: blacklist manipulation, transfer taxes/100% sell fee traps, trading freeze backdoors, selfdestruct. The 'Stage 1' prefix implicitly positions it ahead of deep_semantic_audit, though no sibling is named outright.

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?

'Stage 1 Free static' implies this is the cheap first-pass check run before deeper analysis, which is useful implied sequencing. However, there is no explicit when-to-use/when-not guidance, no statement that it is insufficient on its own for a final safety verdict, and no named alternative for full audits.

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 supplied, the description carries the full behavioral burden. It does disclose two genuinely valuable traits absent from any structured field: a mandatory $0.05 USDC x402 micropayment on Base Mainnet and the two-phase deterministic-then-LLM execution model. However, it says nothing about failure modes (e.g., what happens if x402_payment_header is omitted or rejected), latency, or what the audit emits, which matters because no output schema exists.

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

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

Three sentences with the function stated first and the payment prerequisite last; little waste. Mild redundancy between 'Deep Semantic LLM Security and Governance Audit' and 'structured Gemini LLM evaluation' costs it a point but the structure is front-loaded and readable.

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?

This is a complex tool with seven parameters, a paid x402 flow, and no output schema, yet the description never indicates what the audit returns (risk score, verdict, rationale) or how risk_threshold affects the response shape. The payment prerequisite is covered, but the return-value gap is a real omission for a tool of this complexity.

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

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

Schema description coverage is 100%, so all seven parameters, including defaults for chain_id, calldata, policy_prompt, and risk_threshold, are already documented in the schema. The description only gestures at calldata and proposal claims without adding format, interaction, or constraint details beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description names a specific resource and operation: an audit that compares natural-language proposal claims against bytecode and calldata, executed as an LLM evaluation after deterministic on-chain gatekeeping. The verb 'Audit' is abstract and the jargon ('Stage 2', 'deterministic on-chain gatekeeping') demands inference, but the core function is recoverable. It never names siblings like scan_dao_proposals or check_token_honeypot, so an agent cannot distinguish it from them without reading schemas.

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

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

There is no explicit when-to-use or when-not-to-use guidance. 'Stage 2' weakly implies a pipeline ordering, but the description never says which stage-1 tool precedes it or when an agent should prefer check_token_honeypot or scan_dao_proposals instead. Usage is left entirely to inference from the tool's name.

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

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

No annotations are supplied, so the description must carry the behavioral burden. It usefully discloses that the scan is deterministic and free and enumerates the risk categories it detects, but it never states whether the tool performs network/RPC reads, whether it is strictly read-only against the contract, or what the result payload looks like, leaving meaningful gaps for an unannotated tool.

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

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

Two sentences, both front-loaded and dense: the first frames the stage, cost, method, and domain; the second enumerates exactly what is discovered and flagged. 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?

With only three parameters, no annotations, and no output schema, the description does the core job of saying what is scanned and what is detected. It is still thin on result shape and execution behavior (RPC vs. offline, read-only guarantees), which matter more here precisely because no annotations or output schema exist to cover them.

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 chain_id, target_address, and bytecode_override are already fully documented in the schema, including the offline-analysis purpose of the override. The description's mention of 'Base or EVM chains' aligns with chain_id but adds no new parameter semantics, so the baseline 3 applies.

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

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

The description uses a specific verb and resource: 'inspection of smart contract bytecode', and it names concrete outputs (4-byte function selectors, high-risk administrative capabilities: ownership transfer, proxy upgrade, unconstrained minting, selfdestruct). 'Stage 1' implicitly positions it ahead of the deeper audit sibling, but it never names 'deep_semantic_audit' or any other sibling explicitly.

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

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

'Stage 1' and 'Free deterministic' imply this is the cheap first-pass to run before deeper analysis, which is useful implied guidance. There is no explicit when-to-use/when-not statement and no named alternative directing the agent to check_token_honeypot or deep_semantic_audit for follow-up.

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

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

No annotations are supplied, so the description carries the full behavioral burden. It does disclose that it is a free-tier scanner that hits Snapshot DAOs and that it extracts execution payloads to detect takeover attempts, and the existence of the curated offline mode implies outbound network calls by default. It does not state read-only semantics, rate limits, or what is returned when no proposals are found.

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

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

Two dense sentences, front-loaded with what it is and followed by what it extracts, with zero filler. Every clause (spaces covered, target addresses, calldata payloads, purpose of detection) earns its place.

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

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

For a 3-parameter read tool with no annotations and no output schema, the description explains purpose and extraction targets but leaves the caller guessing about the response shape (e.g., per-proposal structure, empty results) and the 'Stage 1' pipeline relationship to deep_semantic_audit. Adequate minimum, but 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 description coverage is 100%, so limit, space_id, and use_curated_offline are already fully documented in the schema. The description only reinforces the space_id domain by naming Arbitrum, Aave, and ENS, which is marginal added meaning; baseline 3 applies.

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

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

The description names a specific verb+resource pair ('scanner for recent Snapshot DAO governance proposals') and even names the covered spaces (Arbitrum, Aave, ENS) plus the analysis output (target addresses, calldata payloads). It is unambiguous what the tool does, but it never references any sibling tool, so differentiation from deep_semantic_audit ('Stage 2' presumably) is left implicit.

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

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

The 'Stage 1 Free scanner' label hints that this is the cheap triage step before a deeper audit, but the description never states when an agent should call this versus deep_semantic_audit or scan_contract_selectors. Usage selection is only implied by the 'Stage 1 / Free' framing, not stated.

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