Provides tools to obtain Bitcoin-related information, such as recommended transaction fees from Mempool.space.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-server-ddd-template Get Bitcoin fee recommendations"
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.
This repository is a template implementation of a Model Context Protocol (MCP) server in Node.js/TypeScript, designed to demonstrate a clean, layered architecture using Domain-Driven Design (DDD) principles. It provides tools to obtain Bitcoin-related information via external APIs.
šļø Template Project: This codebase serves as a reference template for structuring MCP servers with DDD, ready for customization and production use.
š MCP Protocol: Communicates via stdio using the MCP protocol (@modelcontextprotocol/sdk).
šļø Layered DDD Architecture: Clear separation of domain, application, infrastructure, and interface layers.
ā” TypeScript: Fully typed with modern TypeScript for better development experience.
Related MCP server: Bitcoin-MCP-Server
src/
āāā domain/ # šļø Domain models and response interfaces
ā āāā models/
ā āāā responses/
ā āāā ** interfaces responses **
āāā infrastructure/ # š External API clients and request services
ā āāā interfaces/
ā ā āāā IApiClient.ts
ā āāā services/
ā āāā clients/
ā ā āāā ** client api
ā āāā requests/
ā āāā ** requests services **
āāā application/ # āļø Business logic and helpers
ā āāā services/
ā ā āāā ** services implementation **
ā āāā helpers/
ā āāā ** helpers **
āāā interface/ # š® Controllers (MCP tool registration)
ā āāā controllers/
ā āāā base/
ā ā āāā BaseToolsController.ts
ā āāā **controllers to inteface**
ā āāā index.ts
āāā shared/ # š Shared types/parameters
ā āāā parameters/
ā āāā **interfaces parameters**
āāā main.ts # š Application entry pointgit clone https://github.com/alexandresanlim/mcp-server-ddd-template.git
cd mcp-server-ddd-template
npm install
npm run buildAfter building, you can run the server directly:
node build/main.jsOr, if registered as a binary (for example, mcp-server-ddd-template):
npm link
mcp-server-ddd-templateThe server will start on standard output (stdio) and wait for MCP requests.
š° get-recommended-fees: Get recommended Bitcoin transaction fees from Mempool.space
š ping: Simple health check endpoint
To use this MCP server as a tool provider in a client (e.g., Claude client), you can either reference a local build or use the published npm package.
"btc-server": {
"command": "node",
"args": [
"{your project path}/mcp-server-ddd-template/build/main.js"
]
}# Build for Unix/Linux/macOS
npm run build
# Build for Windows
npm run build:windows
# Run the server
npm run server@modelcontextprotocol/sdk: MCP protocol implementation
zod: Runtime type validation
typescript: Type safety and compilation
Pull requests are welcome! Feel free to open issues or suggest improvements for this template repository.
ā Star this repository if you find it helpful!
Returns details about a block from hash
| Name | Required | Description | Default |
|---|---|---|---|
| hash | Yes | The hash info to get block |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits like side effects, read-only nature, or response format. The phrase 'Returns details' lacks specificity.
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?
Single sentence with no wasted words; front-loaded with the key action and resource.
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 output schema, the description is minimally adequate but lacks information about what 'details' are returned, reducing completeness.
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% (1 parameter fully described), so baseline is 3. The description 'The hash info to get block' adds minimal meaning beyond the existing schema definition.
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?
Description uses specific verb 'Returns' and resource 'block' with input 'hash', clearly distinguishing from sibling tools like get-ping and get-recommended-fees which have different purposes.
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?
No explicit guidance on when to use this tool versus alternatives, but the description's specificity makes usage obvious given the siblings' distinct functions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get ping to check service is working
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It states the tool checks service availability but does not disclose any side effects or latency. For a trivial ping, this is adequate.
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 concise sentence with no wasted words. It is front-loaded with the action and purpose.
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?
Given the tool has no parameters, no output schema, and trivial complexity, the description fully covers its purpose and usage.
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?
No parameters exist (0 params), so the description adds no parameter info beyond the schema. Schema coverage is 100% trivially.
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 'Get ping to check service is working' clearly states the verb (get) and resource (ping). It is distinct from sibling tools get-block and get-recommended-fees, which have different purposes.
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?
No explicit when-to-use or when-not-to-use guidance is provided, but for a simple health check, the usage context is obvious. A score of 3 reflects the lack of explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recommended fees for Bitcoin
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided and the description does not disclose behavioral traits such as data source or side effects; even for a simple get, more transparency is needed.
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?
Extremely concise, one sentence, front-loaded with the key verb and resource, no wasted words.
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 is largely complete, though it could mention return format or basis of fees.
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?
No parameters exist, so schema coverage is 100%. The description adds no parameter meaning, but baseline is 3 for high coverage.
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 verb 'Get' and the resource 'recommended fees for Bitcoin', distinguishing it from siblings like get-block and get-ping.
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?
No guidance on when to use this tool vs alternatives; the description is minimal without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0get-blockget-pingget-recommended-feesScored across 3 tools
Each tool targets a distinct purpose: block details, health check, and fee recommendations. There is no overlap or ambiguity.
All tools follow a consistent 'get-' prefix with hyphenated lowercase naming, forming a clear pattern.
Three tools is a reasonable count for a minimal Bitcoin service, though the server's purpose as a template might justify even fewer.
The set covers block retrieval, health checking, and fee recommendations, but lacks common Bitcoin operations like transaction handling, making it somewhat incomplete for a full service.
MCP server with quote and live cryptocurrency price tools, local and cloud-deployed transports.
MCP server for Modern Treasury ā payment orders, transactions, counterparties and ledgers.
MCP server for Boson Protocol ā on-chain agentic commerce for physical & digital goods.
A paid remote MCP for CLI tool MCP, built to return verdicts, receipts, usage logs, and audit-ready
