주요 거래소와의 통합을 통해 실시간 및 과거 암호화폐 시장 데이터를 제공하는 모델 컨텍스트 프로토콜(MCP) 서버입니다. 이 서버를 통해 클로드와 같은 LLM은 현재 가격을 확인하고, 시장 동향을 분석하고, 자세한 거래 정보에 접근할 수 있습니다.
실시간 시장 데이터
현재 암호화폐 가격
매수/매도 스프레드가 포함된 시장 요약
거래량 기준 상위 거래 쌍
다중 거래소 지원
역사적 분석
OHLCV(캔들스틱) 데이터
가격 변화 통계
볼륨 내역 추적
사용자 정의 가능한 시간 프레임
교환 지원
바이낸스
코인베이스
크라켄
쿠코인
하이퍼리퀴드
후오비
비트파이넥스
바이비트
오케이엑스
멕시코
Related MCP server: Crypto MCP Server
Smithery를 통해 Claude Desktop용 Cryptocurrency Market Data Server를 자동으로 설치하려면:
지엑스피1
# Using uv (recommended)
uv pip install mcp ccxt
# Using pip
pip install mcp ccxtpython crypto_server.pyClaude 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 Desktop을 다시 시작하세요
가격 받기
모든 거래 쌍의 현재 가격을 확인하세요
예: "바이낸스에서 BTC/USDT의 현재 가격은 얼마인가요?"
get-market-summary
자세한 시장 정보를 가져옵니다
예: "ETH/USDT에 대한 시장 요약을 보여주세요"
최고 볼륨 얻기
거래량별 상위 거래 쌍 목록
예: "Kraken에서 가장 인기 있는 거래 쌍 5개는 무엇입니까?"
목록 교환
지원되는 모든 거래소 표시
예: "어떤 거래소가 지원되나요?"
get-historical-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 : 암호화폐 거래소 거래 라이브러리
파이썬 3.9 이상
서버는 다음을 사용합니다.
효율적인 교환 통신을 위한 CCXT의 비동기 지원
LLM 통합을 위한 MCP 도구 시스템
일관된 출력을 위한 표준화된 데이터 형식
최적의 성능을 위한 연결 풀링
서버는 다음에 대해 강력한 오류 처리를 구현합니다.
유효하지 않은 거래 쌍
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 라이선스 - 자세한 내용은 라이선스 파일을 참조하세요.
거래소 통합을 위한 CCXT
MCP 사양을 위한 모델 컨텍스트 프로토콜
시장 데이터 API를 제공하는 암호화폐 거래소
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
