Skip to main content
Glama
enesjakozh
AbdelStark

Bitcoin MCP Server

by AbdelStark
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Servidor MCP de Bitcoin y Lightning Network

Descripción general

Un servidor de Protocolo de Contexto de Modelo (MCP) que permite que los modelos de IA interactúen con Bitcoin y Lightning Network, lo que les permite generar claves, validar direcciones, decodificar transacciones, consultar la cadena de bloques y más.

Related MCP server: Bankless Onchain MCP Server

🎮 Demostración

Vídeo de demostración de Claude

Vídeo de demostración de Goose

💼 Índice de contenidos

🔧 Características

  • Generación de claves : crea nuevos pares de claves de Bitcoin, incluida la dirección, la clave pública y la clave privada (WIF).

  • Validación de dirección : valida la exactitud de una dirección de Bitcoin.

  • Descodificación de transacciones : analiza una transacción de Bitcoin sin procesar y muestra sus detalles en un formato legible para humanos.

  • Consultas de blockchain :

    • Último bloque : recupera detalles sobre el bloque más reciente (hash, altura, marca de tiempo, recuento de transacciones, etc.).

    • Detalles de la transacción : obtiene información detallada sobre una transacción utilizando su TXID.

  • Red Lightning :

    • Descodificación de facturas : analiza una factura BOLT11 Lightning y muestra información legible para humanos.

    • Pago : Pague una factura Lightning directamente desde su billetera LNBits.

🔑 Integración de escritorio de Claude

Para utilizar el servidor Bitcoin MCP con Claude Desktop (la aplicación de escritorio de Anthropic para Claude), siga estos pasos:

  1. Descarga e instala Claude Desktop: Visita la página oficial de descargas de Claude Desktop y descarga la app para tu sistema operativo (MacOS o Windows) ( Instalación de Claude Desktop | Centro de ayuda de Anthropic ). Instala la app y asegúrate de usar la última versión (puedes buscar actualizaciones en el menú de la app).

  2. Configure Claude Desktop para usar el servidor MCP de Bitcoin: abra el archivo de configuración de Claude Desktop (se crea cuando edita por primera vez la configuración en Claude Desktop):

    • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

    • Ventanas: %APPDATA%\Claude\claude_desktop_config.json
      Agregue una entrada para el servidor MCP de Bitcoin en esta configuración JSON, en la sección "mcpServers" . Por ejemplo:

    {
  "mcpServers": {
    "bitcoin-mcp": {
      "command": "npx",
      "args": ["-y", "bitcoin-mcp@latest"]
    }
  }
}

    En el fragmento anterior, "bitcoin-mcp" es un identificador del servidor (puedes nombrarlo como quieras). El command está configurado para ejecutar el comando npx , y args apunta a la ruta del script del servidor Bitcoin MCP o al comando para ejecutar el servidor.

  3. Reiniciar Claude Desktop: Guarda el archivo claude_desktop_config.json y cierra y vuelve a abrir Claude Desktop . La próxima vez que lo inicies, Claude iniciará automáticamente el servidor Bitcoin MCP según su configuración. Si Claude Desktop estaba en ejecución, debes reiniciarlo para que los cambios surtan efecto.

Prueba de la integración de Claude Desktop

