LION - keyless multi-chain RPC + attested data for agents

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

Despite no annotations, the description fully discloses behavioral traits: payment ($0.005 USDC on Base), keyless x402 mechanism, no API key required, multi-chain data handling, and the challenge/response flow. This provides comprehensive transparency beyond the structured fields.

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 information-dense but front-loads the core value ('One endpoint, multiple live sources'). Every sentence adds value, but the technical details about the x402 challenge could be slightly shortened. Still, it remains efficient for the complexity covered.

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

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

For a tool with 5 parameters, no output schema, and no annotations, the description covers payment, source list, use cases, and technical mechanics. Missing details include what each source returns (e.g., data format) and error handling, but the description is sufficiently complete for an adaptive query 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 each parameter is documented in the schema. The description adds value by explaining the purpose of each source in the main text (e.g., 'base_dex (price/liquidity/volume)') and how the 'chain' parameter affects data origin but not payment. 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 title and description clearly state 'One endpoint, multiple live sources' and list all six source types (base_dex, token_risk, etc.), establishing a specific verb-resource pairing (query multiple live sources). It distinguishes from siblings by emphasizing the x402 payment model and multi-source capability, which no other sibling tool offers.

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 use cases: 'Perfect for pre-swap checks, counterparty profiling, market context' and mentions 'Use with credits for high volume.' However, it does not specify when NOT to use the tool or compare directly to sibling tools (e.g., lion_enrich_v1 or lion_token_risk_indicators) for decision-making.

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

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

No annotations are provided, so the description carries the full burden. It discloses key traits: keyless operation, x402 payment in USDC on Base, Ed25519 attestation for enrichment, pricing details, and no PII. It adds significant behavioral context beyond what annotations would provide.

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 front-loaded with the core purpose. It packs multiple aspects (onchain, enrichment, pricing, authentication) without waste. Slightly verbose but appropriate for the tool's 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 the complexity (6 parameters, no output schema), the description is complete. It covers both halves (onchain and enrichment), pricing, authentication, and verification. It does not explain return values, but rules allow this since no output schema exists.

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%, baseline 3. The description adds meaning beyond the schema by explaining what each parameter returns (e.g., address gives native balance + contract flag, tx gives receipt fields) and how to use fields vs. format for enrichment.

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 with verifiable enrichment, covering Base and Ethereum. It distinguishes from Ethereum-only keyless RPC (e.g., OneSource), providing a specific verb+resource combination.

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 (as a broader, verifiable alternative to Ethereum-only keyless RPC) and gives explicit usage for onchain reads and enrichment. However, it does not explicitly state 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?

Despite no annotations, the description discloses key behaviors: the purchase flow, token usage, automatic deduction, refill capability, keyless and no-PII nature, and references error_recovery and payment_instructions as other tools. Lacks explicit mention of expiration or refund policy.

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

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

Front-loaded with the key benefit ('repeat-usage killer feature'), each sentence adds value. Slightly lengthy due to technical endpoint note, but still efficient overall.

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 and the comprehensive explanation of the token purchase and usage flow, the description sufficiently covers the tool's role in the broader ecosystem, including references to sibling paid tools and error handling.

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 'pack' is already well-described in the schema with enum values and description. The tool description adds context about default value (0.10) and links packs to USD credits, enhancing semantic 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: purchasing a session token for repeated use across paid tools, distinguishing it from sibling tools that are paid endpoints themselves.

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 recommends for high-volume agents (50+ calls/day) and implies the use case of avoiding per-call x402 payments, but does not list explicit when-not-to-use scenarios or alternative methods.

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 that it is free, returns a Quick Intel sample with specific fields, records the need, and provides a paid upgrade path. Without annotations, this is good disclosure, though it does not mention storage duration 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?

Front-loads key information (FREE, primary way), but includes some marketing phrases ('Start free, get value, pay only when you need depth') that add length without essential technical 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 complexity of being a free sample tool with a paid path, the description covers the input, output, and upgrade flow. However, it does not explicitly state that it is scoped to Base, which is implied but not guaranteed.

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?

With 100% schema coverage, the description adds value by providing examples and context for the 'need' parameter, and clarifies the purpose of 'category' and 'max_price_usdc' 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?

