Skip to main content
Glama
Sign In
@cryptoapis-io/mcp-signer

@cryptoapis-io/mcp-signer

Official
by CryptoAPIs-io
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

@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.

Related MCP server: local-kms-mcp-server

Installation

npm install @cryptoapis-io/mcp-signer

Or install all Crypto APIs MCP servers: npm install @cryptoapis-io/mcp

Usage

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):

{
  "mcpServers": {
    "cryptoapis-signer": {
      "command": "npx",
      "args": ["-y", "@cryptoapis-io/mcp-signer"]
    }
  }
}

Cursor

Add to .cursor/mcp.json (project) or ~/.cursor/mcp.json (global):

{
  "mcpServers": {
    "cryptoapis-signer": {
      "command": "npx",
      "args": ["-y", "@cryptoapis-io/mcp-signer"]
    }
  }
}

MCP Inspector

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

Available Tools

7 tools
evm_signA

Sign an EVM transaction or EIP-712 typed-data message. Three actions: (1) sign-unsigned-hex: sign pre-built unsigned tx hex; (2) sign-from-details: build and sign from fields (blockchain, network, toAddress, value, gas, fee, etc.); (3) sign-typed-data: sign an EIP-712 typed-data message — the x402 GASLESS path, e.g. the EIP-3009 TransferWithAuthorization returned by the x402 buyer /authorize (scheme eip712). For (3) pass domain/types/primaryType/message verbatim; it returns a 65-byte signature (no tx built). Network names (e.g. ethereum+sepolia, polygon+mainnet) are mapped to chainId internally. Private key is always passed as parameter (never from env). SECURITY: Private keys may be logged by MCP clients or stored in conversation history — use only in trusted local environments.

Inputs: no named parameters.

kaspa_signA

Sign a Kaspa (native KAS) transaction locally. Kaspa is a UTXO/blockDAG chain (schnorr signatures, mainnet only). Action sign-from-details: sign from a prepared transaction object (data.item from the Kaspa prepare-transaction API) — each input carries its prevout script + sompi. Returns the signed tx as JSON (the form the Kaspa broadcast service expects). Private keys (one per input) are passed as parameters (never from env). SECURITY: Private keys may be logged by MCP clients or stored in conversation history — use only in trusted local environments.

Inputs: no named parameters.

svm_signA

Partial-sign a Solana (SVM) x402 payment transaction locally (@solana/web3.js). One action: partial-sign — deserialize the base64 UNSIGNED TransferChecked tx from the x402 buyer /authorize (scheme svm-transaction), add ONLY the source-authority (buyer) signature, and re-serialize to base64. The feePayer slot stays UNSIGNED — the facilitator signs it at settle. Returns { transaction } (base64). Secret key is base58, passed as parameter (never from env). SECURITY: keys may be logged by MCP clients or stored in conversation history — use only in trusted local environments.

Inputs: no named parameters.

tezos_signA

Sign a Tezos operation locally for tz1 (ed25519), tz2 (secp256k1) or tz3 (P-256) keys. Action sign-forged-operation: pass the forgedOperation hex from prepare_transactions_tezos and the secret key (edsk…/spsk…/p2sk…). Before signing, the operation is decoded and checked: only reveal/transaction ops from the key's own address are signed, and expected (destination, amount in mutez, maxFee) must match — always pass what the user asked for. Returns signedOperation (hex to broadcast with broadcast_signed_transaction), operationHash (o…), signature and the decoded contents. SECURITY: Private keys may be logged by MCP clients or stored in conversation history — use only in trusted local environments.

Inputs: no named parameters.

tron_signA

Sign a Tron transaction (no TronWeb): Node crypto (sha256) + elliptic (secp256k1) + minimal protobuf encode/decode. Two actions: (1) sign-from-details: sign from transaction object (must include raw_data_hex); (2) sign-unsigned-hex: sign from raw unsigned tx hex. Returns signedTransactionHex. Private key is passed as parameter (never from env). SECURITY: Private keys may be logged by MCP clients or stored in conversation history — use only in trusted local environments.

Inputs: no named parameters.

utxo_signA

Sign a UTXO transaction (bitcoin, bitcoin-cash, litecoin, dogecoin, dash, zcash). Two actions: (1) sign-from-details: sign from prepared transaction object (e.g. HD wallet prepare-transaction) — for zcash this produces a v5 (ZIP 225/244) transaction and requires exactly one of targetHeight (chain tip + 1) or consensusBranchId; (2) sign-unsigned-hex: sign from raw unsigned tx hex (provide inputs metadata: script, satoshis per input) — does not support zcash. Private key is passed as parameter (never from env). SECURITY: Private keys may be logged by MCP clients or stored in conversation history — use only in trusted local environments.

Inputs: no named parameters.

xrp_signA

Sign an XRP (Ripple) transaction. Two actions: (1) sign-from-details: sign from transaction object (JSON); (2) sign-unsigned-hex: sign from raw unsigned tx hex (XRPL serialized). Returns signedTransactionHex and signedTransactionHash. Secret is passed as parameter (never from env). SECURITY: Private keys may be logged by MCP clients or stored in conversation history — use only in trusted local environments.

Inputs: no named parameters.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    Deploy Server
    One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

    TDQS

    A4.5/5.0

    Scored across 7 tools

    Disambiguation5/5

    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.

    Naming Consistency5/5

    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.

    Tool Count5/5

    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.

    Completeness4/5

    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.

    Maintenance

    ActivityMaintained
    ResponsivenessOutdated data

    Resources

    Related MCP Connectors

    Related MCP Servers