PreFlyte — DeFi Financial Intelligence for AI Agents

verify_claim

Verify 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", ...}, ...]')

Input Schema

TableJSON Schema

Name	Required	Default
`asset`	No
`chain`	No	ethereum
`value`	No
`claims`	No
`api_key`	Yes
`operator`	No	above
`protocol`	No
`claim_type`	No

Schema Changelog

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

First observedApr 14, 2026

TDQS

A4.8/5.0

Behavior5/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, 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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

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?