@cryptoapis-io/mcp-signer
Official# @cryptoapis-io/mcp-signer
MCP server for **local transaction signing** across EVM, UTXO, Tron, XRP, Kaspa, Solana and Tezos. No Crypto APIs HTTP calls — signing happens entirely on your machine. No API key required.
## Security
- **Stdio only** — no HTTP transport. The server does not listen on any port.
- **Private keys in tool input** — each tool receives `privateKey` / `privateKeys` / `secret` as parameters. Keys are never read from environment variables.
- **No network calls** — all signing is done locally using cryptographic libraries.
## Installation
```bash
npm install @cryptoapis-io/mcp-signer
```
Or install all Crypto APIs MCP servers: `npm install @cryptoapis-io/mcp`
## Usage
```bash
npx @cryptoapis-io/mcp-signer
```
### Claude Desktop
Add to your Claude Desktop config (`~/Library/Application Support/Claude/claude_desktop_config.json` on macOS, `%APPDATA%\Claude\claude_desktop_config.json` on Windows):
```json
{
"mcpServers": {
"cryptoapis-signer": {
"command": "npx",
"args": ["-y", "@cryptoapis-io/mcp-signer"]
}
}
}
```
### Cursor
Add to `.cursor/mcp.json` (project) or `~/.cursor/mcp.json` (global):
```json
{
"mcpServers": {
"cryptoapis-signer": {
"command": "npx",
"args": ["-y", "@cryptoapis-io/mcp-signer"]
}
}
}
```
### MCP Inspector
```bash
npx @modelcontextprotocol/inspector npx @cryptoapis-io/mcp-signer
```
## Available Tools
### `evm_sign`
Sign an EVM transaction (Ethereum, Ethereum Classic, BSC, Polygon, Avalanche (C-Chain), Arbitrum, Base, Optimism, Tron).
| Action | Description |
|--------|-------------|
| `sign-from-details` | Sign from structured transaction fields (to, value, gasLimit, etc.) |
| `sign-unsigned-hex` | Sign a pre-built unsigned transaction hex |
| `sign-typed-data` | Sign an EIP-712 typed-data message (the x402 gasless path — e.g. the EIP-3009 `TransferWithAuthorization` from the x402 buyer `/authorize`). Returns `{ signature }`, not a tx. |
### `utxo_sign`
Sign a UTXO transaction (Bitcoin, Bitcoin Cash, Litecoin, Dogecoin, Dash, Zcash).
| Action | Description |
|--------|-------------|
| `sign-from-details` | Sign from a prepared transaction object (inputs, outputs). For zcash, produces a v5 (ZIP 225/244) transaction and requires exactly one of `targetHeight` (current chain tip + 1) or `consensusBranchId` (e.g. a node's `getblockchaininfo` `consensus.nextblock`) |
| `sign-unsigned-hex` | Sign a raw unsigned transaction hex with input descriptors. Does not support zcash |
### `tron_sign`
Sign a Tron transaction using secp256k1 (no TronWeb dependency).
| Action | Description |
|--------|-------------|
| `sign-from-details` | Sign from a transaction object with `raw_data_hex` |
| `sign-unsigned-hex` | Sign a pre-built unsigned transaction hex |
### `xrp_sign`
Sign an XRP transaction.
| Action | Description |
|--------|-------------|
| `sign-from-details` | Sign from structured XRP transaction fields |
| `sign-unsigned-hex` | Sign a pre-built unsigned transaction hex |
### `kaspa_sign`
Sign a Kaspa transaction using schnorr (BIP340) via `kaspa-wasm`. Mainnet only.
| Action | Description |
|--------|-------------|
| `sign-from-details` | Sign a prepared Kaspa transaction (from the prepare-transaction API) |
### `svm_sign`
Partial-sign a Solana (SVM) x402 payment transaction — the buyer's source-authority signature only
(the facilitator's feePayer slot stays unsigned, signed at settle).
| Action | Description |
|--------|-------------|
| `partial-sign` | Deserialize the base64 unsigned TransferChecked tx from the x402 buyer `/authorize` (scheme `svm-transaction`), add the buyer signature, re-serialize to base64. Returns `{ transaction }`. |
### `tezos_sign`
Sign a Tezos operation for tz1 (ed25519), tz2 (secp256k1) or tz3 (P-256) keys (`edsk…` / `spsk…` / `p2sk…`).
| Action | Description |
|--------|-------------|
| `sign-forged-operation` | Sign the `forgedOperation` hex from `prepare_transactions_tezos`. The operation is decoded first: only reveal/transaction ops from the key's own address are signed, and the optional `expected` (`destination`, `amount` in mutez, `maxFee`) must match. Returns `{ signedOperation, operationHash, signature, … }`; broadcast `signedOperation`. |
Most tools return `signedTransactionHex` — ready to broadcast with `@cryptoapis-io/mcp-broadcast`. The
x402 paths return `{ signature }` (EVM typed-data) or `{ transaction }` (SVM) instead.
## Dependencies
| Package | Purpose |
|---------|---------|
| `ethers` | EVM transaction signing |
| `bitcoinjs-lib` + `ecpair` + `tiny-secp256k1` | UTXO transaction signing |
| `elliptic` | Tron transaction signing (secp256k1) |
| `xrpl` | XRP transaction signing |
## License
MIT
TDQS
Scored across 7 tools
Each tool maps to a distinct chain family (UTXO, EVM, Kaspa, SVM, Tron, Tezos, XRP), so an agent can pick purely from the blockchain name. The only mild overlap is utxo_sign vs kaspa_sign (both UTXO-style), but Kaspa's schnorr/blockDAG specifics and explicit exclusion from utxo_sign make the boundary clear. Multi-action tools are documented with enumerated actions, keeping intra-tool selection unambiguous.
All seven tools follow an identical <chain>_sign pattern (utxo_sign, evm_sign, kaspa_sign, svm_sign, tron_sign, tezos_sign, xrp_sign). Predictable, scannable, and no mixed conventions or stray verbs.
Seven tools is well within the sweet spot and each one earns its place by covering a distinct signing domain. The multi-action design (sign-from-details, sign-unsigned-hex, typed-data, partial-sign) avoids fragmenting into dozens of per-action tools.
The signing lifecycle is well covered across major chains, including niche needs like x402 gasless EIP-712 and Solana partial-sign. Gaps exist: EVM lacks a plain personal_sign/message-signing action, and there is no key/address derivation or verify tool, though these are workable around. Broadcasting is delegated to other services (referenced in tezos_sign), so the surface is coherent for a signer-only server.