Clearly states it is the primary bootstrap tool for research on Base, taking a plain-language need and returning a free Quick Intel sample. Distinguished from siblings by being the free entry point and mentioning the upgrade path.

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 a recommended flow (declare_need -> quick_intel -> paid) and advises including &ref=. Implicitly suggests using this when starting free, but does not explicitly exclude cases where direct tools like lion_quick_intel might be more appropriate.

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

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

With no annotations provided, the description fully carries the burden. It details data sources (Cloudflare DNS-over-HTTPS, crt.sh), the payment mechanism (x402 with price), and states that no API key or signup is required. It also clarifies the output format and the trust score range.

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 dense but well-organized, starting with a summary, then listing signals, and ending with payment details. It could be slightly more concise, but every sentence adds value without repetition.

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 (multiple signal types, payment, no output schema), the description is highly complete. It explains the JSON structure, the sources, and the payment flow. Sibling tools are provided, and the description clearly defines the scope (domain/infrastructure only).

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% coverage with a clear description of the 'domain' parameter. The description adds valuable context by providing an example ('?domain=stripe.com') and noting that scheme/path is stripped, which goes 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 clearly states the tool provides domain and trust intelligence with specific signals (DNS, HTTP, TLS, etc.) and a trust score. It explicitly distinguishes by being keyless and payment-gated, and the verb 'get structured JSON' is specific. It differentiates from siblings by focusing on mechanical trust signals.

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 when to use ('to gate a counterparty before trusting it') and explicitly states limitations ('domain/infrastructure signals only, no people, no PII'). While it does not name specific sibling alternatives, the context is clear and implies the tool is for domain-level trust assessment.

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

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

With no annotations provided, the description carries the full burden. It discloses the tool is paid ($0.005 base, volume tiers), uses keyless x402 and Bearer tokens for authentication, returns 'Structured JSON only', and details the endpoint. Behavioral traits like safety (read-only implied) and payment mechanism are well-covered, though specific behaviors like rate limits or error handling 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 overly verbose and marketing-heavy, using phrases like 'THE IRRESISTIBLE DEFAULT'. It includes pricing details, authentication flow, and instructions that could be simplified or moved to a separate metadata field. The length and promotional tone hinder quick comprehension.

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 should explain the return value structure. It only mentions 'Structured JSON' without detailing fields for enrichment or transaction data. For a bundled tool of moderate complexity, this is a gap. However, it does provide endpoint info and optionality hints, making it marginally 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?

Input schema coverage is 100% with descriptions for both parameters. The description adds nuance by stating each parameter is optional if the other is provided, clarifying independence. No additional format or example is given, but the baseline of 3 is exceeded due to clarifying optionality.

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 a combined one-call default for company/web enrichment and Base tx receipt with calldata decode. It uses specific verbs ('enrichment', 'decoded') and distinguishes from sibling tools like lion_enrich_v1 and lion_tx_receipt_decoded by being a bundled offering.

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 guidance, suggesting free tools like lion_declare_need or lion_quick_intel for initial exploration, then using this as a paid default. It mentions pricing and authentication model, but does not explicitly state when not to use it or provide exclusions for 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?

Discloses all key behaviors: keyless, no PII, public data only, x402 payment (0.002 USDC/field), cryptographic attestation, and return structure {value, confidence, source, as_of}. No annotations provided, so description carries full burden and exceeds expectations.

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 very long and dense. While comprehensive, it could be more structured (e.g., bullet points) for easier parsing. Still, every sentence adds value given the tool's 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?

Complete for a complex enrichment tool: explains return values, sources, payment, verification, and relationships to sibling tools like lion_domain_intel and lion_sec_financials. No output schema, but description fully compensates.

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 description adds significant meaning: explains field selection, identifier vs domain usage, and format parameter for Apollo. Also details field categories and return object structure, far beyond schema basics.

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: keyless company/org enrichment with cryptographic attestation, field granularity, and drop-in replacement for Apollo Org Enrich. It distinguishes itself from black-box aggregators and sibling tools.

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

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

Provides clear guidance: use company name for firmographic/web fields, US ticker for financials, and format=apollo_org for Apollo drop-in. No explicit when-not-to-use, but context is sufficient for an AI agent to determine appropriateness.

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 thoroughly discloses read-only nature, chainId, failover, payment mechanism ($0.01 per call via x402 or prepay), and that no PII is involved. 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?

