Use when you have an address AND/OR entity name/domain and need a signed multi-list receipt. Prefer over lion_wallet_screen when you need more than OFAC SDN. $0.02 Base USDC. [x402 paid: GET /api/x402/multi-sanctions-bundle-json]
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Entity/company name for multi-list screen | |
| domain | No | Optional domain trust check | |
| address | No | Crypto wallet for OFAC SDN address screen |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the tool generates a signed receipt, implies a cost of $0.02 Base USDC, and indicates an x402 payment endpoint. However, it doesn't clarify what 'signed' means, what happens if no parameters are provided (all are optional), or any behavioral side effects. Given the payment aspect, more transparency about the cost and authorization process would be helpful.
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, with three sentences and a cost note. It front-loads the primary use case and sibling differentiation. The x402 endpoint detail is somewhat niche but useful. Overall, it earns its place with minimal fluff, though the cost and endpoint details could be moved to annotations or a separate metadata field.
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 screening tool with no required parameters, the description does a decent job. It explains when to use it, differentiates from a key sibling, and mentions cost. However, it lacks information about the output format (what the signed receipt contains), error scenarios (e.g., invalid address), or whether any of the fields are truly required in practice. With no output schema, the agent has no idea what a valid response looks like. This is a notable gap.
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 the schema already documents each parameter. The description adds 'Entity/company name for multi-list screen' implicitly but doesn't add much beyond the schema. It does clarify that address is for OFAC SDN screening and domain is for trust check, but those are already in the schema. The description doesn't explain how parameters combine (AND/OR) or what happens if all are empty. Baseline 3 is appropriate since the schema covers it.
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 purpose: screening an address AND/OR entity name/domain against multiple sanctions lists and returning a signed receipt. It distinguishes itself from lion_wallet_screen by noting it covers more than OFAC SDN. However, the phrase 'multi-list receipt' could be clearer about the exact output, and the title is null, which slightly reduces clarity.
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 gives clear usage context: use when you have an address and/or entity name/domain and need a signed multi-list receipt. It explicitly says to prefer this over lion_wallet_screen when more than OFAC SDN is needed. However, it doesn't mention when NOT to use it or when to use other siblings like lion_compliance_bundle, so there's room for more differentiation.
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.