LION - keyless x402 data + RPC for agents

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

No annotations exist, but the description fully discloses payment details ($0.005 USDC on Base), keyless x402 mechanism, and the API challenge process. It does not state read-only explicitly but implies via 'query' and the source descriptions. No contradictions.

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 value proposition ('One endpoint, multiple live sources'), then details sources and payment. Every sentence adds unique information, though it could be slightly 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?

The description covers purpose, sources, and payment well, but lacks an output schema or explanation of return format/errors. Given 5 parameters and 6 sources, some output details are needed for complete context.

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. The description adds value by linking parameters to specific sources (e.g., 'token' for token_risk/token_holders) and explaining payment is always on Base despite chain choice.

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 is a unified endpoint querying multiple on-chain sources, listing each source and its purpose (e.g., base_dex for price/liquidity/volume). This distinguishes it from sibling tools like lion_token_risk_indicators which are single-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?

Description gives explicit use cases: 'pre-swap checks, counterparty profiling, market context' and mentions using credits for high volume. It does not explicitly say when not to use or list alternatives, but the concrete scenarios provide sufficient 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 carries full burden. It discloses that the tool is premium paid, outputs a signed receipt plus verdict, is stored and re-fetchable via receipt_id, and uses keyless x402 payment. Missing details on error handling but sufficiently covers key behaviors.

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 verbose, repeating some terms (e.g., 'PREMIUM RETAINED ATTESTED DOSSIER' alongside explanations) and including raw endpoint/pricing details that could be shortened. It is front-loaded with purpose, but 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?

Given the existence of an output schema, the description needn't detail return values. It covers pricing, storage, re-fetchability, and clear differentiation from sibling tools. Adequately complete for 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 description coverage is 100%, so the schema already documents each parameter. The description adds value by stating parameters are combinable ('and/or') and provides the query parameter format, aiding usage 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 starts with a clear label 'PREMIUM RETAINED ATTESTED DOSSIER' and explains it returns a multi-source intelligence dossier as a retained, offline-verifiable receipt. It explicitly distinguishes itself from the routine screen (lion_compliance_bundle) by stating use cases for each.

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 directs to use lion_compliance_bundle for routine per-payment checks and this tool when retained audit evidence is needed. Also mentions the payment mechanism ($1 USDC via x402) and endpoint structure.

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. Discloses it is a paid x402 tool ($0.05 USDC), returns a signed receipt, is keyless and no PII, and produces a combined verdict. Does not mention rate limits or failure modes, but covers key behavioral traits.

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 lengthy but every sentence adds essential information: purpose, what it screens, how it works, cost, and receipt feature. Front-loaded with main action. Could be slightly more concise but 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?

Given 5 parameters (none required) and presence of output schema, description explains all inputs and key output (signed receipt). Covers payment mechanism and verification details. Sufficient for an AI agent to understand 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?

All 5 parameters have schema descriptions (100% coverage). Description adds value by explaining each parameter's role, e.g., 'address: EVM address (0x...) to screen: OFAC SDN + wallet/contract risk' and the receipt parameter's purpose.

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?

Title and description clearly specify screening a counterparty before payment, with specific resources: OFAC sanctions, domain trust, multi-chain token risk, firmographics. Distinguishes from siblings like 'lion_ofac_sanctions_screen' and 'lion_compliance_audit_receipt' by combining multiple checks and producing a signed receipt.

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 'Screen payTo before USDC' and 'this closes that exact gap' indicating when to use. Clarifies that x402 verifies payment mechanics, not sanctions, so it's complementary. Does not explicitly list alternatives but context implies it's the combined compliance check.

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 bears behavioral transparency. It discloses that it's keyless, read-only (no PII), uses Ed25519 attestation, x402 protocol, and pricing per read/enrich field. It also notes the return of a challenge and source-labeled data.

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 front-loaded with the key value proposition. Every sentence adds value, though pricing details could be more succinct. Overall it's well-structured, moving from overall purpose to parameter details to pricing and auth.

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 complexity of 6 parameters, no output schema, and no annotations, the description is complete. It covers purpose, usage, all parameters, behavioral traits (keyless, attested, pricing), and authentication flow. Implicitly describes return values (onchain results, enrichment fields, attestation). No gaps.

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 value: for 'address' it says 'native balance + contract flag'; for 'tx' it says 'receipt: status/block/from/to'; for 'identifier' it explains enrichment returns firmographics and financials; examples for 'fields' and 'format' are given. This goes 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 it provides multi-chain keyless RPC and verifiable enrichment in one call. It distinguishes from siblings like lion_keyless_base_rpc by offering both Base and Ethereum, and contrasts with 'Ethereum-only keyless RPC (e.g. OneSource).' The verb+resource is specific: 'read onchain + 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?