Dense paragraph with all key info front-loaded. Could benefit from better structure (e.g., bullet points for payment), but no wasted sentences.

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, but description notes returns JSON-RPC reply. Covers allowed methods, batch, payment, and constraints. Missing explicit error handling details but adequate for this tool type.

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

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

Schema coverage is 100%, and the description adds significant context: batch capability (up to 10), allowed methods, JSON-RPC version, and no API key. This greatly informs 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?

Clearly describes a keyless, read-only Base RPC proxy with specific verb (POST), resource (Base methods), and scope (chainId 8453, no API key). Distinguishes from siblings by being a specialized RPC 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?

States when to use: for read-only Base RPC reads without API key. Mentions payment methods and that write methods are rejected. Could improve by explicitly comparing to sibling tools.

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

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

With no annotations, the description must disclose behavior. It states the tool uses mechanical public data (OSM, PVGIS), handles no PII, and is a paid x402 tool with a specified endpoint and price. However, it does not address error handling, rate limits, or what happens for invalid addresses.

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, using a clear transformation arrow and bullet-like structure. Every sentence serves a purpose: use cases, payment, data sources, privacy. The x402 technical detail is relevant 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 partially explains return values as 'Structured JSON' with geocode, elevation, and solar potential fields. It lacks a detailed response structure, which would help agents parse results. The number of parameters (3) and absence of output schema warrant more detail.

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 three parameters are documented in the schema (100% coverage). The description adds meaning by explaining that lat+lon can be used together to skip geocoding, and that address is free-form. This clarifies usage 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 states the tool transforms address or lat/lon into geocode, elevation, and solar PV potential. It specifies use cases for real-estate, logistics, solar, and site-selection agents, and mentions data sources (OSM, PVGIS). This differentiates it from sibling tools like domain intel or business search.

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 use cases but does not explicitly state when not to use this tool or provide comparisons with siblings. It mentions payment via credits but lacks guidance on choosing between this and other enrichment tools like lion_domain_intel or lion_poi_business_search.

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 responsibility. It discloses key behavioral traits: keyless operation, payment requirement, output format (structured JSON with fields like sanctioned, list, match), daily refresh of snapshot, limitation on live XML parsing, and informational nature. 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 lengthy and includes technical details (e.g., x402 payment, 80MB XML limitation) that are relevant but could be more concise. It is front-loaded with the core purpose but includes extra information that might be streamlined.

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 explicitly lists all fields in the JSON response (sanctioned, list, match, snapshot_as_of, total_sanctioned_addresses). It explains limitations (live XML parsing impossible) and addresses edge cases (informational, not legal advice). For a single-parameter tool with no output schema, this is thorough.

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 sole parameter 'address' has a schema description (100% coverage). The tool's description adds an example ('0x...') and mentions support for ETH and BTC addresses, adding value beyond the schema. However, it does not provide additional format constraints or validation rules.

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: 'Keyless OFAC sanctions screening for crypto addresses.' It specifies the action (screening), the resource (crypto addresses), and the target list (US Treasury OFAC SDN list). This distinguishes it from sibling tools, which focus on enrichment, queries, or other 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 provides context for use: 'Compliance/KYB/AML lane (StableEnrich-style sanctions screening).' It also notes that it is address-level only and informational, not legal advice. However, it does not explicitly mention when not to use or provide direct alternatives among siblings.

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

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

No annotations provided, but description fully covers behavioral traits: keyless, pay-per-query, source (OSM Overpass + Nominatim), coverage varies, not verified, and detailed x402 payment mechanism with price and network. This is comprehensive 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?

Description is a single paragraph with dense information, but every sentence adds value. Could benefit from bullet points or better structure, but content is well-organized and front-loaded with core functionality.

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, but description details return fields: name, category, full address, phone, website, opening_hours, brand, lat/lon. Also covers limitations and data source. Complete for a search tool with no output schema.

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

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

Schema coverage is 100%, and the description adds significant meaning: explains mutual exclusivity of area/bbox and tag/category, provides example formats for area and tag, lists category options. This enhances 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?

Description clearly states it is a 'Keyless POI / business directory search' and specifies its function: pass an area and category/tag to get structured business listings. It distinguishes itself from Google Places, Foursquare, Yelp, providing a unique value proposition.

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 use cases: lead-generation, local-business intelligence, retail/CPG distribution mapping, logistics, competitive-mapping agents. Also clarifies what it is not: no people, no PII, not a verified business registry. This provides clear context for when to use this tool.

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

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

