Skip to main content
Glama
abe-source

mcp-crypto-arbitrage

by abe-source
OverviewSchemaRelated ServersScoreDiscussions
TypeScript

An MCP server that exposes CoinGecko crypto market data as tools — get spot prices and find cross-exchange arbitrage spreads without ever needing an API key.

Tools

Tool

What it does

get_coin_prices

Current USD prices for one or more coins by CoinGecko ID

find_arbitrage

Widest cross-exchange USD/USDT price spread for one coin, above a minimum percentage

scan_top_coins

Scan the top N coins by market cap for arbitrage spreads above a threshold

Related MCP server: coingecko-mcp-server

Prerequisites

  • Node.js 18+

  • Nothing else — CoinGecko's public API works with no key. Optionally set COINGECKO_API_KEY (free Demo key) for a higher rate limit (100 calls/min vs the public tier's much lower limit)

Installation

Quick install

The package is published on npm, so these register it in one step — no cloning or building required:

Claude Code:

claude mcp add crypto-arbitrage -- npx -y mcp-crypto-arbitrage

Codex CLI:

codex mcp add crypto-arbitrage -- npx -y mcp-crypto-arbitrage

Manual config (any stdio MCP client)

Most clients that support stdio MCP servers (Claude Desktop, Cursor, Windsurf, etc.) use this same config shape — add it to whichever config file your client expects:

{
  "mcpServers": {
    "crypto-arbitrage": {
      "command": "node",
      "args": ["/absolute/path/to/mcp-crypto-arbitrage/dist/index.js"]
    }
  }
}

Add COINGECKO_API_KEY under env if you have one.

Restart your client, then try asking:

"What's the price of bitcoin and ethereum right now?"

"Is there an arbitrage opportunity on solana above 0.5%?"

"Scan the top 10 coins for cross-exchange spreads"

How it works