Una vez que se reinicie Claude Desktop, puede probar si el servidor Bitcoin MCP está funcionando correctamente:

  • Hazle a Claude una pregunta de ejemplo relacionada con Bitcoin. Por ejemplo, intenta preguntar: "¿Cuál es el último bloque en la red Bitcoin?". Si la integración es exitosa, la respuesta de Claude debería incluir el último bloque obtenido a través del servidor MCP, en lugar de un "No lo sé" o una respuesta genérica. También puedes probar otras consultas como "Indícame información sobre la transacción con TXID abcdef1234567890abcdef1234567890abcdef1234567890abcdef1234567890". Claude debería usar las herramientas del servidor MCP para recuperar los datos y responder a tu consulta.

  • Verificar la respuesta: Claude debería devolver una respuesta detallada (por ejemplo, el último bloque en la red Bitcoin) sin errores. Si recibe un mensaje de error o ninguna respuesta útil, es posible que el servidor MCP no esté conectado correctamente.

  • Revisar los registros de Claude (si es necesario): Claude Desktop proporciona archivos de registro que pueden ayudar a depurar las integraciones de MCP. Si la herramienta no responde, revise los archivos de registro en:

    • macOS: ~/Library/Logs/Claude/

    • Ventanas: %APPDATA%\Claude\logs\
      Busque mcp.log para los mensajes generales de conexión de MCP y un archivo llamado mcp-server-bitcoin-mcp.log (o con el nombre que haya usado) para la salida/errores del servidor MCP. Estos registros mostrarán si el servidor se inició o si hubo algún error (como una ruta incorrecta o excepciones en el servidor). Si detecta errores, corrija la configuración o el entorno según sea necesario, reinicie Claude Desktop y vuelva a probar.

🦆 Integración de Goose

Goose es un framework de agente de IA de código abierto de Block que admite extensiones mediante el Protocolo de Contexto de Modelo. Puedes integrar el servidor MCP de Bitcoin como una extensión de Goose para que Goose interactúe con la blockchain de Bitcoin. Goose admite dos modos de integración para servidores MCP: ejecutar el servidor como un proceso local (STDIO) o conectarse a él como un servicio remoto mediante Eventos Enviados por el Servidor (SSE). A continuación, se detallan las instrucciones para ambos métodos:

Uso de STDIO (extensión local)

Este método ejecuta el servidor Bitcoin MCP localmente como un subproceso de Goose, comunicándose a través de entrada/salida estándar.

  1. Añadir una nueva extensión en Goose: Abra la interfaz de configuración de Goose. Puede hacerlo mediante la línea de comandos ejecutando goose configure o en la aplicación Goose Desktop, en Configuración > Extensiones . En el menú, seleccione "Añadir extensión". ( Usar extensiones | goose )

  2. Elija el tipo de extensión: Extensión de línea de comandos: cuando se le solicite el tipo de extensión, seleccione Extensión de línea de comandos (en el menú CLI o UI) para que Goose sepa que debe iniciar un comando local ( Uso de extensiones | goose ) (en lugar de una extensión integrada o remota).

  3. Ingrese los detalles de la extensión: Proporcione un nombre y un comando para el servidor Bitcoin MCP:

    • Nombre: Puedes llamarlo "bitcoin", o cualquier identificador (así será como te referirás a la extensión).

    • Comando: Especifique cómo ejecutar el servidor MCP. Por ejemplo, si tiene el script de Python, introduzca el comando para ejecutarlo. En el configurador de la CLI, podría preguntar "¿Qué comando se debe ejecutar?". Introduzca:

      npx -y bitcoin-mcp@latest

      Esto le indica a Goose que inicie el servidor Bitcoin MCP ( GitHub - AbdelStark/bitcoin-mcp: Servidor Bitcoin MCP ). (Asegúrese de usar la ruta correcta al script del servidor o el comando correcto para ejecutarlo, como en la configuración de Claude).

    • Normalmente no es necesario añadir ningún argumento más allá de la ruta del script (a menos que su servidor requiera indicadores especiales). El comando anterior utiliza el transporte STDIO predeterminado, que Goose espera para una extensión de línea de comandos. (En el archivo de configuración de Goose, esto correspondería a una entrada con cmd: "npx" y args: ["-y", "bitcoin-mcp@latest"] , con type: stdio indicando el modo de E/S estándar ( Uso de extensiones | goose ).)

  4. Finalizar y habilitar: Complete la adición de la extensión. Goose añadirá esta nueva extensión a su configuración (normalmente ~/.config/goose/config.yaml ). Asegúrese de que la extensión esté habilitada (si usa el asistente de la CLI, debería estar habilitada por defecto una vez añadida; en la aplicación Goose Desktop, puede consultar la lista de extensiones y activarla si no lo está ya ( Usar extensiones | goose ) ( Usar extensiones | goose )).

  5. Iniciar una sesión de Goose con la nueva extensión: Ahora puede usar la extensión en Goose. Si ejecuta Goose mediante la CLI, inicie una sesión que incluya la extensión ejecutando:

    goose session --with-extension "bitcoin"

