What can you do with this server?

AgentPay x402 provides AI agents with autonomous, pay-per-call access to real-time cryptocurrency data tools, with payments settled in USDC on Stellar or Base via the x402 protocol — no API keys or subscriptions required. Available Tools (pay-per-call, $0.001–$0.005 USDC each): * Token Price ($0.001): Current USD price, 24h change, and market cap for any token * Wallet Balance ($0.002): Token holdings for Ethereum (0x...) or Stellar (G...) addresses * DEX Liquidity ($0.003): Volume, price, market cap, and ATH for DEX token pairs * Gas Tracker ($0.001): Ethereum gas prices (slow/standard/fast), base fee, and confirmation times * Dune Analytics ($0.005): Run any Dune query by ID for live on-chain data * Fear & Greed Index ($0.001): Market sentiment score (0–100) with optional 30-day history * Crypto News ($0.003): Headlines and sentiment (bullish/neutral/bearish) from r/CryptoCurrency * DeFi TVL ($0.002): Total Value Locked for specific protocols or top 10 via DeFiLlama * Whale Activity ($0.002): Large token transfers above a configurable USD threshold * Token Security Scan ($0.002): Honeypot detection, buy/sell taxes, mintability, and ownership risks for ERC-20/BEP-20 contracts * Yield Scanner & Funding Rates: Additional DeFi and derivatives market data Key Features: * Dual payment networks: Stellar (5-second settlement, ~$0.00001 fee) or Base (2-second settlement, ~$0.0001 fee) * Budget-aware sessions: Set spending caps to prevent overspending, with automatic fallback to cheaper tools * Developer-friendly: Python SDK handles payment flow automatically; raw HTTP works with any language * AI agent compatibility: Works with any x402-compatible agent and includes MCP server support for Claude Desktop * Data sources: CoinGecko, Etherscan, DeFiLlama, Dune Analytics, GoPlus, Binance, and more

Which integrations are available for this server?

Provides capabilities for monitoring Ethereum network activity, including gas price tracking, whale transaction monitoring, and account balance lookups. Enables AI agents to retrieve and analyze cryptocurrency-related news headlines and sentiment data from Reddit. Facilitates autonomous agent payments and settlements using USDC on the Stellar network, while providing tools to check Stellar wallet balances.

AgentPay x402 — Economic-intelligence layer for AI Agents

by romudille-bit

Overview Schema Related Servers Score Discussions

Python

Remote

AgentPay

Tests PyPI Python License: MIT MCP Live gateway

Most agent-payment tools are a wallet — they move money. AgentPay is the layer that decides whether to spend it at all.

AgentPay is the economic intelligence layer for MCP servers and AI agents.

Agents spend money. Most don't know how much, or why, until the session ends and the bill arrives.

AgentPay gives agents economic intelligence — the ability to reason about cost while they work, not after.

It starts with a budget. Every session opens with a hard cap enforced at the payment layer — not in code a model can ignore, but at the point where money moves. The agent knows from the first call exactly what it has to spend.

Before calling a tool, it knows what that call costs. Mid-task, it can check what's left and route to a cheaper alternative if the math doesn't work. When the session ends, a receipt captures every call, every cost, every decision — not a debug log, but proof of economic accountability.

The developer sees all of it: spending patterns per agent, anomaly flags when something loops or spikes, policy controls that enforce exactly which tools an agent can use and how much it can spend on each.

The result is an agent that doesn't just have a budget. It knows how to use one.

Start free: 20 tools (17 free), no USDC needed, no wallet setup required.
Live gateway: https://agentpay.tools

Install

pip install agentpay-x402            # core (Stellar)
pip install "agentpay-x402[base]"    # + pay tools that settle on Base

Related MCP server: CorteX402

Quickstart — 3 lines, zero setup

17 free tools. No USDC, no wallet, no API keys, no human. quickstart() registers an agent, mints a wallet, and returns a ready, budget-capped session.

from agentpay import quickstart

s = quickstart()                                   # registers + mints a wallet
print(s.call("token_price", {"symbol": "ETH"})["result"]["price_usd"])
print(s.spending_summary())                        # receipt: every call, cost, tx

Set a hard budget, or bring your own funded wallet to pay for tools:

s = quickstart(max_spend="0.50")                   # cap this run at $0.50
s = quickstart(secret_key="S...", base_key="0x...")  # your wallet (Stellar + Base)

Every call is session-tracked, and the cap is enforced before any payment is signed.

20 Tools (17 Free + 3 Paid)

Every call is session-tracked — you get a receipt showing every tool called, every cost, and every timestamp.