The description explicitly says when to use this tool: for onchain reads on Base and Ethereum and enrichment. It names an alternative (OneSource) and explains prerequisites: prepay via lion_credits_purchase and use Bearer token. It also clarifies that it's keyless and for public facts only.

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 fully discloses behavior: it is a paid tool requesting 0.02 USDC via x402, returns Ed25519-attested JSON, uses crowdsourced pricing, and is keyless. It implies read-only access to product data. The only missing detail is potential rate limits or idempotency, but overall transparency is strong given the lack of annotations.

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 and contains promotional language ('THE simple useful paid API', 'This is the one') that could be trimmed. However, it front-loads the core function and includes all necessary information (function, data, payment, use cases). It is structured but not maximally concise, earning a middle score.

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 lacking an output schema, the description fully explains return values: 'clean attested JSON with product (name, brands, categories, nutrition...) + prices (price, currency, shop location, date)'. It also covers payment flow, verification, and endpoint details. For the tool's complexity, the description is complete and leaves no critical gaps.

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 covers 100% of parameters with descriptions, but the description adds significant value: it clarifies barcode is primary, name is a fallback, and domain defaults to auto-detection. Examples are provided. This goes beyond the schema's bare descriptions by explaining priority and typical usage patterns.

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 provides 'real CPG product data + live shop prices by barcode or name', with specific examples (barcode=5449000000996, name='coca cola'). It distinguishes itself from sibling tools by focusing on consumer packaged goods with pricing, a niche not covered by others like 'lion_domain_intel' or 'lion_web_search'. The verb+resource is explicit and 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 lists ideal use cases ('price bots, shopping agents, retail intel, market research agents') and mentions the tool is paid (x402). However, it does not explicitly state when NOT to use it or provide alternatives. The sibling tools cover domains like compliance, web scraping, etc., so the context is implicit but not explicit. Guidance is present but lacks exclusions.

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 bears full responsibility. It thoroughly discloses behaviors: payment via x402, session token issuance, automatic balance deduction, keyless operation, no PII, USDC on Base, and references to error_recovery and payment_instructions.

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 verbose (over 100 words) and includes extraneous details like the API endpoint. While it uses bold for emphasis, it lacks clear structuring and could be more concise by separating key points.

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 presence of an output schema, the description adequately explains the workflow and state transitions. It covers the core process, but omits details about error handling or insufficient balance scenarios.

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 has 100% coverage with a clear enum description. However, the description mentions pack values ($0.10 / $0.50 / $1.00) that contradict the schema's enum (1.00, 5.00, 20.00), causing confusion. The description does not add meaningful semantics beyond what the schema provides, and the inconsistency is detrimental.

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: purchasing LION credits via x402 payment to obtain a session token for repeated usage of paid tools. It distinguishes itself from siblings by being the dedicated payment mechanism for agents making many calls.

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 explicitly says 'Essential for agents doing 50+ calls/day' and contrasts with per-call payment methods (no new EIP-712, no 402, no JWS per call). It provides clear guidance on when to use this tool, though it does not explicitly list alternatives for smaller-scale usage.

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 disclose behavioral traits. It mentions the tool is FREE, routes to paid services, and includes Ed25519 attestation for paid responses. However, it lacks details on rate limits, auth requirements, or failure modes. The free sample example is helpful 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 front-loaded with a clear 'FREE. Tell LION what you need in plain language.' but becomes dense with multiple routing examples and price references. It could be more structured, e.g., separating core usage from options.

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 role as a router to many paid services, the description adequately explains the default path, free sample, and routing logic. An output schema exists, so return values are covered. It provides sufficient context for an agent to decide correctness, though examples of successful calls would improve completeness.

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 value by explaining that 'need' is a plain-language string, 'category' is an optional hint, and 'max_price_usdc' is a maximum payment. It also provides inline examples and free sample syntax, enriching the schema definition.

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 core purpose: 'Tell LION what you need in plain language.' It identifies this as a free router to various paid LION services, distinguishing it from sibling tools like lion_verified_company_file and lion_enrich_v1, which are specific endpoints. However, the description is dense with multiple routing options, slightly diluting focus.

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 usage guidance: it's free, defaults to lion_verified_company_file, and offers alternative paid paths with example queries. It mentions a free sample format and tracking parameter. While it doesn't explicitly state when not to use, the context is clear enough for an agent to make an informed choice.

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. It details the internal pipeline (web search -> scrape -> enrich via Wikidata/SEC -> domain trust) and output format (Ed25519-attested JSON). It also notes keyless, no account, no PII, and the x402 payment model. However, it does not explicitly state error handling 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?