Reemplazar "bitcoin" por el nombre que le haya asignado a la extensión ( Uso de extensiones | goose ). (Esto garantiza que la sesión cargue la extensión. Alternativamente, si la extensión está habilitada globalmente, Goose Desktop o CLI la tendrán disponible automáticamente en todas las sesiones).

Uso de SSE (extensión remota)

Este método conecta Goose a un servidor MCP ya en ejecución mediante una secuencia HTTP SSE. Úselo si desea ejecutar el servidor MCP de Bitcoin como un servicio independiente (posiblemente en otra máquina o de forma independiente de Goose).

  1. Iniciar el servidor MCP como servicio independiente: Ejecutar el servidor MCP de Bitcoin para que escuche conexiones. En la práctica, esto significa que el servidor debe iniciarse en un modo que sirva un punto final HTTP para MCP. Por ejemplo, se puede ejecutar el servidor con un comando u opción específica para escuchar en un puerto (como usar las funciones de servidor web integradas de una biblioteca MCP o ejecutarlo bajo un framework web). Asegúrese de que el servidor sea accesible en una URL conocida (p. ej., http://localhost:9000 ) y que sea compatible con el protocolo MCP a través de SSE.

  2. Añadir una nueva extensión en Goose (Remoto): Como antes, ejecute goose configure o use la interfaz de usuario de Goose para añadir una extensión ( Uso de extensiones | goose ). Esta vez, seleccione Extensión remota cuando se le solicite el tipo de extensión ( Uso de extensiones | goose ). Esto indica a Goose que se conectará a un servidor externo mediante SSE.

  3. Introduce los datos de la extensión remota: Asígnale un nombre a la extensión (p. ej., "bitcoin") y proporciona la URL del servidor. En la URL , introduce la dirección base donde se ejecuta el servidor MCP. Por ejemplo, si tu servidor escucha en el puerto 9000 de tu equipo local, podrías introducir http://localhost:9000 . Goose intentará conectarse al punto final SSE del servidor MCP en esa dirección. (Goose utiliza la ruta SSE estándar de MCP, que por convención se encuentra en la ruta /mcp/sse del servidor; normalmente, solo necesitas proporcionar el host y el puerto, y Goose se encarga del resto).

  4. Habilitar la extensión: Después de agregar la extensión remota, asegúrese de que esté habilitada en la configuración de Goose (igual que en el caso de STDIO). Solo es necesario habilitar una de las extensiones, STDIO o SSE (con las mismas herramientas). Si habilita accidentalmente una versión local y otra remota del mismo servidor, le recomendamos deshabilitar una para evitar confusiones.

Uso de la extensión Bitcoin MCP en Goose: Una vez configurada y habilitada la extensión (mediante cualquiera de los métodos anteriores), podrá interactuar con Goose y consultar datos de Bitcoin a través de ella. En un nuevo chat o sesión de Goose, simplemente haga preguntas como lo haría normalmente. Goose reconocerá cuándo usar las herramientas Bitcoin MCP para atender su solicitud. Por ejemplo:

  • "¿Cuál es el último bloque de Bitcoin?"

  • "Dame información sobre la transacción con TXID abcdef1234567890abcdef1234567890abcdef1234567890abcdef1234567890."

Al hacer estas preguntas, Goose invocará las herramientas del servidor MCP y devolverá la respuesta (por ejemplo, la información más reciente del bloque de Bitcoin). Debería ver a Goose respondiendo con información actualizada extraída de la cadena de bloques de Bitcoin a través del servidor MCP.

Si Goose no parece usar la extensión (por ejemplo, si indica que no encuentra la información), asegúrese de que esté habilitada y de que el servidor esté ejecutándose (en modo SSE para acceso remoto). También puede ejecutar la CLI de Goose con registro detallado para comprobar si intentó llamar a la extensión. Generalmente, si se configura correctamente, Goose detectará automáticamente las capacidades del servidor MCP y las usará cuando sea necesario.

Recursos adicionales: Para más detalles sobre las extensiones de Goose y el MCP, consulte la documentación oficial de Goose ( Uso de extensiones | goose ). La documentación incluye una lista de extensiones integradas y de la comunidad, y explica cómo se integran los servidores MCP en Goose. También puede encontrar un directorio de servidores MCP disponibles y consejos de configuración adicionales en la documentación de Goose y la documentación del Protocolo de Contexto de Modelo. Esto puede ser útil si desea explorar más extensiones o desarrollar las suyas propias.

Configuración del desarrollo

Encuentre las instrucciones de configuración en la guía de configuración de desarrollo .

Configuración de la red Lightning (opcional)

Para usar las funciones de Lightning Network, deberá configurar los detalles de conexión de LNBits. Estos son opcionales y solo son necesarios si planea usar las herramientas de Lightning Network.

{
  "lnbitsUrl": "https://demo.lnbits.com",  
  "lnbitsAdminKey": "your_admin_key",      // Required for making payments
  "lnbitsReadKey": "your_read_key"         // Required for wallet information
}

Puedes obtener estos valores:

  1. Crear una cuenta en LNBits

  2. Creando una nueva billetera

  3. Vaya a la información de API para encontrar sus claves de API

📦 Herramientas disponibles

Encuentre las herramientas disponibles en la guía de referencia de API .

🚨 Manejo de errores

El servidor utiliza tipos de error personalizados para gestionar las operaciones de Bitcoin y las consultas de blockchain. Los mensajes de error detallados se registran mediante Pino y se incluyen en las respuestas del cliente para facilitar la depuración.

🤝 Contribuyendo

¡Agradecemos sus contribuciones y solicitudes de funcionalidad! No dude en enviar solicitudes de incorporación de cambios o abrir incidencias en GitHub.

📝 Licencia

Este proyecto está licenciado bajo la licencia MIT .

Available Tools

7 tools
decode_invoiceC

Decode a Lightning invoice

ParametersJSON Schema
NameRequiredDescriptionDefault
invoiceYesBOLT11 Lightning invoice

TDQS

C2.9/5.0
Behavior2/5

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 'decode' but doesn't explain what decoding entails (e.g., extracting payment details, checking validity, or returning structured data). For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior and output.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly. No unnecessary words or redundant information are included.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

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 tool returns (e.g., decoded fields like amount, timestamp, or destination) or potential errors (e.g., invalid invoice format). For a decoding tool with no structured output documentation, this leaves the agent guessing about results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with the parameter 'invoice' documented as a 'BOLT11 Lightning invoice'. The description doesn't add any meaning beyond this, such as format examples or validation rules. Since the schema already provides adequate coverage, the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'decode' and the resource 'Lightning invoice', making the purpose immediately understandable. It doesn't differentiate from siblings like 'decode_tx' or 'pay_invoice', but the core action is specific enough to understand what the tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 'decode_tx' or 'validate_address'. It doesn't mention prerequisites, such as needing a valid BOLT11 invoice, or clarify that this is for decoding rather than processing payments (which 'pay_invoice' handles).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

decode_txC

Decode a Bitcoin transaction

ParametersJSON Schema
NameRequiredDescriptionDefault
rawHexYesTransaction hex

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden but offers minimal behavioral insight. It doesn't disclose whether this is a read-only operation, if it requires network access, potential rate limits, error conditions, or what the decoded output looks like. The description is functional but lacks context about how the tool behaves.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core purpose and appropriately sized for a simple tool with one parameter.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no annotations and no output schema, the description is inadequate. It doesn't explain what 'decode' entails (e.g., parsing inputs/outputs, scripts), the format of the result, or error handling. Given the complexity of Bitcoin transactions and lack of structured context, more completeness is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100%, with the parameter 'rawHex' fully documented in the schema as 'Transaction hex'. The description adds no additional meaning beyond this, so it meets the baseline for high schema coverage without compensating value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('decode') and resource ('a Bitcoin transaction'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_transaction' or 'decode_invoice', which prevents 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.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided about when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing raw hex data), exclusions, or comparisons to sibling tools like 'get_transaction' (which might retrieve transaction details differently).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generate_keyB

Generate a new Bitcoin key pair and address

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden but only states what the tool does without behavioral details. It doesn't disclose if this requires network connectivity, has rate limits, stores keys securely, or what format the output takes (e.g., public/private keys, address type). This leaves significant gaps for agent understanding.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It is front-loaded with the core action and resource, 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.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of generating cryptographic keys and the lack of annotations and output schema, the description is incomplete. It doesn't explain return values (e.g., key formats), security implications, or error conditions, leaving the agent with insufficient context for safe and effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately avoids discussing parameters, focusing on the tool's purpose. A baseline of 4 is applied as it compensates adequately for the lack of parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Generate') and the resource ('a new Bitcoin key pair and address'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'validate_address' or 'pay_invoice', which prevents 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.

Usage Guidelines2/5

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 'validate_address' for checking existing addresses or 'pay_invoice' for transactions. It lacks context about prerequisites, such as needing Bitcoin network access or when key generation is appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_latest_blockC

Get the latest block

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

C2.9/5.0
Behavior2/5

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 only states the action without details on permissions, rate limits, response format, or potential side effects. For a tool with zero annotation coverage, this is insufficient to inform the agent adequately.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with a single sentence, 'Get the latest block', which is front-loaded and wastes no words. It efficiently conveys the core purpose without unnecessary elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

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 does not explain what the tool returns (e.g., block data structure, error handling) or provide context for its use among siblings. For a tool with no structured support, more descriptive content is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add parameter information, which is appropriate here, but it could have clarified the lack of parameters explicitly. Baseline is 4 due to the absence of parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Get the latest block' clearly states the action (get) and resource (latest block), making the purpose understandable. However, it lacks specificity about what a 'block' refers to in this context (e.g., blockchain block, data block) and does not differentiate from sibling tools like 'get_transaction', leaving room for ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 does not mention any prerequisites, context, or comparisons to sibling tools such as 'get_transaction' or 'decode_tx', leaving the agent without usage instructions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_transactionC

Get transaction details

ParametersJSON Schema
NameRequiredDescriptionDefault
txidYesTransaction ID

TDQS

C2.6/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden but only states the basic action without disclosing behavioral traits such as whether this is a read-only operation, error handling, rate limits, or authentication needs. It mentions 'details' but doesn't specify what those include.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with 'Get transaction details'—a single, front-loaded sentence that efficiently conveys the core purpose without unnecessary words. However, it may be overly terse for a tool with no annotations or output schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

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 transaction details are returned, error conditions, or how it differs from sibling tools. For a tool with one parameter but no structured context, more information is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, clearly documenting the 'txid' parameter. The description adds no additional meaning beyond the schema, so it meets the baseline of 3 for adequate but not enhanced parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Get transaction details' states the basic action (get) and resource (transaction details), but it's vague about what specific details are retrieved and doesn't differentiate from sibling tools like 'decode_tx' or 'get_latest_block'. It provides minimal but adequate purpose information.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like 'decode_tx' (which might decode transaction data) or 'get_latest_block' (which retrieves block information). The description lacks context about prerequisites or typical use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

pay_invoiceC

Pay a Lightning invoice

ParametersJSON Schema
NameRequiredDescriptionDefault
invoiceYesBOLT11 Lightning invoice

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It states 'Pay a Lightning invoice' which implies a financial transaction, but doesn't clarify if this is irreversible, requires authentication, has rate limits, or what happens on success/failure. This is inadequate for a payment tool with zero 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a simple tool with one parameter and gets straight to the point without unnecessary elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a payment tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after payment (success confirmation, error handling), doesn't mention security implications, and provides minimal behavioral context despite the tool's financial nature.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, with the 'invoice' parameter documented as 'BOLT11 Lightning invoice'. The description doesn't add any additional meaning beyond what the schema provides, such as format examples or validation requirements, so it 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.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Pay') and target resource ('a Lightning invoice'), making the purpose immediately understandable. It doesn't differentiate from siblings like 'decode_invoice' or 'get_transaction', but it's specific enough to understand what the tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 'decode_invoice' or 'validate_address'. It doesn't mention prerequisites, such as requiring a valid invoice or sufficient balance, leaving the agent to infer usage context from the tool name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

validate_addressC

Validate a Bitcoin address

ParametersJSON Schema
NameRequiredDescriptionDefault
addressYesThe Bitcoin address to validate

TDQS

C2.9/5.0
Behavior2/5

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. 'Validate' implies a read-only check, but the description doesn't specify what validation entails (format, checksum, network type), whether it requires network connectivity, what happens with invalid inputs, or what the output format will be. 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.

Conciseness5/5

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 with zero wasted words. It's appropriately sized for a simple validation tool and is perfectly front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a validation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what constitutes validation, what the tool returns (success/failure, validation details, error messages), or how it differs from related sibling tools. The agent would lack critical context to use this tool effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 100% description coverage, with the single parameter 'address' clearly documented as 'The Bitcoin address to validate'. The description adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('validate') and resource ('Bitcoin address'), making the purpose immediately understandable. However, it doesn't differentiate this validation tool from potential sibling tools that might also validate addresses in different contexts or with different criteria.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 whether this is for address format validation, network compatibility checking, or other specific validation contexts, nor does it reference any sibling tools that might serve related purposes.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 7 tool updates
    • First observeddecode_invoice
    • First observeddecode_tx
    • First observedgenerate_key
    • First observedget_latest_block
    • First observedget_transaction
    • First observedpay_invoice
    • First observedvalidate_address
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.4/5.0

Scored across 7 tools

Disambiguation5/5

Each tool has a clearly distinct purpose with no ambiguity: decode_invoice and decode_tx handle decoding, generate_key creates keys, get_latest_block and get_transaction retrieve blockchain data, pay_invoice processes payments, and validate_address checks addresses. There is no overlap in functionality that could cause misselection.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (e.g., decode_invoice, generate_key, get_transaction) with no deviations in style or convention. This predictability makes the set easy to navigate and understand.

Tool Count5/5

With 7 tools, the count is well-scoped for a Bitcoin server, covering key operations like decoding, key generation, data retrieval, payments, and validation. Each tool earns its place without feeling excessive or insufficient for the domain.

Completeness4/5

The tool surface covers core Bitcoin and Lightning operations effectively, including decoding, key management, transaction handling, and payments. A minor gap exists in lifecycle coverage, such as missing tools for creating transactions or managing wallets, but agents can work around this for most workflows.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Bankless Onchain MCP Server by Bankless

    Bankless Onchain MCP Serverofficial

    Bankless
    A
    license
    B
    quality
    F
    maintenance
    Implements the Model Context Protocol to allow AI models to access and interact with blockchain data, including reading contract states, retrieving events, and accessing transaction information across various networks.
    10
    106 npm
    79
    MIT
  • Satstream MCP Server by satstream

    Satstream MCP Serverofficial

    satstream
    A
    license
    B
    quality
    D
    maintenance
    A Model Context Protocol server that enables querying Bitcoin blockchain data, including address information, transaction details, mempool statistics, and ordinals/runes data through the Satstream API.
    37
    MIT

  • Mempool MCP Server

    alexandresanlim
    A
    license
    B
    quality
    D
    maintenance
    A Model Context Protocol server that provides real-time Bitcoin blockchain and mempool data to AI clients, allowing access to comprehensive Bitcoin network information through various data tools.
    31
    6 npm
    5
    MIT

Appeared in Searches