LION - keyless x402 data + RPC for agents

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

With no annotations provided, the description fully carries the burden of behavioral transparency. It discloses the x402 payment system, cost per call, multi-chain behavior (data on Base or Ethereum, payment on Base), and what each source returns. It does not mention rate limits or error handling, but the core behaviors are well explained.

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 comprehensive but efficiently structured, with key information front-loaded (purpose, chains, sources) followed by examples and payment details. While lengthy, every sentence provides necessary context for agent usage.

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 the tool's complexity (five parameters, six sources, payment mechanism, no output schema), the description is remarkably complete. It covers all possible parameter combinations, example agent flows, and the payment authentication process, making it self-sufficient for an AI agent.

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%, but the description adds significant context beyond the schema. It explains how parameters like 'token', 'address', and 'tx' relate to specific sources, and provides example query strings. This clarifies parameter combinations and 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 clearly states the tool is a multi-chain onchain intelligence layer with six distinct data sources, each named and described. It distinguishes itself from siblings like 'lion_token_risk_indicators' by being a unified query endpoint that selects sources via a 'source' parameter.

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 explicit when-to-use guidance for each source with concrete examples (e.g., 'before a swap call source=token_risk', 'to profile a counterparty call source=wallet_profile'), explains payment mechanism, and notes that no API key is needed. It covers all major use cases.

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 fully discloses behavior: single payment, session token minting, drawdown per call, no account/API key/PII, payment in USDC on Base via x402, and the x402 challenge endpoint. No behavioral surprises remain.

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 dense but well-organized, front-loading the core action and then explaining usage details. Every sentence adds necessary information without redundancy. Could be slightly more structured (e.g., bullet points), but it remains effective.

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 the tool has only one optional parameter and no output schema, the description covers the entire purchase and usage flow comprehensively. It explains payment, token acquisition, authentication for subsequent calls, and cost drawdown, leaving no gaps for an agent 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 coverage is 100% with one enum parameter. The description adds context by specifying the default pack ('0.10') and explaining that pack values represent USD amounts. This adds meaning beyond the raw enum list, though the schema already describes the parameter well.

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 explicitly states the tool's function: buying prepaid LION session credits via a single x402 payment. It distinguishes itself from sibling tools by detailing the unique credit-purchase mechanism and token-based usage flow, leaving no ambiguity about its 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?

The description provides clear usage context: when to use (to prepay for LION paid routes), how to choose the pack, and how to use the resulting token in subsequent calls. It lacks explicit 'when not to use' or alternative tools, but the guidance is sufficiently clear for an agent to decide correctly.

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. It mentions being free and returning a match, but lacks details on the matching process, latency, or side effects, which is adequate for a simple meta-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 three sentences, starting with the key action, but the leading 'FREE' is slightly distracting. Overall efficient and clear.

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 the tool's simplicity and full schema coverage, the description provides sufficient context for a meta-tool. It could hint at the output format, but the mention of 'returns the best-matching available tool' is adequate.

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 good parameter descriptions. The description adds minor value by calling 'need' plain-language and mentioning max_price_usdc, but does not significantly enhance 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 clearly states the tool's purpose: it takes a user's need and returns the best-matching tool, distinguishing it from sibling tools which are specific data 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 description advises using this tool when unsure which tool to call ('so you stop guessing') and highlights it's free, but does not explicitly state when not to use or provide 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?

Since no annotations are provided, the description carries full transparency burden. It discloses the payment mechanism ('$0.005 USDC on Base via x402'), data sources (Cloudflare DNS-over-HTTPS, crt.sh CT logs), and output structure. It lacks details on rate limits or error handling but is otherwise thorough.

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 long but dense with useful information. It starts with purpose, then detailed output, then payment. It could be more concise (e.g., merge output enumeration), but it is well-organized. Some redundancy exists (payment info mentioned twice).

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, the description explicitly lists all output components (DNS, HTTP, TLS, tech_hints, trust_signals, trust_score) and data sources. It also explains the payment flow (402 challenge). It misses some details like error responses or pagination, but for a single-domain query tool it is adequate.

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% (domain param described with example and note about scheme/path stripping). The description adds value by repeating the example and the stripping behavior, reinforcing the schema. Baseline 3 is raised to 4 because the description clarifies usage 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 clearly identifies the tool's purpose: 'Keyless domain & trust intelligence' that produces a structured JSON of DNS, HTTP, TLS, and trust signals. It distinguishes from siblings (other LION tools are for queries, credits, etc.), leaving no doubt about its 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?

It states when to use: 'to gate a counterparty before trusting it', and provides examples like 'pass a domain (?domain=stripe.com)'. It also clarifies scope: 'Domain/infrastructure signals only, no people, no PII.' However, it does not explicitly mention when not to use or list alternatives, so it's slightly below perfect.

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 provides good behavioral context: no PII, numeric/boolean outputs, usage limits (x402 payment), and structured JSON for loops. However, it does not specify behavior when both parameters are omitted or error handling.

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 front-loaded with the core purpose and is reasonably concise given the complexity. It could be tightened slightly but overall efficient.

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?

Without an output schema, the description lacks specifics on return JSON structure. It mentions 'structured JSON' but no details; also missing error behavior. Adequate but not fully comprehensive.

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 description restates parameter purposes without adding new meaning beyond 'optional if entity/tx only'. This meets the baseline but does not enhance understanding.

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 does both company enrichment and transaction decoding in one bundle. It differentiates from siblings like lion_web_enrichment_bundle and lion_tx_receipt_decoded by explicitly marking it as a combined bundle.

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 implies when to use this tool: when both enrichment and transaction decoding are needed. It mentions 'Pass entity and/or tx' but does not explicitly advise against using individual sibling tools for specific cases.

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 fully discloses behavioral traits: pricing per field (0.002 USDC), payment via x402, response format ({value, confidence, source, as_of}), data sources (Wikidata CC0, SEC EDGAR), and that it only handles public company/org data (no PII). This is comprehensive and leaves no ambiguity about cost or 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 description is informative and well-structured, starting with the core value proposition and then covering pricing, response, fields, usage, payment. It is longer than necessary but each sentence serves a purpose, making it efficient for the complexity of a pay-per-field enrichment 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?