The description is comprehensive but somewhat lengthy, including pricing details and alternative tool mentions. While it is front-loaded with the main purpose, some information (e.g., pricing formulas) could be streamlined or placed elsewhere. It is not wasteful but not maximally 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?

Given the lack of an output schema, the description does not explain the structure of the returned JSON beyond being 'Ed25519-attested'. The tool has 4 parameters with full schema coverage, and the description covers input semantics well. However, the output format is not described, which could leave the agent uncertain about what data it will 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 100%, but the description adds value by explaining usage examples for q (e.g., 'stripe.com' or 'Anthropic'), clarifying defaults and max for num, and describing the purpose of domain (override for firmographics) and receipt (portable receipt). This goes beyond the 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 identifies the tool as a one-call deep research tool for companies and crypto, combining search, scrape, enrichment, and domain trust into an attested JSON. It explicitly distinguishes from sibling tools by contrasting with StableEnrich's multi-call loop and directing people/email/LinkedIn/maps queries to another tool.

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 guidance on when to use: company research, vendor due diligence, business intelligence, SEC financials, and crypto/token research. Also provides when not to use: for people/email/LinkedIn/maps, directing to stableenrich.dev. Additionally, mentions the cost benefit over 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 provided, the description bears full responsibility. It discloses data sources (Cloudflare DNS-over-HTTPS, crt.sh), attestation (Ed25519), payment requirement (x402, 0.005 USDC on Base), and the fact that no API key is needed. It also notes the tool is keyless and verifiable offline.

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 quite verbose, containing multiple technical details in a single paragraph. While it is front-loaded with the core purpose, the length could be reduced without losing key 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?

Given the absence of an output schema, the description thoroughly lists the output fields (DNS records, HTTP headers, TLS info, tech_hints, trust_signals, trust_score) and explains the payment mechanism. This provides sufficient context for an agent to understand what the tool returns.

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 'domain' described as 'Domain or hostname to score'. The description adds minor clarifications about passing via query parameter and stripping scheme/path, but these add limited value beyond the schema's 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 states 'Keyless domain & trust intelligence' and specifies that it returns structured JSON of mechanical trust (DNS, HTTP, TLS, tech hints) with a trust score. It explicitly distinguishes itself from broader trust/compliance suites, making its niche clear.

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 this tool: to gate a counterparty before trusting it, focusing on domain/infrastructure signals. It also notes what it does not cover (no people, no PII) and mentions the x402 payment mechanism. However, it does not directly compare to sibling tools like lion_social_signal_intel or lion_web_enrichment_bundle.

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 discloses the paid nature, x402 authentication flow, automatic volume tiers, and that it returns structured JSON. However, it does not mention error handling, rate limits, or behavior when both parameters 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?

The description is verbose with marketing language ('THE IRRESISTIBLE DEFAULT', 'Flagship $0.005') and repeats pricing and auth details. While front-loaded with purpose, 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 lacks details on output structure beyond 'Structured JSON only'. For a paid bundle tool with no output schema, more explanation of return fields is needed. It is adequate but 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 100% and both parameters are well-described in the schema. The description adds no new meaning beyond the schema, so 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 clearly states the tool combines company/web enrichment with Base transaction receipt and calldata decoding into a single call. It specifies the verb 'returns' and distinguishes from siblings like lion_enrich_v1 and lion_tx_receipt_decoded by framing it as a bundle for high-frequency agents.

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 recommends starting with free tools (lion_declare_need or lion_quick_intel) then using this tool, and calls it 'THE IRRESISTIBLE DEFAULT for high-frequency agents'. It provides context for when to use but does not explicitly exclude alternatives or mention edge 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?