Tool	Parameters	Returns
`url_reader`	`url`	Clean markdown content of any web page
`web_search`	`query`	Top 5 results with full content
`market_snapshot`	—	S&P 500, Treasury yield, BTC, ETH, gas in one call
`token_price`	`symbol` (BTC, ETH, SOL…)	price_usd, change_24h_pct, market_cap_usd
`gas_tracker`	—	slow/standard/fast gwei, base_fee_gwei
`fear_greed_index`	`limit` (days of history, default 1)	value 0–100, value_classification, history[]
`token_market_data`	`token_a`, `token_b`	volume_24h_usd, market_cap_usd, price_usd
`wallet_balance`	`address`, `chain` (ethereum/stellar)	token balances
`whale_activity`	`token`, `min_usd` (default 100k)	large_transfers[] with direction, total_volume_usd
`defi_tvl`	`protocol` (optional, e.g. "uniswap")	tvl, change_1d, change_7d, chains[]
`token_security`	`contract_address`, `chain`	risk_level, is_honeypot, buy_tax, sell_tax
`open_interest`	`symbol` (BTC, ETH…)	total_oi_usd, oi_change_1h/24h_pct, long_short_ratio
`orderbook_depth`	`symbol` (e.g. ETHUSDT)	best_bid/ask, spread_pct, slippage at $10k/$50k/$250k
`funding_rates`	`asset` (optional)	funding_rate_pct, annualized_rate_pct, sentiment per exchange
`crypto_news`	`currencies` (e.g. "ETH,BTC"), `filter`	headlines[] with title, url, sentiment, score
`yield_scanner`	`token`, `chain` (optional), `min_tvl`	top 10 pools by APY with protocol, tvl_usd, risk_level
`dune_query`	`query_id`, `limit`, `fast_only`	rows[], columns[], row_count from Dune Analytics
`session_create`	`agent_address`, `max_spend`, `label`	session_id, budget config, gateway_url, receipt — $0.01
`pre_trade_check`	`symbol`, `size_usd`, `side`, `token_address?`	one-call trade verdict (ok/caution/avoid): slippage at YOUR size, side-aware funding carry, OI crowding, optional security — $0.01
`verified_route`	`need`, `budget_usd?`, `chain?`	buyer-side trust oracle: sweeps the x402 marketplace, collapses sybil/factory clusters, ranks real providers by usage × delivery scores → one vetted recommendation + ready_to_pay challenge — $0.01

Session Intelligence

This is the economic intelligence layer in practice. The Session gives your agent — and you — real visibility into what happened, what it cost, and why.

from agentpay import quickstart, BudgetExceeded

# quickstart() registers + mints a wallet; the returned session is also a
# context manager, so you can `with` it for a printed receipt on exit.
# Budget caps are exact: max_spend=0.10 (float) == "0.10" (str).
with quickstart(max_spend=0.10) as session:

    # Price an entire multi-tool plan BEFORE spending anything (free, no wallet)
    plan = session.estimate_plan(["token_price", "pre_trade_check", "session_create"])
    plan["total_usdc"], plan["fits_budget"]   # per-step costs + cheaper alternatives inside

    # Reason about cost before committing (use the *_usd Decimals for comparisons)
    if session.would_exceed(session.tool_cost_usd("dune_query")):
        alt = session.suggest_cheaper("dune_query")   # {"name": ..., "price": ...}

    # Call a tool — budget enforced before any payment is signed
    r = session.call("token_price", {"symbol": "ETH"})
    r.data["price_usd"]    # inner tool output  (r["result"]["price_usd"] still works)
    r.cost                 # payment amount, e.g. "0"
    r.network              # settlement chain, e.g. "stellar-mainnet" / "base"

    session.remaining_usd()   # Decimal('0.10')

    # For an external x402 tool that offers several chains, pick one:
    # session.call("https://some-x402-tool/endpoint", {}, chain="base")

    # Full receipt — every call, cost, tx hash, and settlement chain
    print(session.spending_summary())
    # {
    #   "calls": 1, "spent": "$0", "remaining": "$0.1", "budget": "$0.1",
    #   "breakdown": [
    #     {"tool": "token_price", "cost": "Free", "tx_hash": "", "network": "stellar-mainnet"}
    #   ]
    # }

Policy parameters

Control exactly what your agent is allowed to do:

from agentpay import AgentWallet, Session

wallet = AgentWallet(secret_key="S...", network="mainnet")   # or quickstart()'s minted wallet
with Session(wallet,
             gateway_url="https://agentpay.tools",
             max_spend=0.10,
             allowed_tools=["token_price", "gas_tracker", "web_search"],
             max_per_tool={"dune_query": 0.02},
             rate_limit=10,                # max 10 calls/min
             prefer_chain="base") as session:   # Base is the default; pass "stellar" to override
    ...

BudgetExceeded fires before any payment goes out if a tool would push you over the cap, isn't on the allowlist, or exceeds its per-tool limit.

Example: Market intelligence agent

Five free tools, one session, full receipt.

from agentpay import quickstart

with quickstart() as session:

    snapshot = session.call("market_snapshot", {})
    rates    = session.call("funding_rates",    {"asset": "ETH"})
    oi       = session.call("open_interest",    {"symbol": "ETH"})
    fg       = session.call("fear_greed_index", {})
    whales   = session.call("whale_activity",   {"token": "ETH", "min_usd": 500_000})

    m = snapshot["result"]
    print(f"S&P:       {m['sp500_price']:,.0f}  ({m['sp500_change_pct']:+.2f}%)")
    print(f"ETH:       ${m['eth_price_usd']:,.0f}")
    print(f"Gas:       {m['gas_standard_gwei']} gwei")

    avg_rate = sum(e["funding_rate_pct"] for e in rates["result"]["rates"]) / len(rates["result"]["rates"])
    print(f"Funding:   {avg_rate:+.4f}%/8h")
    print(f"OI 24h:    {oi['result']['oi_change_24h_pct']:+.2f}%")
    print(f"Sentiment: {fg['result']['value_classification']}")
    print(f"Whale vol: ${whales['result']['total_volume_usd']:,.0f}")

    print(session.spending_summary())

Use it in your agent

