一个模型上下文协议 (MCP) 服务器，通过与主要交易所集成，提供实时和历史加密货币市场数据。该服务器使像 Claude 这样的法学硕士 (LLM) 能够获取当前价格、分析市场趋势并访问详细的交易信息。
实时市场数据
当前加密货币价格
包含买卖价差的市场摘要
按交易量排名的前几大交易对
多种交易所支持
历史分析
OHLCV（烛台）数据
价格变动统计
卷历史跟踪
可定制的时间范围
Exchange 支持
币安
Coinbase
海妖
库币
超液体
火币
Bitfinex
比特
OKX
墨西哥
Related MCP server: Crypto MCP Server
要通过Smithery自动为 Claude Desktop 安装加密货币市场数据服务器：
npx -y @smithery/cli install mcp-server-ccxt --client claude# Using uv (recommended)
uv pip install mcp ccxt
# Using pip
pip install mcp ccxtpython crypto_server.py打开您的 Claude Desktop 配置：
macOS： ~/Library/Application Support/Claude/claude_desktop_config.json
Windows： %APPDATA%\Claude\claude_desktop_config.json
添加服务器配置：
{
"mcpServers": {
"crypto": {
"command": "python",
"args": ["/path/to/crypto_server.py"]
}
}
}重启Claude桌面
获取价格
获取任何交易对的当前价格
例如：“币安上 BTC/USDT 的当前价格是多少？”
获取市场摘要
获取详细的市场信息
例如：“显示 ETH/USDT 的市场摘要”
获取最高音量
按交易量列出排名靠前的交易对
例如：“Kraken 上排名前 5 的交易对是什么？”
列表交换
显示所有支持的交易所
例如：“支持哪些交易所？”
获取历史 ohlcv
获取历史烛台数据
示例：“以 1 小时为间隔显示过去 7 天的 BTC/USDT 价格数据”
获取价格变化
计算不同时间段内的价格变化
例如：“SOL/USDT 的 24 小时价格变化是多少？”
获取卷历史记录
跟踪一段时间内的交易量
例如：“显示过去一周 ETH/USDT 的交易量历史记录”
以下是服务器连接后您可以向 Claude 询问的一些示例问题：
- What's the current Bitcoin price on Binance?
- Show me the top 5 trading pairs by volume on Coinbase
- How has ETH/USDT performed over the last 24 hours?
- Give me a detailed market summary for SOL/USDT on Kraken
- What's the trading volume history for BNB/USDT over the last week?mcp ：模型上下文协议 SDK
ccxt ：加密货币交易所交易库
Python 3.9 或更高版本
服务器使用：
CCXT 异步支持高效交易所通信
MCP 的 LLM 集成工具系统
标准化数据格式以实现一致的输出
连接池以实现最佳性能
服务器实现了强大的错误处理：
无效交易对
Exchange 连接问题
速率限制
格式错误的请求
网络超时
# To be implemented
pytest tests/分叉存储库
创建功能分支
进行更改
提交拉取请求
# Clone the repository
git clone [repository-url]
cd crypto-mcp-server
# Install dependencies
uv pip install -e .Exchange 连接错误
检查您的互联网连接
验证交易所是否正常运行
确保所选交易所存在该交易对
速率限制
在请求之间实现延迟
使用不同的交易所进行高频查询
检查交易所特定的汇率限制
数据格式问题
验证交易对格式（例如 BTC/USDT，而不是 BTCUSDT）
检查时间范围规范
确保数值参数在有效范围内
MIT 许可证 - 详情请参阅许可证文件
Get historical OHLCV (candlestick) data for a trading pair
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Trading pair symbol (e.g., BTC/USDT, ETH/USDT) | |
| timeframe | No | Timeframe for candlesticks (e.g., 1m, 5m, 15m, 1h, 4h, 1d) | 1h |
| days_back | No | Number of days of historical data to fetch (default: 7, max: 30) | |
| exchange | No | Exchange to use (supported: binance, coinbase, kraken, kucoin, hyperliquid, huobi, bitfinex, bybit, okx, mexc) | binance |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but lacks details on traits like rate limits, authentication needs, data freshness, or error handling. This is a significant gap for a data-fetching tool with multiple parameters.
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, efficient sentence that front-loads the core purpose without any wasted words. It's appropriately sized for the tool's complexity, making it easy to parse and understand quickly.
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?
Given the tool's moderate complexity (4 parameters, no output schema, no annotations), the description is minimally adequate. It states the purpose but lacks behavioral context and usage guidelines, which are important for an agent to invoke it correctly in a server with multiple market data tools.
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 description adds no parameter-specific information beyond what's in the input schema, which has 100% coverage with detailed descriptions, enums, defaults, and constraints. This meets the baseline score of 3, as the schema adequately documents the parameters without needing extra explanation in the description.
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 clearly states the verb ('Get') and resource ('historical OHLCV (candlestick) data for a trading pair'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get-price' or 'get-volume-history', which might also provide related market data, so it doesn't reach the highest score.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools or contexts where this tool is preferred, such as for chart analysis or historical trends, leaving the agent without explicit usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed market summary for a cryptocurrency pair from a specific exchange
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Trading pair symbol (e.g., BTC/USDT, ETH/USDT) | |
| exchange | No | Exchange to use (supported: binance, coinbase, kraken, kucoin, hyperliquid, huobi, bitfinex, bybit, okx, mexc) | binance |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but fails to describe key traits like whether it's a read-only operation, potential rate limits, authentication needs, error handling, or the format of the returned summary. This leaves significant gaps in understanding how the tool behaves beyond its basic function.
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, efficient sentence that directly states the tool's purpose without any unnecessary words or fluff. It is front-loaded and appropriately sized for its function, making it easy to understand quickly.
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?
Given the lack of annotations and output schema, the description is incomplete. It specifies the tool's function but omits critical details such as the structure of the returned market summary, potential side effects, or error conditions. For a tool with no structured behavioral data, this leaves too many unknowns for effective agent use.
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 has 100% description coverage, clearly documenting both parameters with examples and an enum for 'exchange'. The description adds no additional meaning beyond this, as it doesn't elaborate on parameter usage or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the schema adequately handles parameter semantics without extra description.
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 clearly states the action ('Get detailed market summary') and resource ('for a cryptocurrency pair from a specific exchange'), making the purpose unambiguous. However, it doesn't explicitly differentiate this tool from its siblings like 'get-price' or 'get-price-change', which might also provide market-related data for cryptocurrency pairs.
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 provides no guidance on when to use this tool versus alternatives such as 'get-price' or 'get-historical-ohlcv'. It mentions the resource but lacks explicit instructions on scenarios, prerequisites, or exclusions, leaving usage context implied rather than clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current price of a cryptocurrency pair from a specific exchange
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Trading pair symbol (e.g., BTC/USDT, ETH/USDT) | |
| exchange | No | Exchange to use (supported: binance, coinbase, kraken, kucoin, hyperliquid, huobi, bitfinex, bybit, okx, mexc) | binance |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'current price' and 'specific exchange' but fails to address critical aspects like rate limits, error handling, authentication needs, or response format. For a real-time data tool, this leaves significant behavioral gaps.
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, efficient sentence that front-loads the core purpose without unnecessary elaboration. Every word contributes directly to understanding the tool's function, making it highly concise and well-structured.
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?
Given the lack of annotations and output schema, the description is incomplete for a real-time data tool. It omits details on return values (e.g., price format, timestamp), error conditions, or performance considerations, which are essential for effective agent use in a financial context.
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 schema description coverage is 100%, with both parameters (symbol and exchange) fully documented in the schema. The description adds no additional semantic context beyond what the schema provides, such as examples of valid symbols beyond BTC/USDT or implications of exchange selection. Baseline 3 is appropriate when the schema does the heavy lifting.
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 clearly states the specific action ('Get current price') and resource ('cryptocurrency pair from a specific exchange'), distinguishing it from siblings like get-historical-ohlcv (historical data) and get-market-summary (broader market info). It precisely defines the tool's scope without ambiguity.
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 usage for real-time price queries but provides no explicit guidance on when to use this tool versus alternatives like get-price-change (for price changes) or get-historical-ohlcv (for historical data). It lacks context on prerequisites or exclusions, leaving usage decisions to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get price change statistics over different time periods
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Trading pair symbol (e.g., BTC/USDT, ETH/USDT) | |
| exchange | No | Exchange to use (supported: binance, coinbase, kraken, kucoin, hyperliquid, huobi, bitfinex, bybit, okx, mexc) | binance |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'price change statistics' but doesn't specify what statistics are included (e.g., percentage change, absolute values), time periods available, or any limitations like rate limits or data freshness. This leaves significant gaps in understanding the tool's behavior beyond basic functionality.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse quickly, and every part of the sentence contributes to understanding the tool's function.
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?
Given the lack of annotations and output schema, the description is incomplete for a tool that likely returns complex statistical data. It doesn't explain what 'price change statistics' entail, the available time periods, or the format of the response, leaving the agent with insufficient context to use the tool effectively without trial and error.
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 has 100% description coverage, with clear documentation for both parameters, including an enum for 'exchange' and a default value. The description adds no additional parameter semantics beyond what the schema provides, such as explaining how 'symbol' interacts with 'exchange' or detailing time period options. This meets the baseline for high 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 clearly states the tool's purpose as 'Get price change statistics over different time periods,' which specifies the action (get) and resource (price change statistics) with a time dimension. However, it doesn't explicitly distinguish this from sibling tools like 'get-price' or 'get-historical-ohlcv,' which might provide overlapping or related data, leaving some ambiguity about its unique role.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get-price' or 'get-historical-ohlcv,' nor does it specify scenarios or exclusions for its use, leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get top cryptocurrencies by trading volume from a specific exchange
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of pairs to return (default: 5) | |
| exchange | No | Exchange to use (supported: binance, coinbase, kraken, kucoin, hyperliquid, huobi, bitfinex, bybit, okx, mexc) | binance |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool retrieves data ('Get top cryptocurrencies'), implying a read-only operation, but doesn't specify whether it's real-time or cached, rate limits, authentication needs, or what happens if the exchange is unavailable. This leaves significant gaps for a data-fetching 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, efficient sentence that directly states the tool's purpose without any unnecessary words. It's front-loaded and wastes no space, making it highly concise and well-structured.
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?
Given the tool's moderate complexity (fetching ranked data from exchanges), no annotations, and no output schema, the description is minimally adequate. It specifies the resource and scope but lacks details on behavior, output format, or error handling, leaving room for improvement in completeness.
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 has 100% description coverage, with clear documentation for both parameters (limit and exchange), including defaults and enum values. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline score of 3.
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 clearly states the action ('Get top cryptocurrencies by trading volume') and resource ('from a specific exchange'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get-volume-history' or 'get-market-summary', which might also involve volume data, so it doesn't reach the highest score.
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 provides no guidance on when to use this tool versus alternatives like 'get-volume-history' or 'get-market-summary', nor does it mention prerequisites or exclusions. It only states what the tool does without contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get trading volume history over time
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Trading pair symbol (e.g., BTC/USDT, ETH/USDT) | |
| days | No | Number of days of volume history (default: 7, max: 30) | |
| exchange | No | Exchange to use (supported: binance, coinbase, kraken, kucoin, hyperliquid, huobi, bitfinex, bybit, okx, mexc) | binance |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves historical data, implying it's read-only, but doesn't mention rate limits, authentication needs, data freshness, or what the output looks like (e.g., format, units). This is a significant gap for a tool with no annotation coverage.
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, efficient sentence that front-loads the core purpose without any wasted words. It's appropriately sized for a straightforward data retrieval tool, making it easy for an agent to parse quickly.
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?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the returned volume history includes (e.g., time intervals, data format) or address potential complexities like handling missing data. For a tool with three parameters and no structured output information, more context is needed.
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 description adds no parameter-specific information beyond what's already in the input schema, which has 100% coverage with detailed descriptions for all three parameters. The baseline score of 3 is appropriate since the schema does the heavy lifting, but the description doesn't compensate or provide additional context.
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 clearly states the tool's purpose with a specific verb ('Get') and resource ('trading volume history over time'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get-historical-ohlcv' or 'get-top-volumes', which might also provide volume-related data, so it doesn't reach the highest score.
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 provides no guidance on when to use this tool versus alternatives like 'get-historical-ohlcv' or 'get-top-volumes'. It lacks context on use cases, prerequisites, or exclusions, leaving the agent to infer usage based on the name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all supported cryptocurrency exchanges
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 states the action ('List') but doesn't describe traits like whether the list is static or dynamic, if it requires authentication, rate limits, or the format of the returned data. This leaves significant gaps for a tool with no structured safety hints.
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, efficient sentence that directly states the tool's purpose without any waste. It's front-loaded and appropriately sized for a simple list operation, making it easy to parse quickly.
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?
Given the tool's simplicity (0 parameters, no output schema), the description is adequate as a basic overview. However, with no annotations and siblings that might overlap, it lacks completeness in usage guidance and behavioral context, making it only minimally viable.
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 tool has 0 parameters, and schema description coverage is 100%, so there's no need for parameter details in the description. The description correctly avoids redundant information, earning a high score for not cluttering with unnecessary param semantics.
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 clearly states the action ('List') and resource ('all supported cryptocurrency exchanges'), making the purpose immediately understandable. It doesn't differentiate from sibling tools like 'get-market-summary' or 'get-top-volumes', which might provide overlapping or related exchange data, so it doesn't reach a perfect score.
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 provides no guidance on when to use this tool versus alternatives. For example, it doesn't specify if this is for a basic list, if siblings like 'get-market-summary' offer more detailed exchange info, or if it's the starting point for exchange selection. Without such context, usage is unclear.
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.
get-historical-ohlcvget-market-summaryget-priceget-price-changeget-top-volumesget-volume-historylist-exchangesScored across 7 tools
Each tool has a clearly distinct purpose with no ambiguity: get-historical-ohlcv for candlestick data, get-market-summary for detailed pair info, get-price for current price, get-price-change for statistics, get-top-volumes for volume rankings, get-volume-history for volume trends, and list-exchanges for exchange listing. The descriptions precisely differentiate their functions, making misselection unlikely.
All tool names follow a consistent verb_noun pattern using kebab-case (e.g., get-historical-ohlcv, list-exchanges). The naming is predictable and readable throughout, with 'get-' or 'list-' prefixes clearly indicating the action, ensuring a uniform and professional appearance.
With 7 tools, the server is well-scoped for cryptocurrency market data, covering key areas like pricing, volume, exchanges, and historical data. Each tool earns its place by addressing specific market analysis needs, avoiding bloat while providing comprehensive coverage for the domain.
The tool set offers strong coverage for cryptocurrency market data, including price, volume, historical data, and exchange info. Minor gaps exist, such as no tools for order book depth, trade history, or market sentiment, but agents can work around these with the provided tools for core market analysis tasks.
Unlock the power of real-time cryptocurrency data with our Crypto Price Insights MCP server.
Financial data MCP server for Claude, ChatGPT, Cursor and Codex. Real-time stock quotes, financial statements, options flow, SEC filings, insider trades, 13F holdings, macro data and market news from gloom.sh, the open-source Bloomberg Terminal alternative.
MCP server giving AI agents one-connection access to crypto & DeFi data: DeFi protocol TVL, stableco
Crypto trading intelligence MCP — 34+ endpoints, x402 pay-per-use, AI agent strategy & execution
