LION - keyless x402 data + RPC for agents

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

With no annotations, the description carries the full burden, and it does disclose one important behavioral trait: this is an x402 paid endpoint (GET /api/x402/adaptive-query, $0.005 on Base), which an agent needs to know before calling. It stops short of describing return shape, latency, 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?

A single front-loaded sentence that leads with capability and appends the payment metadata in a bracket. Efficient, though the parenthetical domain list and the bracket are densely packed together.

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 four-parameter tool with no output schema and no annotations, the description is inadequate: it never explains what the tool returns, how 'q' relates to 'domain'/'method', or what the mode values do. An agent has too little to invoke it confidently.

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 25% (only 'mode' is documented), so the description must compensate. It loosely maps the listed domains to the 'domain' parameter but says nothing about 'q' (the core query input) or 'method', leaving three of four parameters semantically unexplained.

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 identifies the resource as 'multi-source on-chain + market intelligence' and enumerates the domains it spans (dex, risk, yields, wallet, holders, rpc). However, it offers no specific verb describing the operation, and 'adaptive query' is broad enough that the agent cannot tell how this differs from siblings like lion_quick_intel or lion_token_risk_indicators.

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 guidance on when to use this tool versus the many lion_* siblings, no prerequisites, and no exclusions. The mode parameter ('auto|rpc|domain|social') hints that behavior varies, but the description never explains which mode applies when.

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, the description carries the full burden and does disclose meaningful traits: it is an x402 paid GET endpoint, costs $0.03 on Base, and is positioned as a taster with a paid upsell. Missing are return-shape, latency, and any auth/rate-limit context, so it is helpful but incomplete for a payment-gated 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?

The purpose is front-loaded, which is good, but the trailing bracket repeats the price already stated in the first line and packs curl-style endpoint syntax into prose. The '$0.03' duplication and mixed currency/endpoint notation make it denser than needed.

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 paid, no-annotation, no-output-schema tool, the description lists rough content categories but never states the response format or fields an agent should expect, and leaves the 'domain' parameter undocumented. It covers pricing and positioning but not enough for a caller to fully know what they receive.

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 50%: 'q' is documented as 'Company or domain' but the 'domain' parameter has no description anywhere. The '?q=coinbase.com' example clarifies that 'q' accepts a bare domain, but the description never explains the 'domain' parameter or the q-vs-domain relationship, leaving real 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?

States a specific verb+resource: 'KYB company dossier / company research pack' with three concrete components (web + firmographics + domain trust). It partially differentiates from siblings by naming the 'verified company file' it upsells and calling itself a 'taster'. However, it does not clearly distinguish itself from close siblings like lion_company_research or lion_company_enrich.

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: 'Vendor intel taster; upsell verified company file $0.95' hints this is a cheap surface-level call versus the deeper paid file, and the '?q=coinbase.com' example shows intended input. There is no explicit when-to-use/when-not statement or named alternative among the many 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?

No annotations are provided, so the description carries the behavioral disclosure burden. It earns credit for revealing the paid model and endpoint ('$0.04 Base USDC. [x402 paid: GET /api/x402/company-enrich]'), which is useful cost context. However, it doesn't disclose failure behavior, permission/auth requirements beyond payment, or output shape — meaningful gaps given zero annotation coverage.

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?

Four short clauses with zero filler, purpose front-loaded first, routing second, and cost/endpoint last. Every sentence earns its place, and the pricing line is information an agent needs before committing to a paid call.

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 no output schema and no annotations, the burden falls on the description. It adequately covers selection and cost, but omits invocation specifics (the identifier-vs-domain usage question) and gives no hint of the return contract. Adequate for routing, incomplete for a first-time caller executing the call without further digging.

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 75% (fields and format have descriptions; domain has none), so the schema does most of the work on documented params. But the description adds nothing about parameters and fails to resolve the inherent identifier-vs-domain ambiguity: identifier accepts 'name or domain' per schema, yet domain is a separate field — the description never clarifies when to use which, leaving a real invocation risk for the one required param.

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 with a concrete output scope: 'Firmographics only (name, employees, country, industry, website).' This precisely delimits what the tool returns and names the sibling it is not ('use lion_company_research for that'), leaving no ambiguity about the tool's role.

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?

Explicitly excludes the web-research alternative ('Not a web-research pack — use lion_company_research for that') and implies the selection condition through 'Firmographics only.' It doesn't fully enumerate when-not-to-use scenarios against the other six siblings, but the primary routing decision is crisply handled.

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, the description carries the full burden. It mentions that this is a 'one-shot' call, returns web/firmographics/domain trust, and costs $0.03 (implying a paid operation). However, it does not disclose whether the call has side effects, requires authentication, or has rate limits, and the output format is not described. This leaves gaps but is not misleading.

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 (three sentences) and front-loaded with the core purpose, followed by routing guidance and pricing. The inclusion of pricing is a small but useful addition. The structure is logical and free of fluff.

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 tool with no output schema, the description should clarify what data is returned. It provides a high-level summary ('web + firmographics + domain trust') but not the exact fields or response structure. It does include pricing and alternative routing, which are helpful. Given the low parameter complexity, this is adequate but not exhaustive.

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 both parameters are already documented. The description adds 'by name or domain' and mentions the domain override, but these are already implicit in the schema. The description adds no new semantic detail beyond the schema, so baseline 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 opens with 'Default company call' and specifies the resource (company research) and the scope ('one-shot web + firmographics + domain trust'). It clearly differentiates this from siblings by name, so an agent immediately understands it is the standard, all-purpose company lookup.

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?

Explicitly states when to use alternatives: 'Use lion_company_enrich if you only need name/employees/country' and 'Use lion_verified_company_file for KYB source trail.' This leaves no ambiguity about tool selection based on the data needed.

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 provided, so the description carries the full burden. It discloses the cost ($0.05 Base USDC), the access method (x402 paid endpoint), and mentions a 'signed receipt' as a deliverable. It does not explicitly state read-only nature or side effects, but given the tool is a data bundle, this is reasonable. The cost and endpoint disclosure adds significant behavioral context beyond a generic description.

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, consisting of two sentences. It front-loads the tool's essence ('Full counterparty pack') and includes all critical information (components, usage guidance, cost, endpoint) without any irrelevant fluff. Every word 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?