Agent Skills (one command, any agent)

npx skills add romudille-bit/agentpay

Installs the agentpay-route skill (find, judge, and pay for the best paid x402 tool within a budget) and agentpay-session (hard spend cap + verifiable receipts) into Claude Code, Codex, Droid, OpenCode, or any skills-CLI-compatible runtime. Pair with the MCP below for keyless routing out of the box; add AGENTPAY_BASE_KEY + AGENTPAY_MAX_SPEND for capped, in-place paid calls.

Claude Code plugin (one command)

/plugin marketplace add romudille-bit/agentpay
/plugin install agentpay@agentpay

Installs the agentpay-route skill — your agent finds, judges, and pays for the best paid x402 tool within a budget — plus the 17 free tools. No keys needed to route.

MCP server (any runtime)

Self-contained — pure Node, no Python, no repo, no keys to start:

npx -y @romudille/agentpay-mcp

{
  "mcpServers": {
    "agentpay": {
      "command": "npx",
      "args": ["-y", "@romudille/agentpay-mcp"]
    }
  }
}

Exposes the 17 free tools plus verified_route (buyer-side trust oracle — free preview keyless, full paid payload in wallet mode), route (legacy alias) and estimate_plan (price a multi-tool plan before spending). Listed on Glama.

Wallet mode (v2.4.0): add an EVM key and paid tools settle in-place — gasless EIP-3009 on Base (no ETH needed; nothing broadcast client-side, a rejected call moves no USDC) under a hard session cap:

{
  "mcpServers": {
    "agentpay": {
      "command": "npx",
      "args": ["-y", "@romudille/agentpay-mcp"],
      "env": {
        "AGENTPAY_BASE_KEY": "0x<EVM private key>",
        "AGENTPAY_MAX_SPEND": "0.10"
      }
    }
  }
}

Fund the key's address with USDC on Base mainnet; every paid call counts against AGENTPAY_MAX_SPEND and is refused past the cap — the budget story, enforced inside the MCP itself. Use a dedicated small-balance key.

Buyer-side routing — find & pay for the best tool, within a budget

When an agent needs a paid tool, AgentPay discovers the options across the x402 marketplace, drops the fake/empty stubs, ranks by real usage (not price), and recommends the cheapest one that actually works — within a budget. The agent pays the provider directly (peer-to-peer, no custody) and keeps a verifiable receipt.

agentpay-route "funding rates" --budget 0.01   # ranked candidates + a recommendation

Paid tools: session_create, pre_trade_check, verified_route ($0.01 each)

Three tools cost money today. session_create opens a budget-capped session with a hard max_spend limit — for autonomous agents that need spend enforcement across multiple calls. pre_trade_check is the first outcome bundle: one call returns an ok/caution/avoid trade verdict from live orderbook slippage at your size, side-aware funding carry, open-interest crowding, and an optional contract security scan — with the per-factor breakdown and raw components embedded. verified_route is the buyer-side trust oracle: "I need X, budget $Y — which x402 tool is real?" It sweeps the whole marketplace, collapses sybil/factory clusters, keeps only providers relevant to your need, ranks them by real unique-payer usage × the Prober's paid delivery scores, and returns one vetted recommendation with a ready-to-pay challenge. All 17 data tools remain free.

Price any plan before spending a cent (free, no wallet): POST /v1/plan/estimate, or session.estimate_plan([...]) from the SDK.

When metered inference ships, it works through the same Session interface — your agent checks cost, decides if it's worth it, and pays in USDC on Base or Stellar (via the SDK).

# Future — inference as a Session tool
remaining = session.remaining()
infer_cost = session.tool_cost("inference")   # e.g. "$0.02"

if remaining >= infer_cost:
    result = session.call("inference", {"prompt": "...", "model": "claude-haiku"})
else:
    result = session.call("url_reader", {"url": summary_url})  # cheaper path

To fund a wallet for session_create: send USDC to a Stellar wallet (S... key, issuer GA5ZSEJYB37JRC5AVCIA5MOP4RHTM335X2KGX3IHOJAPP5RE34K4KZVN) or a Base wallet (0x..., contract 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913).

Eating our own dog food

AgentPay's flagship analyst agent (agents/analyst/) runs daily on these exact rails as a real customer: it prices its plan with estimate_plan, gathers free intel, buys pre_trade_check verdicts on the majors under a hard $0.25 cap, and publishes a market note with an on-chain-verifiable receipt. The first best customer is the house.

Architecture

AgentPay is an x402 payment gateway and economic intelligence layer — agents call tools within a hard budget cap, pay USDC on-chain when tools cost money, and accumulate a full session receipt as they work. Free tools skip the payment step entirely; the session tracking and cost awareness are always on.

Chain support & x402 interop

Base settles via the standard x402 exact scheme (gasless EIP-3009 through the CDP facilitator) — any standard x402 client can pay AgentPay on Base, no AgentPay SDK required.

Stellar settles as a classic payment + text memo verified directly on Horizon. It is supported by the AgentPay SDK (pip install agentpay-x402) and by manual payment per the 402 instructions — but it is not the standard @x402/stellar scheme (which uses Soroban null-account templates, signed auth entries, and facilitator settlement). A standard @x402/stellar client cannot pay AgentPay's Stellar rail today; migrating to the standard Soroban scheme is on the v2 roadmap. Standard clients should pay on Base — Circle CCTP bridges USDC 1:1 between the two.

