Pre-sign wallet firewall: decode a transaction and flag unlimited approvals, setApprovalForAll, scam addresses, and spend-cap breaches before signing. Returns a risk verdict + reasons. (security; $0.008/call in USDC via x402, 25 free/day).
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | ||
| data | No | Calldata (0x...). | |
| from | No | ||
| chain | No | ||
| value | No | Native value in wei. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It reveals that the tool decodes transactions, flags specific risk types, and returns a risk verdict plus reasons. It also transparently mentions the cost per call and free tier. This is good behavioral context, though it doesn't cover edge cases like error handling or privacy implications.
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 concise and front-loaded with the core purpose ('Pre-sign wallet firewall'). It packs key details into one sentence with an appended cost/free-tier note. No redundant words; every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, 1 required, no output schema, and no annotations. The description explains the high-level purpose and return value ('risk verdict + reasons') but does not specify input semantics or provide examples. For a security-critical transaction tool, more detail on how the parameters interact would improve completeness. It is adequate, but gaps remain.
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 40% (data and value have descriptions; to, from, chain do not). The description does not compensate by clarifying the transaction parameters or their formats. It mentions 'decode a transaction' but not what 'to', 'from', 'chain' mean or how they are used. Since coverage is low and the description adds no parameter-specific meaning, the agent is left under-informed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Pre-sign wallet firewall: decode a transaction and flag unlimited approvals, setApprovalForAll, scam addresses, and spend-cap breaches before signing.' It uses a specific verb ('decode') and identifies the resource ('transaction') and the outcome ('risk verdict'). This distinguishes it from sibling tools like check_domain or render_page, which deal with web/content inspection.
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 explicitly says 'before signing', giving a clear time/context for use. It also mentions the security purpose and cost, which helps the agent decide whether to invoke it. However, it does not name alternative tools or state when not to use it, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools have clearly distinct purposes, but there are overlapping pairs: unfurl_url/get_oembed/find_favicon all provide URL metadata, and render_page/screenshot_page both render a page (render_page can also screenshot). Descriptions help disambiguate, so only minor confusion is likely.
Tool names mix verb_noun patterns (check_domain, extract_content) with noun_verb patterns (dns_lookup, ssl_lookup, whois_lookup). Additionally, guard_inspect and guard_tx deviate from the typical verb-first style. The naming is readable but not consistent.
With 19 tools, the server is at the heavier end of the scale. While it covers a broad web-intel toolkit, several tools feel out of place for a 'fetcher' (e.g., generate_qr, guard_tx, guard_inspect), making the set feel bloated and unfocused.
The core web-fetching and analysis surface is well covered: DNS, WHOIS, SSL, headers, content extraction, rendering, screenshots, feeds, embeds, redirects, and robots. Missing is a simple raw HTML fetcher, but extract_content and render_page likely cover most needs. The addition of security and utility tools doesn't fill obvious gaps.