MCP client (Claude, Inspector, ...)
        │  stdio, JSON-RPC
        ▼
  McpServer (src/server.ts)
        │
        ▼
  tools/*.ts     — one file per tool: Zod schema + handler, formats the reply
        │
        ▼
  endpoints/*.ts — one file per CoinGecko endpoint: typed request + response
        │
        ▼
  apiClient.ts   — optional demo-key header, CoinGecko error/rate-limit parsing
        │
        ▼
  client.ts      — generic fetch wrapper, timeout, HTTP error handling
        │
        ▼
  CoinGecko REST API

Each layer knows nothing about the one above it. client.ts doesn't know CoinGecko exists; endpoints/ doesn't know MCP exists. Adding a new tool means one new file in endpoints/, one new file in tools/, one line in tools/index.ts — nothing else changes.

Tool arguments are validated with Zod before any handler runs — a malformed request never reaches the API.

find_arbitrage and scan_top_coins compare only USD/USDT-quoted markets from CoinGecko's /coins/{id}/tickers endpoint — the widest gap between the lowest and highest last-traded price across those markets is reported as the spread. This is raw market-data spread, not a tradeable guarantee: it ignores withdrawal/deposit friction, exchange fees, and execution slippage.

Development

git clone https://github.com/abe-source/mcp-crypto-arbitrage.git
cd mcp-crypto-arbitrage
npm install
npm run build   # compile TypeScript
npm run lint     # check formatting + lint rules
npm run check    # lint + format + fix, in place

Test locally with the MCP Inspector:

npx @modelcontextprotocol/inspector --cli node dist/index.js --method tools/call --tool-name get_coin_prices --tool-arg coins=bitcoin,ethereum

License

MIT

Available Tools

3 tools
find_arbitrageA

Find the widest cross-exchange USD/USDT price spread for one coin, above a minimum percentage.

ParametersJSON Schema
NameRequiredDescriptionDefault
coinYesCoinGecko coin ID, e.g. "bitcoin"
min_spread_pctNoMinimum spread percentage to report

TDQS

A3.7/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 full burden. It discloses the main behavior but lacks details on scope (e.g., which exchanges), latency, or behavior when no spread meets the threshold. Adequate but leaves gaps.

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?

A single, clear, and efficient sentence with no wasted words. Front-loaded with the core purpose.

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?

For a simple tool with 2 parameters and no output schema, the description is minimally adequate. It lacks details on return format or edge cases (e.g., no spread found), but is functional for basic use.

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 baseline is 3. The description adds no new meaning beyond stating the condition 'above a minimum percentage', which is already in the schema's description for min_spread_pct.

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 verb 'find', the resource 'cross-exchange USD/USDT price spread for one coin', and a condition 'above a minimum percentage'. It distinguishes from siblings: 'get_coin_prices' retrieves prices, 'scan_top_coins' scans multiple coins.

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

Usage Guidelines3/5

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

The description implies usage for arbitrage detection but does not explicitly state when to use this tool versus alternatives like 'get_coin_prices' or 'scan_top_coins'. No when-not-to-use guidance is provided.

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

get_coin_pricesA

Get current USD prices for one or more coins by CoinGecko ID (e.g. bitcoin, ethereum).

ParametersJSON Schema
NameRequiredDescriptionDefault
coinsYesCoinGecko coin IDs, e.g. ["bitcoin", "ethereum"]

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 full burden. It only states the basic behavior (get prices) without disclosing any side effects, rate limits, data freshness, or potential errors. For a simple read operation, this is adequate but not exceptional.

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 a single, front-loaded sentence with no redundant words. Every part serves a purpose, making it highly efficient for quick understanding.

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?

While the tool is simple, the description does not explain the return format, which is essential given no output schema. Users are left to infer what the response contains, causing potential ambiguity.

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 schema already describes the 'coins' parameter with 100% coverage, but the description adds value by providing concrete examples ('bitcoin, ethereum'), which helps agents understand the format better than 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 verb 'Get', the resource 'current USD prices for coins', and the input parameter 'CoinGecko ID'. It effectively distinguishes from sibling tools like 'find_arbitrage' and 'scan_top_coins' by specifying the exact data it retrieves.

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

Usage Guidelines3/5

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

The description implies usage when current prices are needed, but lacks explicit guidance on when to use this tool versus alternatives, and no exclusion criteria or prerequisites are mentioned.

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

scan_top_coinsA

Scan the top N coins by market cap for cross-exchange arbitrage spreads above a threshold. Uses N+1 API calls — mind the CoinGecko rate limit.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoHow many top coins to scan
min_spread_pctNoMinimum spread percentage to report

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 full burden. It discloses the N+1 API call pattern and rate limit concern, which is valuable. However, it does not mention read-only nature, error handling on rate limit, or response format.

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?

Two concise sentences: first states purpose, second adds behavioral context. No wasted words, front-loaded with action and resource.

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?

For a simple two-parameter tool, the description covers purpose and a key behavioral note. However, it omits what the output represents (arbitrage opportunities? details?) and lacks guidance on prerequisites or error states.

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 the schema already defines both parameters clearly. The description adds context about API calls but does not clarify parameter semantics beyond schema defaults and ranges.

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 the verb 'scan', the resource 'top N coins by market cap', and the outcome 'for cross-exchange arbitrage spreads above a threshold'. It clearly distinguishes from siblings 'get_coin_prices' and 'find_arbitrage' by focusing on top coins and threshold screening.

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 warns about N+1 API calls and rate limits, guiding users to be mindful when invoking. It implies that this tool is for quick screens of top coins, but does not explicitly state when to use alternatives like 'find_arbitrage' for broader searches.

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. Dates show when Glama detected each change.

  1. 3 tool updatesv1.0.0
    • First observedfind_arbitrage
    • First observedget_coin_prices
    • First observedscan_top_coins
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 clearly distinct purpose: get_coin_prices retrieves prices, find_arbitrage analyzes a single coin's spread, and scan_top_coins scans multiple coins. No overlap.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case: get_coin_prices, find_arbitrage, scan_top_coins. Very predictable.

Tool Count5/5

Three tools is appropriate for a focused crypto arbitrage server. Each tool adds distinct value without redundancy.

Completeness4/5

Covers core arbitrage functionality: price retrieval, single-coin spread, and multi-coin scan. Minor gap: no tool for listing supported coins or exchanges, but CoinGecko IDs are well-known.

Maintenance

ActivitySlowing
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • CoinGecko MCP Server

    friendlygeorge
    A
    license
    A
    quality
    F
    maintenance
    An MCP server for CoinGecko that connects any MCP-compatible client to free crypto market data, providing tools for prices, market caps, trending coins, historical data, and global stats.
    8
    50
    MIT

  • coingecko-mcp-server

    cyanheads
    A
    license
    Not graded
    quality
    A
    maintenance
    MCP server providing market data for 15,000+ cryptocurrencies including prices, history, trends, and deep coin metadata via CoinGecko.
    101
    1
    Apache 2.0

  • mcp-crypto-monitor

    AMEOBIUS-space
    A
    license
    Not graded
    quality
    C
    maintenance
    An MCP server that gives AI agents the ability to check crypto wallet balances, track token prices, calculate portfolio value, monitor gas prices, and track the Fear & Greed Index — all with zero external dependencies using free public APIs.
    MIT

Latest Blog Posts

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/abe-source/mcp-crypto-arbitrage'

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