LION - keyless x402 data + RPC for agents

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

No annotations are provided, so the description must carry behavioral disclosure. It discloses cost ($0.04 USDC), payment method (x402 paid), and endpoint (GET /api/x402/company-enrich). It also scopes output to firmographics. However, it does not describe error handling, latency, rate limits, or what happens on invalid input. Given the tool's simplicity, this is adequate but not rich. A 3 is appropriate as it meets the minimum without being exceptional.

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 two sentences with zero fluff. It front-loads the core scope ('Firmographics only'), then immediately differentiates from the sibling, and finishes with practical cost and endpoint details. Every sentence earns its place.

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

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

For a simple enrichment tool with no output schema, the description covers essential context: scope, alternative, cost, and payment method. It doesn't mention format defaults or error behavior, but given the simplicity and absence of output schema, these are less critical. The description is sufficient for an agent 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 75%, with 'fields' and 'format' documented. The description adds context that available firmographics include name, employees, country, industry, and website, which hints at what fields might be accepted but doesn't map directly to parameters. 'domain' and 'identifier' still lack descriptions, though 'identifier' has a schema description. The description adds modest value beyond schema, so a baseline of 3 is warranted.

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 exactly what the tool does: firmographics (name, employees, country, industry, website). It explicitly contrasts with lion_company_research, making distinction clear. Specific verb 'enrich' is implied, and the scope 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?

The description provides a clear exclusion: 'Not a web-research pack — use lion_company_research for that.' This tells the agent when NOT to use it and points to the alternative. It implies the use case (firmographics) but doesn't elaborate on conditions like required fields or limitations. Still, the exclusion is valuable and explicit.

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 of behavioral disclosure. It does not describe side effects, safety, authentication requirements, rate limits, or what happens to data. While it mentions the cost and paid endpoint, it omits critical behavioral details such as whether this is a read-only operation, what the response format is, or any error conditions. The 'one-shot' term is ambiguous. This is a significant gap for a tool with no annotation support.

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 main purpose, followed by explicit routing to alternatives and pricing/endpoint info. Every clause serves a purpose: differentiation, pricing, and alternative routing. However, it could be slightly more structured (e.g., a clear separation of 'what it does' vs 'how to pay'), but as a single paragraph it is efficient and readable.

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

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

Given there is no output schema, the description should explain what the tool returns or at least the nature of results. It mentions 'web + firmographics + domain trust' but doesn't specify the output format, pagination, or error behavior. It also lacks explanation of what 'one-shot' means. The cost and paid endpoint are useful, but the absence of return-value description makes the tool incomplete for an agent, especially with no schema or annotations to fill the gap.

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

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

Schema description coverage is 100% for both parameters (q and domain), so the schema already documents them. The description mentions 'by name or domain' which aligns with q but adds no additional meaning beyond what the schema provides. The optional domain override is also self-explanatory from the schema. Baseline 3 is appropriate when schema does the heavy lifting and the description adds little extra semantic value.

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 performs company research combining web data, firmographics, and domain trust, and it explicitly differentiates from sibling tools lion_company_enrich and lion_verified_company_file. The verb 'call' and resource 'company' are clear, and the 'Default company call' phrase sets it as the primary option. This is a specific and distinguishable 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?

Explicit usage guidance is provided: 'Use lion_company_enrich if you only need name/employees/country' and 'Use lion_verified_company_file for KYB source trail.' This tells the agent exactly when to choose alternatives, covering both the main use case and exclusions. Nothing is left to inference.

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 discloses the paid nature ($0.05 Base USDC, x402 endpoint), the components included, and the requirement of an address. However, it does not explicitly state whether the operation is read-only or has any side effects, which is a minor gap for a screening 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 description is a single, dense sentence that packs the purpose, cost, endpoint, and alternative usage, with the main function front-loaded. There is no filler or redundancy.

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 description lists all bundle components but does not explain how optional parameters map to those components—for example, whether providing a domain is required to get domain checks. There is no output schema, and the response format is not described, leaving ambiguity for a tool with 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?

