Provides tools to interact with the Bitcoin network, including wallet management (create/restore wallets), sending transactions, retrieving balances, and real-time price conversion.
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., "@Bitcoin MCP Create a new Bitcoin wallet"
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.
A Model Context Protocol (MCP) server that provides Bitcoin tools for AI applications like Claude Desktop and Cursor, allowing them to interact with the Bitcoin Network and manage wallet operations.
The Bitcoin MCP server extends any MCP client's capabilities by providing tools to do anything with Bitcoin:
Create and restore Bitcoin and Ark wallets
Send Bitcoin and Ark transactions
Retrieve Bitcoin and Ark wallet balances
Real-time Bitcoin price conversion
Cache-optimized price fetching via blockchain.info
Strongly typed wallet operations
Comprehensive error handling and fallbacks
Schema validation with Zod
Integration with @arklabs/wallet-sdk
Related MCP server: RGB Lightning Network MCP Server
setup_walletCreate or restore a Bitcoin wallet:
{
action: "create" | "restore",
privateKey?: string,
network?: "bitcoin" | "testnet" | "signet" | "mutinynet",
arkServerUrl?: string,
esploraUrl?: string
}get_wallet_statusGet the current wallet status and initialization state.
get_addressesGet all wallet addresses.
get_balanceGet wallet balance with optional fiat conversion.
send_bitcoinSend Bitcoin to an address:
{
address: string,
amount: number, // in satoshis
feeRate?: number // optional fee rate
}This project uses:
pnpm - Package manager
Vite - Build system
Vitest - Testing framework
TypeScript - Language
Zod - Schema validation
Install dependencies:
pnpm installRun tests:
pnpm testBuild the project:
pnpm buildMIT License
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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. Dates show when Glama detected each change.
v0.0.1get_addressget_balancesend_bitcoinsetup_walletEach tool targets a distinct operation: wallet setup, balance query, transaction sending, and address retrieval. There is no overlap in their purposes.
All tool names follow a consistent verb_noun snake_case pattern: setup_wallet, get_balance, send_bitcoin, get_address. The naming is uniform and predictable.
With four tools, the set is well-scoped for a Bitcoin wallet server. Each tool covers an essential function without redundancy or unnecessary bloat.
The core wallet lifecycle is covered: setup, balance check, sending, and address generation. A minor gap is the lack of transaction history or receive mechanisms, but the essential operations are present.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
Provide AI agents and automation tools with contextual access to blockchain data including balance…
Non-custodial crypto payments for AI assistants: balances, payments, and create payment links.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/tiero/bitcoin-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