With no annotations provided, the description must disclose behavioral traits. It indicates the tool is free and returns a preview, implying read-only behavior. However, it lacks details on idempotency, error handling, rate limits, or authentication. The mention of a 'ref' parameter without schema documentation also creates confusion.

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 well-structured, front-loading 'FREE' and stating the purpose first. It lists outputs and usage in a logical order. Some redundancy exists (e.g., 'zero-commitment sample' and 'free teaser'), but overall it is efficient and non-verbose.

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 required params, output schema present), the description covers the main purpose and outputs. However, it omits operational details like error handling, authentication, and explanation of the undocumented 'ref' parameter. It satisfies basic needs but lacks completeness for a robust agent understanding.

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 documents the 'entity' parameter well with 100% coverage, but the description introduces an undocumented 'ref' parameter ('Pass ?entity=...&ref=....'), which contradicts the schema. This inconsistency reduces trust. The description adds no meaningful parameter-specific details 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 free sample with specific fields like attention_score and momentum for any entity, and explicitly differentiates it from lion_declare_need by calling it a 'primary free teaser'. The verb 'returns' and specific resource listing make the purpose unambiguous.

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

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

The description provides clear context by stating 'Use before any payment to validate fit', indicating when to use this tool. It also mentions it is a free sample alongside lion_declare_need, giving a hint of alternatives. However, it does not explicitly mention when not to use it or list other paid tools as 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?

No annotations are provided, so the description carries the full burden. It discloses: no API key needed, no signup, payment required, sourced from SEC EDGAR, US public companies only, not advice, pay-per-use, and the exact output structure. It does not mention error handling, rate limits, or idempotency, but for a simple read-only paid API, this is sufficient. The description adds significant context beyond the input 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?

The description is moderately long but well-structured: it starts with the core purpose, then input/output, then limitations, then payment details. Every sentence provides useful information, though some redundancy exists (e.g., 'keyless' mentioned twice). It is front-loaded with the key action and resource, making it easy for an agent to quickly grasp the tool's function.

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 details the exact output structure: company profile fields, recent_filings (last 5 with fields), XBRL financials. It also covers pricing ($0.005 USDC), payment method (x402), data source (SEC EDGAR), and limitations (US public only, no financial advice). This is comprehensive enough for an agent to select and invoke the tool correctly without additional information.

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 (ticker and CIK). The description reinforces the OR relationship ('Provide this OR cik') and gives examples, which adds marginal value. However, it does not explain edge cases like invalid tickers or missing parameters. Baseline of 3 is appropriate since the schema already describes parameters 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 clearly states that the tool provides 'keyless US public-company financials + filings' for validation purposes. It specifies the input methods (ticker or CIK) and the output structure (profile, filings, XBRL financials), distinguishing it from sibling tools that focus on domain intel, credit purchase, or other data types. The verb 'get' and resource 'financials+filings' are explicit, and the scope (US public companies only) is clearly 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 explicitly says 'no API key, no signup, payment is the only gate' and 'pass a ticker or CIK'. It also states 'not financial/investment/audit advice', implying limitations. It mentions the payment mechanism (x402, $0.005 USDC on Base). However, it does not explicitly tell when NOT to use this tool compared to alternatives like lion_domain_intel or lion_quick_intel, though the specificity of financial data makes it clear. Score 4 because usage context is clear but no 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?

No annotations are provided, but the description discloses the tool is mechanical, keyless, and uses x402 payment mechanism with a specific price and endpoint. It also notes credit usage for high-volume agents, giving good behavioral context. However, it does not explicitly state the tool is read-only or mention 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 informative but somewhat lengthy, including detailed payment instructions that could be externalized. The core purpose is front-loaded, but there is minor redundancy and non-essential detail that reduce 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 no output schema, the description explains the return value (risk_score 0-1 and itemized flags) and covers allowed chains and payment. It lacks details on error handling or timeouts, but for a mechanical risk check tool, it is fairly 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?

