> For the complete documentation index, see [llms.txt](https://docs-core.allbridge.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs-core.allbridge.io/ai/local-signer-mcp.md).

# Local Signer MCP

It keeps private keys local and only receives the unsigned payload that needs to be signed.

* Repository: [allbridge-io/local-signer-mcp](https://github.com/allbridge-io/local-signer-mcp)
* Docker image: [allbridge/local-signer-mcp:latest](https://hub.docker.com/repository/docker/allbridge/local-signer-mcp/tags?name=latest)

### What it does

Use Local Signer MCP when you need to:

* sign a transaction locally
* sign and broadcast from a local wallet
* keep private keys on the user's machine
* work with desktop MCP clients
* finish execution after another system prepares the unsigned payload

### What it does not do

Local Signer MCP does not:

* plan routes
* quote transfers
* discover docs
* model bridge execution logic

Those responsibilities stay with Allbridge MCP.

### Client integrations

Use stdio when the client can launch a local process on the same machine.

Typical local clients include Claude Desktop, Claude Code, Cursor, Windsurf, Continue, Zed, and Cline.

For local setups, the config entry should add local-signer as one more registry entry instead of replacing the rest of the file.

For Docker-based local setups, use docker run with --env-file so the signer variables stay in a host-side env file and do not appear as separate command-line flags.

For remote connectors, use streamable-http only when the client actually requires a URL.

### Transport and security

stdio is the default local shape.

Docker is still local-first and useful when you want the same stdio entrypoint in a container.

streamable-http is the URL-based shape and should be used only when needed.

For GUI clients, prefer an explicit Node path instead of a bare node command.

### Wallet selection

Local Signer MCP can expose more than one wallet, and the client should choose the intended one explicitly.

Prefer the most specific identifier available:

* walletId when the client already knows the configured local wallet
* from when the flow is EVM-based and the sender address is enough to select the wallet
* explicit wallet-family hints when the request is chain-specific

Selection rules:

* For EVM, choose the wallet that owns the sender address.
* For Solana, Tron, Algorand, Stacks, Soroban / Stellar, and Sui, prefer the configured wallet entry for that family.
* When more than one wallet exists, use walletId instead of guessing.

### Usage

Local Signer MCP is used after another system has prepared an unsigned payload.

The common flow is:

1. An orchestration layer creates an unsigned transaction or bridge step.
2. Local Signer MCP signs the payload locally.
3. The signed payload is broadcast by the appropriate system or client.

Supported execution patterns:

* sign only
* sign and broadcast
* broadcast an already signed transaction

### Examples

Use the examples as starting points when you want a ready-made client config or a flow example.

Canonical starting points:

* Claude Code registration
* Claude Desktop config
* Cursor or similar client config
* Docker-based registration

For Docker, the key idea is simple: keep secrets in --env-file and keep the command line short.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs-core.allbridge.io/ai/local-signer-mcp.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.