LION Trend Intent MCP
Server Details
Read-only x402-paid trend-intent MCP tools for JSON and CSV signals.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.4/5 across 5 of 5 tools scored.
The adaptive_data_query tool overlaps with base_dex_signals_json by offering DEX data, and the two trend_intent_signal tools differ only in format (CSV vs JSON), causing ambiguity about which tool to use. The payment audit tool is distinct, but overall the boundaries are unclear.
All tools use a consistent 'lion_' prefix and snake_case. However, some tools specify the output format (e.g., '_json', '_csv') while others do not (e.g., 'adaptive_data_query'), creating minor inconsistency. Overall, the pattern is predictable.
With 5 tools covering data queries, DEX signals, payment readiness, and trend signals, the count is well-scoped for the server's purpose. Each tool serves a clear function without excessive redundancy in number.
The tool set covers the main use cases: general on-chain data querying, dedicated DEX signals, payment term audits, and trend intent signals. The redundancy between adaptive_data_query and base_dex_signals_json, and the two trend signal formats, is minor. No major gaps are apparent.
Available Tools
5 toolslion_adaptive_data_queryAInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: payment via x402 (0.005 USDC), returning payment-required metadata at the paid endpoint, typed JSON with freshness fields, and that it's raw market data not financial advice. 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 front-loaded with core purpose, then lists parameters, explains sources, payment, and return. It is comprehensive but slightly verbose; each sentence contributes, but some redundancy (e.g., repeated mention of 'x402') 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 no output schema, the description adequately covers return values (typed JSON rows, freshness fields) and payment flow. It explains all parameters and sources. An example return structure would improve completeness, but current level is sufficient.
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 what each source returns (e.g., DexScreener, GoPlus, DefiLlama) and the role of the 'q' parameter (free-text intent). This exceeds baseline.
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 as a unified query endpoint for three on-chain data verticals. It uses a specific verb ('query'/'adapt') and distinguishes itself by covering multiple verticals from one call, differentiating from sibling tools that are likely single-purpose.
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 each data source and when to use them (e.g., base_dex for ranked tokens, token_risk for security card, defi_yields for DeFi pools). It does not explicitly exclude sibling tools but provides clear usage context and hints at self-describing capabilities via ?describe=1.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lion_base_dex_signals_jsonAInspect
Live Base (eip155:8453) DEX market-data feed for trading and research agents. Returns a fresh ranked snapshot of active Base tokens with raw on-chain metrics: price_usd, liquidity_usd, volume_h24, volume_m5, price_change_h1/h24, pair_age_hours, dex, and a transparent mechanical activity_score (volume + liquidity + recency). Source: public DexScreener data, no API key. Raw public market data only - not financial or investment advice, no buy/sell recommendation. Pay 0.005 USDC on Base via x402 at the paid route. tools/call returns payment-required metadata only; settle the x402 invoice at the paid route to fetch the live JSON.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses data source, payment requirement, return flow, and mechanical scoring. It omits rate limits or pagination but adequately warns about financial advisory limitations.
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?
Well-structured with purpose, metrics, source, disclaimer, and payment. Could be slightly shorter 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 zero parameters and no output schema, the description covers what the tool returns, how to access it, and source context. Does not specify snapshot size limits or update frequency, but sufficient for a live feed.
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, so baseline 4. Description adds no parameter info 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 it is a live DEX market-data feed for Base chain, returning ranked snapshots with specific metrics. It distinguishes from sibling tools that focus on trend intent 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?
Describes payment flow and that data is raw market data, not financial advice. However, it does not explicitly differentiate when to use this tool vs siblings like lion_trend_intent_signal_json, leaving usage context implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lion_payment_attempt_readiness_auditAInspect
Pre-spend payment-term trust check for x402 endpoints. Before your agent signs a Payment-Signature, call this with a target x402/MCP service URL: LION extracts the target live 402 payment terms (payTo, amount, asset, network, scheme), cross-checks them for drift across public discovery surfaces, and returns payment_attempt_blockers, buyer_policy_fit, canonical_purchase_recipe, funnel_stage, a transparent readiness score, and risk_flags so the agent can decide whether to sign. 0.05 USDC on Base eip155:8453. Unpaid tools/call returns JSON-RPC error -32402 with the x402 paymentRequirement; wallet-capable MCP clients (e.g. Coinbase Payments MCP, AWS AgentCore Payments) auto-construct the EIP-3009 signature. LION does NOT perform payment inside MCP. Checks payment-term consistency only - not a smart-contract security audit, no settlement guarantee, no fund movement.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public HTTPS x402/MCP service URL to audit. |
Output Schema
| Name | Required | Description |
|---|---|---|
| asset | Yes | |
| payTo | Yes | |
| amount | Yes | |
| scheme | Yes | |
| status | Yes | |
| network | Yes | |
| price_usdc | Yes | |
| instructions | Yes | |
| paid_endpoint_url | Yes | |
| external_paid_proof | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes key behaviors: no payment inside MCP, cost (0.05 USDC), error code (-32402), and return values. Without annotations, it covers safety (read-only check) and scope. Lacks rate limit or auth info but sufficient for one-param 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?
Description is informative but slightly verbose; however, every sentence adds value. Front-loaded with purpose. Could be more concise but not wasteful.
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 one parameter and presence of output schema, description covers usage, behavior, return values, and constraints. No gaps for effective agent 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 covers the single parameter 'url' with description and format. Tool description reinforces its purpose ('target x402/MCP service URL'). Schema coverage is 100%, and description adds no 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?
Description clearly states the tool is a 'pre-spend payment-term trust check for x402 endpoints' and specifies what it returns (blockers, policy fit, recipe, etc.). It is distinct from sibling tools which are data queries and 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 states when to use ('before your agent signs a Payment-Signature') and notes limitations ('not a smart-contract security audit, no settlement guarantee'). Does not explicitly mention alternatives but siblings are unrelated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lion_trend_intent_signal_csvAInspect
Hardware-wallet buyer-intent + self-custody onboarding-friction intelligence as flat CSV. Same column set as the JSON variant: Ledger vs Trezor comparison demand, Bitcoin-only wallet research, under-$100 wallet shopper queries, DeFi hardware-wallet intent, decision-stage crypto purchase research. Optimised for spreadsheet / pipeline ingestion and affiliate-routing or comparison-research workflows. Pay $0.01 USDC on Base mainnet via x402 at the paid route. tools/call returns payment-required metadata only; settle the invoice at the paid route to fetch the CSV.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It discloses the payment requirement ($0.01 USDC via x402) and explains that tools/call returns payment-required metadata, and invoice must be settled to fetch CSV. Provides moderate transparency about the data flow, though could detail more about rate limits or data freshness.
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?
Three sentences: first states purpose and format, second lists column coverage and use cases, third explains payment workflow. Front-loaded with key info, no wasted words.
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?
Explains return flow (metadata first, CSV after payment) and lists columns. No output schema, so description should cover structure; it references 'same column set as JSON variant' but doesn't detail schema. Lacks complete column list but is sufficient for credit.
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 has zero parameters (100% coverage), so baseline is 4. Description adds nothing about parameters because none exist. 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?
Clearly states it provides hardware-wallet buyer-intent and self-custody onboarding-friction intelligence as flat CSV. Lists specific use cases (Ledger vs Trezor, Bitcoin-only wallet research, etc.) and contrasts with the JSON sibling by specifying CSV format and optimized use for spreadsheet/pipeline ingestion and affiliate-routing or comparison-research workflows.
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 when to use (spreadsheet/pipeline ingestion, affiliate-routing/comparison-research workflows) and indirectly distinguishes from JSON variant. However, lacks explicit exclusions or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lion_trend_intent_signal_jsonAInspect
Hardware-wallet buyer-intent + self-custody onboarding-friction intelligence as JSON. Non-PII public-signal feed covering: Ledger vs Trezor comparison demand, Bitcoin-only wallet research, under-$100 wallet shopper queries, DeFi hardware-wallet intent, and adjacent decision-stage crypto purchase research. Designed for agent routing, affiliate / comparison-content workflows, and research context. Pay $0.01 USDC on Base mainnet via x402 (HTTP 402 + EIP-3009 transferWithAuthorization) at the paid route. This MCP tool does NOT return the dataset; tools/call returns payment-required metadata so an x402-capable client can settle and fetch the JSON directly.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the transparency burden. It clearly states that the tool does NOT return the dataset directly; instead, it returns payment-required metadata for an x402-capable client to settle and fetch JSON. This critical behavioral detail is disclosed upfront.
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 appropriately sized (5 sentences) and front-loaded with the core function. Every sentence adds value, including the payment note and the explicit statement that the tool doesn't return data. No wasted words.
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, no output schema, and the complexity of the payment flow, the description is complete. It covers purpose, content, use cases, and the non-standard behavior. The lack of output schema is adequately explained.
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 zero parameters, so baseline is 4. The description adds value by explaining the output mechanism (payment-required metadata) beyond the bare schema, compensating for the lack of 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 + self-custody onboarding-friction intelligence as JSON' and lists specific signal types. It is well-differentiated from the sibling lion_trend_intent_signal_csv by specifying the JSON format.
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 intended use cases: 'agent routing, affiliate / comparison-content workflows, and research context.' It also explains the payment mechanism. However, it does not explicitly state when not to use this tool versus alternatives, though the format distinction from CSV sibling is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!