The schema provides full descriptions for all five parameters (100% coverage), so the description adds little beyond reinforcing that an address is required. It mentions domain and receipt but does not elaborate on their role in the bundle, so it contributes marginal value over 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 clearly states the tool's function as a compliance bundle covering OFAC, entity sanctions, domain, firmographics, and signed receipt. It also explicitly differentiates it from sibling tools by saying 'Use instead of stacking wallet_screen + research,' making its purpose and scope 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?

The description provides direct guidance on when to use this tool, explicitly naming the alternative (stacking wallet_screen + research) and the condition (needs an address). It also includes the cost, which is relevant for an agent deciding whether to invoke it.

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 present, so the description carries full disclosure responsibility. It clearly states the tool is free and returns a path, but it does not disclose whether it performs any side effects (it obviously only routes), or any constraints like rate limits or authentication. The core behavior is implied but not fully spelled out.

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 concise sentences with zero fluff. The 'FREE router' label is front-loaded, and the rest conveys purpose, output, and usage. Highly efficient and well-structured.

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 routing tool with a single parameter and no output schema, the description covers the essential context: it returns a recommendation and lists all possible paid tools with costs. An agent knows exactly what to do and what outcome to expect. Nothing critical is 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?

Schema coverage is 100% and the one parameter 'need' is described in the schema. The description adds the fact that it's in plain language, but that's essentially the same as the schema's description. Minimal added meaning 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?

States a specific purpose: a free router that takes a natural-language need and returns the recommended paid tool. It lists the possible destinations and explicitly says to call it first when unsure, clearly distinguishing it from sibling 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?

Provides explicit guidance: 'Call this first when unsure which tool to use.' Also lists the tool targets, so an agent knows what to expect after calling. This leaves no ambiguity about when to invoke it.

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 burden. It discloses that the tool generates a signed receipt, implies a cost of $0.02 Base USDC, and indicates an x402 payment endpoint. However, it doesn't clarify what 'signed' means, what happens if no parameters are provided (all are optional), or any behavioral side effects. Given the payment aspect, more transparency about the cost and authorization process would be helpful.

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

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

The description is concise, with three sentences and a cost note. It front-loads the primary use case and sibling differentiation. The x402 endpoint detail is somewhat niche but useful. Overall, it earns its place with minimal fluff, though the cost and endpoint details could be moved to annotations or a separate metadata field.

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

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

For a screening tool with no required parameters, the description does a decent job. It explains when to use it, differentiates from a key sibling, and mentions cost. However, it lacks information about the output format (what the signed receipt contains), error scenarios (e.g., invalid address), or whether any of the fields are truly required in practice. With no output schema, the agent has no idea what a valid response looks like. This is a notable gap.

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

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

Schema coverage is 100%, so the schema already documents each parameter. The description adds 'Entity/company name for multi-list screen' implicitly but doesn't add much beyond the schema. It does clarify that address is for OFAC SDN screening and domain is for trust check, but those are already in the schema. The description doesn't explain how parameters combine (AND/OR) or what happens if all are empty. Baseline 3 is appropriate since the schema covers it.

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

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

The description states a specific purpose: screening an address AND/OR entity name/domain against multiple sanctions lists and returning a signed receipt. It distinguishes itself from lion_wallet_screen by noting it covers more than OFAC SDN. However, the phrase 'multi-list receipt' could be clearer about the exact output, and the title is null, which slightly reduces clarity.

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

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