The tool is a bundle that combines multiple checks, and the description lists all components, clarifies the use case, and gives cost and access details. It does not describe the response structure or potential error handling, but given there is no output schema and the description already mentions a 'signed receipt' as an output, it covers what agents need to know to decide and invoke it correctly. A minor gap is not spelling out what happens on failure, but this is acceptable for a paid data endpoint.

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 descriptions for all 5 parameters, so the baseline is 3. The description does not add any new parameter semantics beyond what the schema already provides, except reinforcing the address requirement ('Needs an address') and implicitly connecting the 'domain' parameter to the bundle's 'domain' component. It adds no format or validation details, making it adequate but not enriched.

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 purpose: a 'Full counterparty pack' with specific components (OFAC, entity sanctions, domain, firmographics, signed receipt). It also explicitly differentiates from siblings by saying 'Use instead of stacking wallet_screen + research,' which names the alternative and the resource bundle being provided.

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 guidance: 'Use instead of stacking wallet_screen + research' indicates a superior alternative to combining other tools. It also states the prerequisite 'Needs an address,' which is a clear condition for use. This leaves no ambiguity about when an agent should invoke this tool.

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, the description carries the full disclosure burden, and it does supply genuinely useful behavior: keyless access (no API key), and x402 paid at $0.001 on Base. Missing are auth mechanics beyond 'keyless', rate limits, and what happens when optional params are omitted.

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 tight sentence with the capability statement front-loaded and the payment detail bracketed as secondary. Nothing is padded, though the compressed jargon trades clarity for brevity.

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, no annotations, and both parameters undocumented leaves too much unresolved for a paid multi-purpose bundle. The description does not say what the enrichment covers, what the return shape is, or how partial results are handled.

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 two parameters, and the description never mentions 'chain' or 'identifier'. The agent cannot tell whether identifier is a wallet, tx hash, domain, or entity name, nor what values 'chain' accepts, so the description 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 names the two bundled capabilities ('keyless RPC' and 'Ed25519-attested enrichment') and scopes them as multi-chain, which partly separates it from lion_keyless_base_rpc. However, there is no clear action verb or statement of what the composite result actually is, and 'composite bundle' remains jargon an agent must interpret.

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 when-to-use guidance, no conditions under which this bundle should be chosen over lion_keyless_base_rpc or lion_enrichment_tx_bundle, and no exclusions. The only routing signal is the price bracket, which tells the agent this call costs money but not when it is worth making.

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 provided, so the description carries the full burden. It discloses the decision semantics (which verdicts abort vs proceed), that the receipt contains an OFAC snapshot date and address count, and the pricing/cost ($0.01 Base USDC) and payment mechanism (x402 paid GET endpoint). It does not, however, describe what data source or freshness guarantee backs the OFAC snapshot beyond the date field, nor error/rate-limit 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?

Front-loaded with the operative question, then the verdict mapping, then routing guidance, then pricing. Every clause carries information; 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?

For a 2-param, no-required-param read tool with no output schema, the description covers purpose, routing, verdict semantics, receipt contents, and cost. The main gap is that neither required params nor failure modes are addressed, but the definition is otherwise self-sufficient 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 100% with both parameters fully documented (domain screened against entity-name lists, address checked against OFAC SDN snapshot). The description adds no syntax or format detail beyond the schema, so the baseline of 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 the decision the tool answers (should I pay this wallet), the mapping of verdict to action (STOP/HOLD abort, GO proceeds), and what the receipt contains. Distinguishes itself from lion_wallet_screen explicitly as a re-check rather than a first screen.

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?

Explicit when-to-use ('when paying this address again') and when-not-to-use with a named alternative ('Not the first screen — use lion_wallet_screen for that'). This is exactly the routing information an agent needs and rare to see this clearly 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?

With no annotations, the description carries the whole behavioral burden and does disclose the important traits: response attestation (Ed25519) and that access is paid via x402 at $0.004 on Base, which tells the agent a payment flow is required. It does not mention rate limits, error/failure behavior, or latency.

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 short telegraphic fragments, front-loaded with the resource and its identifiers. Dense and efficient, though the bracketed pricing fragment is slightly clunky and no fragment states an explicit action verb.

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 exist, so the description must stand alone; it sketches the returned content (product data plus shop prices), its provenance, integrity guarantee, and cost/access model. It stops short of describing result shape or pagination, which is a minor gap for a two-input lookup 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 100%, so both parameters are already documented as 'Product name search' and 'EAN/UPC barcode'. The description adds only the generic 'barcode or name' framing and no format or precedence detail beyond the schema, 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?

Names the resource (CPG product data plus shop prices) and the two lookup keys (barcode or name), and names the upstream sources (Open Food Facts, Open Prices). This is unmistakably distinct from every sibling, which are company/sanctions/web enrichment 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 phrase 'by barcode or name' implies the two entry modes, but there is no when-to-use versus when-not guidance and no hint about which key to prefer or whether both can be combined. Usage is inferable but not 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?

With no annotations, the description carries the full burden, and it does add real value by disclosing pricing behavior: this router is FREE while the downstream OFAC screen costs $0.001. However, it says nothing about what the router returns, latency, or any auth/permission requirements.

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?

Four short, front-loaded fragments that waste few words, with the free/paid framing leading. The telegraphic style is efficient, though the fragmented sentences are slightly cryptic rather than fully self-contained.

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 one-parameter router with no output schema, the definition covers routing choices but not what actually happens after the need is declared — no indication of the returned recommendation or next step. Adequate but with a clear gap around the tool's output behavior.

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% for the single 'need' parameter, so the baseline is 3. The description goes further by giving concrete example values for that field (a wallet-payment intent vs. 'recheck' vs. a company name), which meaningfully shapes how an agent should phrase the input.

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 labels itself 'FREE router' and hints at dispatching a stated need, but never plainly says the tool takes a plain-language need and routes it to the right sibling. The verb is implied rather than stated, leaving the core action somewhat opaque even though the routing intent is inferable.

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?

