What can you do with this server?

The Bitcoin MCP Server enables AI models to interact with Bitcoin and the Lightning Network for blockchain-related operations: * Generate Bitcoin key pairs (address, public key, private key in WIF format) * Validate Bitcoin addresses * Decode raw Bitcoin transactions into human-readable format * Query the latest block information * Fetch transaction details using TXID * Decode BOLT11 Lightning invoices * Process Lightning payments using LNBits (requires configuration)

Which integrations are available for this server?

Enables interaction with the Bitcoin blockchain, providing tools for generating keys, validating addresses, decoding transactions, querying latest blocks, and retrieving transaction details.

How do I use Bitcoin MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Bitcoin MCP Server validate this Bitcoin address: 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa" 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.

en es ja ko zh

Bitcoin MCP Server

by AbdelStark

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

₿itcoin & Lightning Network MCP Server

Overview

A Model Context Protocol (MCP) server that enables AI models to interact with Bitcoin and Lightning Network, allowing them to generate keys, validate addresses, decode transactions, query the blockchain, and more.

Related MCP server: Bankless Onchain MCP Server

🎮 Demo

Claude Demo Video	Goose Demo Video

💼 Table of Contents

₿itcoin & Lightning Network MCP Server

🔧 Features

Key Generation: Create new Bitcoin key pairs — including address, public key, and private key (WIF).
Address Validation: Validate the correctness of a Bitcoin address.
Transaction Decoding: Parse a raw Bitcoin transaction and display its details in a human-readable format.
Blockchain Queries:
- Latest Block: Retrieve details about the most recent block (hash, height, timestamp, transaction count, etc.).
- Transaction Details: Fetch detailed information about a transaction using its TXID.
Lightning Network:
- Invoice Decoding: Parse a BOLT11 Lightning invoice and display human-readable information.
- Payment: Pay a Lightning invoice directly from your LNBits wallet.

🔑 Claude Desktop Integration