Given no output schema, the description compensates by detailing the response structure. It covers all input parameters, field lists, payment method, data sources, and usage instructions. The description is complete for understanding how to invoke and interpret results.

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 input schema has 100% description coverage, and the description adds significant value: it explains that identifier should be a name or ticker depending on field categories, gives examples for fields, and lists the full set of available fields. This goes beyond the schema's brief descriptions.

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 does field-granular company/org enrichment, allowing selection of specific fields with pay-per-use pricing. It lists available field categories (firmographics, financials, web-attention) and distinguishes from flat-bundle incumbents, effectively differentiating it from siblings like lion_sec_financials and lion_wikidata_firmographics.

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 clear usage context: use for specific field needs, use company NAME for firmographic/web fields and US TICKER for financial fields. It mentions keyless, no signup, and pay-per-field. However, it does not explicitly state when not to use or direct to alternative bundle tools, though the sibling names imply 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 fully discloses that the tool is read-only, forwards requests across a failover set, returns JSON-RPC replies, charges per call, and requires x402 payment. It also notes no PII, no API key, and that write methods are rejected. This is comprehensive behavioral transparency.

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 somewhat lengthy, especially with the x402 payment detail, but it is well-structured with key information front-loaded. Every sentence adds value, though it could be more concise.

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 covers input format, nature of the tool, payment, limitations, and return value (JSON-RPC reply). It lacks explicit error handling details, but is mostly complete for an agent to use the tool effectively.

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 input schema already describes all 4 parameters with 100% coverage. The description adds context about batch requests up to 10 and valid methods, but this is marginal beyond the schema's descriptions.

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 that the tool performs read-only JSON-RPC calls to the Base blockchain (chainId 8453), listing example methods like eth_call and eth_getBalance. It distinguishes itself from write methods and other sibling tools, which are unrelated.

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 indicates the tool is for read-only queries on Base, mentions the payment requirement (0.01 USDC) and that write methods are rejected. It does not explicitly list when not to use, but the context is clear given the tool's specific niche.

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 well by disclosing the keyless nature, underlying APIs (OpenStreetMap, Open-Elevation, EU PVGIS), payment method (x402 with USDC on Base), and the 402 challenge process. It does not cover error handling or rate limits, but overall provides substantial behavioral context.

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 paragraph but front-loads the key output, then use cases, then technical details. It is dense but not verbose; the x402 payment detail is necessary for operation. Could be slightly more structured, but remains efficient.

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 no output schema, the description covers the return value comprehensively with fields and units. It also provides use cases, data sources, and payment mechanism. Missing error handling details, but overall sufficient for a tool with simple 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 coverage is 100% with each parameter described. The description adds value by explaining that lat+lon skip geocoding, address is free-form, and what the output contains (geocode, terrain, solar). This adds meaning beyond the schema alone.

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 explicitly states the tool accepts an address or lat/lon and returns a JSON with geocode, terrain, and solar potential. It distinguishes itself from siblings (which are for query, need declaration, token risk, and web enrichment) by focusing on location and solar data, making the purpose clear and specific.

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 lists intended use cases (real-estate, solar, logistics, site-selection) and explicitly states the tool is for place/property/solar only and not for people or PII. It lacks explicit when-not-to-use or alternative tool comparisons, but the listed use cases provide clear 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 provided, the description carries full burden and does exceptionally well. It discloses: no API key/signup, payment gate via x402, returns one JSON, US companies only, no people/PII, not financial/investment/advice. It also details the payment flow (0.005 USDC on Base) and data source (SEC EDGAR). This is comprehensive behavioral transparency.

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 relatively long but well-structured, with clear sections for output components and payment details. It front-loads the main purpose. However, some technical details about the x402 flow could be considered extraneous for an AI agent selecting the tool. Still, the information is relevant and 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?

Given no output schema and no annotations, the description is remarkably complete. It fully describes the expected JSON output including fields like 'cik', 'ticker', 'revenue_usd', etc. It covers the payment mechanism, data source, and limitations. The tool's complexity is high, and the description leaves little ambiguity.

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 baseline is 3, but the description adds significant value. It explains the mutual exclusivity of 'cik' and 'ticker' ('Provide this OR cik'), provides example formats ('0000320193' or '320193', 'AAPL'), and clarifies the context of use. This goes beyond the schema's basic explanations.

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 that the tool provides 'US public-company financials + filings' for 'company/financial validation'. It specifies the output JSON structure including company profile, recent filings, and headline financials. The tool is distinct from siblings by being keyless and payment-gated, and it explicitly targets financial data from SEC EDGAR.

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 when to use the tool: for company/financial validation, no API key needed, payment required. It also indicates the input method (ticker or CIK) and the constraint 'US public companies only'. However, it does not explicitly list when not to use this tool or contrast with sibling tools like 'lion_web_enrichment_bundle' or 'lion_domain_intel'.

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, payment mechanism (x402, USDC on Base), endpoint URL, and price (0.01 USDC). However, it does not mention rate limits, idempotency, 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?

