LION Trend Intent MCP

lion_adaptive_data_query

LION Adaptive Data Fabric: ONE typed x402 query endpoint that adapts to any agent request over live Base on-chain data, covering multiple verticals from one call. Query params: source (base_dex | token_risk | defi_yields), token (0x address; for token_risk / single-token base_dex), sort (activity|volume|liquidity|age), limit, min_liquidity, max_age_hours, fields (output projection), q (free-text intent). base_dex = ranked active Base tokens (liquidity, volume, price-change, pair-age, activity_score) via DexScreener; token_risk = token security card (honeypot, buy/sell tax, mintable, owner, holders + mechanical risk_flags) via GoPlus; defi_yields = Base DeFi pools ranked by TVL with APY via DefiLlama. Free self-describing capability manifest at the same URL with ?describe=1 (no payment). Returns typed JSON rows + freshness fields (as_of, data_age_seconds, confidence, source_provider). Public keyless data, no API key. Raw public market data only - not financial or investment advice. Pay 0.005 USDC on Base via x402; tools/call returns payment-required metadata only, settle at the paid route to fetch the live JSON.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "lion_adaptive_data_query"
  }
}

Input Schema

Name	Required	Description
`q`	No	Free-text intent (echoed; reserved for semantic routing).
`sort`	No	Ranking key.
`limit`	No	Max rows.
`token`	No	Base token address; required for token_risk, optional for base_dex single-token lookup.
`fields`	No	Comma-separated output field projection.
`source`	No	Which live data vertical to query. Default base_dex.
`max_age_hours`	No	Filter: max pair age in hours (base_dex).
`min_liquidity`	No	Filter: minimum liquidity/TVL in USD.

Schema Changelog

Changes observed during successful MCP inspections.

AddedJun 8, 2026

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations provided, the description carries full burden. It discloses payment (0.005 USDC), return format (typed JSON rows + freshness fields), public keyless access, the tools/call vs paid route distinction, and a no-advice disclaimer. This is thorough and exceeds the minimum needed.

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

Conciseness4/5

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

The description is dense but front-loaded with the core purpose, followed by parameter breakdown and payment details. Every sentence carries useful information, though length is substantial; it is organized logically.

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

Completeness5/5

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

Given 8 parameters, no output schema, and no annotations, the description is remarkably complete. It covers purpose, parameter semantics for all three verticals, return format, payment flow, and safety disclaimers, leaving little ambiguity for an agent.

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

Parameters4/5

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 exact output semantics (e.g., base_dex via DexScreener, token_risk via GoPlus) and clarifies token requirements per source. However, it does not elaborate on every parameter's syntax beyond schema.

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

Purpose5/5

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

The description clearly states it is a single typed x402 query endpoint for live Base on-chain data, covering multiple verticals (base_dex, token_risk, defi_yields) via one call. This specific verb+resource+scope distinguishes it from siblings like lion_base_dex_signals_json and lion_trend_intent_signal_csv.

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

Usage Guidelines4/5

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

It explains when to use the tool (any agent request over live Base data, multiple verticals) and describes each source's output. It also notes payment requirements, but does not explicitly name alternatives or provide exclusion criteria, so it falls short of a 5.

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

All LION Trend Intent MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?