Skip to main content
Glama
CryptoAPIs-io

@cryptoapis-io/mcp-signer

Official

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

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

CapabilityDetails
tools
{
  "listChanged": true
}
prompts
{
  "listChanged": true
}
resources
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
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); (2) sign-unsigned-hex: sign from raw unsigned tx hex (provide inputs metadata: script, satoshis per input). 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 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.

Prompts

Interactive templates invoked by user choice

NameDescription
sign-transactionSign a raw transaction locally without network transmission

Resources

Contextual data attached and managed by the client

NameDescription
supported-chainsSupported blockchains, networks, and actions for local transaction signing

TDQS

A4.4/5.0

Scored across 7 tools

Disambiguation5/5

Each tool targets a distinct blockchain or ecosystem (EVM, Tezos, Kaspa, SVM, Tron, UTXO, XRP), so an agent can easily select the correct signer based on the chain. The only potential confusion is that Kaspa is a UTXO chain but has its own tool, yet the description of utxo_sign explicitly lists its supported chains and excludes Kaspa, making boundaries clear.

Naming Consistency5/5

All tool names follow a consistent <ecosystem/chain>_sign pattern in snake_case, with no mixing of conventions. The use of ecosystem names (evm, svm, utxo) alongside chain names (tezos, kaspa, tron, xrp) is a minor variation but still predictable and readable.

Tool Count5/5

Seven tools is well-scoped for a multi-chain transaction signer, with each tool covering a distinct ecosystem or chain and earning its place. The count avoids redundancy while providing broad coverage.

Completeness4/5

The surface covers signing for seven major ecosystems, with multiple actions (sign-from-details, sign-unsigned-hex, etc.) where relevant, and no dead ends for the stated purpose. However, message signing is only supported for EVM (via typed data), and other chains might lack that capability, leaving a minor gap.

Maintenance

ActivityMaintained
ResponsivenessNo issues