Evidence-based market data for AI agents deploying capital in DeFi. Empirical, not advertised.
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.
Average 4.5/5 across 9 of 9 tools scored.
Each tool serves a distinct function: assess_opportunity is a holistic decision-maker, check_entry_viability and check_pool_viability target different domains (lending vs. DEX), and estimate_net_position provides a projection unlike get_market_snapshot's current state. Even overlapping tools like get_ranking and get_returns are differentiated by their output format and filtering.
Most tools follow a verb_noun pattern (assess_opportunity, estimate_net_position, verify_claim) or verb_phrase (check_entry_viability, get_market_snapshot). The outlier is gas_timing, which uses a noun_gerund structure instead of starting with a verb, breaking the otherwise consistent convention.
With 9 tools, the server is well-scoped for a DeFi intelligence platform. Each tool covers a distinct aspect—opportunity assessment, viability checks, projections, market snapshots, historical data, gas guidance, and claim verification—without unnecessary redundancy or bloat.
The tool surface covers core decision workflows: assess, check, estimate, snapshot, ranking, history, gas, and verification. Minor gaps include lack of a tool to list supported assets/protocols/chains and no swap projection tool to complement check_pool_viability, but agents can work around these.
assess_opportunityAInspectAssess the best DeFi opportunity for a given capital amount and strategy.
This is the "cold start" tool — call it first to understand where your
capital is viable before making any moves. One call gives you chain
viability, ranked opportunities, gas impact, and an actionable recommendation.
Args:
api_key: Your PreFlyte API key (required).
asset: Token symbol, e.g. "USDC", "WETH".
action: "supply" or "borrow".
position_size_usd: Capital amount in USD.
strategy: One of "yield_farming", "active_trading", "idle_capital".
chain: "ethereum", "arbitrum", or "any" (default: "any").
trades_per_day: For active_trading strategy only. Default 10.
Returns:
JSON with chain viability, ranked opportunities, gas analysis,
break-even calculations, and an actionable recommendation.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | Yes | ||
| chain | No | any | |
| action | Yes | ||
| api_key | Yes | ||
| strategy | Yes | ||
| trades_per_day | No | ||
| position_size_usd | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It explains that the tool returns an assessment and recommendation, and it requires an api_key, but it never explicitly states that the tool is read-only or that it does not execute on-chain transactions. This is important context for a DeFi tool, though the word 'assess' and phrase 'before making any moves' do imply a non-executive advisory role.
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: a concise purpose statement, usage guidance, a clear args list, and a return-value summary. It is somewhat longer than necessary because the args list repeats parameter names already in the schema, but each line adds valuable semantic detail. Overall, the organization is logical and front-loaded, earning a slightly above-average score.
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?
For a tool with 7 parameters, no output schema, and no annotations, the description covers the essential aspects: it explains parameters thoroughly, describes the return value structure (chain viability, ranked opportunities, gas analysis, break-even calculations, and recommendation), and states when to use it. It lacks details on error behavior or data freshness, but these are not critical for understanding the tool's primary function.
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 provides no per-property descriptions (0% coverage), but the description compensates fully by explaining each parameter with concrete examples and constraints. It gives allowed values for action ('supply' or 'borrow'), strategy ('yield_farming', 'active_trading', 'idle_capital'), chain ('ethereum', 'arbitrum', 'any'), and clarifies that trades_per_day applies only to 'active_trading' with a default of 10. This adds meaning far beyond the 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?
The description clearly states the tool's purpose: 'Assess the best DeFi opportunity for a given capital amount and strategy.' It also frames it as the 'cold start' tool, distinguishing it from more granular sibling tools like get_ranking or gas_timing. The mention of delivering chain viability, ranked opportunities, gas impact, and a recommendation makes its role specific and immediately understandable.
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 explicitly says to 'call it first' and frames it as the entry point before making moves, which provides clear when-to-use guidance. However, it does not mention specific when-not-to-use scenarios or name alternative tools for particular follow-up checks, so it falls short of full exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_entry_viabilityAInspectBefore entering a lending position, verify that the market is actually
open and has capacity.
Checks market status (active, frozen, borrowing enabled), supply/borrow
caps, and available liquidity. Returns a clear viable/not-viable verdict.
Args:
api_key: Your PreFlyte API key (required).
protocol: Protocol name — "aave-v3" or "compound-v3".
chain: Chain name — "ethereum" or "arbitrum".
asset: Asset symbol — "USDC", "WETH", etc.
action: "supply" or "borrow".
amount_usd: Intended position size in USD (optional, for context).
Returns:
Dictionary with viable (true/false), market_status, capacity details,
current rate, and confidence level.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | Yes | ||
| chain | Yes | ||
| action | Yes | ||
| api_key | Yes | ||
| protocol | Yes | ||
| amount_usd | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses the checks performed (market status, caps, liquidity) and the return shape (viable verdict, market_status, capacity details, current rate, confidence). This is adequate, though it could mention error behavior or side effects (it appears read-only).
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-organized: a purpose sentence, a check summary, a structured Args list, and a Returns list. It is slightly longer than minimal but every sentence adds necessary context given the lack of schema descriptions. The front-loading of purpose is effective.
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 annotations and no output schema, this description provides a fairly complete picture: when to use, what it checks, parameter meanings, and return format. It lacks explicit exclusions or error semantics, but overall it is comprehensive for this 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?
Schema coverage is 0%, so the description provides all parameter semantics. It gives clear definitions, examples, and requiredness for all six parameters (e.g., protocol values 'aave-v3' or 'compound-v3', chain examples, action 'supply'/'borrow', amount_usd optional). This fully compensates for the bare 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?
The description clearly states the tool's function: 'verify that the market is actually open and has capacity' before entering a lending position. It specifies a distinct resource (lending market) and scope (entry viability), but doesn't explicitly differentiate from siblings like check_pool_viability.
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 explicitly says 'Before entering a lending position,' which provides a clear usage context. It does not mention when not to use the tool or suggest alternatives, hence the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_pool_viabilityAInspectBefore swapping on Uniswap V3, check if pools have sufficient liquidity
for the intended trade size.
Finds all matching pools for a token pair, assesses trade impact relative
to pool TVL, and recommends the best pool.
Args:
api_key: Your PreFlyte API key (required).
chain: Chain name — "ethereum" or "arbitrum".
token_pair: Token pair separated by "/" — e.g. "WETH/USDC", "WBTC/WETH".
trade_size_usd: Intended swap size in USD.
Returns:
Dictionary with per-pool viability (TVL, trade impact, fee cost),
a recommendation, and data freshness.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | Yes | ||
| api_key | Yes | ||
| token_pair | Yes | ||
| trade_size_usd | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool finds matching pools, assesses trade impact relative to TVL, recommends a pool, and returns data freshness. This gives a good sense of behavior, though it does not explicitly state that it is read-only or non-mutating, which is implied by 'check'.
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: purpose first, then method, then args, then returns. It is concise and each sentence adds value, with no fluff or redundant repetition of schema fields.
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 explains return values (per-pool TVL, trade impact, fee cost, recommendation, freshness). It covers inputs and outputs adequately. It could optionally mention edge cases or limitations, but for a moderate 4-param tool, this is nearly complete.
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 description coverage is 0%, so the description must compensate, and it does thoroughly. It explains each parameter with types, examples, and allowed values (e.g., chain as 'ethereum' or 'arbitrum', token_pair format 'WETH/USDC', trade_size_usd as USD). This is exactly the kind of semantic enrichment the schema lacks.
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: 'check if pools have sufficient liquidity for the intended trade size' on Uniswap V3. It specifies the verb (check), the resource (pools), and the scope, distinguishing it from siblings like assess_opportunity or check_entry_viability.
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 explicitly says 'Before swapping on Uniswap V3, check if pools have sufficient liquidity,' providing a clear when-to-use context. However, it does not explicitly state when not to use the tool or name alternative tools, so it misses the 'when-not/alternatives' component.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
estimate_net_positionAInspectDetailed financial estimate for a specific lending position — what will
I actually earn (or pay) after gas costs?
Combines current live rates, gas costs, and historical computed returns
to project net yield over a holding period.
Args:
api_key: Your PreFlyte API key (required).
protocol: Protocol name — "aave-v3" or "compound-v3".
chain: Chain name — "ethereum" or "arbitrum".
asset: Asset symbol — "USDC", "WETH", etc.
action: "supply" or "borrow".
position_size_usd: Amount in USD.
duration_days: Intended holding period in days. Default 30.
Returns:
Dictionary with position details, current snapshot, cost breakdown,
projected return, historical context, and confidence level.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | Yes | ||
| chain | Yes | ||
| action | Yes | ||
| api_key | Yes | ||
| protocol | Yes | ||
| duration_days | No | ||
| position_size_usd | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It transparently discloses the tool's behavior: it 'projects net yield' by combining live rates, gas costs, and historical returns. It also outlines information returned (position details, snapshot, cost breakdown, etc.). While it doesn't mention that this is a read-only operation or potential delays, the description gives a solid behavioral picture.
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 a clear question that defines the tool's value. The Args section is efficiently structured and each line adds necessary detail. The Returns section provides a high-level overview without unnecessary fluff. Every sentence earns its place.
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?
For a tool with 7 parameters, no annotations, and no output schema, the description gives a good end-to-end picture: purpose, parameters, and high-level return structure. It could be more complete by explicitly stating when to use this tool over siblings, and by specifying return format in more detail, but it is sufficient for basic selection.
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 description coverage is 0%, so the description must compensate. It does list all parameters with brief explanations, including the default for duration_days and examples for protocol, chain, and asset. This adds meaning beyond the raw schema, though it could be more detailed (e.g., enumerating supported assets or chain values).
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: 'Detailed financial estimate for a specific lending position — what will I actually earn (or pay) after gas costs?' It specifies the verb (estimate), resource (net position), and unique angle (gas costs). This distinguishes it from siblings like get_returns or gas_timing, which focus on narrower aspects.
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 provides clear context: it is for estimating net yield over a holding period, combining live rates, gas, and historical returns. It does not explicitly name alternatives, but the phrase 'Combines current live rates, gas costs, and historical computed returns' implies it is the comprehensive choice among specialized siblings. No exclusions are stated, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
gas_timingAInspectTell agents whether now is a good or bad time to transact, based on
historical gas patterns.
Compares current gas to 24-hour and 7-day averages, identifies the
cheapest hours of the day, and estimates reference transaction costs.
Args:
api_key: Your PreFlyte API key (required).
chain: Chain name — "ethereum" or "arbitrum".
Returns:
Dictionary with current gas, 24h/7d context, timing assessment
with cheapest hours, and reference transaction costs in USD.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | Yes | ||
| api_key | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains that the tool compares current gas to 24h/7d averages, identifies cheapest hours, and estimates transaction costs. It also describes the return value structure. This goes beyond the schema by detailing the computation logic, although it does not mention any side effects or permissions.
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 concise and well-structured, with separate sections for behavior, args, and returns. Each sentence provides necessary information without redundancy, and the format is easy to scan.
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?
For a tool with only two parameters and no output schema, the description covers all essential aspects: behavior, inputs, and output. It explicitly states what the return dictionary contains, which substitutes for a missing output schema. No critical details are omitted.
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 0% description coverage, so the description compensates by explaining that 'api_key' is a PreFlyte API key (required) and 'chain' is either 'ethereum' or 'arbitrum'. This adds meaning beyond the schema's bare labels 'Api Key' and 'Chain'. It could be more specific about where to obtain the key, but the essential semantics are present.
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 function: telling agents whether now is a good or bad time to transact based on historical gas patterns. It uses a specific verb ('tell') and resource ('gas timing'), and distinguishes itself from sibling tools by focusing on transaction timing rather than market opportunities.
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 provides clear context for when to use the tool (when assessing transaction timing) and what data it uses (historical gas patterns). It does not explicitly mention when not to use it or name alternative tools, but the context is sufficiently clear for an agent to select it for gas-related timing decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_market_snapshotAInspectGet current market snapshot for a specific lending market.
Returns the latest rates, risk parameters, token price, and gas price.
This is the foundation of RealityCheck — giving agents ground truth
about current market conditions before they act.
Args:
api_key: Your PreFlyte API key (required).
protocol: Protocol name — "aave-v3" or "compound-v3".
chain: Chain name — "ethereum" or "arbitrum".
asset: Asset symbol — "USDC", "USDT", "DAI", "WETH", "WBTC", "wstETH".
Returns:
Dictionary with latest lending rates, risk parameters (if available),
current token price, current gas price, data freshness timestamps,
and rate_context (7-day averages, standard deviations, anomaly flags).
| Name | Required | Description | Default |
|---|---|---|---|
| asset | Yes | ||
| chain | Yes | ||
| api_key | Yes | ||
| protocol | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains what the tool returns (rates, risk parameters, token price, gas price, freshness timestamps, rate_context) and notes caveats like 'if available'. It implies read-only behavior but does not explicitly state safety or error characteristics, preventing a 5.
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 clear Args and Returns sections. Every sentence contributes value: the first explains the tool's function, the second enumerates return contents, the third provides usage context, and the remaining sections detail parameters and outputs. No fluff or redundancy.
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 and no annotations, the description is highly complete. It describes all return fields including rate_context details, provides parameter guidance, and gives usage context. It is fully adequate for an agent to understand when and how to use the 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?
Schema coverage is 0%, so the description must compensate. It does so excellently with an Args section that lists each parameter and provides allowed values for protocol ('aave-v3' or 'compound-v3'), chain ('ethereum' or 'arbitrum'), and asset ('USDC', 'USDT', 'DAI', 'WETH', 'WBTC', 'wstETH'), adding significant meaning beyond the raw 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?
The description uses a specific verb 'Get' with a clear resource 'market snapshot' and scope 'specific lending market'. It clearly distinguishes itself from sibling tools that focus on assessment, viability, or returns, making its role as a foundational data fetcher obvious.
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 states it is the 'foundation of RealityCheck' and gives agents 'ground truth about current market conditions before they act', clearly indicating when to use it. However, it does not explicitly mention alternatives or when not to use it, 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.
get_rankingAInspectGet ranked list of best DeFi lending returns, sorted by net APY.
Args:
api_key: Your PreFlyte API key (required).
window_days: Return window — 7, 14, 30, or 90 days. Default 7.
strategy: "supply" or "borrow". Default "supply".
top_n: Number of top results. Default 10, max 30.
Returns:
Ranked list with position number, net_apy_pct, gross_apy_pct,
gas details, and data completeness scores.
| Name | Required | Description | Default |
|---|---|---|---|
| top_n | No | ||
| api_key | Yes | ||
| strategy | No | supply | |
| window_days | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It discloses that it returns a list with position number, net_apy_pct, gross_apy_pct, gas details, and data completeness scores. It also requires an api_key. However, it does not mention potential error conditions, rate limits, or that it is read-only, though 'get' implies no side effects.
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 organized with a purpose sentence, an Args section, and a Returns section. Each line is necessary and adds value. It is efficient without being terse.
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?
With no output schema, the Returns section explicitly lists the output fields. All parameters are covered with defaults and constraints. Missing details like edge-case behavior (e.g., empty results) and error handling are minor, making it nearly complete.
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 schema has 0% description coverage, but the description fully explains all four parameters with allowed values (window_days: 7,14,30,90; strategy: supply/borrow), defaults, and max for top_n. This is excellent compensation.
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 'Get ranked list of best DeFi lending returns, sorted by net APY,' with a specific resource (DeFi lending returns) and sorting criterion. This distinguishes it from siblings like get_returns, which would likely provide unranked returns.
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 provides a clear context for when to use this tool (when a ranked list is desired), but it does not explicitly name alternatives or state when not to use it. Given sibling tools exist, explicit differentiation would earn a 5, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_returnsAInspectQuery historical DeFi lending returns from the ProfitLens engine.
Returns real, empirically measured after-fee returns — not theoretical
APY projections. Data is computed from on-chain index ratios every 30 min.
Args:
api_key: Your PreFlyte API key (required).
chain: Filter by chain — "ethereum" or "arbitrum". Empty = all chains.
protocol: Filter by protocol — "aave-v3" or "compound-v3". Empty = all.
asset: Filter by asset symbol — "USDC", "WETH", etc. Empty = all.
strategy: Filter by strategy — "supply" or "borrow". Empty = both.
window_days: Return window — 7, 14, 30, or 90 days. Default 7.
limit: Max results to return. Default 20, max 50.
Returns:
Dictionary with 'results' array and metadata. Each result includes:
gross_apy_pct, net_apy_pct, gas_cost_pct, data_completeness_pct,
chain, protocol, asset, strategy, and more.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | No | ||
| chain | No | ||
| limit | No | ||
| api_key | Yes | ||
| protocol | No | ||
| strategy | No | ||
| window_days | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses that returns are computed from on-chain index ratios every 30 minutes, that they are after-fee, and it describes the response fields. It does not mention rate limits or permission details beyond the API key, but for a read-only query tool this is sufficient.
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 docstring-style format is front-loaded with the purpose, then logically organizes parameters and return fields. Every sentence adds meaningful information with no redundancy.
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 that there is no output schema and no annotations, the description provides a remarkably complete invocation guide: parameter constraints, defaults, data freshness, and return field names are all covered. The lack of explicit sibling comparisons is not essential for successful 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?
The schema has zero descriptions, but the description's Args section fully defines all seven parameters, including defaults, allowed values (e.g., chain choices, window_days options), and examples like 'USDC'. This completely compensates for the missing schema descriptions.
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 begins with a specific verb and resource: 'Query historical DeFi lending returns from the ProfitLens engine.' It clearly distinguishes this from real-time siblings by emphasizing empirical, after-fee returns rather than theoretical projections.
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 when to use the tool by contrasting 'real, empirically measured after-fee returns' with 'theoretical APY projections,' which helps an agent choose it for historical data needs. It does not explicitly name sibling tools or state when not to use it, so it falls short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_claimAInspectVerify factual claims about current DeFi market conditions.
Supports two modes:
- Single claim: provide claim_type, value, operator (and protocol/chain/asset
as needed). Returns one verification result.
- Batch mode: provide a JSON-encoded array in 'claims'. Each element has
the same fields (claim_type, value, operator, protocol, chain, asset).
Returns all results in one response. If 'claims' is provided, single-claim
parameters are ignored.
Args:
api_key: Your PreFlyte API key (required).
claim_type: What you're checking. One of:
"supply_rate" — current supply APY (%)
"borrow_rate" — current borrow APY (%)
"price" — current token price (USD)
"gas" — current base fee (gwei)
"utilization" — current pool utilization (%)
value: The numeric value you believe to be true.
operator: Comparison operator. One of:
"above" — actual must be >= value
"below" — actual must be <= value
"around" — actual must be within 10% of value
protocol: Required for supply_rate, borrow_rate, utilization.
Use "aave-v3" or "compound-v3".
chain: Chain name — "ethereum" or "arbitrum". Default "ethereum".
asset: Required for supply_rate, borrow_rate, price, utilization.
Use token symbol like "USDC", "WETH", etc.
claims: JSON-encoded array of claim objects for batch verification.
Each object contains: claim_type, value, operator, and optionally
protocol, chain, asset. When provided, single-claim params are ignored.
Returns:
Single mode: Dictionary with status (TRUE/FALSE), actual_value,
claimed_value, delta, delta_pct, data_timestamp, and summary.
Batch mode: Dictionary with 'mode', 'results' array, 'summary' counts,
and 'verified_at' timestamp.
Examples:
Single:
verify_claim(api_key="...", claim_type="supply_rate", value=5.0,
operator="above", protocol="aave-v3", asset="USDC")
Batch:
verify_claim(api_key="...", claims='[{"claim_type": "supply_rate", ...}, ...]')
| Name | Required | Description | Default |
|---|---|---|---|
| asset | No | ||
| chain | No | ethereum | |
| value | No | ||
| claims | No | ||
| api_key | Yes | ||
| operator | No | above | |
| protocol | No | ||
| claim_type | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so thoroughly. It explains that batch mode overrides single-claim parameters, defines the 'around' operator as within 10%, lists the returned fields including data_timestamp, and requires an api_key. These details go beyond the basic read-only nature of the tool, providing critical behavioral context such as parameter precedence and output structure.
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?
While lengthy, the description is well-structured with clear sections (Overview, Modes, Args, Returns, Examples) and each sentence contributes useful information. It is front-loaded with the tool's primary purpose and uses bullet-style formatting for parameters, making it easy to scan. The examples are practical and aid understanding without redundancy.
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?
No output schema exists, so the description appropriately explains return values for both single and batch modes. It also covers all 8 parameters, two execution modes, operator semantics, and provides examples. Given the tool's complexity (8 params, two modes), the description is remarkably complete, leaving no significant gaps in the agent's ability to understand and 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?
The input schema has 0% description coverage, so the description must compensate for all parameter meaning, and it succeeds. The 'Args' section explains each parameter in detail, including allowed values for claim_type and operator, which parameters are required for specific claim types, and the batch-mode 'claims' parameter structure. This adds significant semantic value beyond the schema's names and defaults.
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: 'Verify factual claims about current DeFi market conditions.' It specifies the verb 'verify', the resource (factual claims about DeFi), and distinguishes between single and batch modes. This is distinct from sibling tools like assess_opportunity or get_market_snapshot, which focus on assessment or data retrieval rather than claim verification.
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 provides clear context on when to use the tool (to verify factual claims about DeFi market conditions) and explains the two modes (single and batch). However, it does not explicitly name alternative tools or state when not to use this tool, so it misses the full 'when-not/alternatives' guidance. The inclusion of examples and parameter requirements implies appropriate use cases.
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.
No comments yet. Be the first to start the discussion!