To use the Bitcoin MCP server with Claude Desktop (Anthropic's desktop app for Claude), follow these steps:

Download and Install Claude Desktop: Visit the official Claude Desktop downloads page and get the app for your operating system (macOS or Windows) (Installing Claude for Desktop | Anthropic Help Center). Install the app and ensure you're using the latest version (you can check for updates in the app menu).
Configure Claude Desktop to use the Bitcoin MCP Server: Open the Claude Desktop configuration file (it's created when you first edit settings in Claude Desktop):
- macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
- Windows: %APPDATA%\Claude\claude_desktop_config.json
  Add an entry for the Bitcoin MCP server in this JSON config under the "mcpServers" section. For example:
```
{
  "mcpServers": {
    "bitcoin-mcp": {
      "command": "npx",
      "args": ["-y", "bitcoin-mcp@latest"]
    }
  }
}
```
In the snippet above, "bitcoin-mcp" is an identifier for the server (you can name it whatever you want). The command is set to run the npx command, and args points to the path of your Bitcoin MCP server script or the command to run the server.
Restart Claude Desktop: Save the claude_desktop_config.json file and then close and reopen Claude Desktop. On the next launch, Claude will automatically start the Bitcoin MCP server as configured. If Claude Desktop was running, you need to restart it for the changes to take effect.

Testing the Claude Desktop Integration

Once Claude Desktop is restarted, you can test whether the Bitcoin MCP server is working correctly:

Ask Claude a sample question related to Bitcoin. For example, try asking: "What's the latest block on the Bitcoin network?" If the integration is successful, Claude's response should include the latest block fetched via the MCP server, rather than an "I don't know" or a generic answer. You can also try other queries like "Give me information about the transaction with TXID abcdef1234567890abcdef1234567890abcdef1234567890abcdef1234567890." Claude should use the MCP server's tools to retrieve the data and answer your query.
Verify the response: Claude should return a detailed answer (e.g. the latest block on the Bitcoin network) without errors. If you get an error message or no useful response, the MCP server might not be connected properly.
Check Claude's logs (if needed): Claude Desktop provides log files that can help debug MCP integrations. If the tool isn't responding, check the log files in:
- macOS: ~/Library/Logs/Claude/
- Windows: %APPDATA%\Claude\logs\
  Look for mcp.log for general MCP connection messages, and a file named mcp-server-bitcoin-mcp.log (or with whatever name you used) for the MCP server's output/errors. These logs will show if the server started up or if there were any errors (such as a wrong path or exceptions in the server). If you see errors, fix the configuration or environment as needed, then restart Claude Desktop and test again.

🦆 Goose Integration

Goose is an open-source AI agent framework by Block that supports extensions via the Model Context Protocol. You can integrate the Bitcoin MCP server as a Goose extension to allow Goose to interact with the Bitcoin blockchain. Goose supports two modes of integration for MCP servers: running the server as a local process (STDIO) or connecting to it as a remote service via Server-Sent Events (SSE). Below are instructions for both methods:

Using STDIO (Local Extension)

This method runs the Bitcoin MCP server locally as a subprocess of Goose, communicating through standard input/output.

Add a new extension in Goose: Open Goose's configuration interface. You can do this via the command line by running goose configure, or in the Goose Desktop app by going to Settings > Extensions. From the menu, choose "Add Extension." (Using Extensions | goose)
Choose the extension type – Command-Line Extension: When prompted for the type of extension, select Command-Line Extension (in the CLI menu or UI) so that Goose knows it should launch a local command (Using Extensions | goose) (as opposed to a built-in or remote extension).
Enter the extension details: Provide a name and command for the Bitcoin MCP server:
- Name: You can call it "bitcoin", or any identifier (this will be how you refer to the extension).
- Command: Specify how to run the MCP server. For example, if you have the Python script, enter the command to run it. In the CLI configurator, it might ask "What command should be run?" – you would enter:
  npx -y bitcoin-mcp@latest
  This tells Goose to launch the Bitcoin MCP server (GitHub - AbdelStark/bitcoin-mcp: Bitcoin MCP Server). (Make sure to use the correct path to your server script or the correct command to run the server, just like in the Claude config.)
- You typically do not need to add any arguments beyond the script path (unless your server requires special flags). The above command uses the default STDIO transport, which Goose expects for a command-line extension. (In the Goose config file, this would correspond to an entry with cmd: "npx" and args: ["-y", "bitcoin-mcp@latest"], with type: stdio indicating standard I/O mode (Using Extensions | goose).)
Finalize and enable: Complete the extension addition. Goose will add this new extension to its configuration (usually ~/.config/goose/config.yaml). Ensure the extension is enabled (if using the CLI wizard, it should be enabled by default once added; in the Goose Desktop app, you can check the Extensions list and toggle it on if it isn't already (Using Extensions | goose) (Using Extensions | goose)).
Start a Goose session with the new extension: You can now use the extension in Goose. If you're running Goose via CLI, start a session that includes the extension by running:
```
goose session --with-extension "bitcoin"
```

replacing "bitcoin" with whatever name you gave the extension (Using Extensions | goose). (This ensures the session loads the extension. Alternatively, if the extension is enabled globally, Goose Desktop or CLI will automatically have it available in all sessions.)

Using SSE (Remote Extension)

This method connects Goose to an already-running MCP server via an HTTP SSE stream. Use this if you want to run the Bitcoin MCP server as a standalone service (possibly on another machine or just independently of Goose).

Launch the MCP server as a standalone service: Run the Bitcoin MCP server so that it listens for connections. In practice, this means the server needs to be started in a mode that serves an HTTP endpoint for MCP. For example, you might run the server with a specific command or option to listen on a port (such as using an MCP library's built-in web server capabilities or running under a web framework). Ensure the server is reachable at a known URL (e.g., http://localhost:9000) and supports the MCP protocol over SSE.
Add a new extension in Goose (Remote): As before, run goose configure or use the Goose UI to Add Extension (Using Extensions | goose). This time, choose Remote Extension when asked for the type of extension (Using Extensions | goose). This tells Goose that it will connect to an external server via SSE.
Enter the remote extension details: Give the extension a name (e.g., "bitcoin") and provide the server's URL. For the URL, enter the base address where the MCP server is running. For instance, if your server is listening on port 9000 on your local machine, you might enter http://localhost:9000. Goose will attempt to connect to the MCP server's SSE endpoint at that address. (Goose uses the standard MCP SSE path, which by convention is under the /mcp/sse route on the server, you usually just need to supply the host and port, and Goose handles the rest.)
Enable the extension: After adding the remote extension, ensure it's enabled in Goose's settings (just like in the STDIO case). Only one of the STDIO or SSE extension (with the same tools) needs to be enabled – if you accidentally enable both a local and remote version of the same server, you may want to disable one to avoid confusion.

Using the Bitcoin MCP extension in Goose: Once the extension is set up (via either method above) and enabled, you can interact with Goose and query Bitcoin data through it. In a new Goose chat or session, simply ask questions as you normally would. Goose will recognize when to use the Bitcoin MCP tools to fulfill your request. For example:

"What's the latest Bitcoin block?"
"Give me information about the transaction with TXID abcdef1234567890abcdef1234567890abcdef1234567890abcdef1234567890."

When you ask these questions, Goose will invoke the MCP server's tools and return the answer (e.g., the latest Bitcoin block information). You should see Goose responding with up-to-date information pulled from the Bitcoin blockchain via the MCP server.

If Goose does not seem to use the extension (for instance, if it responds that it cannot find the information), make sure the extension is enabled and that the server is running (in SSE mode for remote). You can also run Goose's CLI with verbose logging to see if it attempted to call the extension. Generally, if configured correctly, Goose will automatically discover the MCP server's capabilities and use them when relevant.

Further Resources: For more details on Goose extensions and the MCP, refer to the official Goose documentation (Using Extensions | goose). The docs include a list of built-in and community extensions and explain how MCP servers integrate into Goose. You can also find a directory of available MCP servers and additional configuration tips in the Goose docs and the Model Context Protocol documentation. This can help if you want to explore more extensions or develop your own.

📦 Development Setup

Find the setup instructions in the Development Setup guide.

Lightning Network Configuration (Optional)

To use Lightning Network features, you'll need to configure LNBits connection details. These are optional and only required if you plan to use the Lightning Network tools.

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

You can obtain these values by:

Creating an account at LNBits
Creating a new wallet
Going to API info to find your API keys

📦 Available Tools

Find the available tools in the API Reference guide.

🚨 Error Handling

The server employs custom error types to handle Bitcoin operations and blockchain queries. Detailed error messages are logged using Pino and included in client responses for easier debugging.

🤝 Contributing

Contributions and feature requests are welcome! Feel free to submit pull requests or open issues on GitHub.

📝 License

This project is licensed under the MIT License.

Available Tools

7 tools

decode_invoiceC

Decode a Lightning invoice

ParametersJSON Schema

Name	Required	Description	Default
`invoice`	Yes	BOLT11 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

Name	Required	Description	Default
`rawHex`	Yes	Transaction 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

Name	Required	Description	Default
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

Name	Required	Description	Default
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

Name	Required	Description	Default
`txid`	Yes	Transaction 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

Name	Required	Description	Default
`invoice`	Yes	BOLT11 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

Name	Required	Description	Default
`address`	Yes	The 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.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0

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

ResponsivenessWithin a week

Resources

Need Help?

Reddit Discussion

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Satoshidata Wallet Intel B
io.github.wrbtc
Bitcoin wallet intelligence for AI agents: trust, labels, tx verify, fees, and timestamps.
Blockchain Finance Cryptocurrency
442
intelligence
app.tinkrr
Bitcoin and YouTube video intelligence for AI agents. Pay-per-call via x402 USDC on Base.
Cryptocurrency Blockchain Entertainment & Media
2
BittensorMCP
io.github.btmcp
Hosted MCP server for live Bittensor chain reads and self-custodial on-chain writes.
Blockchain Cryptocurrency Web3 & Decentralized Tech
1
hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237

Related MCP Servers

MCP Blockchain Query Server
Blockchain Cryptocurrency Web3 & Decentralized Tech
pavel-bc
F
license
Not graded
quality
C
maintenance
A Model Context Protocol server providing tools for querying Bitcoin blockchain data via Blockchain Data and Query APIs, supporting various BTC information retrieval functions.
Updated 9 months ago (2025-12-07 10:23 UTC)
1
Bankless Onchain MCP Serverofficial
Blockchain Web3 & Decentralized Tech
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.
Updated 4 months ago (2026-05-05 11:48 UTC)
10
44
80
MIT
Satstream MCP Serverofficial
Blockchain Web3 & Decentralized Tech Search
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.
Updated a year ago (2025-04-19 04:00 UTC)
37
MIT
Mempool MCP Server
Blockchain Data Platforms
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.
Updated a year ago (2025-07-24 11:34 UTC)
31
13
5
MIT

Appeared in Searches

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/AbdelStark/bitcoin-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

₿itcoin & Lightning Network MCP Server

Overview

🎮 Demo

💼 Table of Contents

🔧 Features

🔑 Claude Desktop Integration

Testing the Claude Desktop Integration

🦆 Goose Integration

Using STDIO (Local Extension)

Using SSE (Remote Extension)

📦 Development Setup

Lightning Network Configuration (Optional)

📦 Available Tools

🚨 Error Handling

🤝 Contributing

📝 License

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Bankless Onchain MCP Serverofficial

Satstream MCP Serverofficial

Appeared in Searches

Latest Blog Posts

MCP directory API