LION - keyless attested compliance & data for AI 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 the premium nature, retention, re-fetchability, payment via x402, and the output format (LION_SIGNED_COMPLIANCE_RECEIPT_V1 + verdict). It does not mention any destructive behavior, but as a read tool, none is expected. Could be more specific about data sources.

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 quite verbose (over 100 words) and includes technical details like API endpoints and payment mechanics. While every sentence adds value, it could be more concise. The structure is adequate with bold heading and contrast to sibling.

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 that an output schema exists, the description does not need to explain return values in depth, but it does mention the receipt format. It covers payment, retention, use case, and contrast to sibling tool. Slightly lacking on exact data sources but sufficient for a paid compliance 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 description coverage is 100%, so baseline is 3. The description does not add significant meaning beyond the schema; it paraphrases the parameters and notes they are optional. No new constraints or formats are provided.

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 premium retained attested dossier for compliance, returning a signed receipt and verdict. It explicitly distinguishes from the $0.05 routine screen (lion_compliance_bundle) mentioned in the context.

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 this tool vs the cheaper screen: 'Use the $0.05 screen (lion_compliance_bundle) for routine per-payment checks; use this when you must RETAIN provable, re-fetchable audit evidence.' It also includes payment and re-fetchability details.

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 adequately discloses behavioral traits: it is keyless, no account, no PII, returns an Ed25519-attested verdict, is fail-closed on a hit, and requires an x402 payment of $0.05 USDC. It also mentions the optional signed receipt and the payment challenge endpoint.

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 well-structured, front-loading the core purpose and then providing use cases, parameter guidance, and pricing details. Every sentence adds value, though it could be slightly more concise without losing clarity.

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 with 5 optional parameters and an output schema, the description covers all essential aspects: what it screens, the output (verdict + flags), the optional receipt, and the payment mechanism. It leaves no critical gaps for an agent to understand 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%, providing baseline descriptions for each parameter. The description adds context by referring to the 'payTo' address and suggesting to pass address, domain, token, etc. This reinforces usage but does not add significant new meaning beyond the schema.

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

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

The description clearly states it screens a counterparty for OFAC sanctions, domain trust, token risk, and firmographics in one call. It distinguishes from sibling tools like lion_ofac_sanctions_screen and lion_token_risk_indicators by stating it is a combined bundle. The use cases list specific scenarios, making 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 explicitly lists use cases such as screening before payment, AML/KYC checks, and due diligence. It distinguishes from x402 by noting that x402 verifies payment mechanics, not sanctions. However, it does not explicitly advise when to use this bundled tool versus using individual sibling tools for specific checks, missing some exclusion 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 provided, so the description carries full burden. It discloses keyless x402 payment on Base, prepaid credits requirement, pricing (0.001 USDC per onchain read, 0.002 USDC per enrich field), Ed25519 attestation for enrichment, and the output structure (source-labeled, confidence-scored). It is 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?

The description is comprehensive and front-loaded with the main purpose. Although somewhat verbose, every sentence adds value, covering purpose, parameters, payment, and verification. Minor redundancy could be trimmed, but it remains efficient.

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

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

No output schema, but the description explains the enrichment output structure (source-labeled, confidence-scored, Ed25519-attested) and mentions the 402 challenge. It covers both onchain and enrichment parts fairly completely given the complexity, though the exact combined output format is not detailed.

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%. The description adds significant context beyond the schema: for 'address' it explains returns native balance + contract flag, for 'tx' returns receipt fields, for 'identifier' explains it accepts name/domain/ticker for firmographics+financials. This enriches parameter semantics beyond the brief 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 combines Multi-Chain Keyless RPC (Base and Ethereum) with Verifiable Enrichment in one call. It distinguishes itself by being broader than Ethereum-only keyless RPC (e.g., OneSource) and implies a composite of onchain reads and enrichment, differentiating from siblings like lion_keyless_base_rpc and lion_enrich_v1.

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 parameters (address, tx, identifier, etc.) and mentions it is a broader alternative to Ethereum-only RPC. However, it lacks explicit guidance on when NOT to use this tool or clear alternatives for specific use cases (e.g., if only onchain or only enrichment is needed).

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

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

No annotations provided, but the description compensates by disclosing the x402 payment mechanism (0.02 USDC), keyless access, Ed25519 attestation, and data sources (crowdsourced Open Prices). It indicates read-only behavior implicitly.

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?

