Un servidor de Protocolo de Contexto de Modelo (MCP) que proporciona datos históricos y en tiempo real del mercado de criptomonedas mediante la integración con las principales plataformas de intercambio. Este servidor permite a los LLM como Claude consultar precios actuales, analizar tendencias del mercado y acceder a información detallada sobre las operaciones.
Datos de mercado en tiempo real
Precios actuales de las criptomonedas
Resúmenes de mercado con diferenciales de oferta y demanda
Principales pares de trading por volumen
Soporte para múltiples intercambios
Análisis histórico
Datos de OHLCV (velas japonesas)
Estadísticas de cambios de precios
Seguimiento del historial de volumen
Marcos de tiempo personalizables
Soporte de Exchange
Binance
Coinbase
Kraken
KuCoin
Hiperlíquido
Huobi
Bitfinex
Bybit
OKX
MEXC
Related MCP server: Crypto MCP Server
Para instalar Cryptocurrency Market Data Server para Claude Desktop automáticamente a través de Smithery :
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.pyAbra la configuración de Claude Desktop en:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Ventanas: %APPDATA%\Claude\claude_desktop_config.json
Agregue la configuración del servidor:
{
"mcpServers": {
"crypto": {
"command": "python",
"args": ["/path/to/crypto_server.py"]
}
}
}Reiniciar Claude Desktop
obtener precio
Obtenga el precio actual de cualquier par comercial
Ejemplo: "¿Cuál es el precio actual de BTC/USDT en Binance?"
obtener resumen del mercado
Obtenga información detallada del mercado
Ejemplo: "Muéstrame un resumen del mercado de ETH/USDT"
obtener los máximos volúmenes
Lista de los principales pares comerciales por volumen
Ejemplo: "¿Cuáles son los 5 pares comerciales principales en Kraken?"
intercambios de listas
Mostrar todos los intercambios admitidos
Ejemplo: "¿Qué intercambios son compatibles?"
obtener-histórico-ohlcv
Obtener datos históricos de velas
Ejemplo: "Muéstrame los datos del precio de BTC/USDT de los últimos 7 días en intervalos de 1 hora"
obtener cambio de precio
Calcular cambios de precios en diferentes períodos de tiempo
Ejemplo: "¿Cuál es el cambio de precio de SOL/USDT en 24 horas?"
obtener historial de volumen
Seguimiento del volumen de operaciones a lo largo del tiempo
Ejemplo: "Muéstrame el historial del volumen de operaciones de ETH/USDT durante la última semana"
Aquí hay algunos ejemplos de preguntas que puedes hacerle a Claude una vez que el servidor esté conectado:
- 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 de protocolo de contexto de modelo
ccxt : Biblioteca de intercambio de criptomonedas
Python 3.9 o superior
El servidor utiliza:
Soporte asíncrono de CCXT para una comunicación de intercambio eficiente
Sistema de herramientas de MCP para la integración de LLM
Formato de datos estandarizado para obtener resultados consistentes
Agrupación de conexiones para un rendimiento óptimo
El servidor implementa un manejo robusto de errores para:
Pares comerciales no válidos
Problemas de conectividad de Exchange
Limitación de velocidad
Solicitudes malformadas
Tiempos de espera de la red
# To be implemented
pytest tests/Bifurcar el repositorio
Crear una rama de características
Realiza tus cambios
Enviar una solicitud de extracción
# Clone the repository
git clone [repository-url]
cd crypto-mcp-server
# Install dependencies
uv pip install -e .Errores de conexión de Exchange
Comprueba tu conexión a Internet
Verificar que el intercambio esté operativo
Asegúrese de que el par comercial exista en el intercambio seleccionado
Limitación de velocidad
Implementar retrasos entre solicitudes
Utilice diferentes intercambios para consultas de alta frecuencia
Consulte los límites de tipos de cambio específicos del cambio
Problemas de formato de datos
Verificar el formato del par comercial (por ejemplo, BTC/USDT, no BTCUSDT)
Consultar las especificaciones del plazo
Asegúrese de que los parámetros numéricos estén dentro de rangos válidos
Licencia MIT: consulte el archivo LICENCIA para obtener más detalles
CCXT para integraciones de intercambio
Protocolo de contexto de modelo para la especificación MCP
Los intercambios de criptomonedas para proporcionar API de datos de mercado
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