Strong routing guidance: it explicitly sends wallet-payment intents to the $0.001 OFAC screen, tells the agent to say 'recheck' only when paying the same wallet again, and routes company names to company research. Alternatives and their triggering conditions are named, though there's no explicit when-not-to-use-this-router statement.

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 exist, so the description carries the full burden, and it does contribute real behavior: it is a paid call ($0.03), settled on Base via x402, Ed25519-attested, and hits a specific GET endpoint. It omits what the response contains, latency, rate limits, and failure modes, so the safety/completeness picture is only half-drawn.

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?

It is front-loaded with the value proposition, which is good, but pricing is repeated twice, the alias and endpoint are both listed, and the upsell sentence consumes space that could carry usage guidance. Information density is high but some sentences do not earn their 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?

With no annotations and no output schema, the description must cover both behavior and return values; it covers payment model and attestation but says nothing about what research data comes back, which matters for a paid research call. Adequate but not complete for a tool at 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?

There is a single required parameter and schema coverage is 100%, so the baseline is 3. The trailing '?q=company or domain' restates the schema's own 'Company name or domain' description without adding format, normalization, or disambiguation guidance for ambiguous 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?

It names the resource (company research) and enumerates the constituent data sources (web, scrape, firmographics, domain trust), so the agent knows roughly what it does. However it never differentiates itself from close siblings like lion_company_research or lion_company_dossier, and the mix of 'company-research' alias with a 'deep-research-json' endpoint muddies what the tool actually is.

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 only placement guidance is 'Use before/after people enrichment', which gives context but no when-not or alternative-selection rule. With four or five near-identical research/enrichment siblings, the absence of explicit routing (e.g. vs lion_company_research or lion_quick_intel) 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?

With no annotations, the description must carry the behavioral burden, and it does add real value: cost ($0.005), payment rail (keyless Base USDC, x402 paid GET endpoint). 'Keyless' implies no API key is required, which is useful. Still missing are rate limits, latency, and what happens on payment failure or invalid domains.

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 payload is front-loaded and telegraphic, which suits a listing-style catalog, but the price is stated twice ($0.005 keyless Base USDC and again in the x402 bracket), which is redundancy. The bracketed endpoint syntax is useful but reads as implementation detail rather than agent-facing guidance.

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 no output schema and no annotations, the description does the right thing by naming the returned fields (DNS records and trust score), which is more than most peers. It is still thin on output shape, score scale, and error behavior for a paid mutation-of-state-free call, leaving the agent only minimally equipped.

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% and the single parameter is already documented as 'Domain e.g. stripe.com'. The description's '?domain=stripe.com' example restates that same example rather than adding new syntax or edge-case guidance, 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 states a concrete verb+resource (domain enrichment) and enumerates the returned data explicitly: live DNS MX/SPF/DMARC/A plus an HTTPS trust score. That is specific enough to know what the tool produces. However, it never differentiates itself from the sibling lion_domain_intel, which by name appears to cover overlapping domain-intelligence ground, so an agent cannot tell them apart from the 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?

There is no stated when-to-use, when-not-to-use, or alternative tool. The presence of lion_domain_intel as a near-namesake makes this omission costly. The only routing-adjacent information is payment mechanics, not task 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?

With no annotations at all, the description carries the full burden, and it does disclose two real behavioral traits: keyless access and a concrete cost ($0.005, with an x402/Base payment route). It says nothing about failure modes, timeouts, rate limits, or what the returned payload looks like, 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?

Front-loaded with the core value proposition and kept to two compact clauses. The bracketed x402 endpoint/price fragment is jargon-dense but earns its place by telling the agent an alternate paid access path exists.

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 no output schema and no annotations, the description is the sole source of information about the tool, and it covers inputs, signals, cost, and payment adequately on the surface. It stops short of describing the response shape, error behavior, or result freshness/latency for a 'live' probe, so an agent cannot fully anticipate the call's behavior.

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 required 'domain' parameter, so the description must compensate. It implies the domain is the subject being probed but gives no format guidance (bare hostname vs. URL, IDN/TLD handling), which is a mild but real gap for a one-parameter tool.

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 enumerates the exact signals produced (DNS MX/SPF/DMARC/A plus an HTTPS probe), so the agent knows precisely what it gets back. It does not, however, differentiate itself from the very similar sibling lion_domain_enrich, leaving ambiguity about which domain tool to pick.

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 use this versus alternatives, no prerequisites, and no exclusions despite several overlapping siblings (lion_domain_enrich, lion_web_enrichment_bundle, lion_quick_intel). The agent must infer usage from the signal list alone.

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, the description carries the full burden, and it does disclose two valuable operational facts: this is an x402 paid endpoint and the price ($0.005 on Base). That is genuinely useful. It does not say what happens if tx is omitted, whether payment/auth is required to execute, or what is returned.

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 sentence with the bundle name front-loaded and pricing metadata bracketed at the end. Efficient, though the redundant 'LION Research Bundle' prefix and the compressed pricing/logistics crammed into brackets slightly hurt readability.

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 composite bundle with no annotations and no output schema, the description should explain what the enrichment covers and how the two data streams combine. Instead it leaves the return content entirely undefined, so an agent cannot predict the value of the 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 100%, so both params (tx, identifier) are already documented in the schema. The description adds only the framing that tx supplies 'context' alongside the enrichment, which is marginally beyond the schema but not a substantive semantic addition.

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 it is a 'one-call enrichment + tx context' bundle, and the identifier param indicates company/org enrichment. However, 'enrichment' is a generic term that doesn't specify what kind of data is returned (firmographics, sanctions, financials?), so it only weakly differentiates from siblings like lion_company_enrich or lion_tx_receipt_decoded.

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 when-to-use guidance, no explanation of how the enrichment and tx components relate, and no routing to or away from the many sibling enrich/bundle tools. The agent gets no signal on when this composite is preferable to calling the individual 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?