While front-loaded with key info, the description includes promotional language and marketing fluff ('THE simple useful paid API AI agents actually pay for', 'This is the one') 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's complexity (3 params, no output schema), the description covers the returned data (product info and prices), payment mechanism, and use cases. It is complete but could mention error handling or rate limits.

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

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

Schema description coverage is 100%, and the description adds meaning beyond the schema by showing example query strings and clarifying that barcode is primary and name is fallback. This 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 provides real CPG product data and live shop prices by barcode or name, with detailed examples and output. It distinguishes itself from siblings which are for different data types (web search, domain intel, etc.).

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 (price bots, shopping agents, retail intel, market research) and mentions it is a paid x402 tool. It does not explicitly state when not to use or list alternatives, but the context signals and sibling list imply differentiation.

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

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

With no annotations, the description fully informs about the tool's behavior: purchase flow, token format (lct_...), balance deduction, keyless/PII-free nature, and reference to standard error_recovery and payment_instructions. It also includes the x402 challenge URL for transparency.

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

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

The description is verbose with multiple sentences. It front-loads the key benefit but includes some redundancy (e.g., 'Top up anytime' repeated the idea). A more concise version could improve efficiency for quick scanning.

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 payment flow complexity, the description covers the core mechanism, token usage, and references to standard patterns. The output schema exists to detail return values. Minor gaps: no explicit mention of how to obtain the output schema or error responses, but sufficient for an agent.

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

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

Schema coverage is 100% with a clear enum description. The description adds context about pack sizes but lists $0.10/$0.50/$1.00, which differs from the schema's enum values (1.00, 5.00, 20.00). This discrepancy could confuse agents, so no added value; baseline 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 description clearly states the tool's purpose: purchasing LION credits via x402 payment to obtain a session token for subsequent paid calls. It distinguishes itself from sibling tools by specifying it's a credit purchase mechanism, not a regular on-chain transaction or query.

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 recommends this tool for agents doing 50+ calls/day and outlines benefits over repeated individual payments. It also indicates when not to use it (no per-call transactions) and mentions the rationale for the credit system.

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 that paid responses are Ed25519-attested and that the tool routes to other tools. Could mention more about side effects or rate limits, but sufficient for a routing 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?

One dense paragraph, front-loaded with 'FREE' and core concept. All sentences contribute useful info, but slightly long. Good structure for a multi-path tool.

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

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

Given complexity (router with many options) and presence of output schema, description adequately covers main paths and response attestation. Could include expected output format or error handling but complete enough for selection.

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%, baseline 3. Description adds value by explaining how 'need' is used (plain-language), suggesting values for 'category' (enrichment, location, etc.), and clarifying 'max_price_usdc' as budget per call.

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 allows users to 'Tell LION what you need in plain language' and distinguishes it from sibling tools by being the entry point for free and paid options, listing specific paths like lion_verified_company_file and lion_token_risk_indicators.

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

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

Provides clear context on when to use via examples ('company enrichment', 'token risk') and mentions default paid path, free samples, and routing. Does not explicitly state when not to use, but implies direct use of siblings for specific 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 fully discloses the workflow: web search -> scrape -> enrich (Wikidata + SEC) -> domain trust -> merge into Ed25519-attested JSON. It also mentions keyless, no account, no PII, and the x402 payment mechanism, so an agent knows it is a read/compute operation with monetization.

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, then efficiently covers parameters, use cases, alternatives, pricing, and payment in a few sentences. No redundant words; every sentence contributes meaningful 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 tool's complexity (multi-step research, payment, alternatives) and lack of output schema, the description provides all necessary context: process, use cases, parameter roles, cost structure, and differentiation. An agent can confidently select and invoke this 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 description coverage is 100%, so baseline is 3. The description adds context by integrating parameters into the workflow (e.g., 'domain override for firmographics') and explains the receipt parameter, but does not add new semantic detail beyond what the schema provides. A 4 reflects good contextual integration.

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 'ONE-CALL attested company/crypto deep research' tool that combines search, scrape, enrich, and domain trust. It distinguishes itself from siblings by contrasting with StableEnrich's 3-4 call loop, so purpose is specific 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?

Explicitly lists use cases (company research, vendor due diligence, etc.) and provides an alternative: 'For people/email/LinkedIn/maps use stableenrich.dev — LION proves companies.' Also explains optional parameters like volume pricing, so agents know when to adjust.

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 behaviors: payment required via x402, use of specific public sources (Cloudflare DNS-over-HTTPS, crt.sh), Ed25519 attestation, and no API key needed. This exceeds basic 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?

