Skip to main content
Glama
Sign In

AgentPay — trust routing + spend caps for x402 agents

by io.github.romudille-bit
OverviewDiscussionsAdmin

funding_spread

Cross-venue perp funding divergence for one asset — the basis/carry read, not the raw rates. Reads Binance, Bybit, OKX, Gate.io, Bitget, Hyperliquid, dYdX, MEXC and KuCoin in parallel, normalises every rate to a per-8h figure (hourly venues scaled), and returns the spread (max minus min, cheapest and dearest venue, deviation from the median), its percentile against the last 7 days of cross-venue spreads, a plain-English read, and — given notional_usd — a carry estimate (per 8h / day / 30d) net of an assumed taker fee with the breakeven holding time. Venues that fail to answer are named in venues_unavailable; the spread is computed over the ones that did.

Use when: An agent wants to know whether funding on one venue is out of line with the others for the same perp — to pick the cheaper venue for a position, or to size a long/short carry across venues. Not for: you only need one venue's current funding — funding_rates is free; you want a trade verdict for one venue — pre_trade_check. This call settles $0.01 on-chain. Returns: asset, as_of, venues[{venue, rate_8h_pct, rate_annualized_pct, raw_rate_pct, interval_hours, next_funding_time}] sorted cheapest first, spread{pct_8h, bps_8h, annualized_pct, median_8h_pct, max_deviation_from_median_pct, cheapest, dearest}, history{days, buckets, spread_pct_8h_p50/p90/max, current_percentile}, carry_estimate{per_8h_usd, per_day_usd, per_30d_usd, taker_fees_round_trip_usd, breakeven_hours, assumptions} | null, read, venues_unavailable{venue: reason} Example response: {"asset":"ETH","as_of":"2026-11-05T12:41:00+00:00","venues":[{"venue":"okx","rate_8h_pct":0.01,"rate_annualized_pct":10.95,"raw_rate_pct":0.01,"interval_hours":8,"next_funding_time":1793923200000},{"venue":"hyperliquid","rate_8h_pct":0.01,"rate_annualized_pct":10.95,"raw_rate_pct":0.00125,"interval_hours":1,"next_funding_time":1793883600000},{"venue":"dydx","rate_8h_pct":0.039,"rate_annualized_pct":42.7,"raw_rate_pct":0.004875,"interval_hours":1,"next_funding_time":1793883600000}],"spread":{"pct_8h":0.029,"bps_8h":2.9,"annualized_pct":31.75,"median_8h_pct":0.01,"max_deviation_from_median_pct":0.029,"cheapest":"okx","dearest":"dydx"},"history":{"days":7,"buckets":22,"venues_with_history":["dydx","hyperliquid","okx"],"spread_pct_8h_p50":0.0125,"spread_pct_8h_p90":0.04242,"spread_pct_8h_max":0.05698,"current_percentile":77},"carry_estimate":{"notional_usd":10000,"long_on":"okx","short_on":"dydx","per_8h_usd":2.9,"per_day_usd":8.7,"per_30d_usd":261,"taker_fees_round_trip_usd":20,"breakeven_hours":55.2,"assumptions":"taker 0.05% per leg on both venues, open and close; spread held constant; no slippage, no basis move"},"read":"ETH funding 0.0390%/8h on dydx vs 0.0100% on okx — 2.9 bps/8h, 77th percentile of the last 7 days (7 of 9 venues answered)","venues_unavailable":{"binance":"geo-blocked (451)","bybit":"geo-blocked (403)"}}

Price: $0.01 USDC per call (x402 over MCP: an unpaid call returns PaymentRequired; pay via _meta x402/payment)

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "symbol": "<symbol>"
    },
    "name": "funding_spread"
  }
}

Input Schema

NameRequiredDescriptionDefault
symbolYesPerp underlying, e.g. 'BTC', 'ETH', 'SOL'
notional_usdNoOptional position size per leg in USD — adds carry_estimate (long the cheapest venue, short the dearest)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior4/5

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

Discloses behavior annotations do not cover: nine venues read in parallel, hourly rates normalised to an 8h basis, partial-failure semantics (failed venues named in venues_unavailable, spread computed over respondents), history window, and the $0.01 on-chain settlement with x402 payment mechanics. The only shortfall is that a taker-fee assumption is mentioned (0.05% per leg) but not stated in the description body, only in the example's assumptions string.

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?

Front-loaded with purpose, then clearly labelled Use when / Not for / Returns blocks, so an agent can stop reading early. The verbatim example response is long, though given the absence of an output schema it substitutes for one rather than being padding.

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?

With no output schema, the description carries the full return contract and does so in detail: every field of venues, spread, history, carry_estimate, read and venues_unavailable, plus a concrete example. Partial-failure and pricing behavior are also covered, leaving nothing an agent needs before calling.

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 both parameters are already documented, and the description largely restates them: notional_usd triggers carry_estimate with 'long the cheapest venue, short the dearest', which mirrors the schema text. It adds the useful detail that the carry is net of an assumed taker fee with breakeven holding time, but no format or bounds guidance.

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?

States a specific verb and resource ('cross-venue perp funding divergence for one asset') and immediately scopes it as 'the basis/carry read, not the raw rates', which separates it from funding_rates without ambiguity. The listed venues and derived outputs (spread, percentile, carry) make the deliverable concrete.

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?

An explicit 'Use when' clause gives the agent two decision scenarios (pick the cheaper venue, size a cross-venue carry), and a 'Not for' clause names both alternatives (funding_rates for a single venue, pre_trade_check for a per-venue verdict). Selection between siblings is fully determined.

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

All AgentPay — trust routing + spend caps for x402 agents toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources