Skip to main content
Glama
donnywin85

arb-dex-mcp

by donnywin85
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

arb-dex-mcp

Live cross-DEX crypto prices for your AI agent — per-venue pool price, pool liquidity and the gross cross-venue spread on 6 EVM chains, read straight from on-chain pool state.

npm npm downloads provenance MCP Registry Indexed on TensorBlock MCP Index Listed on mcpservers.org license

Chains: BSC · Polygon · Arbitrum · Base · Avalanche · Optimism. Venues: PancakeSwap (v2 + v3), Uniswap v3, SushiSwap, QuickSwap, Biswap, ApeSwap, BaseSwap, Trader Joe, Pangolin — every v2-style pool and every v3 fee tier separately, because a $12k 1% pool and a $19M 0.01% pool are not the same quote.

Nothing is modelled, estimated or backfilled. Every payload states its own block number and carries its own scope note, so an agent that quotes a figure also has the caveats attached to it.

Works with no API key against a free hourly public snapshot. Docs · npm

Quickstart

Nothing to clone or build. Your MCP client fetches the package. Requires Node 18+.

Claude Desktop

claude_desktop_config.json — macOS ~/Library/Application Support/Claude/, Windows %APPDATA%\Claude\:

{
  "mcpServers": {
    "arb-dex": {
      "command": "npx",
      "args": ["-y", "arb-dex-mcp"],
      "env": {
        "RAPIDAPI_KEY": "your-rapidapi-key-here"
      }
    }
  }
}

Restart Claude Desktop; the six tools appear under the connectors icon. Drop the env block entirely to run keyless — the server still starts and the free-snapshot tools still answer.

Claude Code

claude mcp add arb-dex --env RAPIDAPI_KEY=your-rapidapi-key-here -- npx -y arb-dex-mcp

Keyless:

claude mcp add arb-dex -- npx -y arb-dex-mcp

Then /mcp to confirm it connected.

Cursor

~/.cursor/mcp.json (global) or .cursor/mcp.json (per project):

{
  "mcpServers": {
    "arb-dex": {
      "command": "npx",
      "args": ["-y", "arb-dex-mcp"],
      "env": {
        "RAPIDAPI_KEY": "your-rapidapi-key-here"
      }
    }
  }
}

Cursor → Settings → MCP shows the server and its tools once the file is saved.

Any other MCP client

Same three facts: command npx, args ["-y", "arb-dex-mcp"], transport stdio, optional env RAPIDAPI_KEY.

Related MCP server: ProfitSpot MCP

Try it

Real prompts, and the real shape that comes back. Payloads below were measured live on 2026-08-15; they are trimmed for width but nothing is invented.

1. "What is WBNB/USDT trading at on every BSC venue right now?"

get_prices reads every pool holding the pair — v2 pairs and each v3 fee tier separately — at one stated block:

{
  "pair": "WBNB/USDT",
  "network": "bsc",
  "chainId": 56,
  "blockNumber": 116151268,
  "pricesByVenue": [
    { "venue": "pancake",        "surface": "v2", "feeBps": 25,  "price": 611.7347, "tvlUsd": 56834814.36 },
    { "venue": "biswap",         "surface": "v2", "feeBps": 10,  "price": 610.8278, "tvlUsd": 415733.94 },
    { "venue": "apeswap",        "surface": "v2", "feeBps": 20,  "price": 611.1244, "tvlUsd": 3659.06 },
    { "venue": "pancakeV3:1",    "surface": "v3", "feeBps": 1,   "price": 610.5684, "tvlUsd": 18596810.32 },
    { "venue": "pancakeV3:5",    "surface": "v3", "feeBps": 5,   "price": 610.6531, "tvlUsd": 4941099.44 },
    { "venue": "pancakeV3:25",   "surface": "v3", "feeBps": 25,  "price": 610.6304, "tvlUsd": 52534.35 },
    { "venue": "pancakeV3:100",  "surface": "v3", "feeBps": 100, "price": 609.1025, "tvlUsd": 12206.21 }
  ],
  "bestBuy":  { "venue": "pancakeV3:100", "price": 609.1025 },
  "bestSell": { "venue": "pancake",       "price": 611.7347 },
  "midSpreadBps": 43.22,
  "crossDex": {
    "grossSpreadBps": 0,
    "grossUsd": 0,
    "optimalInput": { "amount": 0, "token": "WBNB", "usd": 0 },
    "buyVenue": "-",
    "sellVenue": "-"
  },
  "liquidity": { "venues": 7, "totalTvlUsd": 80856857.67 },
  "source": "rpc"
}

Read the two spread numbers against each other. The raw mid spread is 43 bps — and the gross capturable spread is 0. The 609.10 quote lives in a $12k pool; the size that would actually clear it moves the price past the gap before you get there. A tool that reported only the 43 bps would be handing an agent a number it cannot trade. This one reports both, and optimalInput is where the honesty lands.

2. "Show me the cross-DEX spreads on Base — are any actually capturable?"

get_spreads sweeps a whole chain and ranks by gross USD at the optimal size, not by headline basis points:

{
  "network": "base",
  "chainId": 8453,
  "scannedPairs": 11,
  "opportunities": [],
  "found": 0,
  "filters": { "minSpreadBps": 10, "minVenueTvlUsd": 1000, "minGrossUsd": 0.01, "limit": 5 },
  "ranking": "gross USD at the optimal trade size, NOT raw spread — a large spread with a tiny optimal size is not an opportunity",
  "scope": "GROSS cross-venue spread from live pool state, BEFORE gas, MEV and any slippage beyond the optimal size. Not a profit estimate and not trade advice. Venues below the liquidity floor are excluded because a spread against a dust pool is an artefact, not an opportunity.",
  "elapsedMs": 2847
}

found: 0 is a real answer and it is the common one. Eleven pairs scanned, nothing cleared the floor. Venues under $1,000 TVL are dropped outright. When rows do come back, each carries capturable, warning and shallowestSideTvlUsd so a big basis-point number cannot mislead on its own. This tool will tell your agent there is nothing there — which is the whole point of asking it.

3. "How much history does arb-dex actually have, and for which chains?"

get_history_summary sizes the archive before you query it:

{
  "rows": 133,
  "rowsWithPairDetail": 103,
  "rowsByEra": { "digest-totals-only": 30, "top-list-pairs": 5, "full-sweep": 98 },
  "pairsTracked": 107,
  "firstAt": "2026-08-10T17:35:09.355Z",
  "lastAt":  "2026-08-15T20:54:34.417Z",
  "spanHours": 123.32,
  "chainsSeen": ["arbitrum", "avalanche", "base", "bsc", "optimism", "polygon"],
  "pairs": [
    { "chain": "polygon",  "pair": "WBTC/USDC", "observations": 103, "qualifiedObservations": 39 },
    { "chain": "bsc",      "pair": "BTCB/USDT", "observations": 99,  "qualifiedObservations": 15 },
    { "chain": "arbitrum", "pair": "ARB/USDC",  "observations": 98,  "qualifiedObservations": 0 }
  ]
}

Coverage is only what was measured. A gap stays a gap — rowsByEra says how much detail each era of rows carries, and ARB/USDC having 98 observations but 0 qualified is the archive telling you that pair has never once cleared the spread floor.

Tools

Tool

What it answers

Access

get_chains

Which chains are covered, their chain IDs, tokens and DEX venues

Any key · keyless returns the chain list only, and says so

get_pairs

What is priceable on one chain: token universe, venues, pair syntax

Any key · keyless returns the measured subset, labelled as such

get_prices

One pair's price at every venue holding a pool for it, plus reserves, TVL, fee tier and the cross-DEX spread

Any key

get_spreads

A whole chain's cross-venue dislocations, ranked by gross USD at the optimal size