agent (Python SDK)
    │
    │  POST /tools/{name}/call
    │  ← 200 {result: ...}              ← free tools return directly
    │  ← 402 {payment_id, amount, ...}  ← paid tools (session_create, pre_trade_check, verified_route)
    │  → USDC on Base (~2s, standard x402) or Stellar (~3–5s, SDK classic+memo)
    │  → retry with X-Payment header
    │  ← 200 {result: ...}
    ▼
gateway (FastAPI on Railway)
    │
    ├── registry/registry.py   — 20-tool catalog (17 free; session_create, pre_trade_check, verified_route — $0.01 each)
    ├── gateway/routes/plan.py — POST /v1/plan/estimate (free pre-flight plan pricing)
    ├── gateway/radar.py       — Arbitrum x402 Radar discovery + settlement verify (see RADAR.md)
    ├── gateway/stellar.py     — Stellar payment verification via Horizon
    ├── gateway/base.py        — Base payment verification via JSON-RPC
    └── gateway/services/tools_runtime.py — real API dispatchers
            ├── Jina Reader       url_reader
            ├── Jina Search       web_search
            ├── Yahoo+CoinGecko   market_snapshot
            ├── CoinGecko         token_price, token_market_data
            ├── Etherscan V2      gas_tracker, whale_activity, wallet_balance
            ├── DeFiLlama         defi_tvl, yield_scanner
            ├── alternative.me    fear_greed_index
            ├── Reddit            crypto_news
            ├── Dune Analytics    dune_query
            ├── GoPlus            token_security
            └── Binance+Bybit+OKX funding_rates, open_interest, orderbook_depth

Stacks sBTC settlement (M1)

AgentPay settles x402 micropayments in sBTC on Stacks — budget-capped, signed sign-don't-broadcast, broadcast by the gateway. Milestone 1 of the Stacks Endowment grant is demonstrated live on testnet:

Developer guide: docs/stacks-m1.md — setup, known limitations, dependencies.
Runnable demo: examples/stacks_m1_demo.py — capped session → sBTC payment → receipt → over-cap rejection.
Demo video: YouTube (~40s)
On-chain proof: 0xa5351bad… — sbtc-token::transfer, payer → gateway, status success (PoX-5 testnet, block 82215).

Discovery

Directory	Status
PyPI	✅ agentpay-x402
x402scout	✅ indexed, health-checked every 15min
Glama MCP	✅ listed
awesome-x402	✅ listed
npm	✅ @romudille/agentpay-mcp
skills CLI	✅ `npx skills add romudille-bit/agentpay`
402index.io	✅ domain verified, 17 tools synced
Coinbase Bazaar	✅ indexed via REST — `session_create`, `pre_trade_check`, `verified_route` (Base). ⚠️ NOT in the curated set: invisible on the MCP `search_resources` default (AGE-125)
Claude Code plugin	✅ `/plugin marketplace add romudille-bit/agentpay`
MCP Registry	✅ `io.github.romudille-bit/agentpay` v2.4.3 (official)
402audit	✅ audited — score 100, verdict "proprietary"
signal402	✅ auto-indexed from Bazaar (6h refresh)
x402.fuchss.app	✅ listed — grade recovering post-AGE-123
~~xpay.tools~~	dropped — redundant with Bazaar (SPA mirror)

Agent-readable endpoints:

Endpoint	Purpose
`/.well-known/agentpay.json`	AgentPay manifest
`/.well-known/agent.json`	A2A agent card
`/llms.txt`	LLM-readable service description
`/.well-known/l402-services`	402index.io discovery format

Available Tools

10 tools

crypto_newsA

Latest crypto news and community sentiment from r/CryptoCurrency for any token

Use when: You need recent news headlines or community sentiment for one or more crypto tokens. Returns: headlines[] with title, url, sentiment (bullish/neutral/bearish), score, published_at Example response: {"currencies": "ETH", "headlines": [{"title": "Ethereum devs confirm Pectra upgrade timeline", "url": "https://reddit.com/r/CryptoCurrency/...", "sentiment": "bullish", "score": 1842, "published_at": "2026-03-22T08:14:00Z"}, {"title": "ETH gas fees drop to yearly lows", "url": "https://reddit.com/r/CryptoCurrency/...", "sentiment": "bullish", "score": 934, "published_at": "2026-03-22T06:31:00Z"}], "source": "reddit"}

Price: $0.000 USDC per call

ParametersJSON Schema

Name	Required	Description	Default
`filter`	No	Feed sort order (default: hot)	hot
`currencies`	No	Comma-separated token symbols, e.g. 'BTC,ETH'	BTC,ETH

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full responsibility. It discloses the source (Reddit), cost ($0.000 per call), and return format (headlines with fields). It implies read-only behavior but does not explicitly state idempotency or side effects, missing a chance for full transparency.

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 concise and well-structured: purpose first, then usage condition, returns summary, and a complete example. No unnecessary sentences; every part earns its place.

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, the description provides a full example response, sample parameter values, and cost details. It covers all necessary information for an agent to understand input, output, and usage context, making it highly complete.

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%, but the description adds value via the example response, which demonstrates parameter usage (e.g., 'currencies': 'ETH') and clarifies sort order options. The example helps an agent understand the expected output and parameter interplay.

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 retrieves 'latest crypto news and community sentiment from r/CryptoCurrency for any token', specifying the verb (get/retrieve), resource (news and sentiment), and scope (any token). It distinguishes from siblings like token_market_data and fear_greed_index, which focus on different data.

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?

