Skip to main content
Glama

LION - Trend Intent MCP + Marketplace Visibility Audit

by app.netlify.gleaming-cassata-d41682

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNoFree-text intent (echoed; reserved for semantic routing).
sortNoRanking key.
limitNoMax rows.
tokenNoBase token address; required for token_risk, optional for base_dex single-token lookup.
fieldsNoComma-separated output field projection.
sourceNoWhich live data vertical to query. Default base_dex.
max_age_hoursNoFilter: max pair age in hours (base_dex).
min_liquidityNoFilter: minimum liquidity/TVL in USD.

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 + Marketplace Visibility Audit toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0
Disambiguation2/5

The adaptive_data_query and base_dex_signals_json overlap heavily on DEX data, and the two trend_intent_signal tools are identical except for output format, making it unclear which to use for a given task.

Naming Consistency3/5

All tools share the 'lion_' prefix and use snake_case, but the suffix pattern is inconsistent (query, signals_json, audit, signal_csv, signal_json), so naming is only partially predictable.

Tool Count4/5

Five tools is within the reasonable range, but the redundant format variants (CSV/JSON) and overlapping query/signal tools make the effective scope smaller than the count suggests.

Completeness2/5

The server claims to cover trend intent and marketplace visibility audit, yet the tools only provide DEX data, buyer-intent signals, and payment-term checks. There are clear gaps for a dedicated visibility audit and no lifecycle coverage for any specific resource.

Resources