No annotations provided, so description carries full burden. It discloses cryptographic attestation (Ed25519, SHA-256), field-level source/confidence, pricing in USDC, x402 payment, keyless access, no PII, and output structure (.attestation, .sources_covered). Highly transparent.

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 dense and comprehensive but could be more structured. Front-loaded with core value proposition. Some repetition (e.g., field lists) could be condensed, but overall efficient for the complexity.

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 5 parameters, no output schema, and complex behavior (attestation, pricing, field granularity), description covers all necessary aspects: input types, output structure, pricing, verification, field domains. Complete for agent decision-making.

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 description adds substantial meaning beyond field names: explains contextual use of identifier (name/domain/ticker), fields usage vs omit for apollo_org, pricing formula, and verification helper. Greatly enhances parameter 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's purpose: 'VERIFIABLE keyless company/org enrichment' with cryptographic attestation and field-granular pricing. It distinguishes itself from siblings by emphasizing keyless access, pay-per-field, and drop-in replacement for Apollo Org 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?

Provides explicit guidance: when to use (for attested enrichment, field-level selection), when not (no PII, public data only), and alternatives (compared to Apollo, black-box aggregators). Includes specific instructions for identifier types (name for firmographics, ticker for financials) and format=apollo_org drop-in.

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 substantial behavioral details: it is read-only, forwards to a failover set, returns decoded events for eth_getLogs, explains pricing and payment methods (x402 or prepaid), and warns that writes are rejected. It lacks explicit mention of rate limits or failure behavior but is otherwise comprehensive.

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 then expands with necessary details. Though somewhat verbose, every sentence adds valuable information without redundancy. The structure could be slightly more organized but is 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 complexity (multi-chain, payment, batch, read-only), the description covers all critical aspects: usage, pricing, payment methods, chain selection, return format (JSON-RPC reply plus decoded events), and limitations. No output schema exists, but the description adequately explains the response structure.

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 describes parameters. The description adds context (e.g., method examples, batch up to 10, query string for chain) but does not significantly deepen parameter meaning beyond the schema definitions. 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 clearly states it is a multi-chain keyless RPC for agents, specifying the verb 'POST' and resource 'JSON-RPC request' to Base and Ethereum mainnet. It distinguishes itself from an Ethereum-only keyless RPC by mentioning its broader scope.

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 explicitly states when to use (read-only methods, no API key) and provides examples. It indirectly indicates when not to use by stating 'write methods rejected before payment.' It also gives guidance on chain selection via query string. However, it does not explicitly list alternative tools for write operations.

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 that the tool uses mechanical public data (OSM + PVGIS), involves a payment mechanism (x402, 0.02 USDC on Base), and states 'No PII'. This is strong transparency, though it could mention error handling 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?

The description is efficient, front-loading the core function in the first sentence, then adding essential details (output format, use cases, payment). Every sentence adds value without 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 no output schema, the description adequately explains the output (structured JSON with geocode, elevation, solar potential) and lists use cases and data sources. It is mostly complete, though could benefit from mentioning potential error responses or limitations.

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 baseline is 3. The description adds usage guidance: 'Use with lon to skip geocoding' and 'Provide this OR lat+lon', which clarifies parameter relationships beyond the schema's basic descriptions. This additional context earns a 4.

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: 'Address or lat/lon -> geocode + elevation + solar PV potential'. It specifies the verb (enrich) and resources (location, solar). This distinguishes it from sibling tools like lion_domain_intel or lion_quick_intel, which target different domains.

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 for real-estate, logistics, solar agents and mentions 'Use credits for volume' for heavy use. However, it does not explicitly state when not to use this tool or provide alternatives. The guidance is implicit rather than 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?