Explicitly says 'Use when: You need recent news headlines or community sentiment for one or more crypto tokens', providing clear context. While it doesn't list when not to use, the sibling tools cover other domains, so the guidance is sufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

fear_greed_indexA

Crypto Fear & Greed Index (0=extreme fear, 100=extreme greed) with optional history

Use when: You need to gauge overall crypto market sentiment or mood — whether the market is fearful or greedy. Returns: value (0–100), value_classification (e.g. 'Greed'), optional history[] Example response: {"value": 10, "value_classification": "Extreme Fear", "timestamp": 1774137600, "source": "alternative.me"}

Price: $0.000 USDC per call

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Number of days of history to return (default 1, max 30)

TDQS

A4.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, but description adequately explains the tool returns a value and classification with optional history. It is clearly read-only and informational, so no hidden behaviors.

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?

Concise description with all essential information: purpose, usage, return format, example, and cost. Front-loaded with the core definition.

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 the tool's simplicity (one optional param, no output schema), the description fully covers what the agent needs to know: what it does, when to use, what to expect, and cost.

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% for the single 'limit' parameter. Description adds context by mentioning 'optional history' and showing history array in example, reinforcing the parameter's purpose.

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 the 'Crypto Fear & Greed Index' with range (0-100) and optional history. It is distinct from sibling tools like orderbook_depth or crypto_news.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Use when: You need to gauge overall crypto market sentiment or mood — whether the market is fearful or greedy.' Also provides example response and notes cost.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

orderbook_depthA

Get real bid/ask depth and slippage estimates at $10k, $50k, and $250k notional for a trading pair. Returns best bid/ask, spread percentage, and how much slippage to expect at each trade size.

Use when: You need to estimate slippage before executing a large trade. Tells you how much a $10k, $50k, or $250k order will move the market. Returns: best_bid, best_ask, spread_pct, depth with slippage_pct at $10k/$50k/$250k notional, per-exchange best prices Example response: {"asset": "ETH", "pair": "ETH/USDT", "best_ask": 2071.5, "best_bid": 2071.2, "spread_pct": 0.0145, "depth": [{"notional_usd": 10000, "slippage_pct": 0.002, "executable": true}, {"notional_usd": 50000, "slippage_pct": 0.008, "executable": true}, {"notional_usd": 250000, "slippage_pct": 0.031, "executable": true}], "exchanges": [{"exchange": "Binance", "best_ask": 2071.5, "best_bid": 2071.2}, {"exchange": "Bybit", "best_ask": 2071.6, "best_bid": 2071.1}], "source": "binance/bybit"}

Price: $0.000 USDC per call

ParametersJSON Schema

Name	Required	Description	Default
`symbol`	Yes	Trading pair, e.g. ETHUSDT or BTCUSDT
`exchange`	No	Exchange to query: binance (default) or bybit	binance

TDQS

A4.4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, but the description fully discloses the output structure, including best bid/ask, spread, depth with slippage at three notional sizes, per-exchange prices, and pricing per call. No side effects or destructive behavior implied.

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?

Well-structured with a clear first sentence, use case, return format, and example. Slightly lengthy but every sentence adds value. Could be slightly more condensed.

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, but the description explains the return structure thoroughly with an example. Covers important aspects like slippage at specific trade sizes and per-exchange data.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/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 does not add significant meaning beyond the schema for symbol and exchange, though it contextualizes the purpose.

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 gets real bid/ask depth and slippage estimates at specific notional sizes for a trading pair. It distinguishes well from sibling tools like fear_greed_index or crypto_news.

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?

Explicitly says 'Use when: You need to estimate slippage before executing a large trade.' Provides clear context but does not mention when not to use or alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

pre_trade_checkA

One-call pre-trade sanity check: 'I want to long $X of SYMBOL — is now sane?' Combines live orderbook slippage at YOUR size, cross-exchange funding (carry cost), open-interest crowding, and optional contract security into a single ok/caution/avoid verdict with a per-factor breakdown. Replaces four API integrations and the judgment layer on top of them. Raw component data embedded so you can apply your own thresholds.

Use when: An agent (or human) is about to enter a position and wants one verdict covering liquidity, carry, crowding, and security — instead of four raw feeds plus its own synthesis. Returns: verdict (ok/caution/avoid), factors{liquidity,carry,crowding,security} each with level + reason, components{orderbook_depth,funding_rates,open_interest}, symbol, side, size_usd Example response: {"symbol": "ETH", "side": "long", "size_usd": 50000, "verdict": "caution", "factors": {"liquidity": {"level": "ok", "slippage_pct": 0.011, "bucket_usd": 50000, "reason": "fills within 0.011% of best ask"}, "carry": {"level": "caution", "median_funding_pct": 0.062, "annualized_pct": 67.9, "reason": "longs paying elevated funding"}, "crowding": {"level": "ok", "long_short_ratio": 1.4, "oi_change_24h_pct": 3.2, "reason": "positioning unremarkable"}, "security": {"level": "skipped", "reason": "no token_address provided"}}}

Price: $0.01 USDC per call

ParametersJSON Schema

