Provides tools for querying live Bitcoin data from mempool.space, including recommended fees, mempool statistics, blocks, transactions, address balances, and price.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-mempool What are the current Bitcoin fees and mempool stats?"
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.
MCP (Model Context Protocol) server for the mempool.space Bitcoin API. No API key required.
Lets any MCP client (Claude Code, Claude Desktop, etc.) query live Bitcoin data: recommended fees, mempool state, blocks, transactions, addresses, price.
Tool | Arguments | Returns |
| — | Fee estimates in sat/vB (fastest, 30 min, 1 h, economy, minimum) |
| — | Unconfirmed tx count, total vsize, total pending fees |
| — | Current block height and hash |
|
| Recent blocks: height, time, tx count, median fee, mining pool |
|
| Confirmation status, fee, fee rate, inputs/outputs |
|
| Confirmed balance, received total, tx counts, pending delta |
| — | BTC price in USD, EUR, GBP, CAD, CHF, AUD, JPY |
Related MCP server: mcp-l402-gate-example
npm install
npm run buildexamples/client.mjs spawns the server over stdio and calls each tool:
npm run exampleclaude mcp add mempool -- node /path/to/mcp-mempool/dist/index.jsThen ask, for example: "quels frais je mets pour une transaction confirmée dans l'heure ?"
Add to claude_desktop_config.json:
{
"mcpServers": {
"mempool": {
"command": "node",
"args": ["/path/to/mcp-mempool/dist/index.js"]
}
}
}Set MEMPOOL_API_BASE to point elsewhere (default: https://mempool.space/api):
{
"mcpServers": {
"mempool-testnet": {
"command": "node",
"args": ["/path/to/mcp-mempool/dist/index.js"],
"env": { "MEMPOOL_API_BASE": "https://mempool.space/testnet4/api" }
}
}
}Works with any mempool.space-compatible instance (e.g. a self-hosted one on your own node).
Uses the public REST API; heavy usage should point MEMPOOL_API_BASE at a self-hosted instance (mempool.space rate-limits aggressively).
API errors are returned as MCP tool errors (isError: true) with the upstream message, so the model can react to them.
MIT
Get stats for a Bitcoin address: confirmed balance, total received/spent, and transaction counts (on-chain and in mempool).
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Bitcoin address (base58 or bech32) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It transparently lists the returned data categories including mempool transaction counts, indicating a read-only stats operation with no side effects. While it doesn't mention error conditions or unit conventions, it gives a solid picture of what the tool does.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys all essential information without redundancy. Every phrase contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool without an output schema, the description adequately explains the returned information and scope. It could specify units or field names, but for most use cases the listed metrics are sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the 'address' parameter (base58 or bech32, length constraints) with 100% coverage. The description adds no further parameter semantics, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get stats for a Bitcoin address' and enumerates specific metrics (confirmed balance, total received/spent, transaction counts). This distinguishes it from sibling tools like get_transaction or get_mempool_stats, which target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool – whenever address-level statistics are needed. It doesn't explicitly name alternatives or exclusions, but the resource definition ('Bitcoin address') makes the use case unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current state of the Bitcoin mempool: number of unconfirmed transactions, total virtual size (vBytes), and total pending fees in satoshis. Useful to judge network congestion.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the core return data (transaction count, vSize, fees) and indicates it is the 'current state', but does not elaborate on data freshness, response format, or absence of side effects. For a simple read-only getter, this is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that front-load the purpose and immediately mention the returned statistics. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with no output schema, the description fully covers what the tool returns and why it is used. It mentions all key output elements and a practical use case, leaving no notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter documentation burden. The description appropriately focuses on output semantics rather than input syntax, which is sufficient given the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get the current state of the Bitcoin mempool' and enumerates the specific statistics returned (unconfirmed transactions, virtual size, pending fees). This differentiates it from sibling tools like get_recommended_fees and get_transaction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'Useful to judge network congestion.' However, it does not explicitly mention when not to use this tool or compare it to alternatives, so it lacks explicit exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current Bitcoin price in USD, EUR, GBP, CAD, CHF, AUD, and JPY.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the core behavior—fetching current prices—and lists the currencies, but does not mention return format, update frequency, or potential network dependencies. This is moderately transparent for a simple read-only tool, but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence front-loads the action and resource, and the currency list is concise and pertinent. No filler words or redundant information; every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter price lookup tool, the description is largely complete: it names the exact data returned and the currencies. The lack of an output schema or return format description is a minor gap, but the tool's simplicity and the enumerated currencies make the output predictable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (trivially). The description adds semantic value by specifying which currency prices are returned, which is effectively the parameter space. With no params to document, the description adequately conveys the tool's inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb 'Get' and resource 'current Bitcoin price', and enumerates the supported currencies. This distinguishes it from sibling tools like get_recommended_fees or get_transaction, which cover different blockchain data areas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: whenever a current Bitcoin price is needed. It provides a clear context without explicitly mentioning alternatives, but the simple, specialized scope makes the usage obvious. No exclusions or alternative tool references are provided, but they are unnecessary given the tool's specificity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a summary of the most recent Bitcoin blocks: height, hash, timestamp, transaction count, size, and median fee. Returns up to 10 blocks.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of blocks to return (1-10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the return contents (height, hash, timestamp, transaction count, size, median fee) and the upper bound of 10 blocks. This is sufficient for a simple read-only tool, though it doesn't explicitly state that it's non-mutating.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences, front-loaded with the primary action, and every word adds value. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description fully covers what the tool does, what it returns, and its limit. The lack of output schema is compensated by listing all returned fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'limit' parameter, including default, min, max, and description. The description adds no new parameter details beyond reinforcing the 'up to 10' cap, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('recent Bitcoin blocks'), and lists the exact fields returned. This distinguishes it from sibling tools like get_tip, get_transaction, and get_mempool_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving recent block summaries, but offers no explicit guidance on when to choose this tool over siblings or any exclusions. It's clear enough for straightforward use, but lacks explicit comparative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current recommended Bitcoin transaction fees in sat/vB (fastestFee, halfHourFee, hourFee, economyFee, minimumFee). Call this when the user asks what fee to use for a transaction right now.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It correctly implies a read operation via 'Get' and lists the output fields, but it doesn't disclose additional behavioral details like response format, caching, or rate limits. This is adequate for a simple no-parameter tool but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and resource, and every word adds value. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description is complete. It specifies the fee fields returned, the unit (sat/vB), and the usage context, fully covering the tool's purpose and behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so the baseline is 4. The description adds no parameter details because there are none, and none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets current recommended Bitcoin transaction fees in sat/vB and lists the specific fee fields (fastestFee, halfHourFee, etc.), distinguishing it from siblings like get_tip (block height) and get_mempool_stats (mempool data).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit when-to-use guidance: 'Call this when the user asks what fee to use for a transaction right now.' However, it does not explicitly mention when not to use it or name alternative tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current Bitcoin chain tip: block height and block hash.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It accurately describes the return values and implies a read-only operation via the word 'Get'. It does not discuss side effects, but none are expected for this simple query.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately conveys the tool's purpose and output. No word is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameterless tool, the description fully explains what the tool returns (block height and hash). With no output schema, this fulfills the need to document return values. The tool's complexity is low, so this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the description does not need to explain any. The empty schema provides all necessary information, earning the baseline score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function: retrieving the current Bitcoin chain tip with its height and hash. This specific verb-resource pair distinguishes it from sibling tools that focus on fees, mempool stats, blocks, transactions, addresses, or prices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you need the current chain tip, but it does not explicitly state when to use it over alternatives. However, given the distinct purpose, the context is clear and there are no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details for a Bitcoin transaction by txid: confirmation status, block height, fee, size, and inputs/outputs summary.
| Name | Required | Description | Default |
|---|---|---|---|
| txid | Yes | Transaction ID (64 hex chars) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It transparently lists the types of data returned (confirmation status, block height, fee, size, inputs/outputs), giving the agent a clear expectation of the operation's output. It does not mention error cases, but as a read-only getter, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that leads with the action and resource, then lists specific data points. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter getter without an output schema, the description sufficiently covers what the agent needs to know: what the tool does and what information will be returned. The low complexity does not require additional details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the 'txid' parameter already described as a 64-character hex string. The tool description adds minimal semantic value (only 'by txid'), so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving Bitcoin transaction details by txid. It enumerates specific fields (confirmation status, block height, fee, size, inputs/outputs), distinguishing it from sibling tools that handle fees, mempool, blocks, addresses, and prices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the appropriate context: use when you have a transaction ID and need its details. It does not explicitly mention exclusions or alternatives, but given the distinct resource, the usage context is clear and unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct data resource: fees, mempool stats, chain tip, recent blocks, a specific transaction, an address, and price. No two tools overlap in purpose, making selection unambiguous.
All tools follow a consistent 'get_' verb + noun pattern (get_recommended_fees, get_mempool_stats, get_tip, get_recent_blocks, get_transaction, get_address, get_price). The naming scheme is uniform and predictable.
Seven tools is well-scoped for a mempool/blockchain information server. Each tool addresses a common need without redundancy, and the count is within the ideal 3-15 range.
The server covers fees, mempool state, chain tip, recent blocks, transactions, addresses, and price—covering the primary read-only use cases. A notable minor gap is the lack of a way to fetch a specific block by height or hash, but this is not critical for typical mempool queries.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
mempool.space MCP — Bitcoin block explorer + mempool/fee stats
Unlock the power of real-time cryptocurrency data with our Crypto Price Insights MCP server.
Hosted MCP server for live Bittensor chain reads and self-custodial on-chain writes.
Read-only Bitcoin blockchain, mempool, mining, market, and on-chain analytics; no API key.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Ethosbtc/mcp-mempool'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
