LION Trend Intent MCP

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

With no annotations, the description covers key behavioral traits: payment requirement (0.005 USDC via x402, metadata response first), no API key needed, raw market data disclaimer, and a self-describing capability manifest. Missing details like rate limits or error handling are minor given the payment flow emphasis.

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

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

The description is well-structured, front-loaded with purpose, then parameters, source explanations, payment, and disclaimers. Every sentence adds value, though it is slightly verbose and could be tightened 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 complexity (8 parameters, 3 sources, payment flow, no output schema), the description covers all essential aspects: parameter details, source behaviors, payment process, authentication, and return format. It leaves 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%, so baseline is 3. The description adds value by explaining each source's data origin (DexScreener, GoPlus, DefiLlama), when token is required, and the meaning of sort options. Could be more specific on field projections but is already helpful.

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

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

The description explicitly states it is a 'ONE typed x402 query endpoint that adapts to any agent request over live Base on-chain data' and lists the three verticals (base_dex, token_risk, defi_yields), distinguishing it from sibling tools that are more specialized.

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 it is a general-purpose endpoint for multiple verticals but does not explicitly state when to use this tool versus sibling tools like lion_base_dex_signals_json. No direct comparisons or exclusion criteria are given.

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

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

With no annotations, the description carries the full burden. It discloses the data source (DexScreener), payment requirements, and the return of payment-required metadata. However, it lacks details on error handling, rate limits, data freshness, and whether the tool is purely read-only despite payment.

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

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

The description is a single paragraph but front-loads the purpose and covers all key points (metrics, source, payment flow, disclaimer). It is reasonably concise for the amount of information, though could be broken into shorter sentences for 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 no output schema, the description lists the return fields and explains the activity score. It covers data source, payment workflow, and disclaimers. However, it does not specify if the result is a single object or array, or mention pagination or size limits, leaving some gaps for a 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 no parameters and schema coverage is 100% (empty schema). The description adds context about the return data and payment mechanism, which is necessary since the schema provides no information. Baseline of 4 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 provides a live DEX market-data feed for Base tokens, listing specific metrics and distinguishing itself from sibling tools like lion_trend_intent_signal_json by focusing on raw on-chain metrics and a transparent activity 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?

It details the payment flow via x402, explains that the initial call returns payment-required metadata, and includes a disclaimer about not being financial advice. However, it does not explicitly compare to siblings 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?

Without annotations, the description fully discloses behavior: it extracts payment terms, cross-checks drift, returns a readiness score and risk_flags, costs 0.05 USDC, and notes that unpaid calls error with -32402. Also states limitations (no settlement, no fund movement).

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 with purpose first, then behavior, then constraints. Every sentence adds value, though it could be slightly more concise. Still clear and actionable.

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 (x402 payments, blockchain interactions), the description covers trigger conditions, return values, error states, dependencies on wallet clients, and cost. With an output schema, this is complete for an agent to decide invocation.

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

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

Schema coverage is 100% with one 'url' parameter. The description adds context about it being a 'target x402/MCP service URL' but doesn't significantly expand beyond the schema description. 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: a 'pre-spend payment-term trust check for x402 endpoints.' It specifies the action (audit), resource (x402 payment terms), and distinguishes from sibling tools like data queries and trend signals.

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

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

Explicitly tells the agent to call this before signing a Payment-Signature, referencing x402/MCP URLs. Clearly explains what it does and does not do (e.g., 'NOT perform payment', 'not a smart-contract security audit'), though no direct 'do not use when' exclusions are given.

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. It discloses that 'tools/call returns payment-required metadata only; settle the invoice at the paid route to fetch the CSV,' revealing the key behavioral trait that the initial call is a payment request. It also specifies the cost ($0.01 USDC) and payment method (x402 on Base mainnet).

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

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

The description is two sentences with no wasted words. It front-loads the core purpose, then provides details on content, use cases, and payment process. 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 parameters and no output schema, the description fully explains what the CSV contains (column set), its optimized workflows, and the payment mechanism. It references the JSON sibling for comparison, making it complete for an agent to understand and invoke.

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?

There are no parameters (schema is empty, 0 params). Baseline for 0 parameters is 4. The description adds no parameter info since none exist, but this 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 that the tool provides hardware-wallet buyer-intent and self-custody onboarding-friction intelligence as a CSV file. It details the column set (Ledger vs Trezor demand, etc.) and explicitly distinguishes from the JSON sibling tool by format and optimization for spreadsheet/pipeline ingestion.

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 use cases: 'Optimised for spreadsheet / pipeline ingestion and affiliate-routing or comparison-research workflows.' It also explains the payment process. However, it does not explicitly state when not to use or mention alternatives beyond the JSON sibling, but the format difference implies appropriate contexts.

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

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

With no annotations, the description carries the full burden. It discloses the tool is a paid, non-PII public-signal feed that returns payment-required metadata rather than the dataset. This is critical behavioral context. Lacks details on rate limits or authorization beyond payment, but overall 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 fairly long but well-structured: main purpose first, then data details, then payment mechanism. It could be slightly more concise, but all sentences add value and it is front-loaded.

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

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

The description covers the essential workflow including the payment model and the fact that the tool does not return data directly. With no output schema, it explains the return type (payment-required metadata) and the next step (x402 client fetches JSON). Some specifics about the metadata format are missing, but adequate for agent 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?

There are no parameters (0 params, baseline 4). The description adds meaning about what data the tool provides, but since no parameters exist, no further semantic contribution is needed.

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 and self-custody onboarding-friction intelligence as JSON, listing specific data categories. It distinguishes from sibling lion_trend_intent_signal_csv by format (JSON vs CSV) and 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 explains the tool is for agent routing, affiliate/comparison-content workflows, and research context. It also details the payment requirement via x402 and that the tool returns metadata, not data directly. However, it does not explicitly compare with the CSV sibling 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.