Name	Required	Description	Default
`side`	No	Trade direction (funding carry is side-aware)	long
`symbol`	Yes	Asset to check, e.g. 'ETH', 'BTC', 'SOL'
`size_usd`	No	Intended position size in USD (drives the slippage check)
`token_address`	No	Optional ERC-20 contract address — adds a GoPlus security scan

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description fully carries the transparency burden. It discloses the cost ($0.01 per call), explains that the tool returns a verdict with per-factor breakdown and embeds raw component data, and mentions the optional security scan. No contradictions or hidden behaviors.

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 efficiently structured: a concise opening sentence defining the tool, a detailed breakdown of components, explicit usage context, a description of the return format, an example response, and pricing. Every sentence contributes value without unnecessary repetition.

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 the moderate complexity (combining four factors) and the absence of an output schema, the description provides a complete picture. It explains the purpose, when to use it, the exact return format via an example, and even the pricing. No gaps are evident.

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 the baseline is 3. The description adds meaning beyond the schema by explaining that size_usd drives the slippage check and token_address adds a security scan, and it provides an example response that illustrates parameter usage. This adds contextual value over the schema alone.

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 is a one-call pre-trade sanity check combining multiple factors (liquidity, carry, crowding, security) into a verdict. It distinguishes from siblings by noting it replaces four separate API integrations and the judgment layer, giving it a unique value proposition.

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 explicitly states 'Use when: An agent (or human) is about to enter a position and wants one verdict covering liquidity, carry, crowding, and security — instead of four raw feeds plus its own synthesis.' This provides clear context for when to use the tool, though it does not explicitly mention when not to use it or list alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

session_createA

Open a budget-capped agent session on AgentPay. Pay $0.01 USDC once — get a session_id, budget config, and gateway URL. Enforces a hard max_spend cap across all subsequent tool calls via the AgentPay SDK. The entry point for agents discovering AgentPay on Base Bazaar.

Use when: You want to start an AgentPay session with a hard spend cap and get a session_id for tracking. Returns: session_id, max_spend, agent_address, gateway_url, tools_endpoint, created_at, receipt (tx_hash + network) Example response: {"session_id": "f47ac10b-58cc-4372-a567-0e02b2c3d479", "max_spend": "0.10", "agent_address": "GBCVQCNFWPM3GDO4GPT4YEQ42ZHPY67QTJA3WN5ERQIKQDXKBX62SLNJ", "label": null, "gateway_url": "https://agentpay.tools", "tools_endpoint": "https://agentpay.tools/tools", "created_at": "2026-05-27T12:00:00Z", "receipt": {"tx_hash": "0xabc...def", "network": "base", "amount_usdc": "0.01"}, "sdk_hint": "Use from agentpay import Session to enforce the max_spend cap client-side."}

Price: $0.01 USDC per call

ParametersJSON Schema

Name	Required	Description	Default
`label`	No	Optional human-readable label for this session
`max_spend`	No	Hard budget cap in USDC for this session, e.g. '0.10'	0.10
`agent_address`	No	Your wallet address (Stellar G... or EVM 0x...)

TDQS

A4.3/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. Discloses cost ($0.01 USDC), hard max_spend enforcement, returned fields including receipt and SDK hint. This is highly transparent for a paid tool.

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?

Well-structured with clear sections: main action, usage, return fields, example. Every sentence adds value, though slightly lengthy due to example and SDK hint. Front-loaded with the core purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 3 parameters, no output schema, and no annotations, the description provides a detailed example response and explains pricing. It compensates for the lack of output schema and covers all necessary usage context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. Description does not add new meaning beyond schema but includes example values in the response, which provides implicit context. No contradiction or important missing info.

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?

Clearly states the verb 'Open a budget-capped agent session' and specifies the resource 'on AgentPay'. Distinguishes itself from unrelated sibling tools by positioning as the entry point for AgentPay on Base Bazaar.

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?

Explicitly provides a 'Use when' condition for starting a session with a hard spend cap. Does not list when not to use or alternatives, but sibling tools are unrelated so exclusions are unnecessary.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

token_market_dataA

Get market cap, 24h volume, ATH, and price change for any token. Note: does NOT return pool depth or slippage — for pre-trade liquidity estimates, use a dedicated orderbook tool.

Use when: You need 24h trading volume, market cap, or all-time high for a token pair on decentralized exchanges. Returns: volume_24h_usd, market_cap_usd, price_usd, ath_usd, price_change_24h_pct Example response: {"token_a": "ETH", "token_b": "USDC", "price_usd": 2071.45, "volume_24h_usd": 312847293.0, "volume_change_24h_pct": -8.3, "market_cap_usd": 249800000000.0, "ath_usd": 4878.26, "price_change_24h_pct": -3.91, "source": "coingecko"}

Price: $0.000 USDC per call

ParametersJSON Schema

Name	Required	Description	Default
`token_a`	Yes	First token symbol
`token_b`	Yes	Second token symbol, e.g. USDC

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, but description discloses returned fields, source (CoinGecko), and pricing (though $0 per call is unusual). Does not mention rate limits or auth, but acceptable for a read-only data tool.

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?

Well-structured with purpose first, then exclusions, usage, returns, example. The pricing note is slightly extraneous but not harmful. Every sentence earns its place.

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, but description lists all return fields and provides a complete example. Differentiates from siblings and covers all needed context for a simple data retrieval tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with basic parameter descriptions. The description adds an example (ETH/USDC) but does not enrich meaning beyond schema. Baseline 3 is appropriate.

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?