Any key for live: true · keyless serves the free hourly snapshot

get_history_summary

What the measurement archive covers: rows, pairs tracked, chains seen, span, retention

Any key (free tier included)

get_history

One pair's per-venue price/liquidity series and gross cross-venue spread over 24h / 7d / 30d

PRO plan — see Plans

The two history tools read the service's own measurement archive, so they answer the question the live tools cannot: whether a dislocation persisted or was a single sample. Sampling is roughly hourly, and gaps are never interpolated or backfilled. Call get_history_summary first to see what span exists before asking for a window.

What it will not do

  • Spreads are gross — before gas, MEV and slippage beyond the optimal size. Not a profit estimate and not trade advice.

  • It never fabricates a row. Without a key, get_chains, get_pairs and get_spreads answer from the free public surface and each carries a limitation field naming exactly what a key would add. get_prices, get_history_summary and get_history return an explicit key-required error with the signup link rather than a thinner answer dressed up as a full one.

  • It does not execute trades, hold funds, or touch a wallet. It is read-only market data.

  • This package ships no credentials of any kind. The key is yours and stays in your config.

Get a key

The paid tools call the API through RapidAPI using your own key.

  1. Subscribe — there is a free tier: https://rapidapi.com/donnydev/api/multi-chain-dex-prices-liquidity

  2. Copy your X-RapidAPI-Key from the RapidAPI dashboard.

  3. Put it in RAPIDAPI_KEY in the config above — never in code, and never in a commit.

Plans

Five of the six tools work on the free tier. Only the per-pair history series is gated:

Plan

Adds

BASIC ($0)

Live quotes on every chain, plus get_history_summary so you can size the archive before you buy it

PRO ($15/mo)

get_history — the measured per-venue series for one pair, 24h window, 1000 calls/mo

ULTRA ($49/mo)

No window limit and no history meter, plus depth/slippage and spread alerts

MEGA ($149/mo)

Bulk paging over the complete archive for your own store

Calling get_history below PRO returns an explicit tier_required error naming the plan and the upgrade URL — it does not fail silently or return an empty series.

Configuration

Env var

Default

Purpose

RAPIDAPI_KEY

—

Your RapidAPI key. Required for the paid tools.

ARB_DEX_TIMEOUT_MS

45000

Request timeout. A live full-chain sweep is a real on-chain read and can take ~30s.

ARB_DEX_FREE_BASE_URL

production origin

Override the free-surface host.

ARB_DEX_RAPIDAPI_HOST

multi-chain-dex-prices-liquidity.p.rapidapi.com

Override the RapidAPI host.

Set these in your MCP client's env block (see the configs above). .env.example ships in the package and documents the same variables for local runs from a clone.

Test

The test suite is not in the npm tarball — run it from a clone:

git clone https://github.com/donnywin85/arb-dex-mcp.git
cd arb-dex-mcp && npm install

npm run selftest                    # keyless: exercises the free fallbacks
RAPIDAPI_KEY=... npm run selftest   # keyed: exercises the paid routes

The test spawns the server over stdio and calls every tool against the real production API — nothing is mocked. It asserts on live values (block number, per-venue prices, scanned-pair counts), so a run that passes is evidence the data path works end to end.

Links

License

MIT — see LICENSE.

Available Tools

4 tools
get_chainsList supported chains, their tokens and DEX venuesA

