LION - Trend Intent MCP + Marketplace Visibility Audit

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

Despite no annotations, the description transparently discloses key behaviors: payment via x402, return of freshness fields, public keyless data, and that /tools/call returns payment-required metadata. It also clarifies that data is raw market data and not advice. However, it lacks details on error handling or rate limits.

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

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

The description is well-structured, beginning with overall purpose, then listing parameters, source details, return format, and payment. Every sentence is informative and earns its place, with no wasted words given the complexity.

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

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

Despite no output schema, the description fully explains the return format (typed JSON rows with freshness fields) and the payment flow. It covers data sources, filtering, and constraints, leaving no critical gaps 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?

Schema coverage is 100%, and the description significantly enriches each parameter with domain-specific meaning. It explains what each source returns, the purpose of q, sort options, and filters, adding substantial value beyond the schema definitions.

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

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

The description clearly states it is a unified query endpoint for live Base on-chain data, specifying the three verticals (base_dex, token_risk, defi_yields). It distinguishes itself from sibling tools which are more specific output formats or utilities, 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?

No explicit guidance on when to use this tool versus sibling tools. The description does not mention alternatives or provide context for tool selection, leaving the agent to infer usage from capabilities alone.

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: it is a read-only live feed, requires x402 payment, returns payment-required metadata on initial call, and emphasizes it is not financial advice. The payment mechanism and data source are explicitly stated.

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

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

The description is front-loaded with the core purpose and includes necessary details like source, metrics, and payment info. Slightly verbose due to legal disclaimer and payment explanation, but no wasted sentences.

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

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

Despite no output schema and no annotations, the description covers all essential aspects: live data source, input (none), output content (metrics list), payment flow, and lack of advice. It is fully complete for a parameterless data feed 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 tool has zero parameters, so the schema coverage is 100% and the description adds no parameter-specific meaning. Following guidelines, baseline score is 4 for no parameters.

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

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

The description clearly identifies the tool as a live DEX market-data feed for Base tokens, listing specific metrics and distinguishing it from sibling tools like trend intent signals. It states the verb 'returns' and the resource 'ranked snapshot', 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 implies usage for trading and research agents but does not explicitly state when to use this tool vs alternatives such as lion_trend_intent_signal_json or lion_adaptive_data_query. No guidance on exclusions or prerequisites beyond payment requirement.

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

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

With no annotations provided, the description fully discloses behavior: it extracts and cross-checks payment terms, returns specific fields, and notes it does not perform payments, security audits, or fund movements. Limitations are clearly stated.

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 without being verbose, though it could be slightly tighter. It front-loads the key purpose and then provides details. Minor redundancy (e.g., repeating 'LION does NOT perform 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?

Despite no annotations, the description covers purpose, usage, inputs, outputs, and limitations comprehensively. The output schema is implied by listing return fields. No obvious gaps for this single-parameter 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 sole parameter 'url' has a schema description, but the tool description adds context: 'LION extracts the target live 402 payment terms...' explaining how the URL is used. Schema coverage is 100%.

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

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

The description starts with 'Pre-spend payment-term trust check for x402 endpoints,' clearly specifying the tool's function. It distinguishes from sibling tools (data query and signal tools) by focusing on payment audit before signing.

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

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

It states when to use: 'Before your agent signs a Payment-Signature, call this with a target x402/MCP service URL.' It also clarifies what the tool does not do (no payment, no security audit, no settlement), providing exclusion criteria.

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

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

Discloses payment cost ($0.01 USDC), network (Base mainnet), and two-step process (initial call returns metadata, settle invoice to fetch CSV). No annotations provided, so description carries full burden; adequately covers workflow but could mention response size or rate limits.

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

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

Concise single paragraph, front-loads main purpose. Could use bullet points for readability but not overly verbose.

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

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

Covers what the tool returns (CSV content), use cases, and payment workflow. Lacks specifics on CSV format (headers, delimiter) but adequate for agent decision and invocation.

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

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

No parameters, schema coverage 100%; baseline 4. Description adds context about CSV content (column set, use cases) beyond empty 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 provides hardware-wallet buyer-intent intelligence as flat CSV, distinguishes from JSON sibling by format and workflow, and lists specific query types and use cases.

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?

Specifies use cases (spreadsheet/pipeline ingestion, affiliate-routing, comparison-research) and mentions payment workflow. Does not explicitly exclude JSON variant but context from siblings implies when not 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 full burden and does well by disclosing the non-standard behavior: the tool returns payment-required metadata via x402 mechanism (HTTP 402 + EIP-3009), not the dataset. It also explains the payment route. However, it omits details about the metadata structure, error responses, or rate limits, leaving some behavioral aspects unclear.

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 front-loads the purpose and then adds details about payment and use cases. It is informative but a bit lengthy. Some redundancy exists (e.g., 'Hardware-wallet buyer-intent' repeated); could be slightly more concise but overall 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 tool has no parameters and no output schema, the description provides substantial context: data content, payment requirement, and intended workflows. It explains the unconventional return behavior adequately for an agent to understand the prerequisite. However, it lacks details on the exact metadata format and follow-up steps, leaving some contextual gaps.

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

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

The input schema has no parameters, so schema_description_coverage is 100%. According to guidelines, baseline is 3. The description does not add parameter information (none exist), so it meets the baseline without adding extra value. The content descriptions (Ledger vs Trezor, etc.) relate to the output, not parameters.

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

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

The description clearly states the tool provides hardware-wallet buyer-intent intelligence as JSON, listing specific data categories. It explicitly notes that the tool does NOT return the dataset directly but returns payment-required metadata, which differentiates it from a standard data retrieval tool. However, the dual nature (data feed vs. payment initiation) could cause slight ambiguity.

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 the tool is designed for agent routing, affiliate/comparison-content workflows, and research context. It implies sibling differentiation by format (JSON vs CSV for lion_trend_intent_signal_csv). However, it lacks explicit guidance on when not to use this tool or when to prefer alternatives, nor does it clarify the payment prerequisite as a usage constraint.

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