With no annotations present, the description carries the full burden and does disclose a meaningful amount of behavior: it is keyless (no auth), costs $0.04, is billed through an x402 paid route on Base, and sources data from Wikidata+SEC. Missing are rate limits, failure behavior, and whether the identifier must be a domain, name, or LEI, which keeps it from 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 a single front-loaded line that leads with purpose, which is good. It is nonetheless crowded with pricing, upsell, HTTP alias paths and x402 boilerplate that compete with the actionable content, so it reads more like a marketing blurb than a tight tool spec.

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 no output schema, no annotations, and only three parameters, the description should do more than it does: it lists a few returned fields but never describes the response shape, and it omits the accepted identifier format. It is adequate to know roughly what the tool returns, but not complete enough to call it confidently.

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%: 'fields' and 'format' are described in the schema, while the required 'identifier' parameter has no description anywhere. The description restates format=apollo_org and lists returned field names that loosely map to the 'fields' parameter, adding marginal value, but it leaves the most important parameter (what kind of identifier is accepted) entirely unexplained.

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 does state a resource (company/org enrichment) and the fields returned (name, employees, country, industry, website), and it names the data sources (Wikidata+SEC). However, it never distinguishes this tool from the closely overlapping siblings lion_company_enrich, lion_org_enrich, lion_wikidata_firmographics and lion_company_dossier, and the '/company-enrich /org-enrich' aliases actually muddy the picture rather than clarifying which tool to pick.

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, when-not-to-use, or alternative-routing guidance. The only hint is the upsell line pointing at a richer verified company file at $0.95, which implies a tiering but never says when the $0.04 pack is insufficient or when to prefer lion_company_enrich / lion_org_enrich instead.

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, the description carries the full burden and does a good job: it discloses the PASS/BLOCK output shape, the fail-safe behavior when lists are unavailable, keyless access, Ed25519 attestation, and the x402 paid endpoint with price. It does not cover rate limits or what happens on ambiguous matches, but the operational profile is substantially clearer than most tools here.

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 purpose is front-loaded in the first clause, and the following sentences are dense but each carries distinct information (verdict, fail-safe, payment, endpoint). The bracketed x402 metadata is somewhat cluttered, but nothing is redundant 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?

There is no output schema, and the description does step in with PASS/BLOCK, which is adequate. However it never clarifies the relationship between the three input parameters or which sibling tools to prefer, leaving real gaps for an agent choosing among many sanctions-adjacent tools.

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 33%: 'name' is documented while 'entity' and 'company' carry no descriptions. The phrase 'company or entity name' in the description usefully signals that these three parameters are near-aliases for the same input, which partly compensates. It still does not tell the agent which one to prefer or whether they are truly interchangeable.

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 and resource: 'Screen a company or entity name against multi-list sanctions (OFAC/EU/UN public designations index).' That is concrete enough for an agent to know exactly what the tool does. It does not, however, differentiate itself from close siblings such as lion_sanctions_screen or lion_multi_sanctions_bundle, which matters given the crowded sanctions family.

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 guidance and no mention of alternatives. The description says the tool is 'fail-safe if lists unavailable' but never states which screening scenario this tool is for versus lion_sanctions_screen, lion_multi_sanctions_bundle, or lion_wallet_screen. The agent is left to infer routing solely from the 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?

With no annotations, the description carries the full burden and does disclose a critical behavioral trait: the endpoint is now x402-paid at $0.03 per call on Base. That pricing/payment disclosure is genuinely useful. However it omits authentication requirements, return format, and any rate/limit 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?

The leading 'Company research $0.03' is well front-loaded, but the second sentence is historical trivia about the path's past and the bracketed payment metadata is dense machine-oriented noise. Mixed signal-to-noise.

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 no output schema and no annotations, the description must do all the work, yet it never says what the returned research contains or how it is shaped. The 'free'/'paid' naming conflict also risks misleading an agent about cost.

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 50%: 'q' is documented in the schema and echoed by the '?q=stripe.com' example, but the 'domain' parameter is undocumented in both schema and description. The description adds no meaning beyond the schema's existing example.

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 the resource ('Company research') and equates it to /api/x402/company-research, so an agent can infer the output. However, the tool name says 'free' while the text says '$0.03', and the historical note ('used to return a free sample') muddies what the tool actually is today.

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 discloses that this path now costs the same as /api/x402/company-research, which implies an alternative exists, but it never says when to choose this over that sibling or over lion_company_research. No when-to-use or when-not guidance is 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?

With no annotations, the description carries the burden, and it does disclose meaningful traits: the $0.95 cost, that it is x402-paid on Base, and that it previously returned the dossier for free. That pricing/payment context is genuinely useful, but it omits auth requirements and any note on what the returned file 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?

The payload is short but redundant: the $0.95 price appears in both the opening sentence and the bracketed x402 line, and the internal path/URL strings add noise. The historical note is front-loaded ahead of any functional statement, which is not ideal ordering.

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 and no annotations, the description covers cost and equivalence to the paid endpoint, which is the key operational fact. It still lacks any description of file contents or response, leaving it only adequately 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?

There is a single parameter with 100% schema description coverage, so the schema already documents 'domain' with an example. The description's '?domain=stripe.com' sample duplicates the schema rather than adding new semantics, making baseline 3 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 names the resource (a verified company file) and price, and notes it returns the same file as /api/x402/verified-company-file-json, so an agent can relate it to sibling lion_verified_company_file. However, the tool is named 'free' while it charges $0.95, and the description leads with a historical note rather than a clean verb+resource statement, leaving the purpose somewhat muddled.

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 never states when to select this tool versus the sibling lion_verified_company_file, only that they are now equivalent in cost and output. There is no explicit when-to-use, when-not, or alternative-selection 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?

With no annotations, the description does carry real behavioral load: 'Keyless' conveys no API-key/auth requirement and the bracketed text discloses that this is a paid x402 endpoint with a concrete price. However it omits rate limits, error behavior, and explicit read-only confirmation, so the disclosure is only 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?