List every blockchain this API covers, with its chain ID, native asset, default trading pair, the token tickers it prices, and the DEX venues it reads (both Uniswap-v2-style pools and Uniswap-v3-style concentrated-liquidity pools). Call this first to discover valid chain values for the other tools. With a RapidAPI key you get the full per-chain token and venue lists; without one it falls back to the free public snapshot, which names the chains but not their token universes, and says so in the response. Paid route: needs your own RapidAPI key in RAPIDAPI_KEY (free tier available at https://rapidapi.com/donnydev/api/multi-chain-dex-prices-liquidity).

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.5/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 behavioral disclosure burden. It transparently explains the authentication-dependent behavior: with a RapidAPI key the full token/venue lists are returned, while without one a public snapshot is used that omits token universes. It also mentions the paid route and free tier availability, adding valuable context beyond the tool's basic operation.

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 front-loaded with the main action and scope, followed by operational details. Every sentence adds meaningful information—output contents, usage ordering, authentication behavior, and key source—with no redundancy. It is appropriately sized for the tool's complexity.

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 there is no output schema, the description thoroughly explains what the response will include: chains, chain IDs, native assets, pairs, tokens, and DEX venue types. It also covers auth variants, prerequisites, and usage context, making the tool fully understandable without structured output documentation.

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?

The tool has zero parameters, so the schema fully covers the input side. The description compensates by explaining what data the response will contain, which is more than enough for a parameterless tool. No additional parameter semantics are needed.

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 identifies the tool's purpose: listing all supported blockchains with chain IDs, native assets, default trading pairs, token tickers, and DEX venues. It uses a specific verb ('List every blockchain') and enumerates the exact scope, distinguishing it well from sibling tools like get_pairs or get_prices.

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 instructs 'Call this first to discover valid chain values for the other tools,' providing clear usage context and positioning it as a prerequisite. However, it does not explicitly state when not to use it or compare it to alternatives, so it stops 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.

get_pairsWhat can be priced on one chainA

Show what is queryable on a single chain: the token tickers the API prices, the DEX venues it reads, and the chain default pair. A pair for get_prices is written as TOKEN_A/TOKEN_B from these tickers (first symbol is the base, second is the quote) — any ERC-20 contract address on the chain also works in place of a ticker. This returns the token universe, not a fixed enumerated pair list: the API prices whatever pair of these you ask for that has live pool liquidity, and returns 404 when no pool exists. Without a RapidAPI key it falls back to the free snapshot and returns only the pairs actually measured in the latest scan of that chain, labelled as such. Paid route: needs your own RapidAPI key in RAPIDAPI_KEY (free tier available at https://rapidapi.com/donnydev/api/multi-chain-dex-prices-liquidity).

ParametersJSON Schema
NameRequiredDescriptionDefault
chainYesChain key. One of: bsc, polygon, arbitrum, base, avalanche, optimism. Numeric chain IDs are not accepted here — use the key.

TDQS

A4.5/5.0
Behavior5/5

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

No annotations are present, and the description carries the full burden, excelling at it. It discloses that the tool returns a token universe rather than a fixed list, returns 404 when no pool exists, and falls back to a free snapshot without a RapidAPI key, labeled as such. It also notes the paid RapidAPI key requirement, giving complete behavioral 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 five sentences, each adding a distinct piece of information: main purpose, pair format, universe semantics, fallback behavior, and paid access. It is front-loaded with the core purpose and contains no redundant filler.

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?

There is no output schema, so the description must explain what the tool returns, and it does so thoroughly: token tickers, DEX venues, default pair, and the difference between the live universe and the fallback snapshot. It also covers error behavior (404) and authentication requirements, making it complete for a one-parameter 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?

The input schema fully documents the single 'chain' parameter with an enum, descriptions, and a note about numeric IDs not being accepted (100% schema coverage). The description adds contextual value by tying the parameter to chain-specific behavior, but it does not need to repeat the schema. The baseline of 3 applies.

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 opens with 'Show what is queryable on a single chain' and explicitly enumerates the returned items: token tickers, DEX venues, and the chain default pair. It distinguishes from sibling get_prices by explaining how pair strings are constructed, making the tool's role 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?

The description clearly implies usage: it tells users that pairs for get_prices are built from these tickers, so this tool is the prerequisite for constructing price queries. It does not explicitly name alternatives or state when not to use it, but the context is strong enough to guide selection.

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

get_pricesPer-venue live pool prices for one pairA

Live price of one trading pair at EVERY DEX venue on a chain that holds a pool for it, read directly from pool state at a stated block number. Returns per-venue price (quote token per 1 base token), pool reserves, pool TVL in USD and the venue fee tier; plus the best bid/ask venues, the raw mid spread in basis points, aggregate liquidity, and the cross-DEX gross spread with its optimal trade size. Use this when you need the actual number a swap would price against on a specific venue, or to compare one pair across venues. For ranking opportunities across a whole chain, use get_spreads instead. Spreads are GROSS — before gas, MEV and slippage beyond the optimal size — and are not a profit estimate or trade advice. Paid route: needs your own RapidAPI key in RAPIDAPI_KEY (free tier available at https://rapidapi.com/donnydev/api/multi-chain-dex-prices-liquidity).

ParametersJSON Schema
NameRequiredDescriptionDefault
feeNoOptional Uniswap-v3 fee tier in hundredths of a bip (100, 500, 2500, 3000, 10000). Restricts the v3 probe to that single tier instead of sweeping all of them. Omit to sweep every tier.
pairYesPair as BASE/QUOTE, e.g. "WBNB/USDT". The first symbol is the base (the USD-priceable side). A raw 0x… ERC-20 address may replace either ticker. Call get_pairs for the tickers a chain knows.
chainYesChain key. One of: bsc, polygon, arbitrum, base, avalanche, optimism. Numeric chain IDs are not accepted here — use the key.

TDQS

A4.1/5.0
Behavior3/5

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

With no annotations, the description carries the transparency burden. It discloses that reads are from pool state, mentions the gross spread caveat, and notes API key requirements. However, it states data is read 'at a stated block number' but the schema has no block parameter, creating a confusing discrepancy. This undermines transparency despite other useful disclosures.

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 long but every sentence earns its place: it front-loads the core purpose, lists returns, gives usage guidance, includes a vital caveat about gross spreads, and provides auth details. It is well-structured with no filler or repetition.

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 tool's complexity and lack of output schema, the description covers return values, usage context, spread caveats, and authentication. The only notable gap is the misleading reference to a 'stated block number' that doesn't correspond to any parameter, slightly reducing completeness.

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 coverage is 100%, so baseline is 3. The description adds minimal parameter value, only reinforcing pair order via 'quote token per 1 base token'. Critically, it introduces a non-existent 'stated block number' that is not in the schema, confusing parameter semantics. This negative contribution lowers the score below the baseline.

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 function: 'Live price of one trading pair at EVERY DEX venue on a chain that holds a pool for it'. It uses a specific verb and resource scope, and explicitly distinguishes from get_spreads by advising 'For ranking opportunities across a whole chain, use get_spreads instead.' This makes the purpose unambiguous and differentiates it from siblings.

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?

The description provides explicit when-to-use guidance: 'Use this when you need the actual number a swap would price against on a specific venue, or to compare one pair across venues.' It also names an alternative: 'For ranking opportunities across a whole chain, use get_spreads instead.' This clearly scopes usage and directs to the correct alternative.

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

get_spreadsRank cross-DEX spread opportunities on a chainA

Sweep a whole chain and rank its cross-venue price dislocations, each with the buy venue, sell venue, spread in basis points, the optimal trade size, and the gross USD that size would capture. Ranking is by GROSS USD AT THE OPTIMAL SIZE, not by headline basis points — a 160bps spread against a $1,470 pool is worth about a cent, and the payload says so per row (capturable, warning, shallowestSideTvlUsd). Venues below the liquidity floor are excluded because a spread against a dust pool is an artefact, not an opportunity. Numbers are GROSS: before gas, MEV and any slippage beyond the optimal size. Not a profit estimate and not trade advice. With a RapidAPI key and live=true this runs a fresh on-chain sweep (slow, ~30s, most current). Otherwise it serves the free hourly public snapshot, which is keyless and fast — the response always states which, and when it was generated. Paid route: needs your own RapidAPI key in RAPIDAPI_KEY (free tier available at https://rapidapi.com/donnydev/api/multi-chain-dex-prices-liquidity).

ParametersJSON Schema
NameRequiredDescriptionDefault
liveNotrue = run a fresh on-chain sweep now (requires RAPIDAPI_KEY, takes ~30s). false/omitted = the free public snapshot, rebuilt hourly.
chainYesChain key. One of: bsc, polygon, arbitrum, base, avalanche, optimism. Numeric chain IDs are not accepted here — use the key.
limitNoLive sweeps only. Maximum rows, 1..40. Default 15.
minSpreadBpsNoLive sweeps only. Minimum spread in basis points to report. Default 10.

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description fully carries the transparency burden and excels: it discloses ranking by gross USD rather than bps, exclusion of low-liquidity venues, gross vs net numbers, the non-profit/non-advice nature, live vs snapshot timing, response stating data source, and key requirements. This is exemplary behavioral disclosure.

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?

Although long, every sentence adds meaningful value: main action, ranking rule, an illustrative example, exclusion rationale, gross/net clarification, live vs snapshot behavior, and access instructions. It is well-structured and front-loaded with the core purpose.

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 absence of an output schema and the presence of four parameters, the description is remarkably complete. It covers input behaviors, output field names, ranking logic, limitations, authentication needs, and response characteristics, leaving no major gaps for an AI agent to operate effectively.

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?

The input schema already provides 100% coverage with detailed descriptions for all parameters, including the live parameter's behavior and the chain enum. The description adds some context about live requiring a key and snapshot timing, but it largely reiterates schema information. Baseline of 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's function: 'Sweep a whole chain and rank its cross-venue price dislocations' and enumerates the output fields (buy venue, sell venue, spread in bps, optimal size, gross USD). It distinguishes itself from sibling tools like get_prices by focusing on spread opportunities across venues.

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 live=true (with RapidAPI key) versus the free hourly snapshot, and explains the ranking metric (gross USD at optimal size). However, it does not explicitly mention alternatives among sibling tools, so it misses the 'when not to use this' aspect.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 4 tool updatesv1.0.0
    • First observedget_chains
    • First observedget_pairs
    • First observedget_prices
    • First observedget_spreads
Deploy Server
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

TDQS

A4.5/5.0

Scored across 4 tools

Disambiguation5/5

Each tool has a distinct purpose: get_chains discovers chains, get_pairs reveals a chain's token/venue universe, get_prices returns per-venue prices for one pair, and get_spreads ranks cross-venue opportunities chain-wide. Descriptions explicitly reference when to use each tool, eliminating boundary ambiguity.

Naming Consistency5/5

All tools follow the exact `get_<plural_noun>` pattern in snake_case (get_chains, get_pairs, get_prices, get_spreads). The naming is perfectly uniform and predictable.

Tool Count5/5

Four tools are well-scoped for the server's purpose: chain discovery, pair/token discovery, per-pair pricing, and spread scanning. Each tool earns its place without bloat or excessive granularity.

Completeness5/5

The toolset covers the full workflow from discovering chains and tokens to querying live prices and scanning for arbitrage opportunities across all venues. No obvious missing operation for the stated domain.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • ProfitSpot MCP

    omniologynow-rgb
    A
    license
    A
    quality
    B
    maintenance
    Cross-chain DeFi intelligence MCP server for AI agents. 7 tools for yield discovery, pool analysis, profit simulation, risk scoring, whale tracking, impermanent loss calculation, and DeFi overview across 86 chains and 6,500+ liquidity pools.
    7
    1
    AGPL 3.0

  • dexscreener-mcp

    Glebenjoy
    A
    license
    A
    quality
    D
    maintenance
    An MCP server that gives Claude, Cursor, and any MCP-compatible agent live on-chain market data from DexScreener — search pairs, inspect tokens and pools, and pull trending/boosted tokens across every chain.
    6
    81 npm
    MIT