PreFlyte — DeFi Financial Intelligence for AI Agents

get_market_snapshot

Get 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).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`asset`	Yes
`chain`	Yes
`api_key`	Yes
`protocol`	Yes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

First observedApr 14, 2026

TDQS

A4.6/5.0

Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

All PreFlyte — DeFi Financial Intelligence for AI Agents tools Inspect

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

A4.4/5.0

Disambiguation5/5

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.

Naming Consistency4/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Resources

Need Help?