# BSV MCP BSV MCP connects your AI assistant to Bitcoin SV. Ask it to check a transaction, show your balance, send a payment, or create and trade ordinals (content recorded on the blockchain). [Documentation](https://bsvmcp.com/docs) · [All tools](https://bsvmcp.com/docs/tools) · [npm](https://www.npmjs.com/package/bsv-mcp) · [Issues](https://github.com/b-open-io/bsv-mcp/issues) ## Install Install [Bun](https://bun.sh) to run the server and Node.js for the `npx` commands below, then add it to your client: ```sh # Codex codex mcp add bsv-mcp -- npx -y bsv-mcp@latest --stdio # Claude Code claude mcp add --transport stdio bsv-mcp -- npx -y bsv-mcp@latest --stdio # Grok Build grok plugin install b-open-io/bsv-mcp --trust ``` Choose one command. For Cursor or Claude Desktop, use this server configuration: ```json { "mcpServers": { "bsv-mcp": { "command": "npx", "args": ["-y", "bsv-mcp@latest", "--stdio"] } } } ``` Restart your client, then ask: **“Run bsv_status and explain what is available.”** Local stdio needs no Sigma account or OAuth sign-in. It is also the default when no transport is specified. Existing self-hosted HTTP remains opt-in through `TRANSPORT=http`; the deployed hosted endpoint is unchanged. For the Codex desktop plugin, add `b-open-io/claude-plugins` in the plugin marketplace and install **BSV MCP**. The plugin starts the local npm executable and requires Node.js and Bun. Claude Code and Grok plugins bundle the local server and require Bun. Choose one registration to avoid duplicate tools. ## Connect a wallet Ask your assistant to run `wallet_onboarding`. Create, import or unlock a Vault in the local browser. Back it up before funding. Enter passwords only in the local setup UI, never in chat. After a server restart, unlock it again. To use an existing BRC-100 wallet, configure its signing API instead: ```json { "mcpServers": { "bsv-mcp": { "command": "npx", "args": ["-y", "bsv-mcp@latest", "--stdio"], "env": { "BRC100_WALLET_URL": "http://127.0.0.1:3321", "BRC100_WALLET_ORIGINATOR": "bsv-mcp.local" } } } } ``` The wallet keeps its keys and controls permission requests. Its signing API is separate from a wallet-storage endpoint. See [wallet setup](https://bsvmcp.com/docs#wallets) for network settings, account selection and project roles. The package also includes the Bun-based `bsv-mcp-local` launcher for explicit external, legacy embedded and project configurations. Source-checkout examples live in [the installation guide](docs/install-verification.md). ## MCP protocol compatibility Protocol revision `2026-07-28` is preferred, with supported 2025 clients accepted automatically on stdio and HTTP. No compatibility override is needed. Set `MCP_LEGACY_COMPATIBILITY=false` only to require modern clients. This setting also passes through the local launcher. The installed desktop client was verified using legacy requests; modern support is tested separately. Modern clients support wallet operations and request-scoped approval. Approval continuations retain the original operation and bind to its authenticated user, arguments, and expiry. Decline, cancellation, or session revocation stops the operation; replaying a continuation does not repeat a transaction. A client without form elicitation cannot approve a spend. External wallets retain their own signer permission flow. The hosted route exposes public reads only. For the split SDK v2 client: ```ts const client = new Client( { name: "my-app", version: "1" }, { versionNegotiation: { mode: "auto" }, capabilities: { elicitation: { form: {} } } }, ); ``` Register a real human approval handler before using approval-dependent tools. Legacy protocol compatibility is enabled by default; the connected client must support the approval flow needed by the requested tool. The full tool catalog remains the default and is capability-derived: wallet mode, enabled modules, account context, and the selected profile determine what `tools/list` returns. The checked-in manifest is a synthetic baseline for one configured server, not a promise of a fixed default count. Set `MCP_TOOL_CATALOG=compact` only to opt into bounded read families; compact mode uses the same underlying handlers. Tool availability still depends on wallet mode and enabled modules. Its baseline read families are `bsv_read`, `ordinals_read`, `wallet_read`, and `utility`, each with a bounded operation enum; unknown operations are rejected. Eligible sessions also expose separate mutating `wallet_setup` and `wallet_payments` families. See the [MCP client protocol support guide](docs/mcp-client-protocol-support.md) for the per-family operation bounds, endpoint contracts, MCP Apps compatibility, and validation status. ## Social Two tools cover social operations in both full and compact catalogs: - `bsocial_read`: posts, replies, search, likes, friends, channels, messages, videos, and raw action history. - `bsocial_publish`: posts/replies, reposts, likes/unlikes, follows/unfollows, friend/unfriend records, messages, and video records. Tags and attachments use separate, independently signed outputs. ```json {"action":{"type":"post","content":"Hello Bitcoin","tags":["bitcoin"]},"preview":true} ``` Preview returns unsigned outputs without using keys or spending. Remove `preview` to publish through the selected identity wallet's existing permissions. Messages are public unless their content was encrypted beforehand; a recipient context does not encrypt them. Friend records advertise a communication public key from an established key-agreement workflow. See the [social guide](https://bsvmcp.com/docs#social) for examples and migration from the old tool names. `PUBLIC_BMAP_URL` is the indexer server root (with `/social` and `/q` routes), not a wallet or identity API. Raw follow/unfollow records are event history, not a claim about current relationship state. ## Local wallet modes External mode connects to an existing BRC-100 signer. The signer keeps the private keys, wallet storage, and permission decisions; BSV MCP receives only the SDK signer interface. Embedded mode uses an encrypted local Vault wallet. The wallet-ready screen displays an interactive cloud of the connected session’s available tools, generated from its live catalog. When setup is needed, `wallet_onboarding` opens the private browser flow to create, import, or unlock it. The selected account's database and storage configuration remain in use. The launcher's existing-account embedded mode still supplies `BSV_MCP_PASSWORD` at runtime. Project mode opens every explicitly assigned role: `payments`, `identity-signing`, `one-sat`, and `encryption`. It requires paired project selectors and `BSV_MCP_PASSWORD` at runtime; set `VAULT_PATH` when the Vault module does not provide a default path. Bindings pin the selected public key and support direct keys, BRC-42 children, and BRC-157/Yours profile leaves. Changing the project binding or expiring its session revokes captured handles. Derived keys have separate storage; selecting the account's payment root keeps its existing database and deposit prefix. BRC-100 tools accept `walletRole` (`payments`, `identity`, `ordinals`, or `encryption`). Method defaults select the matching role, and sign/abort action continuations retain their originating wallet and authenticated user. An unassigned role fails rather than borrowing another key. BAP tools use the identity wallet for publication, rotation, attestations, and profiles without exporting an xprv. That wallet also funds those transactions and retains BAP records. Signed BSocial posts and SIGMA inscriptions use the configured identity. External registrations can use the same project root/ID pair to derive an isolated permission origin, without a Vault password. Optional `BRC100_WALLET_PUBLIC_KEY` pins the signer identity. `BRC100_WALLET_ROLES` is a JSON object selecting independent role endpoints and public-key pins; see [external signer configuration](docs/external-signer.md). The source launcher accepts `external --project-root /absolute/project --project-id project.example`. It defaults to disabled broadcasting; set `DISABLE_BROADCASTING=false` in its runtime environment to enable transaction tools with the signer's approval. Each mode has its own process environment and should be registered as a separate server when you need to switch between them. Use only the registrations needed by the project. Embedded wallets can list pending PeerPay payments and receive a selected payment with `wallet_peerPayments`. Receiving requires a message ID and acknowledges the message only after the wallet accepts it. These operations do not pay MessageBox service fees. External signers and Droplit do not expose this tool. Project sessions require an assigned payment role. ## Find a skill Use `utils_find_skills` with a short keyword query to find skills in the bOpen catalog. It returns up to five descriptions and links to versioned `SKILL.md` files. It does not download skill contents or install plugins. In compact mode, select `utils_find_skills` from the `utility` tool. The static tutorial prompts and BRC/BitCom resource catalog have been retired. Use the skill finder for those references. Changelog, JungleBus documentation, and the dashboard app resource remain available. ## Bring your wallet and infrastructure Connect a compatible existing wallet with `BRC100_WALLET_URL`, or use the local Vault browser setup (`wallet_onboarding`). `BSV_MCP_PASSWORD` is only for headless agents: set it in the process environment for that session, never in MCP client configuration. `PRIVATE_KEY_WIF` and `IDENTITY_KEY_WIF` are migration sources, not live signing keys; import them into Vault and remove the plaintext copies. Startup never creates keys. See the wallet setup guide for the required wallet API and configuration. The default 1Sat API backend is `https://api.1sat.app`. New mainnet embedded accounts use `https://wallet.1sat.app` for wallet storage by default; testnet accounts do not select a remote storage provider unless configured. Override `ONESAT_API_URL` for API services and `REMOTE_STORAGE_URL` for wallet storage; these are separate settings. Available tools depend on wallet mode and enabled modules. - [Wallet setup](https://bsvmcp.com/docs#wallets) - [Backend configuration](https://bsvmcp.com/docs#backends) - [Tools and workflows](https://bsvmcp.com/docs/tools) - [Paid service requests](https://bsvmcp.com/docs#x402) - [Sponsorship](https://bsvmcp.com/docs#sponsorship) and [agent delegation](https://bsvmcp.com/docs#delegation) - [Troubleshooting and development](https://bsvmcp.com/docs#troubleshooting) ## Development ```sh bun install bun run dev # Website bun run build:all # MCP server and dashboard # Supply BRC100_WALLET_URL in the host environment before this launch. bun --no-env-file scripts/local-mcp-launcher.ts external # Source-checkout local launch bun test ``` Experimental software; APIs may change. Keep a wallet backup. If a transaction request times out, check whether it succeeded before sending it again. MIT licensed. ## Preparing a release package `package.json` `"files"` is the tarball. `prepack` runs `bun run build:all`. Publish with `bun publish`. Compile-time libraries are `devDependencies`; consumers get the bundled `dist/` files, not a second copy of the source tree.