Description is front-loaded with the key value proposition. While lengthier than minimal, each sentence adds necessary detail. Could be slightly more concise but remains structured and 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?

Despite no output schema, the description thoroughly explains the output structure (DNS/HTTP/TLS signals, trust score), verification mode, and payment method. Completely covers what an agent needs to invoke and interpret results.

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

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

Schema coverage is 100% for the single parameter 'domain', so baseline is 3. The description adds value by showing exact usage (?domain=stripe.com) and explaining input processing (scheme/path stripped).

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 the tool provides keyless domain intelligence via a single domain input. Distinguishes itself from sibling tools by emphasizing its narrow, verifiable niche with Ed25519 attestation, and contrasting with a broad trust/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?

Explicitly describes use case: gating a counterparty before trusting. Notes limitations (domain/infrastructure only, no PII). Lacks explicit alternatives but the narrow niche makes it clear when to 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 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?

With no annotations, the description fully discloses all behavioral traits: pay-per-field model (0.002 USDC), keyless access, cryptographic attestation (Ed25519/SHA-256), field-level output structure (value, confidence, source, as_of), data sources (Wikidata CC0, SEC EDGAR), no PII, and x402 payment protocol. 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 but front-loaded with a clear first sentence. Every paragraph adds unique value (use cases, features, pricing, output format, comparison). Minor redundancy exists (e.g., repeated mention of keyless), but overall it is well-structured and 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 tool's complexity (5 parameters, no output schema), the description is exceptionally complete. It covers input types, output format (with attestation), pricing, payment protocol, and use cases tailored for AI agents. It leaves no significant gaps for an agent to misunderstand.

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 beyond the schema. It explains the relationship between identifier (name, domain, ticker) and fields/format, provides examples, and clarifies when to omit fields (for apollo_org format). This helps an agent invoke the tool correctly.

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

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

The description clearly states the tool does company data and firmographics lookup with a specific verb-resource combination. It distinguishes itself from siblings by emphasizing keyless, attested, field-granular, pay-per-field features and mentions 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?

The description provides extensive use cases (enrichment, KYB, verification, onboarding) and explicit input rules (use name for firmographic/web, ticker for financials). It contrasts with alternatives (black-box aggregators, flat-bundle incumbents) but does not explicitly mention when not to use this tool vs specific sibling tools like lion_sec_financials or lion_wikidata_firmographics.

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 behavioral traits: the tool is read-only (write methods rejected before payment), forwards requests to a free public RPC failover set, returns JSON-RPC replies plus decoded events for eth_getLogs, and explains payment requirements via x402 or prepaid credits. 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 somewhat lengthy but each sentence adds crucial information: core functionality, method lists, chain switching, pricing, and payment options. It is well-structured with front-loaded purpose, though minor redundancy could be trimmed.

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 handling) and no output schema, the description covers essential aspects: read-only methods, pricing per method, chain selection, response includes decoded events, and authentication methods. It lacks detail on error handling or rate limits, but is adequate for agent selection.

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 significant value by explaining that requests can be single or batch (up to 10), that a chain query parameter can switch to Ethereum, and which specific methods are supported. This context goes beyond the schema's basic field descriptions.

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

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

The description clearly states that this tool provides a keyless multi-chain RPC for Base and Ethereum, allowing agents to POST standard JSON-RPC requests of read-only methods. It distinguishes itself from sibling tools like lion_adaptive_query or lion_ofac_sanctions_screen by specifying its unique function as a blockchain RPC proxy.

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 read-only blockchain queries without an API key) and contrasts it with Ethereum-only RPCs, but does not explicitly compare to sibling tools. However, the context provided (payment methods, chain switching) gives clear guidance on usage scenarios.

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?

Even with no annotations, the description discloses key behaviors: it uses mechanical public data (OSM + PVGIS), returns structured JSON, is paid via x402, and states no PII is collected. This covers data sources, cost, and privacy. Missing details like rate limits or error responses, but overall transparent for a read-only enrichment 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 detailed but efficient. It front-loads the core transformation and then adds necessary context (data sources, pricing, payment flow). Every sentence contributes meaningful information, though the payment details could be condensed into a separate note.

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

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

The tool has no output schema, but the description mentions output as 'Structured JSON' and lists fields (kWh/m2, optimal tilt/yield). It does not describe error handling or response structure. For a paid tool, more explicit output details would be beneficial, but the description is adequate for a simple enrichment.

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 value by clarifying the usage pattern: 'provide address OR lat+lon' and 'Use with lon to skip geocoding.' This goes beyond the schema's individual parameter descriptions, making it more useful for an AI 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 states the tool's function: converting an address or lat/lon to geocode, elevation, and solar PV potential (kWh/m2, optimal tilt/yield). It lists specific use cases (real-estate, logistics, solar, site-selection agents), which distinguishes it from sibling tools that focus on other domains like business search or 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 provides usage context: it is a paid tool ('Keyless x402 on Base', price 0.02 USDC) and advises using credits for volume. It also notes that providing lat/lon skips geocoding. However, it does not explicitly compare to alternative tools or state when not to use it, though the unique solar potential implicitly differentiates 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: it is a paid tool ($0.005 USDC on Base via x402), uses daily refreshed OFAC SDN list, returns specific fields, and is cryptographically provable (Ed25519-attested). It also notes limitations (no PII, not legal advice).

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 each sentence adds meaningful information: payment, output fields, data source, verification, and disclaimers. It could be slightly more streamlined but 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?

There is no output schema, but the description fully details the output fields (sanctioned, list, match, snapshot_as_of, total_sanctioned_addresses) and explains the technical rationale (80MB XML cannot be parsed live). It covers all necessary context for an agent to 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?

The schema covers the single parameter (address) fully. The description adds valuable context by providing an example (0x... for ETH) and mentioning support for other address types (BTC/other), as well as explaining the screening 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?

The description clearly states the tool screens crypto addresses against the OFAC SDN list, with specific input and output. It distinguishes itself from sibling tools (none of which are similar) and specifies its niche as a single-field verifiable check.

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 the tool is for a narrow verifiable niche, not a broad compliance suite, and is informational only. It advises verifying against the official list for binding compliance. It does not explicitly list when not to use, but context implies it's unsuitable for comprehensive compliance.

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?

No annotations are provided, so the description must disclose behavioral traits. It reveals that the tool is free and includes an example URL, but fails to mention authentication needs, rate limits, or what actions are performed (e.g., any side effects). The description is insufficient for behavioral transparency.

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

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

The description is short but cluttered with pricing and upgrade information that is not directly relevant to tool usage. It lacks a clear structure and prioritizes promotional content over functional explanation.

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 having an output schema (per context signals), the description does not mention what the output contains or how to interpret it. Given the complexity of the sibling tool set, the description is severely incomplete and fails to provide essential context for an AI agent.

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

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

The input schema has one parameter 'entity' with a clear description. However, the description suggests an additional parameter 'ref' that is not in the schema, which contradicts the schema and could mislead. The description adds little value beyond the schema and introduces confusion.

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

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

The description labels the tool as a 'FREE sample teaser' and implies it provides a data quality sample, but doesn't clearly state what the tool does or what output it produces. The purpose is vague and confusing, mixing pricing details with functionality.

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 upgrade alternatives (e.g., lion_verified_company_file) but does not provide explicit guidance on when to use this tool vs. siblings. The context of when to choose a free sample over paid tools is implied but not clearly articulated.

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 attestation, pricing model, honest blocked-page handling, and keyless operation. It does not mention rate limits or restrictions, but for a read-only tool this is adequate.

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

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

The description is two sentences plus pricing detail in brackets. It is front-loaded with the core purpose. The pricing detail, while informative, is slightly extraneous but does not harm 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?

For a simple one-parameter tool with no output schema or annotations, the description adequately covers purpose, return values, behavior on blocked pages, and attestation. Minor gaps exist (e.g., redirect handling, JavaScript support) but are not critical for basic use.

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 (url). The description adds that the URL must be absolute http(s) and provides an example, adding value beyond the schema's terse 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 it does a 'Keyless ATTESTED web scrape' and returns specific fields (title, markdown, word_count). It distinguishes from siblings like lion_web_search by focusing on scraping, not 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 provides context for use ('For research, RAG, and agent grounding') and mentions honest handling of blocked pages. It does not explicitly contrast with alternatives like lion_web_search, but the usage intent 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?

No annotations provided, but description fully compensates. It discloses the exact output structure (JSON with company profile, recent filings, headline financials), cryptographic attestation (Ed25519), source (SEC EDGAR), limitations (US public only, no PII), and payment mechanism. 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?

Description is comprehensive but slightly verbose, repeating phrases like 'no API key, no signup'. However, it front-loads the key purpose and each sentence adds value. Could be tightened slightly without losing 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?

No output schema, but description clearly explains what is returned (company profile, recent filings, headline financials). It also covers payment gate, source, and limitations. Given the complexity and lack of annotations, the description 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 descriptions for 'cik' and 'ticker'. Description adds context by showing example usage ('?ticker=AAPL' or '?cik=0000320193') and explaining that one must be provided. This goes beyond schema to guide 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?

Description clearly states it provides keyless US public-company financials and filings for validation. It distinguishes from siblings by emphasizing the keyless, verifiable niche and narrow scope ('NOT a broad financial-data suite'). Verb is implied but clear (get/retrieve). Resource 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?

Description specifies when to use: for company/financial validation, with US public companies only. It notes the payment gate (x402) and that it's not investment advice. While it doesn't explicitly say when not to use, the context is clear and provides alternatives by omission (narrow niche).

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

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

With no annotations, the description fully discloses key behaviors: keyless access, payment via x402, graceful handling of Reddit rate limits, attestation, source citation, and disclaimer against financial advice. This is 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?

The description is relatively long but each sentence adds unique value (e.g., data sources, output fields, pricing, attestation). It is structured with front-loaded key information and clear details.

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 enumerates the output fields (title, points, etc.) and mentions the trend_score formula is documented elsewhere. For a single-parameter tool, it covers most necessary context, though the formula reference could be inlined.

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 'topic' has complete schema coverage (100%), and the description adds practical context with examples and usage instructions, going beyond the schema's brief 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 'keyless social-signal intel' with explicit data sources (HN primary, Reddit secondary) and output format (attested JSON). It distinguishes itself from sibling tools by focusing on social signals from specific platforms.

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

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

It explains how to use the tool by passing a ?topic parameter with examples. However, it does not explicitly specify when not to use it or how it compares to siblings, leaving some gap in 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 fully discloses behavioral traits: speed (lightning), cost ($0.005), payment mechanism (x402, USDC on Base), attestation (Ed25519), batch mode, and that lion_intel history compounds with calls. This goes well beyond basic functionality.

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, containing multiple use cases, payment details, attestation info, and batch mode. While informative, it could be more concise. The key purpose is front-loaded, but additional sentences on attestation and endpoint are less critical.

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

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

Given no output schema, the description covers return values (risk_score, flags, lion_intel history), and addresses complexity (2 params, batch). It provides comprehensive context for an AI agent to understand the tool's behavior and output.

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% (both parameters described). The description adds some context (default chain, address format) but does not significantly extend beyond the schema. The batch mode description mentions a 'tokens' parameter not in the schema, which could cause confusion.

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

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

The description clearly states the tool's purpose: a pre-trade risk gate for tokens, returning risk score and flags. It distinguishes itself by specifying supported chains, batch mode, and proprietary history, making it distinct from sibling tools. The verb 'check if a token is safe to buy' is specific.

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

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

The description explicitly states 'agents call this BEFORE every swap' and lists use cases (rug check, holder concentration, etc.). It also describes batch mode for portfolio scanning. However, it does not explicitly mention when not to use or compare to siblings like safetyStack or ultraFastBatchRisk, which are similar.

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 bears the burden. It discloses that the tool returns structured JSON, is cryptographically provable (Ed25519-attested), sourced from EU VIES, requires payment, and is not legal advice. No behavioral traits are hidden.

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 necessary context—use case, parameters, sourcing, attestation, payment, and disclaimers. It could be slightly tighter, but the information density justifies the length.

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 output schema, the description adequately explains the return fields. It also covers the payment mechanism and the sourcing from EU VIES. All relevant context for invocation is provided.

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 value by explaining the parameters with examples (e.g., full VAT number or country+number). It clarifies the format and usage beyond the schema's basic 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 validates EU VAT numbers for KYB/compliance and distinguishes itself from a broad compliance suite. The verb 'validate' and resource 'EU VAT number' are specific 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 explains when to use (keyless, single VAT check) and sets expectations by noting it is not a full compliance suite. However, it does not explicitly state when not to use or name 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 the returned data format (merged, attested dossier with source trails), pricing ($1.00, $0.25 cached, free sample), and the x402 payment mechanism. It does not mention rate limits or error handling, but for a paid tool, the cost and payment details are well 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 relatively long but well-structured, starting with the main purpose, then detailing the returned data, use cases, and pricing. Every sentence adds value, though the list of use cases could be summarized. The technical x402 detail is necessary for payment transparency. It is appropriately sized for a complex tool.

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

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

Given the tool's complexity and lack of output schema, the description explains the returned fields, free sample, cost, and payment method. It is missing error handling or rate limit information, but for a paid API tool, these are acceptable gaps. The description is sufficiently complete for an agent to decide when and how to invoke it.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the domain parameter via example, the sample parameter for free samples, and implies the vat parameter for VAT validation. However, it does not explicitly describe the vat parameter's format (e.g., country code) or the exact behavior of sample beyond '?sample=1'. It adds meaning but not fully compensates for the low 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 states the tool's function as a composite KYB, counterparty due diligence, and OFAC sanctions screening service. It lists specific data points (firmographics, SEC EDGAR financials, EU VAT validation, OFAC sanctions flag, domain trust) and distinguishes itself from sibling tools by emphasizing that it merges multiple data sources into one 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?

The description provides explicit use cases (verify before onboarding, KYB/KYC, OFAC screening, vendor due diligence) and mentions pricing. However, it does not explicitly state when not to use this tool (e.g., for a single data point like VAT only), though the sibling tools imply alternatives. The guidance is clear 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?

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 are provided, so the description carries full burden. It discloses that the tool is keyless, requires payment via x402 ($0.02 USDC), returns clean JSON with specified fields, and results are Ed25519-attested for tamper-proof verification. It does not mention error handling or rate limits, but the behavioral traits are clearly communicated.

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 well-structured. It front-loads the key feature 'attested web search' and then covers payment, output format, and use cases. Every sentence adds value, though it could be slightly more concise without losing 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 tool has only two parameters, no output schema, and no annotations, the description covers the essential aspects: result format, payment, attestation, and use cases. It lacks explicit handling of errors or edge cases, but for a simple search tool it is contextually 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% (both parameters have descriptions). The description adds value by specifying the query format ('Pass ?q=<query>'), the optional num parameter with max 20, and the default of 8. This provides practical guidance beyond the schema.

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

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

The description clearly identifies the tool as an attested web search, specifies the output (title, url, snippet, source as clean JSON), and highlights the key differentiator (Ed25519 attestation). It distinguishes this tool from sibling tools by focusing on web search with cryptographic attestation, which is unique among the listed 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?

The description explicitly states use cases: 'For research, RAG, fact-finding, and agent grounding.' It mentions that results are premium when configured and Wikipedia/encyclopedic otherwise. However, it does not explicitly exclude alternatives or provide when-not-to-use guidance relative to siblings, which is a minor 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.

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

With no annotations, the description fully discloses behavioral traits: paid tool ($0.01 USDC on Base), Ed25519-attested, proprietary panel of 25k+ endpoints daily-probed (41% live), keyless, and the 402 challenge mechanism. 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 dense but front-loaded with core purpose. It includes necessary technical details (e.g., payment, attestation) but could be slightly more structured, e.g., separating the technical note about GET request.

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 key use cases, data source (25k endpoints, 41% live), and payment. However, without an output schema, it lacks details on return format or pagination, though the x402 protocol may provide that 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%, and the description adds context to each parameter (e.g., 'url' for verification, 'address' for screening, 'categories' for fair price), enhancing understanding 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 is a discovery and trust layer for the x402 economy, listing specific queries (?need=, ?url=, ?address=, ?categories=1) that differentiate it from siblings like lion_web_search or lion_token_risk_indicators.

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

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

The description provides explicit guidance on when to use each parameter (e.g., '?need=' for discovery, '?url=' for verification) and mentions spam-farms are excluded, but does not explicitly compare to sibling tools or state when not 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?

No annotations are present, so the description fully carries behavioral disclosure. It details the paid x402 mechanism ($0.005 flat), the GET endpoint, payment header, return array with risk fields, and Ed25519 attestation. This is 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?

The description is long but well-structured with front-loaded key info and clear paragraphs. While every sentence adds value, it could be slightly more concise. Still, it is appropriately detailed for a complex paid tool.

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

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

Without an output schema, the description fully explains the return structure (results array with risk_score, risk_band, flags, etc.). It also covers payment flow, alternatives, and chain constraints, making it complete for an agent to invoke correctly.

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

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

Schema coverage is 100%, and the description adds significant meaning: how tokens are passed as comma-separated query string, that chain is optional but payment always on Base, and that max is 10 tokens. This complements the schema effectively.

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

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