It is a single compact line with no wasted prose, but the structure is cluttered: pricing is stated twice (from $0.001 and the x402 bracket), and the query-string syntax and the HTTP endpoint are mixed into what should be a capability 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?

For a 3-parameter, single-required tool with no output schema and no annotations, the description covers the essentials (what it does, chains, keyless, cost) but says nothing about the response shape or error handling. Adequate but leaving clear gaps for a payment-gated external 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 100%, so the schema already documents chain, method, and params. The description adds only a chain value example ('?chain=ethereum'), which is redundant with the schema's 'base|ethereum' enumeration. Baseline 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?

States a specific verb and resource: 'Keyless multi-chain JSON-RPC reads, Base + Ethereum,' so an agent immediately knows this is a raw RPC proxy for two chains rather than an enrichment tool. It distinguishes itself from the research/enrichment siblings by being a low-level chain read, though it doesn't name a sibling directly.

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 guidance, no indication of when this RPC proxy is preferred over enriched siblings like lion_tx_receipt_decoded or lion_token_risk_indicators, and no prerequisites. The only usage hint is the '?chain=ethereum' example, which maps a parameter rather than a decision.

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, the description carries the burden and does a good job: it discloses the keyless/no-API-key auth model, the upstream source (api.gleif.org Golden Copy), the returned fields (LEI, jurisdiction, registration status, LOU), and the $0.005 USDC x402 cost on Base. It doesn't mention rate limits, caching, or error behavior, so it falls 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?

The operational details are front-loaded and useful, but the sentence is bloated with SEO keyword stuffing ('Matches: LEI, GLEIF, legal entity identifier, LEI lookup, company LEI') and a bracketed endpoint/pricing restatement that duplicates the earlier cost line. Those clauses don't help an agent select or invoke the tool.

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-optional-param lookup with no output schema and no annotations, the description supplies source, auth model, cost, and the shape of returned fields, which is close to sufficient. It leaves out response structure details and any guidance on which key to prefer, keeping it short of a 5.

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 all three parameters including the 20-char LEI format and the domain-to-name mapping. The description's 'by LEI code, legal name, or domain' adds nothing beyond the schema. Baseline 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?

States a specific verb+resource (GLEIF LEI lookup / Legal Entity Identifier search) and names the three lookup keys (LEI code, legal name, domain). The resource is distinct enough from the deep-research and enrichment siblings that an agent can recognize it without opening the schema, though it never explicitly contrasts itself 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?

It describes the data source and payment model but gives no when-to-use guidance, no conditions for choosing LEI vs name vs domain, and no alternatives named against the many sibling lookup/enrich tools. The agent must 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?

With no annotations, the description must carry the behavioral load; it usefully discloses that this is a paid x402 endpoint at $0.02 on Base and gives the underlying GET route. That cost/payment context is real added value, but it omits auth specifics, whether calls are idempotent, and any response characteristics.

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?

One compact sentence that front-loads purpose, then input modes, then payment metadata. No filler; every clause carries 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 three-parameter tool with no annotations and no output schema, the description covers purpose, accepted inputs, and cost, but says nothing about the returned solar/location fields that an output schema would otherwise supply. Adequate but with a visible gap around return values.

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%, so the description must compensate. It does convey the key semantic that address or lat/lon are alternative input modes, which the schema (three flat optional properties) does not express. However, it doesn't clarify that lat and lon must be supplied together, nor any format or range constraints.

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 combined capability ('Location + solar PV potential for sites/properties'), which an agent can immediately distinguish from the company/domain/sanctions siblings. The verb is implicit (enrichment), but the outcome is concrete.

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 use this versus other lion_* enrichment tools, nor any prerequisite or exclusion. The only guidance is implicit in the input syntax, which tells the agent nothing about tool selection.

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 are absent, so the description carries the full burden. It discloses that the operation is paid ($0.02 USDC) and indicates the output is a signed receipt. However, it does not explicitly state whether the tool is read-only, what side effects exist, or how the signed receipt is produced. The cost and payment method provide some transparency, but more detail about data handling and limitations would be expected.

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 primary use case. It packs essential information (when to use, alternative tool, pricing, payment endpoint) into a few sentences without redundancy or 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 tool has no output schema, so the description must clarify return value. It mentions a 'signed multi-list receipt' but does not specify which sanctions lists are covered (beyond implying multiple) or the structure of the receipt. It also lacks information on error handling, authentication requirements beyond payment, and any prerequisites. This is a moderate gap given the tool's 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 coverage is 100% since each parameter has a description. The description adds context by stating that the inputs are alternative combinations (address AND/OR entity), which aligns with the schema's optionality. However, it does not significantly deepen understanding beyond the schema's own descriptions, so the baseline score 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 clearly states the tool's purpose: obtaining a signed multi-list sanctions receipt given an address and/or entity name/domain. It uses a specific verb and resource and distinguishes itself from lion_wallet_screen by noting it goes beyond OFAC SDN.

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 explicitly provides usage context ('Use when you have an address AND/OR entity name/domain'), names a sibling alternative (lion_wallet_screen), and states the condition for preferring this tool ('when you need more than OFAC SDN'). It also gives pricing and payment details, which are practical usage considerations.

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, the description carries the full burden, and it does add real operational facts: $0.04 cost, keyless access, apollo_org output format, and the x402 paid endpoint on Base. It omits whether the call is read-only, what happens on a miss, rate limits, and the response shape, so it is useful but incomplete.

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?

Dense and front-loaded with the core purpose first. Minor waste: the $0.04 price is stated twice (in prose and again in the x402 bracket), and the Apollo/x402 jargon adds noise without clarifying behavior.

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 an enrich tool with no annotations, no output schema, and zero schema coverage, the description supplies some pricing/payment context but leaves the return payload, identifier syntax, and field-selection mechanics unstated. Adequate but with real gaps an agent may need to 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%, so the description must compensate for three undocumented parameters. It gestures at each: 'domain or name' for identifier, 'format=apollo_org' for format, and the field list for fields, but never matches these to the actual parameter names or gives value syntax.

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+resource (company enrichment) and enumerates the returned firmographics (name, employees, country, website), plus the accepted input key (domain or name). However, it does nothing to separate itself from overlapping siblings like lion_company_enrich, lion_domain_enrich, or lion_wikidata_firmographics, 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?