It gives clear usage context: use when you have an address and/or entity name/domain and need a signed multi-list receipt. It explicitly says to prefer this over lion_wallet_screen when more than OFAC SDN is needed. However, it doesn't mention when NOT to use it or when to use other siblings like lion_compliance_bundle, so there's room for more differentiation.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that it is a teaser and does not return a full dossier, which sets expectations about the depth of output. However, it does not mention any side effects, authentication requirements, or the nature of the returned data beyond 'teaser'. This is a moderate disclosure, sufficient for a simple free preview 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 exactly two sentences, with the core purpose and limitation front-loaded in the first sentence and the upgrade options in the second. Every word adds value, and it avoids redundancy. It is appropriately sized for a simple tool with a single parameter.

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 one parameter and no output schema, the description covers the essential behavior: it returns a teaser, not a full dossier, and mentions two upgrade paths. It does not explain the output format or list specific fields, but that may be acceptable for a free teaser. It also omits mention of other sibling tools that could be alternatives, but the two named are the most relevant upgrades. Overall, it is fairly complete for its simplicity.

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 schema only defines 'entity' as a string with no description, and parameter description coverage is 0%. The description partially compensates by stating the tool is 'for a company/domain', clarifying that the entity parameter refers to a company name or domain. This adds meaning, but it does not specify acceptable formats (e.g., full name, URL) or whether it is required (schema says 0 required). It provides some value beyond the bare schema but not comprehensive.

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 'FREE teaser for a company/domain' and explicitly notes that it does not return a full dossier, clearly indicating it provides a preview. It also names specific sibling tools (lion_company_research, lion_verified_company_file) to differentiate its limited scope from fuller alternatives. This makes the purpose clear, though it lacks a direct verb like 'retrieves' or 'returns'.

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 says 'Upgrade: lion_company_research ($0.03) or lion_verified_company_file ($0.95)', which implies this tool is for a free, quick look and provides explicit alternatives for users needing more detail. It does not formally state 'use when you only need a teaser', but the pricing and 'teaser' language make the usage context clear. It does not mention other siblings like lion_company_enrich or lion_wallet_screen, but the two named suffice for common upgrade paths.

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 weight. It discloses the cost ($0.95), payment method (x402 paid endpoint), and the nature of output (attested dossier with source trail). However, it does not describe the response format, error behavior, or any side effects. It adds useful context but leaves some operational details implicit.

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: it states the purpose first, then gives usage guidance, cost, and endpoint. Every sentence earns its place; 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 1-parameter tool with no output schema, the description covers usage context, cost, and the nature of the return (dossier with source trail). It lacks explicit mention of output format (e.g., JSON vs file), but the tool name and 'dossier' imply a file-like result. It is sufficiently complete for an agent to decide and invoke.

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% and the schema already describes 'domain' as a company website domain. The description reiterates 'by domain' but adds no new syntax or format details. Baseline of 3 is appropriate since the schema does the heavy lifting.

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

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

The description states 'Full attested KYB dossier by domain' with a specific verb and resource, and distinguishes itself from siblings like lion_company_research by emphasizing 'attested' and 'per-field source trail'. It clearly explains what the tool returns and its unique value.

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 says 'Use after lion_company_research/enrich when you need per-field source trail' and 'Not a first call.' This tells the agent when to call it, when not to, and names the prerequisite tools. Perfect guidance for 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds significant context: discloses the cost ($0.001 Base USDC), the HTTP method and endpoint (GET /api/x402/wallet-screen-json), and the output type (PASS/WARN/BLOCK). This goes beyond a typical bare description. It does not mention rate limits or explicit read-only status, but the GET method implies read-only, and the cost disclosure is valuable.

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

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

The description is compact and front-loaded with the core usage condition. It packs usage, exclusions, alternatives, cost, and endpoint into three sentences with zero redundancy. Every sentence contributes unique information.

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

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

For a single-parameter tool with no output schema, this description is relatively complete: it covers purpose, usage conditions, alternatives, cost, and endpoint. The return format (PASS/WARN/BLOCK) is mentioned, though not detailed (e.g., data structure). It omits edge cases like invalid addresses or timeouts, but for the simplicity of the tool this is acceptable.

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

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

Schema description coverage is 100%, so the parameter is already fully documented in the schema (Crypto wallet address to OFAC SDN screen, EVM 0x…). The description adds usage context (before paying, not company names) but does not add new technical details about the 'address' parameter beyond the schema. Baseline of 3 is appropriate.

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

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

The description states a specific use case: screening a 0x wallet address before payment, with an expected outcome of PASS/WARN/BLOCK. It clearly distinguishes itself from sibling tools by explicitly saying it's not for company names and naming the appropriate alternatives.

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

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

It provides explicit when-to-use (when you have a 0x address and need to screen before paying) and when-not-to-use (company names), and points to specific alternatives: lion_multi_sanctions_bundle and lion_compliance_bundle. No ambiguity remains about when to select this tool.

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