@cryptoapis-io/mcp-signer
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| 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. |
| 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. |
| 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. |
| 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. |
| 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. |
| 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. |
| tezos_signA | Sign a Tezos operation locally for tz1 (ed25519), tz2 (secp256k1) or tz3 (P-256) keys. Action sign-forged-operation: pass the |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| sign-transaction | Sign a raw transaction locally without network transmission |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| supported-chains | Supported blockchains, networks, and actions for local transaction signing |
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.