Use when you have a 0x address and need PASS/WARN/BLOCK before paying anyone. Not for company names — use lion_multi_sanctions_bundle or lion_compliance_bundle. $0.001 Base USDC. [x402 paid: GET /api/x402/wallet-screen-json]
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Crypto wallet address to OFAC SDN screen (EVM 0x…) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds significant context: discloses the cost ($0.001 Base USDC), the HTTP method and endpoint (GET /api/x402/wallet-screen-json), and the output type (PASS/WARN/BLOCK). This goes beyond a typical bare description. It does not mention rate limits or explicit read-only status, but the GET method implies read-only, and the cost disclosure is valuable.
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 compact and front-loaded with the core usage condition. It packs usage, exclusions, alternatives, cost, and endpoint into three sentences with zero redundancy. Every sentence contributes unique information.
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 single-parameter tool with no output schema, this description is relatively complete: it covers purpose, usage conditions, alternatives, cost, and endpoint. The return format (PASS/WARN/BLOCK) is mentioned, though not detailed (e.g., data structure). It omits edge cases like invalid addresses or timeouts, but for the simplicity of the tool this is acceptable.
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 the parameter is already fully documented in the schema (Crypto wallet address to OFAC SDN screen, EVM 0x…). The description adds usage context (before paying, not company names) but does not add new technical details about the 'address' parameter beyond the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific use case: screening a 0x wallet address before payment, with an expected outcome of PASS/WARN/BLOCK. It clearly distinguishes itself from sibling tools by explicitly saying it's not for company names and naming the appropriate alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit when-to-use (when you have a 0x address and need to screen before paying) and when-not-to-use (company names), and points to specific alternatives: lion_multi_sanctions_bundle and lion_compliance_bundle. No ambiguity remains about when to select this tool.
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.
Each tool has a clearly defined purpose with explicit usage notes, e.g., lion_company_enrich is firmographics-only while lion_company_research adds web data, and lion_verified_company_file provides a full source trail. Even overlapping tools like wallet_screen and multi_sanctions_bundle are scoped by input type and desired output, leaving no ambiguity.
All tools follow a strict 'lion_' prefix with snake_case descriptive names (e.g., lion_company_enrich, lion_wallet_screen). The verb-noun pattern is consistent across the set, making it predictable and easy to navigate.
With exactly 8 tools, the server is well-scoped for its stated purpose of x402 data and RPC. The count is neither bloated nor thin, and each tool addresses a distinct use case from quick intel to full compliance bundles.
The tool surface covers the full lifecycle of company and Sanctions screening: free tier (quick_intel, declare_need), enrichment, research, sanctions (wallet_screen, multi_sanctions_bundle), and verified KYB (verified_company_file). No obvious gaps like missing update/delete actions exist, and all core workflows end in a paid path without dead ends.