'Firmographics by domain or name' implies acceptable input, but there is no when-to-use guidance, no exclusion, and no pointer to the many adjacent enrichment tools an agent could pick instead. The agent is left to guess which enrichment sibling is appropriate.

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, the description carries the full burden, and it does disclose useful behavior: keyless access, OSM as the data source, an x402 payment endpoint, and a $0.01 cost on Base. That payment/cost disclosure is genuinely valuable. It still omits what the search returns, latency, rate limits, and how lat/lon vs q interact.

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 line that leads with the purpose and appends access/pricing metadata in brackets. Minimal waste, though the x402 bracket is dense and could have been split for readability.

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-param search tool with no annotations and no output schema, the description covers source and cost but leaves parameter semantics and return shape unspecified. It is minimally adequate for invocation but not for confident selection or correct argument usage.

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 3 parameters, and the description explains none of them. Only 'q' (query) and lat/lon (coordinates) can be guessed from the POI framing; there is no statement of format, coordinate convention, or whether q is required alongside coordinates.

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+resource (POI/business search) and adds distinguishing context via '(keyless, OSM)', which differentiates it from company/dossier siblings. However, it never names an alternative tool or explicitly contrasts with lion_web_search or lion_scrape, so differentiation is implied 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 when-to-use or when-not-to-use guidance. 'keyless' hints at an access mode but not a selection condition, and no alternative sibling is named despite 30+ siblings in the set. The agent must infer usage entirely.

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 provided, the description must carry the full burden. It only discloses that the tool is free and returns a teaser (not a full dossier), which is output scope rather than behavioral traits like request handling, potential failures, or response structure. No mention of network calls, authentication, or limitations beyond the 'free' label.

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 fluff. The core message is front-loaded ('FREE teaser for a company/domain') and the upgrade info is precise. Every word serves a purpose.

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 tool with no output schema and an undocumented parameter, the description is insufficient. It doesn't specify what the teaser contains, how the entity should be formatted, or what the response looks like. The upgrade path gives some context but leaves essential operational details missing.

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 'entity' has zero schema description and zero coverage. The description mentions 'company/domain' but doesn't clarify the expected format (e.g., domain name, company name, URL) or give examples. This is minimal compensation for a completely undocumented 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 clearly states it provides a 'FREE teaser for a company/domain' and explicitly says it does not return a full dossier, distinguishing it from lion_company_research and lion_verified_company_file. The purpose is specific and separates it from siblings, though it doesn't define what a 'teaser' includes.

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 directly names the upgrade tools (lion_company_research, $0.03; lion_verified_company_file, $0.95) and implies these are for when full data is needed. This tells the agent when to use this free teaser versus the paid alternatives, though it doesn't mention any exclusions or conditions like rate limits.

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 the description carries the full burden, and it discloses meaningful traits: cost ($0.005), payment mechanism (x402 paid GET on Base), and that results are Ed25519-attested. It omits auth requirements for the paid call and what a match vs no-match response looks like.

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?

Front-loaded with the core question, followed by a compact comparison, provenance, and endpoint metadata. The parenthetical is dense but every clause earns its place and nothing is padding.

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 exists, so return shape rests partly on the description; 'fuller fields + multi-list metadata' hints at the response and the pricing/attestation round it out. It is adequate for a one-parameter screen, though a bit more on match output would help.

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 'address' parameter is fully described in the schema (100% coverage: 'EVM address to OFAC SDN / sanctions screen'). The description says 'this address' but adds no format, chain, or validation detail beyond the schema, so the baseline of 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 opening question 'Is this address on the OFAC SDN list?' states a specific verb and resource, and the parenthetical 'same list as $0.001 wallet-screen, fuller fields + multi-list metadata' explicitly distinguishes it from the lion_wallet_screen sibling. Address-scope also separates it from lion_entity_sanctions_screen.

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 names an alternative (the $0.001 wallet-screen over the same list) and gives the condition that selects this one: fuller fields plus multi-list metadata. It stops short of a full when-not set, e.g. it does not contrast with lion_multi_sanctions_bundle or lion_entity_sanctions_screen.

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, the description carries the full burden, and it does disclose the important behavioral facts that access is keyless and that calls cost $0.02 USDC on Base via an x402 paid endpoint. However it says nothing about rate limits, timeouts, failure/refund behavior, or what happens when the target URL is unreachable, which matters for a paid operation.

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?

Front-loaded with the core purpose and output shape, which is good, but the pricing is stated twice ('$0.02 Base USDC' and the bracketed x402 line) and the bracketed clause is dense protocol jargon that mixes an endpoint path into a tool description.

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, the description does supply the return shape and the payment model, which is the minimum an agent needs. It is still thin on operational behavior (errors, limits, large-page handling) that a paid scraping tool should surface.

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 exists and schema coverage is 100%, so the schema already documents 'url' as an absolute http(s) URL. The description's '?url=' notation adds a query-parameter framing but no new semantic detail, so the baseline of 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+resource ('Keyless attested web scrape') and even sketches the return shape ({ title, markdown, word_count }), so an agent knows exactly what comes back. It does not explicitly name or contrast itself with the closest sibling (lion_web_search), which keeps it below 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?

There is no when-to-use guidance, no exclusions, and no pointer to alternatives such as lion_web_search or lion_web_enrichment_bundle. The agent must infer that this tool is for fetching a single URL's readable content.

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, the description carries the full burden. It does disclose useful behavioral context: keyless access, attested data, and payment/price via x402 on Base. But it says nothing about return contents, rate limits, or reliability, leaving significant gaps for a data-fetch 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?