The description clearly states the tool is a batch pre-trade risk gate for up to 10 tokens, specifying use cases like portfolio scanning and multi-snipe safety. It distinguishes from sibling tools like 'ultraFastIsHoneypot' and 'ultraFastLiquidityCheck' by offering a comprehensive batch verdict.

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 explicit use cases (scan wallet holdings, multi-snipe pre-trade gate, portfolio refresh, batch go/no-go) and mentions a single-token alternative mode. It lacks explicit 'when not to use' but context implies batch usage for multiple tokens.

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 behavioral traits: it costs $0.025, returns an Ed25519-attested response, supports up to 3 tokens, and clarifies that 'smart_money' is a heuristic, not labeled data. It also notes that all checks derive from one on-chain computation rather than separate paid calls. These details are critical for an AI agent to assess safety and cost.

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 each sentence adds necessary detail: purpose, cost, checks, endpoint format, output structure, note about heuristic, and payment instructions. It is front-loaded with the core purpose and progressively layers details. Minor redundancy could be trimmed, but overall effective.

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

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

Given the tool's complexity (multiple checks, attestation, payment), the description covers all essential aspects: what checks are performed, input format (single or up to 3 tokens), output fields (go_no_go, all_pass, count, tokens with details, attestation), pricing, API endpoint, and caveats (smart_money heuristic). No output schema exists, but the description fully documents the return format.

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

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

Schema coverage is 100%, but the description adds meaningful context beyond the schema definitions. It explains the single token alternative ('?token=0x...&view=fullstack'), the max of 3 tokens, the comma-separated format, and the required 'view=fullstack' parameter. This helps the agent construct the correct API call.

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 this tool performs 'ALL seven UltraFast checks' and returns a master GO/NO_GO. It specifies the exact checks included (risk, honeypot, liquidity, etc.) and distinguishes itself from sibling tools like ultraFastIsHoneypot or ultraFastSafetyStack by being a bundle. The name and title also reinforce the bundling concept.

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 positions the tool as 'the default safety layer for autonomous agents' and 'the one call to drop in front of every trade,' implying broad usage. However, it does not explicitly state when to use this bundle versus individual checks (e.g., for a single token) or when not to use it. Sibling tools are listed but without comparative 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 fully discloses behavior: it is a pre-swap check that returns an 'Ed25519-attested verdict' with fields like isHoneypot, honeypotScore, etc. It explains the payment flow ('After paying, GET /api/x402/...') and pricing. While it doesn't mention read-only nature explicitly, the use case implies it is non-destructive.

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 covers purpose, usage, return format, use cases, and pricing. It is front-loaded with the core purpose. While it could be slightly better structured with bullet points, it remains concise and 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?

For a simple tool with one parameter, no output schema, and no annotations, the description is remarkably complete: it explains what it does, how to call it, what it returns, use cases, pricing, and how it fits with sibling tools. No gaps remain.

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

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

Schema coverage is 100% for the single parameter 'token' with a description. The description adds context about the format and chain ('0x + 40 hex', 'Base/Ethereum') but does not significantly enhance beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Pure pre-swap honeypot check for autonomous sniping, MEV and trading agents - is this token a honeypot/trap before you buy?' It distinguishes from sibling tools like ultraFastLiquidityCheck and lion_token_risk_indicators by specifying its specific role in a pre-trade safety stack.

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 use cases: 'block a honeypot before a snipe; gate every buy on a fast honeypot check; pair with ultraFastLiquidityCheck + lion_token_risk_indicators for a full pre-trade safety stack.' It also mentions pricing and payment method. However, it does not explicitly state when not to use it or directly contrast with 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?

With no annotations, the description fully discloses behavioral traits: it is a paid tool ($0.005), keyless x402, read-only (pre-swap check), returns an Ed25519-attested verdict with specific fields, and requires a payment-signature header. It also specifies the network (Base). 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 concise, with front-loaded purpose and well-organized sections (purpose, use cases, response, payment). Each sentence adds value, though the payment details could be slightly shortened.

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

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

Given the tool's simplicity (one parameter, no output schema), the description is complete: it explains the return values, use cases, payment mechanism, and how to call it. An agent has all necessary information to select 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?

The single parameter 'token' is described with format (0x + 40 hex), how it is sent in the URL (?token=...&view=liquidity), and supported networks (Base/Ethereum). This adds meaning beyond the schema, which only gives type and a brief 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 exactly what the tool does: a pre-swap liquidity check for tokens, answering whether a token has real DEX liquidity and depth. It is specific about the resource (token liquidity) and the verb (check), and distinguishes itself from sibling tools like ultraFastIsHoneypot and lion_token_risk_indicators.

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

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

The description provides explicit use cases: avoid swapping into thin liquidity, gate buys on minimum liquidity, and pair with other tools for a full safety stack. It also mentions payment details. However, it does not include explicit when-not-to-use scenarios, but the 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?

