Arbitron

Current cross-venue spreads

arbitron_get_spreads

Read-onlyIdempotent

The price spread between two venues' perpetuals on the same coin RIGHT NOW, from the engine's last print (seconds old): one row per venue pair and symbol, best spread first. spread_pct is the better of the two entry directions in percent of price and direction names it (long_a_short_b = buy on exchange_a, sell on exchange_b); both directions, the bid and ask on each leg, 24h volumes, the funding rates with their intervals and strength (0 to 5) are included. Filter by coin, venues (either or both legs), spread bounds, direction, volume on both legs, strength or print age. For how often a spread paid over a window use arbitron_get_spread_backtest. Demo accounts get the print 15 minutes late, without the five widest spreads of any venue (meta.withheld says how many the snapshot holds back), and at most 100 rows deep.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "arbitron_get_spreads"
  }
}

Input Schema

Name	Required	Description
`coin`	No	One ticker or a comma-separated list, for example BTC,ETH. Case-insensitive.
`sort`	No	spread_desc (default), spread_asc, volume_desc, volume_asc, strength_desc, updated_desc, coin_asc. volume is the smaller leg.
`limit`	No	Rows to return, 1 to 50. Default 10.
`cursor`	No	meta.next_cursor from the previous page, to continue.
`exchange`	No	Keep pairs with these venues. One venue or a comma-separated list, spelled as arbitron_get_exchanges returns it, for example Binance,Bybit.
`direction`	No	long_a_short_b or short_a_long_b: keep pairs whose better side is that one. Default: both.
`min_strength`	No	Keep pairs whose strength is at least this, 0 to 5.
`exchange_match`	No	any (default): either leg is in exchange. all: both legs are, i.e. spreads among the listed venues only.
`max_spread_pct`	No	Keep pairs whose spread_pct is at most this many percent, for example 5 to drop dead markets.
`min_spread_pct`	No	Keep pairs whose spread_pct is at least this many percent, for example 0.3.
`max_age_seconds`	No	Keep pairs printed within this many seconds of meta.as_of, 1 to 120.
`min_volume_usdt`	No	Keep pairs where BOTH legs' 24h volume is at least this many USDT, for example 500000.
`exclude_exchange`	No	Drop pairs with any of these venues on either leg. One venue or a comma-separated list, spelled as arbitron_get_exchanges returns it, for example Binance,Bybit.

Output Schema

Name	Required	Description	Default
`data`	Yes
`meta`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 1, 2026
- addedOutput schema / properties / meta / properties / withheld
```
Added value: +{
+  "default": null,
+  "type": [
+    "integer",
+    "null"
+  ]
+}
```
First observedSep 22, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the readOnly/idempotent annotations: discloses data freshness (seconds old, engine's last print), demo-account degradation (15-minute delay, five widest spreads withheld, meta.withheld counter, 100-row depth cap). These materially change what an agent can expect from a result set.

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-loads the core concept and then the returned fields, filters and demo caveats in a tight sequence. It is dense and slightly run-on in the filter sentence, but every clause carries distinct information.

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?

For a 13-parameter, zero-required query tool with an output schema and full annotation coverage, the description supplies the freshness, paging behavior and demo caveats an agent needs. Nothing essential to correct invocation is missing.

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 already 100%, so the baseline is 3, but the description adds interpretation the schema lacks: what spread_pct actually measures (the better of the two entry directions, in percent of price) and how direction naming maps to legs (long_a_short_b = buy on exchange_a, sell on exchange_b).

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 ('the price spread between two venues' perpetuals on the same coin RIGHT NOW') with clear scope (one row per venue pair and symbol, best spread first) and explicitly separates itself from arbitron_get_spread_backtest.

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?

Routes the agent to the right alternative for the historical case ('For how often a spread paid over a window use arbitron_get_spread_backtest') and enumerates the filter dimensions available. It lacks an explicit 'when not to use' beyond that single alternative, but the snaspshot-vs-backtest distinction is unambiguous.

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

All Arbitron tools Inspect

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.