A single dense sentence with the resource front-loaded and no filler. The bracketed pricing detail is compact and informative, though its density slightly crowds the core purpose.

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 annotations, no output schema, and 0% parameter coverage mean the description should compensate but does not. It never explains what financials are returned or how to select between the two identifier parameters.

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 neither 'cik' nor 'ticker' is mentioned in the description. The agent gets no guidance on which identifier to supply, their formats, or whether one is preferred over the other.

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 resource (SEC EDGAR financials for public companies), which is clear and distinguishable from most siblings. However it does not name or contrast with sibling alternatives, so an agent must infer differentiation.

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 explains access models (keyless, attested, x402 paid at $0.005) but gives no when-to-use guidance relative to the many sibling research/enrichment tools. No conditions, prerequisites, or alternatives are mentioned.

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, the description carries full burden and does disclose useful operational facts: keyless access (no auth) and an x402 payment of $0.004 on Base via GET. It omits rate limits, return shape, and failure modes, so it is helpful but not complete.

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 compact line with the core identity front-loaded and pricing/access details bracketed at the end. Nothing is wasted, though the parenthetical packs several distinct concepts into one sentence.

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 tool with three undocumented parameters, no output schema, and no annotations, the description should at least sketch argument semantics and return content. It covers cost and access but leaves the agent guessing about how to build a valid call and what comes back.

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?

Three parameters (q, topic, entity) with 0% schema description coverage, and the description explains none of them — not whether they are alternatives, combinable, or which is preferred. The names are loosely self-evident, but the description 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?

Identifies the resource (social signal intelligence) and its data sources (HN + Reddit) and the dimension it measures (attention/trend), which separates it from sibling enrichment/search tools. No explicit verb is given ('fetch'/'analyze'), but the intent is unambiguous.

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 choose this over lion_web_search, lion_quick_intel, or the other 30+ siblings, and no conditions or exclusions. Usage can only be inferred from the name and source list.

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 provided, so the description carries the full burden. It usefully discloses the payment model ($0.03, Base USDC, keyless x402 paid endpoint), which is real behavioral context, but says nothing about latency, rate limits, or what happens on an unknown token.

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?

Front-loaded with purpose, which is good, but the pricing is stated twice ('$0.03 Base USDC keyless x402' then again bracketed 'price $0.03 on Base') and the bracketed endpoint text reads like raw metadata rather than agent-facing prose.

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 no output schema and no annotations, the description should explain what the risk indicators actually contain on return, and it does not. An agent knows the price and the input but not the shape or scope of the result.

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 both parameters are already documented in the schema. The description's chain list mirrors the schema's 'base|ethereum|solana' enum-like description rather than adding new meaning, 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 resource (token risk indicators) and use case (pre-trade) and enumerates supported chains (Base/Eth/Solana). It is clearly the only token-risk sibling in the list, though it never names another tool to explicitly differentiate itself.

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 'Pre-trade' implies the context in which to reach for it, but there are no explicit when-not conditions or named alternatives among the many lion_* siblings. Usage is implied rather than instructed.

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 provided, so the description carries the full burden. It usefully discloses that this is an x402-paid endpoint (GET /api/x402/tx-receipt-decoded-json, $0.01), which is real behavioral context an agent needs before calling. However, it says nothing about auth mechanics, rate limits, or failure modes.

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 compact line with the core purpose front-loaded and payment metadata bracketed at the end. Efficient, though the mixed formatting (query-param example plus pricing block) is slightly cryptic.

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 one-parameter lookup with no output schema and no annotations, the description covers what is returned (receipt + decoded calldata) and the cost of the call. It lacks return-format specifics and error semantics, but is broadly sufficient to invoke 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 description coverage is 100% for the single tx parameter, so the schema already documents 'Base tx hash 0x...'. The description's '(?tx=0x...)' merely restates the same format, adding no value beyond the schema; 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: fetching a Base transaction receipt plus decoded calldata. It clearly distinguishes itself from generic RPC siblings like lion_keyless_base_rpc by promising decoded calldata, though it never names siblings 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?

Gives no when-to-use guidance, no conditions, and no mention of alternatives such as lion_keyless_base_rpc for raw receipt access. Usage is only weakly implied by the resource name and the '?tx=' example.

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 exist, so the description carries the full burden. It does disclose two genuinely useful behavioral facts — the lookup is keyless and an x402-paid variant exists at $0.005 on Base — but it says nothing about failure modes, rate limits, or what happens with malformed input, leaving key behavior undocumented.

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 with no filler; the distinction between the keyless VIES call and the paid x402 endpoint is placed up front. The bracketed pricing/endpoint metadata is dense and slightly disrupts readability but is not wasted space.

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 no output schema and no annotations, the description should explain what a validation returns (valid/invalid status, matched company name/address) and how the alternative parameter forms behave, and it does neither. For a 3-parameter tool with a third of the schema undocumented, this is materially 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 coverage is only 33% (just 'vat' is documented). The description's phrase 'VAT / tax ID' hints at the two input forms but does not explain the relationship between 'number' and 'country' (i.e. that they are the split alternative to a full VAT string), so it fails to 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?

States a specific verb+resource ('EU VAT / tax ID validation') and the backing service (VIES), which is enough to distinguish it from the company/enrichment siblings that populate this toolset. It never explicitly contrasts itself with any sibling, and the bracketed payment string muddies the otherwise clear one-line purpose.

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 when-to-use guidance, no indication of when to prefer this over a broader company/enrichment tool, and no prerequisites (e.g. whether the VAT number must include the country prefix). Only the implied 'use this to validate a VAT number' is present.

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 provided, so the description carries the full burden. It discloses the cost ($0.95 Base USDC), the paid endpoint, and that it is not a first call. However, it does not describe the output format (JSON, file), error behaviors, or data freshness. It also implies a read operation via the GET endpoint but does not explicitly state it. These gaps limit its transparency in a context where annotations are absent.

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 purpose. It includes usage guidance and cost in a few short sentences. Minor redundancy exists with the cost mentioned twice ('$0.95' in the first sentence and again as '$0.95 Base USDC'), which slightly detracts but does not undermine readability.

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 and no annotations, the description covers the essential context: purpose, usage order, cost, and endpoint. However, it omits what the returned 'dossier' looks like (e.g., JSON structure, fields) and does not address potential failure modes. Given the tool is part of a pipeline (not a first call), the missing output details may mislead the agent about the response shape.

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% and the schema already clearly explains the domain parameter ('Company website domain e.g. stripe.com (not a full URL)'). The description only repeats 'by domain' without adding extra constraints or conversion details, so it adds no value 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?

The description states precisely what the tool does: it returns a 'Full attested KYB dossier by domain', which is a specific resource. It also differentiates itself from siblings by noting it provides a 'per-field source trail' and is meant 'after lion_company_research/enrich', making its role clear relative to the other 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?

Explicitly lists when to use: 'Use after lion_company_research/enrich when you need per-field source trail' and when not to: 'Not a first call'. This leaves no ambiguity about the intended chain of tool usage and the decision 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?

No annotations are provided, so the description carries full burden for behavioral disclosure. It mentions the tool returns PASS/WARN/BLOCK and notes a $0.001 Base USDC cost, indicating a paid operation. However, it does not explicitly state whether the operation is read-only, nor does it mention rate limits, authentication, or any side effects beyond cost. This is reasonable for a simple screening tool but not exhaustive.

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 extremely concise, consisting of three short sentences: usage condition, exclusion with alternatives, and cost/endpoint. Every sentence earns its place, and the most critical usage information is front-loaded. No fluff or redundant 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 tool with a single parameter and no output schema, the description covers all essential aspects: when to use, what it returns (PASS/WARN/BLOCK), cost, and endpoint. It distinguishes from siblings and specifies the address type. There is no missing information an agent would need to correctly invoke 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 100% for the single 'address' parameter, which is clearly described as 'EVM 0x…'. The tool description adds context that this is for payments but does not provide additional syntax or constraints beyond the schema. With high schema coverage, the baseline of 3 is appropriate; the description adds minimal extra meaning.

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 a 0x wallet address to obtain a PASS/WARN/BLOCK verdict before payments. It explicitly disambiguates from sibling tools by noting it is not for company names, directing to lion_multi_sanctions_bundle or lion_compliance_bundle instead. This clearly identifies the verb (screen/check), resource (wallet address), and expected output.

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?

Provides explicit when-to-use (when holding a 0x address and needing a compliance decision before paying) and when-not-to-use (for company names) with named alternative tools. Also mentions the cost and the specific API endpoint, which gives practical usage context beyond basic conditions.

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 provided, so the description carries the full burden. It does disclose genuinely useful behavior: the operation is keyless (no auth) and is x402-paid ($0.005 on Base), which tells the agent it will incur cost. However, it says nothing about what data is returned, rate limits, or error 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?

It is a single, compact sentence with the payment/endpoint detail appended in brackets. Nothing is padded, though the terse style pushes useful information into a dense bracketed clause rather than clearly front-loading the core purpose.

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 no output schema, no annotations, and 0% parameter documentation, the description needs to do the heavy lifting and falls well short. An agent knows the tool is paid and keyless but not what it returns or how to invoke it correctly with the two parameters.

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 compensate for the two undocumented parameters 'domain' and 'identifier', and it does not mention either. The parameter names are somewhat self-explanatory, but the description adds no meaning about their expected format or how they interact.

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 phrase 'company enrichment vectors' gestures at a resource and action, but 'vectors' is undefined jargon that does not clarify what the tool actually returns. With siblings like lion_company_enrich, lion_org_enrich, and lion_domain_enrich present, the description provides no basis for telling this tool apart from the others.

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 use this tool or how it differs from the many sibling enrichment tools. The only contextual cue is a payment note, which does not guide selection between alternatives.

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, the description carries full burden and does add real context: it is keyless (no auth), costs $0.025 USDC on Base via x402, and returns an Ed25519-attested result set. Payment model and attestation are meaningful disclosures, but rate limits, error behavior, and result shape are absent.

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?

Front-loads the core purpose well, but the pricing is stated twice ($0.025 Base USDC and again in the bracketed x402 line) and the dense notation ('agent-search band', '(?q=)') is cryptic. It is compact but has redundancy and could be tighter.

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 paid, attested search tool with no annotations and no output schema, the description covers cost and verification but omits return format, result count, and failure handling. Adequate but leaves gaps an agent must discover by calling.

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% for the single 'q' parameter, so the baseline is 3. The description's '(?q=)' only restates the query parameter name, adding no syntax or format detail beyond what the schema already documents.

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 ('web search') with a clear purpose qualifier ('for agent grounding'). It distinguishes itself from data-enrichment siblings like lion_scrape or lion_deep_research by being a plain keyless search, though it never names an alternative to route against.

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?

'for agent grounding' implies a use context but gives no when-to-use vs. when-not guidance and never references any of the many sibling research/scrape tools. The agent must infer routing entirely on its own.

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, the description carries the full behavioral burden, and it does disclose genuinely useful non-obvious traits: no API key required, CC0 licensing, and a paid x402 route with an explicit price ($0.005) and network (Base). It says nothing, however, about return format, rate limits, or failure modes, 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?

A single sentence that front-loads the resource and tucks the payment metadata into a bracketed suffix. Almost no waste, though the bracketed endpoint/price string is dense and slightly obscures the core purpose.

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?

There is no output schema and no annotations, and the description does not explain the three unlabeled parameters or what firmographic fields are returned. For a tool with three undocumented inputs and no structured safety or return information, this is well 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 0% and the description never mentions the q, qid, or entity parameters, their formats, or whether they are alternatives. Three fully undocumented parameters with no compensating text in the description leave the agent guessing how to call 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 names a specific resource (Wikidata firmographics) and adds distinctive qualifiers (keyless, CC0, paid x402 endpoint), so an agent knows it is a firmographic lookup backed by Wikidata. However there is no verb and no differentiation from the many overlapping company-enrichment siblings (lion_company_enrich, lion_org_enrich, lion_company_dossier), leaving the purpose only partially pinned down.

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 use this tool versus the numerous sibling enrichment/dossier tools, no prerequisites, and no hint about which of the three params to supply. The only routing signal is the implicit 'keyless/CC0' framing, which an agent must interpret on its own.

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