With no annotations, the description fully bears the transparency burden. It discloses key behaviors: keyless but payment-gated, returns specific JSON fields, uses daily refreshed OFAC list, provides cryptographically provable results, and disclaims legal advice. No contradictions.

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 detailed but slightly verbose, including secondary details like the x402 challenge. It is front-loaded with purpose and key outcomes, earning a high score but missing full conciseness.

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 one required parameter, no output schema, and high schema coverage, the description comprehensively explains the return format, limitations, and context. It leaves no critical gaps.

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 (address) with 100% schema coverage. The description adds value by providing examples (ETH/BTC) and explaining that it accepts various address formats.

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 screens crypto addresses against the OFAC SDN list, returning a structured JSON. It distinguishes itself from siblings by specifying its niche (sanctions screening) and limitations (address-level only, not a broad compliance suite).

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 checking a crypto address against OFAC) and notes it's not for broad compliance. However, it does not explicitly mention alternative tools for broader compliance, leaving some room for improvement.

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 responsibility. It discloses key behaviors: no API key, pay-per-query ($0.01 USDC), returns structured JSON with specific fields, sources from OSM, and coverage limitations. It mentions the x402 payment mechanism but omits details on error handling 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?

The description is a single paragraph that efficiently packs essential information: purpose, parameters, output, use cases, source, and pricing. It could be slightly more structured (e.g., bullet points) but each sentence earns its place, and the core intent is front-loaded.

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 absence of an output schema, the description adequately covers output fields (name, category, address, etc.) and operational details (pricing, source, coverage). It lacks information on error responses or pagination, but overall it is sufficiently complete for a straightforward search 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 the schema already describes all parameters. The description adds some value by providing examples (e.g., `?area=Soho, New York`) and explaining relationships (tag vs category, area vs bbox). However, this additional context is modest, warranting the baseline score for high coverage.

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 as a keyless POI/business directory search, contrasting with Google Places, Foursquare, and Yelp. It specifies the verb (search) and resource (POI/businesses), and provides concrete examples of parameters and output, 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 gives explicit usage scenarios: pass an area and a category or OSM tag. It lists sample use cases like lead-generation and logistics. However, it does not explicitly differentiate from sibling tools or state when not to use it, which slightly reduces 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?

No annotations exist, and the description provides no behavioral details (e.g., what data it returns, any restrictions, or side effects). It only promotes the free sample.

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 (3 sentences) but poorly structured, mixing a teaser, a URL command, and a pricing list. It feels promotional rather than informative.

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 low parameter count and presence of an output schema, the description should clearly differentiate this tool from its many siblings. It fails to explain the tool's purpose or output, leaving it 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 100% with a clear parameter description. The description adds a usage example with the 'entity' parameter but does not significantly enhance semantic understanding 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 calls it a 'FREE sample teaser' but does not clearly state what the tool actually does. It mentions an example URL and pricing for other services, leaving the core function vague.

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 explicitly names the upgrade tool (lion_verified_company_file) and other alternatives, giving clear context on when to use this free sample versus paid options.

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?

Discloses key behavioral traits: honest status for blocked pages ('never fabricated content'), Ed25519 attestation for tamper-proofing, and the x402 payment flow. Without annotations, this provides good transparency, though rate limits or error handling beyond blocked pages are not covered.

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 with information but well-structured: purpose, output, pricing, behavior, use cases, payment note. It is efficient and front-loaded, though slightly verbose with the payment URL detail.

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 tool with one parameter and no output schema, the description explains the return value, error handling for blocked pages, and attestation. It is sufficiently complete for an agent to understand and invoke the tool, though some details like verification of attestation are left out.

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 only parameter 'url' is fully described in the schema (100% coverage). The description adds little beyond the schema, only repeating the query parameter format. Baseline 3 is appropriate as the schema already suffices.

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 'Keyless ATTESTED web scrape' and details the return format { title, markdown, word_count }. It distinguishes the tool by highlighting keyless, attested nature and comparing pricing to Firecrawl, setting it apart 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?

