signer-mcp

Sign CEX orders from any MCP-aware AI agent — keys never leave an AWS Nitro Enclave.

signer-mcpis the public face ofUsenami Signer. It gives Claude Desktop, Cursor, ElizaOS, and any other MCP-aware client a six-tool surface for trading real CEX/DEX perp accounts (Binance, OKX, Asterdex, KuCoin, Bybit, Hyperliquid) without ever loading a private key into the agent's process — or yours.

Status:v0 (alpha), invite-based pilot. Venue manifest, attestation, account read, place/cancel order, and a two-leg hedge. ⚠️Assume orders are real.Which venue and network your orders hit is decided by the policy bound to your token, and neither this page norlist_venuescan tell you which — ask whoever issued the token. There is no implicit testnet safety net, so treat every order as mainnet money until you have confirmed otherwise. Readplace_orderbefore sending anything.

Get a token.Access isinvite-basedduring the pilot — there is no self-serve signup yet; request access viausenami.io/signer(contact link at the bottom) and your token is provisioned at onboarding, bound to a policy with per-venue caps.No token yet?Steps 2–4 still work:list_venuesandget_attestationneed no token. Note what each one actually does, because only one of them talks to us:get_attestationfetches a live, NSM-signed documentfrom the gateway, whilelist_venuesanswers from a static manifest compiled into this package and makesno network call at all.

{ "mcpServers": { "signer": { "command": "npx", "args": ["-y", "@usenami/signer-mcp@^0.6.0"], "env": { "SIGNER_GATEWAY_URL": "https://signer-demo.usenami.io:8443", "SIGNER_API_TOKEN": "sk_live_..." } } } }

Pin@^0.6.0— earlier versions do not work out of the box.Every published version up to and including0.5.0defaultsSIGNER_GATEWAY_URLtohttps://signer.usenami.io, which301-redirects every path to the marketing landing page. The network tools then receive HTML and die withUnexpected token '<'.0.6.0changed the default to the demo gateway. If you are pasting a config from an older post or cached answer, check this first — the symptom looks like a broken server and is a stale default.
-

Restart Claude Desktopand look for the 🔌 plug icon. You should see six tools listed undersigner.

Try the read-only tools first.Ask Claude:

"List the venues available through Signer, then return the current attestation document."

No funds at risk — these don't sign anything, and neither needs a token.

Once you have a token and trust the attestation, you can place a first order — knowingly.⚠️ This signs areal order on the venue your token's policy allows, and you should assume that meansmainnet, real money— 0.001 BTC is a real position, not a testnet exercise, unless the person who issued your token told you otherwise. Start with the smallest size your policy allows, and only then:

"Get my Binance account, then if I have at least $20 of free margin, place a market buy for 0.001 BTC."

If anything looks wrong, the agent can callcancel_orderimmediately.

ElizaOS has anative plugin:@usenami/plugin-signer(same gateway contract — a token issued for one works with the other). Prefer it: actions land directly in the agent, plus an attestation provider that keeps the current PCR0 in context.

Alternatively, ElizaOS can reach this MCP server through the generic bridge@elizaos/plugin-mcpoverstdio:

{ "plugins": ["@elizaos/plugin-mcp"], "settings": { "mcp": { "servers": { "signer": { "type": "stdio", "command": "npx", "args": ["-y", "@usenami/signer-mcp@^0.6.0"], "env": { "SIGNER_GATEWAY_URL": "https://signer-demo.usenami.io:8443", "SIGNER_API_TOKEN": "sk_live_..." } } } } } }

The agent now exposes the same six tools (list_venues,get_attestation,get_account,place_order,place_hedge,cancel_order). Same trust model: the signing key never enters the Eliza process — start the agent on the read-only tools (list_venues/get_attestation) and verify the attestation before letting it place orders. Onlyget_attestationreaches the gateway;list_venuesis served from a static manifest inside the package, so a greenlist_venuessays nothing about whether your gateway is reachable.