Description clearly states it retrieves market cap, 24h volume, ATH, and price change for any token on DEXes. It explicitly distinguishes from sibling tool orderbook_depth by noting what it does NOT return (pool depth/slippage).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit 'Use when' clause specifies when to use (24h volume, market cap, ATH) and when not (pre-trade liquidity) with alternative recommendation (orderbook tool).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

token_securityA

Scan any token contract for honeypot, rug pull, and security risks

Use when: You need to check if a token contract is safe before trading or investing. Returns: risk_level, is_honeypot, buy_tax, sell_tax, holder_count, owner_address, is_mintable, can_take_back_ownership Example response: {"contract_address": "0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2", "chain": "ethereum", "risk_level": "low", "is_honeypot": false, "buy_tax": 0.0, "sell_tax": 0.0, "holder_count": 842341, "is_mintable": false, "can_take_back_ownership": false, "source": "goplus"}

Price: $0.000 USDC per call

ParametersJSON Schema

Name	Required	Description	Default
`chain`	No	Blockchain to query (default: ethereum)	ethereum
`contract_address`	Yes	Token contract address (0x...)

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses the return fields and provides an example response and pricing, but lacks details on rate limits, authentication, or other behavioral traits beyond the core functionality.

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 relatively concise and front-loaded with the main purpose. It includes an example and pricing information, which is useful but slightly extraneous. Still, overall structure is efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description compensates well by listing return fields and providing a detailed example. It covers essential aspects for a security scanning tool, though it could improve by explaining risk_level interpretation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents both parameters. The description adds the example response showing parameter usage, but does not provide additional semantic context beyond what the schema offers.

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 starts with a clear verb ('Scan') and resource ('any token contract'), specifying the action and scope. It distinguishes from siblings like token_market_data by focusing on security risks.

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?

Explicitly states 'Use when: You need to check if a token contract is safe before trading or investing.' This provides clear context for when to invoke the tool, though no alternatives or exclusions are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

url_readerA

Convert any URL to clean, LLM-ready markdown. Strips ads, nav, and boilerplate — returns just the content. No API key needed.

Use when: You need to read the content of a web page or article and get clean, structured text for further processing. Returns: content (markdown), url, length, truncated flag Example response: {"url": "https://example.com", "content": "# Example Domain\n\nThis domain is for use in illustrative examples...", "length": 1256, "truncated": false, "source": "jina_reader"}

Price: $0.000 USDC per call

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	The URL to fetch and convert to markdown

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description bears full responsibility. It discloses that no API key is needed, the tool strips ads/nav, and it returns a truncated flag. However, it does not specify rate limits, error handling, or behavior for inaccessible URLs. This leaves some transparency gaps.

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 concise, with a clear purpose statement, usage guidance, example response, and pricing. It is front-loaded and avoids unnecessary words, though the pricing line could be considered extraneous.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple schema (1 param) and no output schema, the description adequately covers return fields (content, url, length, truncated) and explains the transformation. It provides a complete mental model for using this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with one parameter well-described. The description adds context about the conversion process but does not further clarify the 'url' parameter beyond the schema. Baseline 3 is appropriate.

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 converts any URL to LLM-ready markdown, stripping ads and boilerplate. It distinguishes itself from sibling tools which are all crypto/defi focused, making its purpose unambiguous.

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 explicitly states when to use the tool ('when you need to read the content of a web page or article'). While it does not mention when not to use it, the sibling tools are self-evidently different, so the guidance is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

whale_activityA

Detect recent large wallet movements for a token (whale tracking)

Use when: You need to detect large token transfers that may signal institutional moves, accumulation, or sell-offs. Returns: large_transfers[] with from, to, amount, usd_value, minutes_ago; total_volume_usd Example response: {"token": "USDC", "large_transfers": [{"from": "0xabc...1234", "to": "0xdef...5678", "amount": 5000000.0, "usd_value": 5000000.0, "minutes_ago": 12}, {"from": "0x111...aaaa", "to": "0x222...bbbb", "amount": 2500000.0, "usd_value": 2500000.0, "minutes_ago": 34}], "total_volume_usd": 7500000.0, "source": "etherscan"}

Price: $0.000 USDC per call

ParametersJSON Schema

Name	Required	Description	Default
`token`	Yes	Token symbol to track
`min_usd`	No	Minimum transaction size in USD

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided; description states return structure and gives an example, but lacks details on authentication, rate limits, or edge cases.

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?

Description is reasonably concise and front-loaded, but includes a price line that may be extraneous for an AI agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, but the example response clarifies return format; description is sufficiently complete for a simple data retrieval tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema covers 100% of parameters with descriptions; the tool description adds little beyond the example usage, so baseline score is appropriate.

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 specifies a clear verb ('detect') and resource ('recent large wallet movements for a token'), and distinguishes well from sibling tools like orderbook_depth or fear_greed_index.

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?

Provides explicit guidance on when to use ('when you need to detect large token transfers that may signal institutional moves'), but does not mention when not to use or alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

yield_scannerA

Find best DeFi yield opportunities across protocols for a given token

