Signer MCP

What namixai/signer-mcp MCP server does

namixai/signer-mcp MCP server gives an MCP-aware client a controlled interface for exchange account reads and perpetual-futures order operations. Supported venue identifiers include Binance, OKX, Asterdex, KuCoin, Bybit, and Hyperliquid entries in the package manifest. The available operations include listing venues, retrieving enclave attestation, reading account state, placing one market or limit order, and cancelling an order by venue order ID.

The service is designed so the exchange signing key is generated and retained inside an AWS Nitro Enclave. The client receives the result of an approved signing operation rather than the credential itself. Order requests are checked against the policy attached to the caller's token, including venue permissions and configured caps.

How it works

The package runs as a local stdio MCP process. It communicates with a configured Signer gateway, which handles requests involving the attested enclave. list_venues is different: it reads a static manifest bundled with the package and makes no network request. get_attestation retrieves a live NSM-signed document from the gateway, including the enclave's PCR0 measurement.

The PCR0 value can be compared with the published build by hashing the corresponding enclave image. This provides a way to inspect which enclave measurement AWS attested before authorizing trading actions.

get_account returns equity, free margin, and open positions for a venue. place_order supports a single market or limit order, subject to the enclave's policy checks. cancel_order accepts a venue order ID and is idempotent; an already-filled or unknown order returns an unsuccessful result with the venue's reason rather than raising an error.

Setup and configuration

Install the package through npm and configure it as an MCP stdio server. The documented Claude Desktop command uses npx -y @usenami/signer-mcp@^0.6.0. Version 0.6.0 or later is important because earlier published versions used a gateway default that redirected requests to a landing page.

Set SIGNER_GATEWAY_URL to the hosted demo gateway or to a self-hosted deployment. Set SIGNER_API_TOKEN with the bearer token issued during the invite-based pilot. The token is needed for account and order tools, but not for list_venues or get_attestation. SIGNER_FETCH_TIMEOUT_MS optionally changes the per-request timeout and must be a positive integer.

The process reads the token at startup and keeps it in memory. The README states that it does not store data on disk. The same stdio configuration can be reached from ElizaOS through its generic MCP bridge, although that bridge is separate from this package.

Limitations and notes

The project is marked alpha and access is invite-based. The token's policy determines the permitted venue and network; the package's static venue list cannot reveal those token-specific details. Do not assume a testnet environment: the documentation warns that orders may use mainnet and real funds unless the token issuer confirms otherwise.

The signing design limits what a compromised agent can request to the active policy window, but it does not make incorrect orders safe. Review the attestation, venue status, notes, order parameters, and policy before enabling execution. list_venues succeeding does not prove that the configured gateway is reachable because it does not contact the gateway.