No annotations provided, but the description fully discloses the return format (Ed25519-attested JSON with fields), pricing ($0.005), payment mechanism (keyless x402), and API endpoint. This adequately 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 dense but well-structured, covering purpose, usage, return format, pricing, and API details. Slightly verbose but every sentence adds 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 and no annotations, the description provides sufficient context: return fields, payment details, and when to call. Minor gap in explaining the full structure of 'checks', but overall complete for its paid nature.

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 (token) with schema coverage 100%. The description does not add significant meaning beyond the schema, which already documents it as an EVM token address. 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 'one-call go/no-go before you spend' that bundles risk, honeypot, and liquidity checks. It distinguishes itself from sibling tools like ultraFastIsHoneypot and ultraFastLiquidityCheck by positioning as a consolidated replacement.

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

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

Explicitly says 'call it before EVERY swap' and targets autonomous agents. However, it does not state when not to use it or explicitly list alternatives, though it implies it replaces separate checks.

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 the tool's behavior: it requires a paid x402 call, returns Ed25519-attested data, and includes rug score components (high-risk functions, unverified/owner-retained contract, holder concentration, thin liquidity). It also describes the API endpoint and payment 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 efficient, front-loading the purpose and providing key details. It is slightly verbose with repeated payment information ('$0.005', 'Base'), but overall each sentence contributes value. It could be more concise, but 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?

Given the single parameter, no output schema, and no annotations, the description provides comprehensive context: purpose, usage, payment, API call, response structure, and the components of the rug score. It leaves no critical gaps for an agent evaluating whether to use this 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 baseline is 3. The description in the main text adds some context about how the parameter is used (in the URL query string after payment), but the schema already describes the parameter as an EVM token address. The description does not add significant semantic meaning beyond what the schema 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?

The description clearly states the tool collapses rug risk into a single number for autonomous sniping/MEV/trading agents. It specifies the verb 'Collapse' and the resource 'rug risk' into a score, and distinguishes from sibling tools like ultraFastIsHoneypot or ultraFastLiquidityCheck by providing a blended composite score.

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 'Use it as a one-glance go/no-go number before a snipe,' providing clear usage context. It does not explicitly state when not to use or compare to alternatives, but the sibling context and the indication that it's a single-number summary imply it's for quick decisions, not deep analysis.

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 covers cost ($0.012 flat), payment mechanism (x402 with Payment-Signature header), returns attested response, and explains the call flow. It does not mention any destructive actions, which is appropriate.

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 core value proposition. Every sentence adds useful information, though the technical endpoint details could be slightly more 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 attestation response structure, token-level checks, and master verdict. It covers payment, token limit, and usage format, making it complete for the tool's purpose.

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. The description adds valuable context like comma-separated format, view parameter, and that tokens are Base/Ethereum addresses, going beyond the basic schema.

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

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

The description clearly identifies the tool as a complete pre-trade safety bundle that performs multiple checks (risk, honeypot, liquidity, OFAC) for up to 5 tokens and returns a single GO/NO-GO verdict. It explicitly distinguishes from sibling tools like ultraFastIsHoneypot or ultraFastLiquidityCheck.

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 the tool is for 'autonomous sniping, MEV, portfolio and multi-token trading agents' that want one gate instead of stitching separate checks. It provides an alternative (using individual checks) by referencing siblings, though it does not explicitly list 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?

No annotations provided, but description fully discloses HTTP method, endpoint, payment mechanism (keyless x402), return structure (Ed25519-attested JSON), and important caveats (heuristic, not labeled-wallet tracking, use topHolderOverlap as concrete number).

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 but well-structured: purpose, API call, return fields, caveat, pricing. No redundant sentences. Could be slightly more concise but all information is relevant.

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

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

For a tool with one parameter and no output schema, the description covers API endpoint, payment, return structure, attestation details, and limitations. Completely adequate for an agent to understand and invoke 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?

Single parameter 'token' is described with 100% schema coverage. Description adds context that it's an EVM address, sent as query parameter, and works on Base/Ethereum. Provides slight extra value 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?

Title and description clearly state it provides a fast holder-distribution signal for trading agents, specifically a 'smart money' flag based on holder concentration. It distinguishes from sibling tools like 'ultraFastIsHoneypot' by focusing on concentration heuristics.

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?

Describes the payment process, HTTP GET endpoint with required header, and explicitly advises using 'topHolderOverlap' as the concrete number. Does not explicitly state when not to use or compare with alternatives, but context is clear enough.

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