Explicitly mentions use cases: 'For research, RAG, and agent grounding.' Provides a usage example and payment mechanism. However, it does not compare to alternatives like lion_web_search or specify when not to use it, which would improve clarity.

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, but the description comprehensively discloses behavioral traits: keyless access, payment required, returns structured JSON, cryptographically provable (Ed25519), sourced from SEC EDGAR, US public companies only, no PII, and disclaimers about advice. This fully compensates for missing annotations.

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 every sentence adds value. It is front-loaded with the key purpose and includes necessary details in an organized manner. Minor redundancy (e.g., repeating 'keyless') could be trimmed, but overall it is 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?

Despite no output schema, the description details the return structure (company profile, recent filings, headline financials) and explains the payment mechanism and source. It covers all relevant aspects: input, output, authentication, cost, and limitations. For a tool with two simple parameters, this is very 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 coverage is 100% with both parameters described (cik and ticker). The description adds meaning beyond the schema by explaining that passing either returns a single structured JSON with specific fields (profile, filings, financials) and mentions the payment flow. This provides useful context for parameter usage.

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 US public-company financials and filings keyless, with specific parameters (ticker or CIK). It distinguishes itself as a narrow, verifiable niche tool, not a broad financial-data suite, setting it apart 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?

The description specifies when to use the tool (for company/financial validation, keyless, no API key) and includes a payment gate. It also notes limitations (US public companies only, no PII, not advice). While it does not explicitly compare to siblings, it frames the tool as a narrow niche, implying it is not for broad financial data needs.

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 fully discloses: keyless access, paid x402 mechanism with exact price and chain, data sources (Algolia, Reddit), behavior on rate limits, output structure (HN primary, Reddit secondary), trend_score formula, attestation, and disclaimer. This is exemplary.

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 every sentence adds valuable detail (e.g., sources, pricing, limitations). It is front-loaded with the main function and structure is clear. Could be slightly more concise, but efficiency is good for the complexity.

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 completely explains the output (JSON with fields, attestation, sources). It covers input, behavior, pricing, and caveats. Nothing essential is missing for an agent to invoke this tool 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?

The input schema already describes the single 'topic' parameter clearly (e.g., 'Search query'). The tool description adds an example syntax and context about the query format. Since schema_coverage is 100%, baseline is 3; the example pushes it to 4 by clarifying usage.

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 'social-signal intel' from HN and Reddit, using specific sources and output format. It distinguishes from sibling tools like 'lion_web_enrichment_bundle' which are general web enrichment, and 'lion_quick_intel' which is broader. The verb 'get' is implied, and the resource 'social-signal intel' is well-defined.

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 how to use it (pass ?topic=) and what it returns. It also notes limitations (graceful empty on 429/block) and that it's for public post metadata only, no PII. While it doesn't explicitly list alternatives or when not to use, it gives enough context for appropriate 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 carries the transparency burden. It discloses the tool is paid ('Keyless x402 $0.02'), provides an endpoint for payment, and notes that data 'compounds with every call' (side effect). It does not fully detail rate limits or all side effects, but the key behavioral traits are covered, earning a strong score.

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 main purpose and key outputs (risk_score, flags, proprietary block). It includes a bracketed technical detail about the 402 challenge, which is useful but slightly verbose. At ~100 words, it is mostly efficient with minimal waste.

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 adequately explains return values (risk_score 0-1, itemized flags, proprietary block). It also addresses payment, chain scope, and data accumulation. Given the tool's complexity and lack of annotations, this description is sufficiently complete for an agent to understand and invoke the tool 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%, so baseline is 3. The description adds value beyond the schema by clarifying that payment is always on Base regardless of the chain parameter, which is critical for correct use. It also reiterates address formats, but the payment context is the key 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 clearly states the tool's purpose: 'Pre-trade token risk for Base/Ethereum/Solana' with a proprietary 'lion_intel block'. It specifies outputs (risk_score 0-1 + itemized flags). This is distinct from sibling tools like lion_quick_intel or lion_deep_research, as it focuses on token risk with accumulated history.

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 for 'Pre-trade' safety checks but does not explicitly state when to use this tool over alternatives like lion_quick_intel or lion_x402_intel. No direct comparison or exclusion criteria are given, leaving the agent to infer context from the title and sibling tool names.

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?

Describes it as a read operation and lists returned data, but does not disclose error behavior, rate limits, or authorization needs. Annotations are absent, so description carries full burden; moderate 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?