Environment variables passed via theenvblock ofclaude_desktop_config.json(or your client's equivalent):

The MCP server itself stores nothing on disk. Tokens are read from environment on startup and held in memory for the lifetime of the process — kill the agent, the token goes with it.

Returns the static manifest of venues this Signer can sign for.Read-only, does not contact the gateway, works without a token. Call this first to discover what's supported.

{ "venues": [ { "venue": "binance", "asset_class": "perp", "auth_scheme": "hmac_sha256", "status": "live", "notes": "..." } ], "count": 7 }

Every entry carries astatus:live(the enclave will sign for it) ordenied(the enclave refuses by policy — supplying credentials will not change it). Some entries add anetworkfield (bsc,hyperliquid-testnet, …).Readstatusandnotesbefore choosing a venue.

The agent config block is identical for every venue — pointSIGNER_GATEWAY_URLat your Signer and setSIGNER_API_TOKEN. Which venues a given token may trade is bound server-side to that token's policy;list_venuesreports the full set the gateway can sign, not your per-token allow-list.

Returns the Nitro attestation document for the currently-running enclave. The PCR0 measurement here is what AWS signed when it booted the enclave; you can verify it matches the published build by hashing the corresponding EIF and comparing.

{ "pcr0_sha384": "...sha384 hex...", "attestation_doc_b64": "...base64 COSE_Sign1, signed by AWS Nitro...", "registered_onchain": true, "timestamp_ms": 1785847208571 }

pcr0_sha384is a convenience copy; the evidence isattestation_doc_b64— the AWS-signed COSE document containing all PCRs. Trust the document, not the field printed beside it.

Returns equity, free margin, and open positions for a venue.

{ "venue": "binance", "equity_usd": 145.32, "free_margin_usd": 92.10, "positions": [ { "symbol": "BTCUSDT", "qty": 0.002, "entry_price": 67120.5 } ], "updated_at": "2026-05-31T18:01:11Z" }

Place a single market or limit order. The enclave signs the payload after checking policy caps.

- venue— one ofbinance | okx | asterdex | kucoin | bybit | hyperliquid_testnet | hyperliquid_main. ⚠️ v0 has structured order routes forbinance | okxonly— other venues return a clear error (they expose read-only account access); and checklist_venuesstatusfirst
- symbol— canonical (BTC,BTCUSDT,BTC/USDT)orvenue-native (BTC-USDT-SWAP,XBTUSDTM, …). The client translates to the venue's native format and echoes it back.
- side—buy|sell
- qty—always base-asset quantity(e.g. 0.001 for 0.001 BTC). Not USD-notional, not venue contracts. Contract-denominated venues (okx: 1 contract = 0.01 BTC onBTC-USDT-SWAP) are converted automatically; sizes off the venue's contract grid are rejected, never silently rounded.
- type—market|limit
- price— required iftype=limit, ignored iftype=market
- policy_id— optional override; defaults to the policy bound to your token

The result includes atranslationecho — checktranslation.sentto see the exact venue-native symbol + size that hit the exchange:

{ "requested": { "symbol": "BTC", "qty": 0.01, "unit": "base_asset" }, "sent": { "symbol": "BTC-USDT-SWAP", "qty": "1", "unit": "contracts", "ctVal": "0.01" } }

{ "venue": "binance", "order_id": "...", "status": "FILLED", "filled_qty": 0.001, "avg_fill_price": 67128.9, "policy_id": "default", "attested_at": "..." }

Destructive.RequiresSIGNER_API_TOKEN. ⚠️Orders go where your token's policy sends them — there is no implicit testnet routing.On Binance the hosted whether a given gateway signs against mainnet or testnet, and with what caps, is a property of that deployment and of your token's policy — this page cannot tell you, and neither canlist_venues. On Hyperliquid the enclave signs both testnet and mainnet, and mainnet additionally requires an authority-signed policy carrying binding per-asset caps — a blob without them is refused at load, unconditionally. Note thatneitherHyperliquid venue is reachable throughplace_order/cancel_orderin v0: those carry structured routes forbinanceandokxonly. An earlier revision of this section said "v0 routes Binance/OKX to testnet" — that was wrong, see CHANGELOG 0.6.0.

Places a 2-leg hedge withatomic signing: both legs are signed inside the enclave all-or-nothing (a policy denial on either leg meansnothingis even sent), then the gateway fires both venue callsserver-side in parallel— the leg gap collapses to the venues' own latency spread and the signed auth headers never transit through your client. ⚠️ Venueexecution is not atomic: thepartialandunknownstatuses below exist precisely because an exchange can accept one leg and lose or reject the other.

- legs— exactly 2, each{venue, symbol, side, qty, type}. v1 constraints:type: "market"only (a resting limit leg would let "executed" hide an unfilled leg — useplace_orderfor limits) and venues limited tobinance | okx. Typical hedge: same symbol, opposite sides, equal base-asset qty on two venues.
- Symbols andqtyuse the same canonical/base-asset translation asplace_order; per-legtranslationsare echoed back.

Read the result'sstatusbefore anything else:

- executed— both legs live.
- partial— 🔴exactly one leg live: the position is NAKED.Repair by closing the live leg or re-placing therejectedone. Never re-place a leg whose outcome isunknown.
- unknown— 🔴 a leg's receipt was lost (timeout / venue 5xx) — that ordermay be live. Do NOT retryplace_hedge; reconcile first viaget_accounton both venues.
- failed— both legs definitively rejected, nothing live, safe to fix and retry.

Destructive(moves real positions on two venues at once). RequiresSIGNER_API_TOKEN. Gateways older than the/hedgeendpoint return a clear "use two place_order calls" error.

Cancels an outstanding order by its venue order id. Idempotent — cancelling an already-filled or non-existent order returnsok: falsewith a venue reason instead of erroring.

Available forbinance | okxin v0 — other venues have no structured cancel route yet and return a clear error (same limitation asplace_order).

- venue—binance | okx
- order_id— the venue id returned byplace_order
- symbol—required(canonicalBTCor venue-native; translated exactly likeplace_order) — both venues' REST cancel routes need it alongsideorder_id

A trustworthy Signer is one whose enclave measurement matches a build you can audit. The workflow:
- Callget_attestationand copy the returnedpcr0_sha384(or, stricter, read PCR0 out of the signedattestation_doc_b64itself).
- Visitusenami.io/signer/attestations.
- Cross-reference the PCR0 against the published build for the current production version.
- Optionally rebuild the EIF from source and verify the measurement yourself — step-by-step instructions:VERIFY-SIGNER-YOURSELF.

# install deps npm install # typecheck + build npm run build # run from source against the hosted demo enclave SIGNER_GATEWAY_URL=https://signer-demo.usenami.io:8443 \ SIGNER_API_TOKEN=sk_test_... \ npm run dev

The transport is stdio; you'll need an MCP-aware client to actually exercise the tools. The Anthropicmcp-inspectoris the fastest way to poke at it locally.

Crypto trading backtesting, bot deployment, and account management for Sentinel Bot via AI agents.