evm_signLABSCO SUMMARY
Nothing leaves the machine, but the key travels through the tool call.
There is no HTTP transport, no listening port and no call out to any service — signing happens locally with the standard libraries for each chain, which is the right shape for a signer. The consequence worth reasoning about is where the key goes: it arrives as a parameter on the tool call rather than from the environment, so it passes through whatever your client logs, stores or includes in that call. Pair it with the broadcast package when the signed transaction actually needs to reach a chain, and remember that the two x402 paths hand back a signature or a re-serialized transaction rather than a broadcastable hex.
What it is
A local transaction signer exposed over MCP. Six tools cover EVM chains, UTXO chains, Tron, XRP, Kaspa and Solana, each taking the transaction and the key as call parameters and returning something ready to broadcast. It speaks stdio only, listens on no port, and makes no HTTP call to Crypto APIs or anywhere else.
What you get
- evm_sign covers Ethereum, Ethereum Classic, BSC, Polygon, Avalanche C-Chain, Arbitrum, Base, Optimism and Tron, either from structured transaction fields or from a pre-built unsigned hex
- evm_sign also signs EIP-712 typed data — the x402 gasless path, such as the EIP-3009 TransferWithAuthorization from a buyer's /authorize — returning a signature rather than a transaction
- utxo_sign covers Bitcoin, Bitcoin Cash, Litecoin, Dogecoin, Dash and Zcash, from a prepared inputs-and-outputs object or a raw unsigned hex with input descriptors
- tron_sign signs with secp256k1 and no TronWeb dependency, and xrp_sign handles XRP from structured fields or unsigned hex
- kaspa_sign uses schnorr (BIP340) through kaspa-wasm, mainnet only
- svm_sign partial-signs a Solana x402 payment, adding only the buyer's source-authority signature and leaving the facilitator's feePayer slot to be signed at settlement
- Most tools return signedTransactionHex ready to broadcast; the x402 paths return a signature or a re-serialized transaction instead
Requirements
npx @cryptoapis-io/mcp-signer over stdio. No API key and no account. The private key travels as a tool parameter — privateKey, privateKeys or secret — and is deliberately never read from an environment variable. Signing uses ethers for EVM, bitcoinjs-lib with ecpair and tiny-secp256k1 for UTXO, elliptic for Tron and xrpl for XRP. MIT.
Setup effort
One command — npm install @cryptoapis-io/mcp-signer
USE CASES
01
Signing an EVM transaction without a hosted wallet service
Build the transaction from fields or hand over a pre-built unsigned hex, and get the signed hex back without the transaction or the key crossing a network.
02
Paying an x402 invoice on Base
Sign the EIP-712 typed data from the buyer's authorize step. What comes back is a signature for the gasless transfer, not a transaction to broadcast.
03
Signing a Bitcoin-family transaction
Prepared inputs and outputs, or a raw unsigned hex with its input descriptors, across Bitcoin, Bitcoin Cash, Litecoin, Dogecoin, Dash and Zcash.
04
Covering chains outside the EVM and UTXO families
Tron with plain secp256k1 and no TronWeb, XRP from structured fields, and Kaspa through schnorr on mainnet — all in the same local process.
6 tools
Listed in project docs. Your client may show a different list.
utxo_signtron_signxrp_signkaspa_signsvm_signBEFORE YOU INSTALL
What to know first
Tools you get
6 tools named in the project's documentation.
Where it runs
Both documented clients run the server on your machine.
INSTALLATION
Connect your client
Server setup
TERMINAL
npm install @cryptoapis-io/mcp-signerMCP Clients
Claude Desktop, Cursor
JSON
{
"mcpServers": {
"cryptoapis-signer": {
"command": "npx",
"args": [
"-y",
"@cryptoapis-io/mcp-signer"
]
}
}
}
