Provides signed, verifiable crypto market analysis for Bitcoin via CryptoCapi tools such as get_insight, including pulse/alpha views and Quant Plus reproducible signals; batch_signals also supports Bitcoin.
Provides signed, verifiable crypto market analysis for Ethereum via CryptoCapi tools such as get_insight, including pulse/alpha views and Quant Plus reproducible signals; batch_signals also supports Ethereum.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@CryptoCapi give me the signed insight for Bitcoin"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Sin cuenta, sin registrarte, sin clave. Va en el archivo de configuración de tu cliente MCP:
{
"mcpServers": {
"cryptocapi": {
"command": "npx",
"args": ["-y", "@cryptocapi/mcp"]
}
}
}Con eso ya podés preguntarle a tu agente por Bitcoin o Ethereum y recibir el análisis firmado por los dos motores que lo firman. El detalle de hasta dónde llega la demo está más abajo.
Related MCP server: carbon-cashmere-mcp
Herramienta | Motor | Qué devuelve | Qué requiere |
| Radar | Análisis de un activo. La vista |
|
| Quant Plus | El mismo activo firmado por el motor determinista, con sello | Pase Quant Plus |
| Quant Plus | Señales de varios activos en una llamada | Pase Quant Plus |
| Quant Pro | Señal cuantitativa de un par de trading | Pase Quant Pro |
| Market Scan (capa de ranking) | Ranking del mercado según una estrategia | Pase Market Scan |
Son cinco filas para cuatro herramientas porque get_insight es la puerta de dos motores, y cada uno pide su propio pase. Tener Radar Alpha no abre Quant Plus por ese mismo tool: cambia el parámetro engine y cambia el pase que se exige.
Market Scan no es un cuarto motor. No calcula señales propias: ordena el mercado sobre las señales de Quant Plus. Se vende aparte porque es otro producto.
Hasta el 2026-08-30 había tres herramientas más (get_market_summary, get_prices, get_macro) que devolvían dato de terceros: capitalización y miedo y codicia, precios de CoinGecko y series macro de FRED. Se retiraron porque CryptoCapi no es un agregador: sus motores firman inteligencia derivada y el dato ajeno es insumo interno. Un agente que preguntaba «¿cómo está el mercado?» agarraba el resumen y se iba con dato de terceros sin tocar un motor. Esos endpoints siguen existiendo en la API REST; lo que se retiró es que el agente los vea como herramientas.
Cada motor se compra por separado, así que tener uno no habilita los otros. Las descripciones nombran el motor que hace falta, no un «PRO» genérico, para que el agente no gaste intentos en herramientas que su clave no abre. Cuando igual las intenta, el error le dice qué pase falta y cuál sí tiene, en vez de un 403 pelado.
Ojo con un detalle de formato que hace fallar a los agentes: get_signal toma un par de trading (BTCUSDT) y batch_signals toma identificadores de moneda (bitcoin). Es el mismo motor con dos formatos, y cada campo lo aclara en su esquema.
La configuración por defecto usa la key pública de demostración. No hace falta cuenta.
{
"mcpServers": {
"cryptocapi": {
"command": "npx",
"args": ["-y", "@cryptocapi/mcp"],
"env": { "CRYPTOCAPI_API_KEY": "demo_btc_eth_public" }
}
}
}La env es opcional: sin ninguna variable el paquete cae solo en la key pública de demostración, así que alcanza con command y args.
Qué alcanza con la demo key, medido el 2026-08-30 contra la versión publicada:
Motor | Herramienta | Con la demo key |
Radar |
| ✅ solo bitcoin y ethereum, siempre en vista |
Quant Plus |
| ✅ solo bitcoin y ethereum, sello reproducible con |
Quant Plus |
| ✅ solo bitcoin y ethereum, mismo alcance que |
Quant Pro |
| ❌ cerrado, para cualquier par |
Market Scan |
| ❌ cerrado, para cualquier estrategia |
Las tres cerradas no fallan por la moneda, fallan siempre: get_signal con BTCUSDT, que es el par de Bitcoin, también devuelve 403. La restricción a bitcoin y ethereum aplica a get_insight y nada más.
O sea que en la primera sesión responde una de las cuatro herramientas, y es la que muestra el producto: el análisis firmado, sobre Bitcoin, con los dos motores que lo firman.
Para probar los tres motores y Market Scan sin límite de moneda hace falta el trial de 14 días, gratis, en https://cryptocapi.com. Esa key abre todo mientras dura.
La respuesta de los motores viaja con un audit_trail que incluye un protocol_hash: un sello del cálculo determinista que produjo el análisis. Este paquete reenvía esos valores tal como llegaron de la API, sin volver a serializarlos, porque reformatear un solo número bastaría para que el hash dejara de verificar.
No hace falta creernos: pedile a tu agente el análisis con get_insight(coin_id="bitcoin", view="alpha") y compará el protocol_hash de esa salida con el de la misma consulta hecha directo contra la API.
curl -H "x-api-key: demo_btc_eth_public" \
"https://api.cryptocapi.com/v1/market/insights/bitcoin?view=alpha"Tienen que ser idénticos. Si algún día no lo son, es un fallo de este paquete y merece un issue.
El límite, dicho también: el sello prueba que el cálculo es reproducible y que no lo escribió un modelo de lenguaje. No prueba que el análisis acierte, y hoy es un checksum sin firma criptográfica, así que acredita integridad, no origen.
El sello cubre los datos. Que el tarball que te bajás sea el que salió de este código lo cubre otra cosa: se publica desde CI con procedencia de npm, así que cada versión queda ligada al commit y al workflow que la construyeron.
npm audit signaturesEn la página del paquete en npm aparece además el enlace al commit exacto. Es el mismo principio que el protocol_hash, aplicado a la cadena de suministro en vez de a los datos: no hace falta creernos, se comprueba.
Variable | Para qué | Por defecto |
| Tu API key |
|
| Base de la API, para desarrollo |
|
| Presupuesto por request, en ms. Ver abajo | según la herramienta |
El presupuesto de tiempo no es uno solo. Cada herramienta pide el suyo, porque
no cuestan lo mismo: 20 s para un motor sobre un activo (get_insight,
get_signal) y 45 s para los que recorren varios (batch_signals, scan_market).
Cortar un recorrido del mercado con el presupuesto de una lectura da un timeout
falso, y el agente concluye que la API está caída cuando en realidad estaba
trabajando.
CRYPTOCAPI_TIMEOUT_MS reemplaza esos presupuestos, no se suma a ellos: el
número que pongas rige para las cuatro herramientas. Ponerlo en 30000 para
darle más aire a scan_market en realidad se lo recorta, de 45 s a 30. Si se toca,
conviene que sea por encima del más alto.
Cuando una herramienta se corta, el error dice el presupuesto que efectivamente rigió, así que ese número es el que hay que superar.
Conseguir una key con prueba de 14 días: cryptocapi.com
npm install
npm run check # tipos + tests + auditoría de dependencias
npm run contrato # verifica contra la API real que el contrato copiado sigue vigenteLos tests corren con el runner nativo de Node y no tienen una sola dependencia de test ni tocan la red: la API se levanta falsa con node:http. Prueban el paquete, no el servicio, que es lo que los hace rápidos y estables.
Ese runner carga TypeScript sin transpilar, así que para desarrollar hace falta
Node 22.18 o superior, aunque el paquete publicado corra en 20: es lo que
declara engines, y lo que el CI verifica arrancando el artefacto construido en
20, 22 y 24. Es un requisito de desarrollo, no de uso.
Eso deja afuera a propósito una mitad: si el paquete publicado se porta bien contra la API real y dentro de un agente. Para eso está PRUEBAS.md, catorce comprobaciones manuales que se corren después de cada release.
npm run contrato cubre una parte de esa mitad sin intervención humana. Los tests
no tocan la red a propósito, y ese aislamiento tiene un punto ciego: en septiembre
de 2026 se encontraron cuatro bugs y tres eran sobre qué manda la API de verdad
contra qué asumía el paquete, invisibles para un servidor falso que solo devuelve
lo que el test escribió. El chequeo de contrato mira justo eso, corre solo una vez
por día y abre un issue si algo se movió.
Lo que se encontró y todavía no se arregló vive en PENDIENTES.md, con el porqué de cada cosa y lo suficiente para retomarla sin volver a investigarla.
Se dispara con un tag y publica desde CI con procedencia, en npm y en el MCP Registry:
npm version <patch|minor|major> # subir también las dos versiones de server.json, y commitear
git tag -a vX.Y.Z -m "vX.Y.Z" && git push origin vX.Y.ZEl workflow comprueba primero que el tag coincida con la versión del package.json y con las dos de server.json, porque en npm una versión no se puede reusar y ese error no se deshace. La autenticación es trusted publishing por OIDC, sin token: está atada al nombre de release.yml, así que renombrar ese archivo rompe la publicación.
Con npm arriba, un segundo job le manda el server.json al Registry, también por OIDC. Va aparte para que, si el Registry falla, «Re-run failed jobs» reintente solo eso sin volver a pasar por npm publish.
Para el servidor, npm version es la única fuente de la versión: lee el package.json publicado para declarar su serverInfo.version, y un test del handshake falla si los dos números se separan. El único literal a mano es el de server.json, y si queda atrás el tag no pasa la primera comprobación.
Desde la 1.0.0 el paquete sigue semver. El contrato son las cuatro herramientas, sus parámetros y la forma de sus respuestas:
Parche (1.0.x): arreglos y textos. Las herramientas y sus parámetros quedan iguales.
Menor (1.x.0): lo nuevo que no rompe nada, como una herramienta o un parámetro opcional más.
Mayor (2.0.0): sacar o renombrar una herramienta, o cambiar un parámetro que ya existe. Si alguna vez hace falta, se avisa antes.
Las respuestas viajan tal cual las sirve la API, así que un campo nuevo puede aparecer en ellas sin una versión nueva del paquete.
Señales de Quant Plus para varios activos en una sola llamada. Requiere el pase Quant Plus, con una excepción: con la key pública de demostración funciona para bitcoin y ethereum, igual que get_insight. Ojo con el formato: acá van identificadores de moneda ("bitcoin"), no pares de trading, al revés que en get_signal. Solo un universo curado tiene señal, bastante más chico que el conjunto de activos que CryptoCapi sigue: un activo fuera de él vuelve con available: false, y eso es la respuesta correcta, no un error.
| Name | Required | Description | Default |
|---|---|---|---|
| symbols | Yes | Identificadores de moneda, de 1 a 50: ["bitcoin", "ethereum"]. El tope de 50 es del pedido, no de las señales disponibles. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the read-only/idempotent annotations by disclosing the auth model, the demo-key exception, and — critically — that only a curated universe yields signals and out-of-universe assets return `available: false` as a correct response rather than an error. That is exactly the behavioral context an agent needs to avoid misreading a legitimate result as failure.
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?
Five tight sentences, purpose first, then auth, then input format, then output semantics. Every sentence carries distinct information with no repetition or filler.
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?
With no output schema, the description compensates by explaining the `available: false` return case and framing it as expected. Auth, format, and edge-case behavior are all covered for a one-parameter batch tool.
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 coverage is 100%, so the baseline is 3, but the description adds real meaning: coin identifiers like "bitcoin", not trading pairs, explicitly contrasting the convention with get_signal. It also clarifies that the 50-item cap is a request limit, not a limit on available signals.
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?
Opens with a specific verb+resource+scope: 'Señales de Quant Plus para varios activos en una sola llamada.' It is immediately distinguishable from get_signal and get_insight, and the batched nature of the call is stated up front.
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?
Explicitly states the prerequisite (Quant Plus pass) and a documented exception (demo public key works for bitcoin/ethereum, same as get_insight), and names get_signal as the contrasting tool whose input format differs. This is when-to-use plus when-not guidance, including alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Análisis de un activo con el motor determinista de CryptoCapi. La vista "pulse" no exige pase con una key del plan free. La vista "alpha" trae el análisis profundo con el audit_trail y su protocol_hash, que es el sello del cálculo, y requiere el pase Radar Alpha (o Quant Plus si se pide engine="quant_plus"). Con la key pública de demostración, que es la que se usa si no se configura otra, solo responden bitcoin y ethereum, en cualquier vista, y la respuesta es siempre la alpha: otra moneda da 403 aunque se pida "pulse". Al leer la respuesta: z_score mide el MOVIMIENTO del último día cerrado (UTC), no el del día en curso, contra los movimientos pasados, y la posición en Bandas de Bollinger mide el NIVEL de precio contra su rango. Son ejes distintos: precio en el tercio superior con z_score negativo no es una contradicción, es un nivel alto después de un día que cerró con una caída fuerte. No las mezcles en una sola frase. Las stablecoins se leen por la distancia de su último cierre al dólar, no por el z_score. Si la moneda todavía no tiene análisis, la respuesta es {"status":"success","data":null}: no es un error ni un fallo de la consulta, es que ningún motor calculó nada para ese activo. Decilo así, «no hay análisis disponible», y no completes el hueco por tu cuenta.
| Name | Required | Description | Default |
|---|---|---|---|
| view | No | "pulse" no exige pase con una key free; "alpha" trae el sello y requiere pase. Con la key de demostración la respuesta es siempre alpha. Por defecto "pulse". | |
| engine | No | Motor que firma el análisis. Por defecto "radar". | |
| coin_id | Yes | Identificador de la moneda, en minúsculas: "bitcoin", "ethereum", "solana". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (read-only, idempotent, non-destructive, open-world), yet the description adds substantial context beyond them: demo-key 403 behavior for non-BTC/ETH coins, the fact that demo responses are always alpha, and the exact empty-result envelope semantics. This is exactly the kind of auth/error/result behavior the description should carry.
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?
Dense but front-loaded: purpose first, then access rules, then response interpretation. It is on the long side for a 3-param read tool and slightly re-states the view/engine access rules already in the schema, but nearly every sentence carries usable information, so little is wasted.
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?
With no output schema, the description correctly shoulders the burden of explaining the return values — audit_trail, protocol_hash, z_score vs Bollinger-band semantics, stablecoin reading, and the {status:success, data:null} empty case. An agent has everything needed to call and interpret the result without guessing.
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 coverage is 100%, so 3 is the baseline, but the description adds meaning the schema does not fully carry — the demo key forces an alpha response in any view, and unknown coins 403 even when pulse is requested. That interaction between view and key state goes beyond the enum descriptions.
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?
States a specific verb and resource — deep deterministic analysis of a single asset via CryptoCapi's engine, with the two views (pulse/alpha) named. It is clear what the tool does, but it never distinguishes itself from siblings like get_signal or scan_market, leaving the agent to infer which analysis surface to pick.
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?
Gives concrete conditional guidance: pulse needs no paid pass, alpha requires the Radar Alpha (or Quant Plus with engine="quant_plus") pass, and the demo key path. It stops short of naming alternatives or stating when to prefer this over get_signal, so context is clear but exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Señal cuantitativa para un par de trading. Requiere el pase Quant Pro: ningún otro motor lo habilita. Ojo con el formato, que no es el mismo que en las otras herramientas: acá va el par ("BTCUSDT"), no el identificador de moneda ("bitcoin").
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Par de trading, por ejemplo "BTCUSDT" o "ETHUSDT". No "bitcoin". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, openWorld and non-destructive behavior, so the safety profile is covered. The description adds genuinely new behavioral context: an authorization prerequisite (Quant Pro pass) and a cross-tool input-format quirk, which the annotations cannot convey.
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?
Three short sentences, front-loaded with the purpose and then the access requirement. It is slightly redundant with the schema's own format warning, which is the only waste.
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?
Low complexity (one required parameter), rich annotations, and the description covers the auth gate and the input-format pitfall. With no output schema the description does not say what a 'quantitative signal' contains, which is the only notable gap.
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 coverage is 100% and the schema itself already documents the symbol format with examples ('BTCUSDT', not 'bitcoin'). The description mostly restates that same constraint, adding only the framing that this differs from other tools, so the baseline 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 states a specific verb+resource: it returns a quantitative signal for a trading pair, which is clearly distinguishable in kind from batch_signals and scan_market. It does not explicitly name a sibling or state which one to prefer, so it stops short of full differentiation.
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?
It gives one real usage condition (the Quant Pro pass is required and no other engine enables it) and warns about the input format. However, it never says when to choose this over get_insight, batch_signals, or scan_market, so the routing guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recorre el mercado y devuelve los activos mejor rankeados según una estrategia. Requiere el pase Market Scan, que se vende aparte de Quant Plus aunque el ranking se arme sobre sus señales. El ranking cubre el universo curado de Quant Plus, bastante más chico que el conjunto de activos que CryptoCapi sigue, así que pedir 50 puede devolver bastante menos. Eso no es un fallo.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Cuántos activos devolver, de 1 a 50. Por defecto 10. Es un techo del pedido: si el universo rankeado es menor, vuelven menos. | |
| strategy | No | Perfil del ranking. Por defecto "balanced". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent, openWorld and non-destructive. Beyond that, the description discloses a paid-access requirement and the crucial caveat that the ranked universe is smaller than the broader asset set, so fewer than `limit` items may return and that is not an error. This is real behavioral value not present in the structured fields.
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?
Three tightly packed sentences: purpose first, then the access prerequisite, then the result-count caveat. No filler, and the most decision-relevant information is front-loaded.
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?
With no output schema, the description still conveys what comes back (a ranked asset list) and the count caveat, plus the access requirement. It stops short of describing the shape/fields of each ranked asset, which is the one remaining gap for a no-output-schema tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented, including the 'limit as a ceiling' behavior and the default strategy. The description largely restates the universe caveat rather than adding new parameter semantics, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete verb and resource: scans the market and returns assets ranked by a strategy. The scope (curated Quant Plus universe) makes it clearly distinct from the signal/insight siblings, but it never explicitly names or contrasts those alternatives.
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?
It gives a gating prerequisite (the Market Scan pass is required and sold separately) but never states when to choose this over get_signal, batch_signals, or get_insight. Usage is implied by the ranking scope rather than spelled out.
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.
v1.0.0batch_signalsget_insightget_signalscan_marketScored across 4 tools
The four tools target distinguishable operations: single-asset insight, single-pair signal, multi-asset signals, and market ranking. However, get_signal, batch_signals, and scan_market all revolve around quantitative signals and require different passes, which creates mild overlap an agent could mix up. The descriptions clarify input formats (pair vs. coin id) and pass requirements, mitigating most confusion.
Names mostly follow a verb_noun pattern (get_insight, get_signal, batch_signals, scan_market) in consistent snake_case. The deviation is that similar operations use different leading verbs (get_ vs. batch_ vs. scan_), but the style is otherwise predictable.
Four tools is slightly thin but reasonable for a read-only analytics/market-data API. Each tool maps to a distinct product tier (Insight, Quant Pro, Quant Plus, Market Scan), so none feel redundant. A couple more lifecycle helpers could round it out, but nothing is bloated.
As a read-only crypto analytics surface, it covers single-asset analysis, single-pair signals, batch signals, and market scanning, which is good lifecycle coverage for queries. No obvious query gaps for the stated purpose, though discoverability of the curated universe is left implicit.
Pay-per-call DeFi and macro intel for AI agents. x402 USDC tools via streamable HTTP /api/mcp.
Crypto trading intelligence MCP — 34+ endpoints, x402 pay-per-use, AI agent strategy & execution
Crypto MCP with 21 tools for market data, DeFi, analytics, and sentiment. Post-paid USDC billing.
Agent-native crypto market-data over MCP+REST: order flow, whales, liquidations, calibrated scores