The description is concise with two sentences. The first sentence delivers the core purpose, and the second adds payment details. The second sentence is slightly verbose with the full URL, but overall efficient.

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 the tool's simplicity (one parameter, no output schema), the description covers purpose, payment, endpoint, and the specific risk indicators. It could mention the return format or error handling, but is largely complete for selection and 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 one parameter 'token' described as 'Base token contract address (0x...).' The description repeats 'Pass a token address,' adding no meaningful semantic detail 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 clearly states the tool returns a security/risk card for a Base token, listing specific indicators like honeypot, buy/sell tax, etc. It explicitly says to pass a token address, making the purpose distinct from sibling tools which are unrelated.

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 implies usage by stating 'Pass a token address' and mentions it's a paid tool, but provides no explicit guidance on when to use this tool versus alternatives or when not to use it. The sibling tools are not similar, so the context is limited.

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, description carries full burden. It discloses it is a read operation, costs money ($0.01), and details the x402 payment flow. Provides behavioral context beyond schema.

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?

Description is relatively concise, front-loading the main purpose. Some technical billing details could be streamlined, but overall efficient.

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 a single parameter and no output schema, the description adequately explains the tool's function, payment model, and complementary relation to others. Could benefit from more on error handling or output format.

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 parameter 'tx'. Description adds that it is a Base tx hash and explains what the tool fetches (receipt and decoded calldata), providing additional context.

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?

Description clearly states it returns a Base tx receipt with decoded calldata, specifies fields (status, block, from, to, value, gas, logs) and differentiates from siblings like keyless-rpc and enrichment.

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?

Does not explicitly state when to use vs alternatives, but mentions it is complementary to other tools and is a non-commodity read. Provides payment context but lacks explicit guidance on conditional use.

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 disclose behavioral traits. It clearly states the tool is paid (USDC on Base via x402), returns only structured JSON (no raw fetched text), and does not pass through PII. This covers cost, output format, and data privacy adequately.

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 the first clearly stating the purpose and output, and the second providing important context on budgets and payment. Every sentence adds value with no 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?

Given the tool has one parameter and no output schema, the description is complete. It explains the output format (structured JSON), payment method, and privacy stance. No additional context is needed for an agent to invoke it 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 coverage is 100% for the single 'entity' parameter. The description adds examples ('Coinbase', 'base.org', 'stablecoins') and clarifies that the value is echoed back and never used for personal data, going beyond the schema's minimal description.

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: 'Score a topic, brand, company, or domain and receive one structured numeric/boolean JSON enrichment vector.' The verb 'score' and resource types are specific. It distinguishes from sibling tools like lion_adaptive_query (which likely queries in natural language) or lion_token_risk_indicators (crypto-specific) by focusing on general topic enrichment with structured 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?

The description mentions it's 'built for agent context budgets' and implies use when structured output without raw text is desired, but it does not explicitly state when to use this tool versus siblings like lion_adaptive_query or lion_declare_need. No exclusions or alternatives are provided.

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 provided, so description carries full burden. It discloses key behaviors: keyless, no API key/signup, payment via x402 at $0.005 USDC, returns only company/org facts, no PII, from Wikidata CC0 data. Lacks error handling or rate limit details but covers main behavioral aspects well.

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?

Single dense paragraph, well-structured with front-loaded purpose, then input/output, limitations, and payment info. Every sentence is informative, though slightly lengthy. Could be broken into clearer sections, but remains efficient.

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?

Despite no output schema, the description fully details the output structure (entity and firmographics fields). It covers data source, payment method, country scope, and intentional exclusions (no people). Given the complexity of a paid enrichment tool, it provides complete context for agent selection and 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 description coverage is 100%, but the tool description adds significant value by explaining the mutually exclusive relationship (provide this OR qid), giving concrete examples (e.g., '?entity=Coinbase'), and clarifying optionality. This goes well beyond schema descriptions.

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 as 'Keyless GLOBAL firmographic enrichment for any company/org' and specifies inputs (entity name or Wikidata QID) and outputs (structured JSON). It distinguishes from siblings by noting it complements US-only SEC and on-chain tools and explicitly excludes person properties.

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 guidance: for off-chain company enrichment from Wikidata, globally, and for any country. It also states what to use instead (not for people data) and clarifies it complements sibling tools like SEC financials and on-chain enrichment.

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