Concise two-sentence description that front-loads key functionality. The second sentence includes pricing and technical details, which is efficient but slightly dense.

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 adequately explains return content (receipt fields, decoded calldata). Simple parameter, no nested objects. Sufficient for agent to understand data 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 coverage is 100% with one parameter. Description repeats the parameter's purpose (Base tx hash) but adds no new constraints or formatting details beyond the schema. At baseline for high coverage.

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?

Clearly states it returns Base transaction receipt and decoded calldata, specifying fields (status, block, from, to, value, gas, logs) and decoded input. Mentions complementarity to keyless-rpc and enrichment, distinguishing it from siblings.

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?

Indicates it is complementary to keyless-rpc and enrichment but does not explicitly state when to use this tool versus alternatives. Mentions cost and non-commodity nature, but lacks when-not 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 must fully disclose behavior. It reveals the tool is paid, keyless, sources data live from the EU Commission VIES, returns structured JSON with specific fields, and provides cryptographic attestation (Ed25519). It could mention rate limits or error handling, but overall transparency is high.

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 lengthy but well-structured, starting with the core purpose, then elaborating on inputs, output, verification, caveats, and payment. Every sentence provides necessary information. Could be slightly more concise, but no waste.

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 the description compensates by enumerating return fields (valid, company_name, address, etc.) and explaining the x402 payment flow. It also mentions data source and authority. Some details like timeout or failure modes are missing, but overall it sufficiently describes the tool's context.

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 description adds value beyond the schema by explaining parameter relationships (provide vat OR country+number), giving concrete examples ('IE6388047V'), and detailing format constraints. This reduces ambiguity in selecting parameters.

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 tool performs 'Keyless EU VAT number validation for KYB / compliance' with specific verb and resource. It distinguishes from siblings by emphasizing a 'narrow VERIFIABLE niche' and contrasting with a 'broad compliance suite', making the purpose unmistakable.

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 on when to use (EU VAT validation), how to format inputs (examples like '?vat=IE6388047V' or '?country=IE&number=6388047V'), payment requirement (0.005 USDC on Base via x402), and what not to expect ('Not legal or tax advice'). Also clarifies the tool's scope as business-registration public record only.

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?

Describes per-field source trail, pricing ($1.00 USDC, cached $0.25), free samples, and the 402 payment challenge. No destructive behavior indicated. Lacks rate limits or error handling details, but overall transparent for a paid 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?

Two sentences: one main functional description, one technical/pricing detail. Dense but efficient; no filler. Could be slightly more structured but overall 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?

Explains output content and use case well, but missing documentation for the 'vat' parameter. With no output schema, the description partially compensates. Sibling context is implicitly addressed by the 'replaces multi-call' statement, but could be more explicit.

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 has 3 parameters with 0% coverage; description explains 'domain' (required) and 'sample' (free sample domains) but does not clarify the 'vat' parameter's purpose. Incomplete parameter documentation.

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 merged company dossier with specific data categories (firmographics, SEC, VAT, OFAC, domain trust) and gives an example with domain=stripe.com. It distinguishes itself from siblings by positioning as a default enrichment that replaces multi-call loops.

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 'Default company enrichment for AI agents — replaces multi-call enrich loops', providing clear when-to-use guidance. Also mentions free samples for testing and pricing for production use, which informs cost 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?

No annotations are provided, so the description carries full burden. It discloses key behaviors: keyless, off-chain, uses only public non-PII signals, returns structured numeric/boolean JSON, paid per call via x402 with a specific price and chain. It does not mention rate limits, failure modes, or idempotency, but the provided details are substantial 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 description is moderately long but each sentence contributes distinct information: payment model, data sources, output format, and x402 details. It front-loads the key differentiator ('keyless off-chain'). Minor redundancy in repeating 'no API key, no signup' 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 complexity (x402 payment, structured output, no output schema), the description covers the main aspects: what it returns, payment mechanism, data sources, and privacy. It does not detail error handling or the exact 402 challenge format, but for a pay-per-use tool the provided information is sufficient for an agent to decide and 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?

