Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@crypto-price-mcp compare BTC prices across exchanges"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP (Model Context Protocol) server that fetches cryptocurrency prices from multiple exchanges.
Fetch real-time prices from 8 exchanges in parallel
Compare prices across all exchanges and find the best rate
Get 24-hour volume rankings per exchange
List all tradable pairs on a given exchange
Related MCP server: Crypto MCP Server
Exchange | Region | Quote Currency |
Binance | Global | USDT |
Coinbase | Global | USD |
Kraken | Global | USD |
Bybit | Global | USDT |
OKX | Global | USDT |
Bitget | Global | USDT |
bitFlyer | Japan | JPY |
GMO Coin | Japan | JPY |
get_priceFetch the current price of a cryptocurrency from one or more exchanges.
symbol : Asset symbol (e.g., BTC, ETH, SOL)
exchanges : (optional) List of exchanges to query. Defaults to all.compare_pricesCompare prices across all exchanges and show the lowest/highest price with spread percentage.
symbol : Asset symbol (e.g., BTC, ETH, SOL)get_top_rankingGet the top N cryptocurrencies ranked by 24-hour volume on a given exchange.
exchange : Exchange name
limit : (optional) Number of results. Default: 10, max: 50get_pairsList all tradable pairs available on a given exchange.
exchange : Exchange nameRequires Python 3.12+ and uv.
git clone https://github.com/your-username/crypto-price-mcp.git
cd crypto-price-mcp
uv syncuv run python -m crypto_price_mcp.serverAdd the following to your Claude Desktop config (~/Library/Application Support/Claude/claude_desktop_config.json):
{
"mcpServers": {
"crypto-price-mcp": {
"command": "/path/to/uv",
"args": [
"--directory",
"/path/to/crypto-price-mcp",
"run",
"python",
"-m",
"crypto_price_mcp.server"
]
}
}
}# Run tests
uv run pytest
# Lint
uv run ruff check src tests
# Type check
uv run mypy srcMCP Python SDK — MCP server framework
httpx — Async HTTP client
uv — Package manager
Compare the price of a specified asset across all exchanges, showing the lowest and highest prices. Examples: BTC, ETH, SOL, etc.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Asset symbol (e.g., BTC, ETH, SOL) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose the core behavior (showing lowest and highest prices), but it does not add context about output structure, data freshness, or possible failure modes. It is not misleading, but it leaves some behavioral gaps unaddressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence followed by examples. It is front-loaded with the action and scope, and every part earns its place with no redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter comparison tool with no output schema, the description adequately conveys what is returned (lowest and highest prices). Minor gaps like handling of invalid symbols are not critical for a tool this simple, so it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the symbol parameter is already documented. The description reinforces that the symbol refers to a tradeable asset and repeats the examples, but adds no new semantic detail beyond what the schema already provides. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Compare') and resource ('price of a specified asset across all exchanges'), clearly distinguishing it from sibling tools like get_price which presumably returns a single price. It also gives concrete examples (BTC, ETH, SOL) that ground the asset concept.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: when you need to compare prices across exchanges and see the lowest/highest values. However, it does not explicitly name alternatives like get_price or state when not to use it, 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.
Fetch all tradable pairs available on a specified exchange. Supported exchanges: binance, coinbase, kraken, bitflyer, gmo, bybit, okx, bitget
| Name | Required | Description | Default |
|---|---|---|---|
| exchange | Yes | Exchange name. Options: binance, coinbase, kraken, bitflyer, gmo, bybit, okx, bitget |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It accurately conveys a read-only fetch operation scoped to an exchange, which is useful. But it does not disclose return shape, pagination, or exchange-specific caveats, though those are relatively minor for this simple tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one front-loaded sentence that immediately states the operation and scope, followed by a compact list of supported exchanges. There is no filler, vague phrasing, or unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only tool, the description covers purpose, scope, and valid exchange values. The only notable gap is the lack of an output schema or explicit statement of return format, but the phrase 'tradable pairs' makes the expected result type reasonably inferable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the only parameter, 'exchange', including the same list of supported values. The description adds no semantic information beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Fetch'), a clear resource ('all tradable pairs'), and the scope ('specified exchange'). It naturally distinguishes this tool from siblings like get_price, compare_prices, and get_top_ranking, which address different data needs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the intended use clear: fetch all pairs for a supported exchange, and the supported-exchange list adds context. However, it does not explicitly say when to prefer this over sibling tools or when it should not be used, so some routing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the current price of a specified cryptocurrency from each exchange. Examples: BTC, ETH, SOL, etc. Supported exchanges: binance, coinbase, kraken, bitflyer, gmo, bybit, okx, bitget
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Asset symbol (e.g., BTC, ETH, SOL) | |
| exchanges | No | List of exchanges to query. Defaults to all exchanges. Options: binance, coinbase, kraken, bitflyer, gmo, bybit, okx, bitget |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses that the tool fetches prices 'from each exchange' and enumerates supported exchanges, which is useful. It does not mention output format, failure behavior, rate limits, or how results are structured when multiple exchanges are queried.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is built from one action-first sentence plus compact, useful lists of examples and supported exchanges. There is no filler or redundant elaboration, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool, the description and schema together provide enough to call it correctly: the symbol is required, exchanges are optional, and supported options are listed. The lack of an output schema means return-value details are not fully specified, but the phrase 'current price... from each exchange' gives a sufficient mental model.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds examples like 'BTC, ETH, SOL' and repeats the exchange options, but these largely mirror the schema descriptions. It does not add new meaning around symbol normalization, quote currency, or exchange-specific quirks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Fetch the current price of a specified cryptocurrency from each exchange.' It clearly distinguishes get_price from siblings like get_top_ranking, compare_prices, and get_pairs by focusing on single-asset price lookup across exchanges.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage context: when you need a current price for a symbol like BTC or ETH, and it lists supported exchanges. However, it does not explicitly state when to prefer this over compare_prices or get_pairs, nor does it provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the 24-hour volume ranking for a specified exchange. Supported exchanges: binance, coinbase, kraken, bitflyer, gmo, bybit, okx, bitget
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results (default: 10, max: 50) | |
| exchange | Yes | Exchange name. Options: binance, coinbase, kraken, bitflyer, gmo, bybit, okx, bitget |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It adds the supported exchanges and the time window, but it does not explain the ordering of results, what fields are returned, how `limit` affects the response, or any rate-limit or error behavior. This is thin for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that names the resource, the required parameter, and the valid choices. Every word earns its place, and the supported exchanges list is immediately useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two parameters, but with no output schema and no annotations, the description does not fully clarify what the returned ranking looks like or whether it is sorted descending by volume. It is adequate for basic invocation but not entirely self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both `exchange` and `limit` clearly. The description mostly repeats the exchange options rather than adding new meaning, which matches the baseline score of 3 for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Fetch'), a concrete resource ('24-hour volume ranking'), and the target context ('for a specified exchange'). It is clearly distinguishable from sibling tools like get_price and compare_prices, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: whenever the 24-hour volume ranking for one of the supported exchanges is needed. However, it never explicitly contrasts it with get_price, compare_prices, or get_pairs, nor does it mention any exclusions or alternative conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0compare_pricesget_pairsget_priceget_top_rankingScored across 4 tools
Most tools are clearly distinct, but get_price and compare_prices overlap: both retrieve current prices, with compare_prices adding cross-exchange comparison and min/max output. The descriptions help clarify the difference, but an agent could still be uncertain which tool to use for a single-exchange price query.
Tool names mostly follow a get_ prefix pattern: get_top_ranking, get_price, get_pairs. compare_prices deviates slightly but is still readable and consistent with snake_case naming. Overall the pattern is predictable.
Four tools is well-scoped for a crypto price MCP server. Each tool covers a distinct core need: price lookup, price comparison, tradable pairs, and volume ranking, without unnecessary bloat.
The tool surface covers the primary price-checking workflow: retrieving prices, comparing prices across exchanges, discovering pairs, and checking volume rankings. Historical price data or market cap information would be nice additions, but their absence does not create a serious dead end for the stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Real-time crypto prices from Binance, Coinbase, Kraken, OKX, and Bybit
Provide real-time cryptocurrency price data and market analysis.
Live crypto prices, conversion, gas tracker, portfolio tools, and calculators for AI agents.