Use when: You need to find the best yield/APY for a token across DeFi protocols. Returns: list of pools with protocol, apy, tvl_usd, chain, risk_level sorted by APY descending Example response: {"token": "USDC", "pools": [{"protocol": "morpho", "apy": 8.74, "tvl_usd": 312000000.0, "chain": "Ethereum", "risk_level": "low"}, {"protocol": "aave-v3", "apy": 5.21, "tvl_usd": 1840000000.0, "chain": "Ethereum", "risk_level": "low"}, {"protocol": "compound-v3", "apy": 4.87, "tvl_usd": 920000000.0, "chain": "Ethereum", "risk_level": "low"}], "source": "defillama"}

Price: $0.000 USDC per call

ParametersJSON Schema

Name	Required	Description
`chain`	No
`token`	Yes	Token symbol, e.g. ETH, USDC
`min_tvl`	No

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It describes return format, sorting, and source, but doesn't explicitly state it's read-only or disclose any 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is concise, includes usage and example. Slightly redundant with the example response, but overall well-structured and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the example response helps. However, details on chain parameter and min_tvl are missing. Adequate but not fully comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is low (33%). The description explains 'token' via example but does not add meaning for 'chain' or 'min_tvl' beyond the schema 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 finds best DeFi yield opportunities for a given token, with an example. It distinguishes from siblings like token_market_data or orderbook_depth.

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?

Provides explicit 'Use when' guidance for finding best yield/APY. Lacks explicit when-not-to-use or alternatives, but context is fairly complete.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0

Disambiguation5/5

Each tool has a distinct purpose: orderbook depth, sentiment index, news, yield, whale tracking, market data, security, URL reading, session creation, and a composite pre-trade check. There is no overlap between tools, and descriptions clearly differentiate them.

Naming Consistency4/5

All tool names use lowercase snake_case consistently, which is good. However, the naming pattern is not strictly verb_noun; some are noun_noun (e.g., 'orderbook_depth', 'fear_greed_index') or verb_implied (e.g., 'yield_scanner'). This deviation from a pure verb_noun pattern is minor but prevents a perfect score.

Tool Count5/5

With 10 tools, the set is well-scoped for an economic-intelligence layer. Each tool provides a specific capability without redundancy or unnecessary complexity. The count is neither too few nor too many for the domain.

Completeness4/5

The tool set covers most essential aspects for crypto economic intelligence: market data, sentiment, news, yield, on-chain activity, security, and a composite pre-trade check. However, there is no standalone funding rate tool (only included in pre_trade_check) and the 'url_reader' tool feels somewhat out of domain, being a generic web scraping utility.

Maintenance

ActivityActive

ResponsivenessSlow

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Polyform A
org.polyform
Pay-per-call data APIs for AI agents. USDC on Base via x402. 33 tools, no signup.
Cryptocurrency AI & Machine Learning
501
Agent Newsstand C
com.agentnewsstand
Market data and web intelligence for AI agents, paid per call in USDC on Base via x402.
Finance Search RAG Systems
161
CryptoPulse Data API A
ai.saascloud
Pay-per-call crypto market intelligence for AI agents. USDC on Base via x402.
Cryptocurrency Web3 & Decentralized Tech Finance
111
agent-data-api
io.sslip.195.82.231.168
Pay-per-call (x402/USDC-Base) web + crypto data tools for AI agents: audit, extract, crypto, DeFi.
Web Scraping Cryptocurrency Blockchain
2

Related MCP Servers

hyperd-mcpofficial
Blockchain Cryptocurrency Web3 & Decentralized Tech
hyperd-ai
A
license
A
quality
C
maintenance
Pre-trade DeFi intelligence for AI agents. 20 paid x402 endpoints, USDC on Base.
Updated 3 months ago (2026-06-09 22:01 UTC)
23
58
1
MIT
CorteX402
Blockchain Cryptocurrency Finance
Ooak21
A
license
A
quality
D
maintenance
Pay-per-call x402 data products on Base mainnet — sanctions screening, aviation weather, mortgage rates, US property dossier, title chain, wallet balance, and agent session auth. Every call settles in USDC with an on-chain receipt, no accounts or API keys.
Updated 3 months ago (2026-06-07 00:54 UTC)
7
98
MIT
dyoe-agent-tools-mcp
Autonomous Agents Cryptocurrency Web Scraping
bjyoe2016
F
license
A
quality
C
maintenance
Pay-per-call tools for AI agents including trust checks, due diligence, market data, and human-verified approvals, settled in USDC on Base via the x402 protocol.
Updated 2 months ago (2026-07-01 10:19 UTC)
16
Santos Automation
Browser Automation Web Scraping AI & Machine Learning
thereal-baitjet
A
license
Not graded
quality
B
maintenance
Website intelligence tools for AI agents. Ten pay-per-call tools via x402 micropayments (USDC on Base) — no accounts, no API keys.
Updated a month ago (2026-07-31 16:32 UTC)
2
MIT

Appeared in Searches

The Agent Times - Publication or Newsletter

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/romudille-bit/agentpay'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

AgentPay

Install

Quickstart — 3 lines, zero setup

20 Tools (17 Free + 3 Paid)

Session Intelligence

Policy parameters

Example: Market intelligence agent

Use it in your agent

Agent Skills (one command, any agent)

Claude Code plugin (one command)

MCP server (any runtime)

Buyer-side routing — find & pay for the best tool, within a budget

Paid tools: session_create, pre_trade_check, verified_route ($0.01 each)

Eating our own dog food

Architecture

Chain support & x402 interop

Stacks sBTC settlement (M1)

Discovery

Available Tools

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

hyperd-mcpofficial

Appeared in Searches

Latest Blog Posts

MCP directory API