Un servidor de Protocolo de Contexto de Modelo (MCP) que proporciona un análisis exhaustivo de criptomonedas mediante la API de CoinCap. Este servidor ofrece datos de precios en tiempo real, análisis de mercado y tendencias históricas mediante una interfaz intuitiva.
Esta es una bifurcación del proyecto original mcp-crypto-price de Tracey Russell
✅ Qué ha cambiado:
Actualizado para utilizar la API CoinCap v3 (ya que la v2 está siendo descontinuada).
Se planean mejoras y pruebas adicionales según el tiempo lo permita.
💡 Un agradecimiento especial a Coin Cap por su modelo de suscripción "stake-to-API", algo que espero que adopten más proveedores de API. ¡La fatiga por suscripciones es real!
Nota del paquete : Este proyecto está alojado en GitHub como
wazzan/mcp-coincap-jjpero publicado en npm como@bujaayjaay/mcp-coincap-jj
Related MCP server: Coin MCP Server
Si eres nuevo en los servidores MCP, esta guía proporciona instrucciones paso a paso para ayudarte a comenzar.
Probé esto en una máquina virtual con Windows 11 para evitar saturar mi Mac. ¡Funcionó perfectamente!
Ubicaciones de configuración del escritorio de Claude:
MacOS : ~/Library/Application Support/Claude/claude_desktop_config.json
Ventanas : %APPDATA%/Claude/claude_desktop_config.json
Guía de configuración de Windows (mismos pasos para cualquier cliente MCP)
Instalar Node.js: ( https://nodejs.org/es )
Instalar Claude Desktop
Configurar Claude Desktop:
Abra el menú de hamburguesa (esquina superior izquierda) → Archivo → Configuración → Desarrollador → Editar configuración
Esto abre la ubicación del archivo claude_desktop_config.json en el Explorador de Windows.
Edítelo con su editor favorito y agregue la siguiente configuración (¡asegúrese de incluir todas las llaves de cierre!):
Tenga en cuenta que puede utilizar estas mismas instrucciones para cualquier otro cliente MCP
{
"mcpServers": {
"mcp-coincap-jj": {
"command": "npx",
"args": [
"-y",
"@bujaayjaay/mcp-coincap-jj"
],
"env": {
"COINCAP_API_KEY": "INPUT_YOUR_API_KEY_HERE"
}
}
}
}Para desarrolladores y colaboradores que quieran trabajar en el proyecto localmente:
npm install @bujaayjaay/mcp-coincap-jjgit clone https://github.com/wazzan/mcp-coincap-jj.git
cd mcp-coincap-jj
npm install # Install dependencies
npm run build # Compile TypeScript code
npm test # Run tests to verify everything works
npm start # Starts the MCP server locallyConfiguración del servidor MCP para pruebas locales (ejemplo de Windows)
Si se ejecuta localmente con npx, use esta configuración en Claude Desktop (o cualquier cliente MCP):
{
"mcpServers": {
"mcp-coincap-jj": {
"command": "cmd.exe",
"args": [
"/c",
"C:\\Program Files\\nodejs\\npx.cmd",
"C:\\Users\\YOUR-WINDOWS-USERNAME\\repos\\github\\mcp-coincap-jj"
],
"env": {
"COINCAP_API_KEY": "YOUR_API_KEY_HERE"
},
"disabled": false,
"alwaysAllow": []
}
}
}🔧 Consejo profesional: el uso de rutas absolutas en Windows garantiza una experiencia fluida, especialmente al ejecutar múltiples entornos.
Si bien esto quita algo de la experiencia de aprendizaje personal, ¡es un excelente comienzo rápido!
Asegúrate de tener Smithery instalado para tu aplicación Claude Desktop
Ejecute el siguiente comando:
smithery install @bujaayjaay/mcp-coincap-jjSe le pedirá que ingrese su clave API de CoinCap durante la configuración
Ahora debe obtener una clave API de CoinCap para usar la API v3 actualizada, ya que la v2 está en desuso: ( https://pro.coincap.io/api-docs/ )
get-crypto-priceObtiene el precio actual y las estadísticas de 24 horas para cualquier criptomoneda, incluidas:
Precio actual en USD
Cambio de precio de 24 horas
Volumen de operaciones
capitalización de mercado
Clasificación en el mercado
get-market-analysisProporciona un análisis detallado del mercado que incluye:
Los 5 principales exchanges por volumen
Variaciones de precios entre bolsas
Análisis de distribución de volumen
VWAP (Precio promedio ponderado por volumen)
get-historical-analysisAnaliza datos de precios históricos con:
Intervalos de tiempo personalizables (de 5 minutos a 1 día)
Admite hasta 30 días de datos históricos
Análisis de tendencias de precios
Métricas de volatilidad
Rangos de precios altos/bajos
"¿Cuál es el precio actual de Bitcoin?"
"Muéstrame el análisis del mercado de ETH"
"Dame el historial de precios de DOGE de los últimos 7 días"
¿Cuáles son los principales exchanges que negocian BTC?
Muéstrame las tendencias de precios de SOL en intervalos de una hora.
Este proyecto es una bifurcación de mcp-crypto-price de Tracey Russell.
El proyecto de Tracey se inspiró en el proyecto coincap-mcp de Alex Andru.
Este proyecto está licenciado bajo la licencia MIT.
Get current price and 24h stats for a cryptocurrency
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Cryptocurrency symbol (e.g., BTC, ETH) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. Only states output is price and 24h stats, but omits details like update frequency, data source, or behavior on invalid symbol.
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?
Single sentence, no unnecessary words, front-loaded with verb and resource.
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 simple tool (1 param, no output schema, no annotations), description is adequate for basic understanding but lacks detail on what '24h stats' includes (e.g., change, volume).
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%, baseline 3. Description adds no extra detail beyond 'gets crypto price for given symbol'; schema already specifies symbol as string with examples.
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?
Description clearly states verb 'get', resource 'current price and 24h stats', and scope 'cryptocurrency'. Easily distinguished from siblings 'historical-analysis' and 'market-analysis'.
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?
No guidance on when to use this tool vs alternatives (e.g., for historical data use get-historical-analysis). No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get historical price analysis with customizable timeframe
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Cryptocurrency symbol (e.g., BTC, ETH) | |
| interval | No | Time interval (m5, m15, m30, h1, h2, h6, h12, d1) | h1 |
| days | No | Number of days to analyze (1-30) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose behavioral traits such as data source (e.g., real-time vs delayed), caching, rate limits, or whether the analysis includes derived metrics like moving averages.
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?
Single sentence, front-loaded with action and key qualifier. No wasted words, but could benefit from a second sentence to enhance completeness without harming conciseness.
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?
No output schema, so the agent cannot infer return format or fields. Description lacks details on data scope (e.g., OHLCV, volume) and pagination. Adequate for a simple analysis tool but incomplete.
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?
With 100% schema coverage, parameters are documented. The description adds 'customizable timeframe' but does not elaborate on default behavior or mutually exclusive options beyond schema.
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 retrieves historical price analysis with customizable timeframe. It distinguishes from 'get-crypto-price' (current price) and 'get-market-analysis' (broader market).
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?
No explicit guidance on when to use this tool versus siblings. The description does not specify context like trend analysis vs point-in-time price, nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed market analysis including top exchanges and volume distribution
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Cryptocurrency symbol (e.g., BTC, ETH) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It only mentions 'detailed' analysis without disclosing behavioral traits like rate limits, authentication needs, or mutability. The description adds minimal value beyond the tool name.
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 sentence long and front-loaded with the main purpose. It is efficient but could be slightly more informative without being verbose.
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 (one param, no output schema, no annotations), the description minimally covers purpose but lacks context on when to use or what to expect. It is adequate but not complete for an autonomous agent.
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 parameter 'symbol' is fully described in the schema with coverage at 100%. The description repeats 'e.g., BTC, ETH' which is already in the schema, adding no new semantic information. Baseline score of 3 is appropriate.
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 retrieves 'detailed market analysis' and specifies included data like 'top exchanges and volume distribution'. It distinguishes itself from siblings 'get-crypto-price' (price only) and 'get-historical-analysis' (historical data).
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 use for market analysis but does not explicitly state when to use it versus alternatives. No guidance on prerequisites or exclusions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct aspect: current price, historical analysis, and market analysis. No overlap in purpose.
All tools follow a consistent 'get-' prefix with snake_case descriptors, e.g., get-crypto-price, get-historical-analysis.
Three tools is an ideal size for a focused crypto data server, covering essential operations without bloat.
Covers current price, historical trends, and market depth. Minor gap: no tool to list supported cryptocurrencies, but core workflows are complete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Unlock the power of real-time cryptocurrency data with our Crypto Price Insights MCP server.
A Model Context Protocol (MCP) server for Selise Blocks Cloud integration
MCP server giving AI agents one-connection access to crypto & DeFi data: DeFi protocol TVL, stableco
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/wazzan/mcp-coincap-jj'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