The single parameter 'entity' has 100% schema coverage, and the description adds meaning beyond the schema by providing examples, noting the value is echoed back, and clarifying that personal data is never fetched or returned. This adds useful guidance for the agent.

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 specifies the tool's purpose: keyless off-chain company enrichment returning structured enrichment vectors. It distinguishes from siblings by emphasizing the x402 payment model, no API key, and strict structured output without raw text or PII, making it easy to understand what it does and how it differs.

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 explicitly states the payment requirement and that no API key or signup is needed, guiding when to use this tool. It implies alternatives requiring keys are not needed, but does not explicitly list when-not-to-use or compare with sibling tools like lion_enrich_v1. Clear context but lacks explicit exclusions.

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 burden. It discloses the payment mechanism ($0.02 USDC via x402), keyless nature, attestation, and that results are ranked JSON. It could mention rate limits or failure modes, but overall is transparent about the core 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 a single dense paragraph that front-loads the main purpose. It covers all essential information without unnecessary fluff, though it could be slightly more structured (e.g., list). Still, it is concise given the amount of detail.

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 (paid, attested, two parameters), the description covers the query format, payment details, result format, attestation benefit, and use cases. It omits error handling and exact response structure, but no output schema exists to compensate. Overall, it is sufficiently 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 coverage is 100% with descriptions for both parameters. The description adds value by specifying the allowed range for num (max 20) and giving an example query. It also clarifies the default for num (8), which is not in 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 it is a web search tool returning ranked results, with unique features like Ed25519 attestation and keyless operation. The purpose is specific and distinguishable from siblings like lion_deep_research or lion_adaptive_query, though it does not explicitly contrast 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?

Provides basic usage instructions (pass query, optional num) and mentions use cases (research, RAG, fact-finding, agent grounding). However, it lacks explicit guidance on when to use this tool versus alternatives or when not to use 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?

With no annotations, the description fully discloses behavior: keyless, no API key, no signup, payment gate of 0.005 USDC via x402, returns one structured JSON, data source (Wikidata CC0), and explicit exclusions (no people). No contradictions with annotations.

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 front-loaded with the main purpose and is structured with separate points for usage, output, exclusions, and pricing. Some redundancy (e.g., 'keyless' repeated) but each sentence adds distinct value.

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 thoroughly explains the return format (entity and firmographics fields), data source, limitations, and payment mechanism, making it fully complete for an agent to understand and use the 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%, but description adds value by providing examples ('?entity=Coinbase', '?qid=Q5463952') and clarifying mutual exclusivity of parameters, enhancing understanding beyond 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?

Description clearly states 'Keyless GLOBAL firmographic enrichment for any company/org' and specifies the output structure. It distinguishes itself by noting it complements US-only SEC and on-chain tools, providing context for when to use this global Wikidata-based tool.

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 the tool is for off-chain, global firmographics, complements US-only SEC and on-chain tools, and returns company/org-level facts only. It explicitly states what is not returned (founder/CEO/board, no people/PII), guiding agents to use alternative tools for person data.

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?

Without annotations, the description carries full burden. It discloses key behaviors: it's a paid tool ($0.01 USDC on Base), keyless, Ed25519-attested, returns a 402 challenge, and uses a proprietary panel with daily probing. Missing details on output format and 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 verbose and includes implementation-specific details (e.g., exact GET endpoint, blockchain identifier) that could be streamlined. It lacks a clear front-loaded summary, though the title and first sentence are helpful.

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 does not explain the return format beyond mentioning the 402 challenge. It covers parameter usage and behavioral traits but leaves gaps in what the agent can expect as output, making it incomplete for an agent to fully rely on.

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?

Input schema covers 100% of parameters, and the description adds meaningful context for each (e.g., '?url= -> verify a specific endpoint is live & legit before paying'). The mapping from schema properties to usage is clear, exceeding the baseline of 3.

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 title and first sentence clearly state the tool's domain: 'LION x402 Intelligence — find & vet x402 services'. The description elaborates with specific query parameters and actions, though it mixes technical implementation details that slightly obscure the core 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 implies usage scenarios via parameters (e.g., '?need=' for discovery, '?url=' for verification) but does not explicitly state when to use this tool over sibling tools like 'lion_web_search' or 'lion_token_risk_indicators'. No exclusion criteria or alternative guidance is provided.

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