F
licenseNot graded
qualityC
maintenanceA Model Context Protocol server providing tools for querying Bitcoin blockchain data via Blockchain Data and Query APIs, supporting various BTC information retrieval functions.
1
-
Bitcoin MCP Server
by AbdelStark
₿itcoin 和闪电网络 MCP 服务器
概述
模型上下文协议 (MCP) 服务器使 AI 模型能够与比特币和闪电网络交互，从而允许它们生成密钥、验证地址、解码交易、查询区块链等。
Related MCP server: Bankless Onchain MCP Server
🎮 演示
💼 目录
🔧 功能
密钥生成：创建新的比特币密钥对——包括地址、公钥和私钥（WIF）。
地址验证：验证比特币地址的正确性。
交易解码：解析原始比特币交易并以人类可读的格式显示其详细信息。
区块链查询：
最新区块：检索有关最新区块的详细信息（哈希值、高度、时间戳、交易计数等）。
交易详情：使用 TXID 获取有关交易的详细信息。
闪电网络：
发票解码：解析 BOLT11 Lightning 发票并显示人类可读的信息。
付款：直接从您的 LNBits 钱包支付 Lightning 发票。
🔑 Claude 桌面集成
要将比特币 MCP 服务器与 Claude Desktop（Anthropic 为 Claude 开发的桌面应用程序）一起使用，请按照以下步骤操作：
**下载并安装 Claude Desktop：**访问 Claude Desktop 官方下载页面，获取适用于您操作系统（macOS 或 Windows）的应用程序（ 安装 Claude Desktop | Anthropic 帮助中心）。安装应用程序并确保您使用的是最新版本（您可以在应用程序菜单中检查更新）。
**配置 Claude Desktop 以使用比特币 MCP 服务器：**打开 Claude Desktop 配置文件（它是在您第一次在 Claude Desktop 中编辑设置时创建的）：
macOS：
~/Library/Application Support/Claude/claude_desktop_config.jsonWindows：
%APPDATA%\Claude\claude_desktop_config.json
在此 JSON 配置的"mcpServers"部分下添加比特币 MCP 服务器的条目。例如：
{ "mcpServers": { "bitcoin-mcp": { "command": "npx", "args": ["-y", "bitcoin-mcp@latest"] } } }在上面的代码片段中，
"bitcoin-mcp"是服务器的标识符（您可以随意命名）。command设置为运行npx命令，args指向您的比特币 MCP 服务器脚本的路径或运行服务器的命令。重启 Claude Desktop：保存
claude_desktop_config.json文件，然后关闭并重新打开 Claude Desktop 。下次启动时，Claude 将自动按照配置启动比特币 MCP 服务器。如果 Claude Desktop 正在运行，则需要重启它以使更改生效。
测试 Claude 桌面集成
一旦 Claude Desktop 重新启动，您就可以测试比特币 MCP 服务器是否正常工作：
**向 Claude 询问一个与比特币相关的示例问题。**例如，尝试询问： “比特币网络上的最新区块是什么？”如果集成成功，Claude 的回复应该包含通过 MCP 服务器获取的最新区块，而不是“我不知道”或泛泛而谈。您还可以尝试其他查询，例如“请提供 TXID 为 abcdef1234567890abcdef1234567890abcdef1234567890abcdef1234567890 的交易信息”。Claude应该使用 MCP 服务器的工具来检索数据并回答您的查询。
验证响应： Claude 应该返回一个详细的答案（例如，比特币网络上的最新区块），并且没有错误。如果您收到错误消息或没有有用的响应，则 MCP 服务器可能未正确连接。
检查 Claude 的日志（如有需要）： Claude Desktop 提供了日志文件，可帮助调试 MCP 集成。如果该工具没有响应，请检查以下日志文件：
macOS：
~/Library/Logs/Claude/Windows：
%APPDATA%\Claude\logs\
查找mcp.log以获取常规 MCP 连接消息，以及名为mcp-server-bitcoin-mcp.log（或您使用的任何名称）的文件以获取 MCP 服务器的输出/错误。这些日志将显示服务器是否启动或是否存在任何错误（例如路径错误或服务器异常）。如果您发现错误，请根据需要修复配置或环境，然后重新启动 Claude Desktop 并再次测试。
🦆 Goose 集成
Goose 是由 Block 开发的开源 AI 代理框架，支持通过模型上下文协议 (MCP) 进行扩展。您可以将比特币 MCP 服务器集成为 Goose 扩展，以便 Goose 与比特币区块链进行交互。Goose 支持两种 MCP 服务器集成模式：将服务器作为本地进程 (STDIO) 运行，或通过服务器发送事件 (SSE) 将其作为远程服务连接。以下是两种方法的说明：
使用 STDIO（本地扩展）
该方法在本地运行比特币 MCP 服务器作为 Goose 的子进程，通过标准输入/输出进行通信。
在 Goose 中添加新扩展：打开 Goose 的配置界面。您可以通过命令行运行
goose configure来执行此操作，或者在 Goose 桌面应用中前往“设置”>“扩展”。从菜单中选择**“添加扩展”。** （ 使用扩展 | goose ）选择扩展类型 - 命令行扩展：当提示输入扩展类型时，选择命令行扩展（在 CLI 菜单或 UI 中），以便 Goose 知道它应该启动本地命令（ 使用扩展 | goose ）（而不是内置或远程扩展）。
**输入扩展详细信息：**提供比特币 MCP 服务器的名称和命令：
**名称：**您可以将其称为“比特币”，或任何标识符（这将是您引用扩展的方式）。
**命令：**指定如何运行 MCP 服务器。例如，如果您有 Python 脚本，请输入运行该脚本的命令。在 CLI 配置器中，系统可能会询问“应该运行什么命令？”，您可以输入：
npx -y bitcoin-mcp@latest这告诉 Goose 启动比特币 MCP 服务器 ( GitHub - AbdelStark/bitcoin-mcp: Bitcoin MCP Server )。（请确保使用正确的服务器脚本路径或正确的命令来运行服务器，就像在 Claude 配置中一样。）
通常，除了脚本路径之外，您无需添加任何参数（除非您的服务器需要特殊标志）。上述命令使用默认的 STDIO 传输，Goose 期望该传输方式用于命令行扩展。（在 Goose 配置文件中，这对应于一个包含
cmd: "npx"和args: ["-y", "bitcoin-mcp@latest"]条目，其中type: stdio表示标准 I/O 模式（ 使用扩展 | goose ）。）
完成并启用：完成扩展添加。Goose 会将此新扩展添加到其配置中（通常为
~/.config/goose/config.yaml）。确保扩展已启用（如果使用 CLI 向导，则添加后应默认启用；在 Goose Desktop 应用中，您可以检查扩展列表，如果尚未启用，请将其切换为启用状态（ 使用扩展 | goose ）（ 使用扩展 | goose ））。**使用新扩展启动 Goose 会话：**您现在可以在 Goose 中使用该扩展。如果您通过 CLI 运行 Goose，请运行以下命令启动包含该扩展的会话：
goose session --with-extension "bitcoin"
将“bitcoin”替换为您为扩展程序指定的任何名称（ 使用扩展程序 | goose ）。 （这可确保会话加载扩展程序。或者，如果扩展程序已全局启用，则 Goose Desktop 或 CLI 将自动在所有会话中提供该扩展程序。）
使用 SSE（远程扩展）
此方法通过 HTTP SSE 流将 Goose 连接到已运行的 MCP 服务器。如果您想将比特币 MCP 服务器作为独立服务运行（可能在另一台机器上，或者独立于 Goose），请使用此方法。
**将 MCP 服务器作为独立服务启动：**运行比特币 MCP 服务器，使其监听连接。实际上，这意味着服务器需要以服务于 MCP HTTP 端点的模式启动。例如，您可以使用特定命令或选项运行服务器以监听端口（例如，使用 MCP 库的内置 Web 服务器功能或在 Web 框架下运行）。确保服务器可以通过已知 URL（例如
http://localhost:9000）访问，并支持基于 SSE 的 MCP 协议。在 Goose 中添加新扩展（远程）：像以前一样，运行
goose configure或使用 Goose UI添加扩展（ 使用扩展 | goose ）。这次，当系统询问扩展类型时，选择**“远程扩展”** （ 使用扩展 | goose ）。这会告诉 Goose 它将通过 SSE 连接到外部服务器。输入远程扩展的详细信息：为扩展命名（例如，“bitcoin”）并提供服务器的 URL。对于URL ，请输入 MCP 服务器运行的基址。例如，如果您的服务器在本地计算机上监听的是 9000 端口，您可以输入
http://localhost:9000。Goose 将尝试连接到该地址的 MCP 服务器的 SSE 端点。（Goose 使用标准的 MCP SSE 路径，按照惯例位于服务器上的/mcp/sse路由下，您通常只需提供主机名和端口号，Goose 会处理其余部分。）**启用扩展：**添加远程扩展后，请确保在 Goose 的设置中启用该扩展（与 STDIO 的情况类似）。STDIO 或 SSE 扩展（使用相同的工具）只需启用其中一个即可——如果您不小心同时启用了同一服务器的本地版本和远程版本，则可能需要禁用其中一个以避免混淆。
**在 Goose 中使用比特币 MCP 扩展：**设置扩展程序（通过上述任一方法）并启用后，您就可以与 Goose 交互并通过它查询比特币数据。在新的 Goose 聊天或会话中，您可以像平常一样提问。Goose 会识别何时使用比特币 MCP 工具来满足您的请求。例如：
“最新的比特币区块是多少？”
“请向我提供有关 TXID 为 abcdef1234567890abcdef1234567890abcdef1234567890abcdef1234567890 的交易的信息。”
当你提出这些问题时，Goose 会调用 MCP 服务器的工具并返回答案（例如，最新的比特币区块信息）。你应该会看到 Goose 通过 MCP 服务器从比特币区块链中提取最新信息进行响应。
如果 Goose 似乎未使用该扩展程序（例如，它响应说找不到信息），请确保该扩展程序已启用且服务器正在运行（远程服务器处于 SSE 模式）。您还可以运行 Goose 的 CLI 并设置详细日志记录，以查看它是否尝试调用该扩展程序。通常，如果配置正确，Goose 会自动发现 MCP 服务器的功能并在需要时使用它们。
**更多资源：**有关 Goose 扩展和 MCP 的更多详细信息，请参阅 Goose 官方文档（ 使用扩展 | goose ）。该文档包含内置扩展和社区扩展的列表，并解释了 MCP 服务器如何集成到 Goose 中。您还可以在 Goose 文档和模型上下文协议文档中找到可用 MCP 服务器的目录和其他配置技巧。如果您想探索更多扩展或开发自己的扩展，这些文档会对您有所帮助。
📦开发设置
在开发设置指南中查找设置说明。
闪电网络配置（可选）
要使用闪电网络功能，您需要配置 LNBits 连接详细信息。这些配置是可选的，仅当您计划使用闪电网络工具时才需要。
{
"lnbitsUrl": "https://demo.lnbits.com",
"lnbitsAdminKey": "your_admin_key", // Required for making payments
"lnbitsReadKey": "your_read_key" // Required for wallet information
}您可以通过以下方式获取这些值：
在LNBits创建账户
创建新钱包
前往 API 信息查找您的 API 密钥
📦可用工具
在API 参考指南中查找可用的工具。
🚨错误处理
服务器使用自定义错误类型来处理比特币操作和区块链查询。详细的错误消息使用 Pino 记录，并包含在客户端响应中，以便于调试。
🤝 贡献
欢迎贡献代码和提出功能请求！欢迎在 GitHub 上提交 Pull 请求或提出问题。
📝 许可证
该项目已获得MIT 许可。
Available Tools
7 toolsdecode_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.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
7 tool updates
- First observed
decode_invoice - First observed
decode_tx - First observed
generate_key - First observed
get_latest_block - First observed
get_transaction - First observed
pay_invoice - First observed
validate_address
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
Related MCP Connectors
Bitcoin + Ethereum RPC for AI agents. 44 tools. x402 payments in USDC on Base mainnet.
Bitcoin wallet intelligence for AI agents: trust, labels, tx verify, fees, and timestamps.
Bitcoin and YouTube video intelligence for AI agents. Pay-per-call via x402 USDC on Base.
Deterministic MCP utilities, validation, evidence verification, and x402 commerce on Base.
Related MCP Servers
- AlicenseBqualityFmaintenanceImplements 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.10106 npm79MIT
Satstream MCP Serverofficial
AlicenseBqualityDmaintenanceA 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.37MIT- AlicenseBqualityDmaintenanceA 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.316 npm5MIT