The schema covers both parameters with descriptions, and the description adds value by specifying supported chains (Base/Ethereum/Solana) and token address formats, as well as noting payment is always on Base. This enhances understanding 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 clearly states the tool returns a risk score and itemized flags for token safety, positioning it as a pre-trade check for any swap or token interaction. This distinguishes it from sibling tools which cover queries, credits, enrichment, and other 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 explicitly says 'Call before any swap or token interaction' and 'Essential for autonomous trading / wallet agents', providing clear when-to-use guidance. While alternatives are not discussed, the sibling tools are distinct enough that context suffices.

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 the tool is a read operation (GET), mentions it is non-commodity, and details the payment flow via x402 with price and network. However, it does not describe any side effects or safety aspects beyond being a read.

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

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

The description is concise and front-loaded with core functionality. It includes necessary details about the x402 payment flow without being overly verbose. A slight reduction in payment details could improve 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 the tool has only one parameter and no output schema, the description adequately covers what the tool does, what it returns, and the payment method. It is complete enough for an agent to 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?

The only parameter 'tx' is described in the schema, and the description adds minimal extra meaning ('Base tx hash 0x...'). With 100% schema coverage, the description adds no significant value beyond what the schema already provides.

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 the tool returns a transaction receipt and decoded calldata, specifying the endpoint and fields. It distinguishes from siblings like lion_enrichment_tx_bundle by noting it is complementary.

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 is complementary to keyless-rpc and enrichment, implying when to use it, but does not explicitly state when not to use it or specify alternatives. The guidance is implied 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 covers behavioral traits: it is keyless, requires payment via x402, sources data from the EU Commission VIES service, and includes a legal disclaimer. The output format and limitations (public records only) are disclosed.

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 with all essential details (purpose, usage, output, payment), but is somewhat lengthy. It is front-loaded with the core purpose, and every sentence adds 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 no output schema, the description thoroughly specifies the return fields (valid, company_name, address, etc.), payment method, data source, and limitations. It leaves no major gaps for correct agent 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 parameter descriptions. The description adds value by showing usage examples (e.g., '?vat=IE6388047V' or 'country=IE&number=6388047V') and explaining the logic of providing either full vat or country+number.

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: 'Keyless EU VAT number validation for KYB / compliance' and explicitly describes the output format. It is well-differentiated from sibling tools, which cover different domains like sanctions screening, business search, and financials.

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 (for EU VAT validation in KYB/compliance) and mentions that the buyer supplies the VAT number. It lacks explicit comparison to alternatives, but no sibling tool offers VAT validation, so usage context is clear.

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 x402 payment flow, price, structured output nature, and that no PII is returned. However, it does not discuss error conditions or what happens if the entity is not found. Still, for a paid tool, key behaviors are 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 one paragraph with key information front-loaded. However, it includes some marketing language (e.g., 'the way agents actually buy it') that could be trimmed for 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 the tool has one parameter and no output schema, the description covers the essential points: purpose, return type (structured numeric/boolean), payment model, and privacy reassurance. It is complete enough for this simple 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?

The only parameter 'entity' is well-described in the schema and the description adds context: 'Echoed back; never used to fetch or return personal data.' This goes beyond the schema's description and clarifies correct 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 the tool's function: keyless off-chain company enrichment returning a structured JSON vector. It specifies the type of data (firmographics, funding, etc.) and distinguishes itself from siblings by being keyless and pay-per-call.

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

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

No explicit guidance on when to use this tool versus alternatives. The description implies usage for company enrichment but does not provide when-not scenarios or mention sibling tools. Given 16 siblings, this is a significant gap.

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

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

No annotations provided, so description carries full burden. It discloses payment requirement ($0.005 USDC), data source (Wikidata CC0), and return scope (no people). Also explains the 402 challenge mechanism.

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 slightly verbose but every sentence adds necessary context. It is front-loaded with the most important information (keyless, global, payment).

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 structure, data source, limitations (no people), and payment model. It also hints at complementing sibling tools.

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

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

Schema coverage is 100%, but description adds value by explaining mutual exclusivity of 'entity' and 'qid', and clarifying the difference between name resolution vs direct QID lookup.

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 GLOBAL firmographic enrichment for any company/org' and specifies the output structure. It distinguishes from sibling tools by noting it complements US-only SEC and on-chain 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 provides clear context on when to use (global enrichment, keyless) and what not to use (no people/PII). It implies alternatives but does not explicitly name sibling tools.

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