The signer-mcp server enables AI agents to securely sign and manage orders on cryptocurrency exchanges within an AWS Nitro Enclave, keeping private keys isolated and never exposed.
list_venues — Discover all supported trading venues (Binance, OKX, Asterdex, KuCoin, Bybit, Hyperliquid). Read-only; works even if the Signer gateway is unreachable.
get_attestation — Retrieve the AWS Nitro attestation document (PCR0/1/2 measurements + AWS signature) to cryptographically verify the enclave running your trades matches the published source code.
get_account — Fetch a real-time account snapshot for a given venue: equity (USD), free margin (USD), and open positions (symbol, quantity, entry price). Requires an API token.
place_order — Submit a market or limit order on a supported venue. The enclave signs the order server-side within pre-configured policy caps (per-asset/per-period limits). Supports buy/sell sides and base-asset quantity input. Destructive — results in a real or testnet trade.
cancel_order — Cancel an outstanding order by its venue-native order ID. Idempotent: cancelling an already-filled or non-existent order returns a soft failure (ok: false) with a reason rather than an error.
All order signing happens inside the attested enclave with policy enforcement configured via the usenami.io/signer platform. The server integrates with MCP-aware AI agents such as Claude Desktop and ElizaOS, and is configured via environment variables for the gateway URL, API token, and request timeout.
Allows placing and canceling orders on Binance perpetual futures (USD-M) through MCP tools, with account read capability.
Provides order placement and cancellation for KuCoin Futures (perp) with HMAC authentication, including account information retrieval.
Enables trading on OKX perpetual swap contracts via MCP tools, supporting market and limit orders, and account queries.
Sign CEX orders from any MCP-aware AI agent — the signing secret never leaves the AWS Nitro Enclave.
signer-mcp is the public face of Usenami 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 the signing secret ever entering 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 nor list_venues can 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. Read place_order before sending anything.
Every agent framework that touches a CEX today loads the API key into the agent process. That puts the secret on disk, in env vars, in npm packages, in prompt-engineered tool calls, and in your shell history. One prompt injection, one supply-chain compromise, one accidental log line, one curious co-worker — and the key leaks.
Signer takes the opposite approach. The signing key is generated inside an AWS Nitro Enclave attested by AWS itself. The enclave's measurement (PCR0) is published on https://usenami.io/signer/attestations. The MCP server you install here can ask the enclave to sign a specific order — bounded by an explicit policy (per-asset cap, per-period cap, allowed venues) — but it cannot read the key. Neither can the agent, your laptop, your IaC, or our own engineers.
If the agent gets compromised, the worst it can do is place orders inside your policy window. The key itself stays attested.
Related MCP server: Openterms-mcp
Get a token. Access is invite-based during the pilot — there is no self-serve signup yet; request access via usenami.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_venues and get_attestation need no token. Note what each one actually does, because only one of them talks to us: get_attestation fetches a live, NSM-signed document from the gateway, while list_venues answers from a static manifest compiled into this package and makes no network call at all.
Edit claude_desktop_config.json. Path is ~/Library/Application Support/Claude/claude_desktop_config.json on macOS.
{
"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 Desktop and look for the 🔌 plug icon. You should see six tools listed under signer.
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 a real order on the venue your token's policy allows, and you should assume that means mainnet, 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 call cancel_order immediately.
ElizaOS has a native 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-mcp over stdio:
npm install @elizaos/plugin-mcpThen in your character / agent config:
{
"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. Only get_attestation reaches the gateway; list_venues is served from a
static manifest inside the package, so a green list_venues says nothing about whether
your gateway is reachable.
Environment variables passed via the env block of claude_desktop_config.json (or your client's equivalent):
Variable | Required | Default | Notes |
| no |
| The hosted attested demo enclave. Override for self-hosted deployments. |
| yes (for account/order tools) | — | Bearer token provisioned at onboarding (invite-based pilot). |
| no |
| Per-request fetch timeout in ms. Lower for CI / smoke tests; raise on slow links. Must be positive integer. |
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.
list_venuesReturns 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 a status: live (the enclave will sign for it) or denied
(the enclave refuses by policy — supplying credentials will not change it). Some
entries add a network field (bsc, hyperliquid-testnet, …). Read status
and notes before choosing a venue.
| status | asset class | auth scheme | symbol example | notes |
| live | perp | hmac_sha256 |
| Binance USD-M futures. ⚠️ Assume mainnet, real funds — the network is set by your token's policy, not by this table |
| live | perp | hmac_sha256 |
| OKX perpetual swap. Signs where an OKX key is provisioned; only the gateway you point at can say whether one is. Sizes are in contracts (1 |
| live | perp | eip712 (bsc) |
| Asterdex on-chain perp (BSC) |
| live | perp | hmac_sha256 |
| KuCoin Futures (HMAC + encrypted passphrase); qty in contracts |
| live | perp | hmac_sha256 |
| Bybit V5 linear ( |
| live | perp | eip712 (hyperliquid) |
| Same enclave code as mainnet, testnet phantom-agent source. Not reachable via |
| live | perp | eip712 (hyperliquid) |
| Order and cancel only — the enclave has no withdrawal or transfer action for this venue. Mainnet carries an unconditional money floor (authority-signed policy + binding per-asset caps by integer asset index), not relaxable by a build flag. Account read is the public |
The agent config block is identical for every venue — point SIGNER_GATEWAY_URL at your Signer and set SIGNER_API_TOKEN. Which venues a given token may trade is bound server-side to that token's policy; list_venues reports the full set the gateway can sign, not your per-token allow-list.
get_attestationReturns 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_sha384 is a convenience copy; the evidence is attestation_doc_b64 — the
AWS-signed COSE document containing all PCRs. Trust the document, not the field
printed beside it.
Read-only, works without a token.
get_accountReturns 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"
}Read-only. Requires SIGNER_API_TOKEN.
place_orderPlace a single market or limit order. The enclave signs the payload after checking policy caps.
Args:
venue — one of binance | okx | asterdex | kucoin | bybit | hyperliquid_testnet | hyperliquid_main. ⚠️ v0 has structured order routes for binance | okx only — other venues return a clear error (they expose read-only account access); and check list_venues status first
symbol — canonical (BTC, BTCUSDT, BTC/USDT) or venue-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 on BTC-USDT-SWAP) are converted automatically; sizes off the venue's contract grid are rejected, never silently rounded.
type — market | limit
price — required if type=limit, ignored if type=market
policy_id — optional override; defaults to the policy bound to your token
The result includes a translation echo — check translation.sent to 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. Requires SIGNER_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 can
list_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 that neither Hyperliquid venue is
reachable through place_order / cancel_order in v0: those carry structured routes for
binance and okx only.
An earlier revision of this section said "v0 routes Binance/OKX to testnet" —
that was wrong, see CHANGELOG 0.6.0.
place_hedgePlaces a 2-leg hedge with atomic signing: both legs are signed inside the
enclave all-or-nothing (a policy denial on either leg means nothing is even
sent), then the gateway fires both venue calls server-side in parallel — the
leg gap collapses to the venues' own latency spread and the signed auth headers
never transit through your client. ⚠️ Venue execution is not atomic: the
partial and unknown statuses below exist precisely because an exchange can
accept one leg and lose or reject the other.
Args:
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 — use place_order for limits) and venues limited to
binance | okx. Typical hedge: same symbol, opposite sides, equal
base-asset qty on two venues.
Symbols and qty use the same canonical/base-asset translation as
place_order; per-leg translations are echoed back.
Read the result's status before anything else:
executed — both legs live.
partial — 🔴 exactly one leg live: the position is NAKED. Repair by
closing the live leg or re-placing the rejected one. Never re-place a leg
whose outcome is unknown.
unknown — 🔴 a leg's receipt was lost (timeout / venue 5xx) — that order
may be live. Do NOT retry place_hedge; reconcile first via
get_account on both venues.
failed — both legs definitively rejected, nothing live, safe to fix and retry.
Destructive (moves real positions on two venues at once). Requires
SIGNER_API_TOKEN. Gateways older than the /hedge endpoint return a clear
"use two place_order calls" error.
cancel_orderCancels an outstanding order by its venue order id. Idempotent — cancelling an already-filled or non-existent order returns ok: false with a venue reason instead of erroring.
Available for binance | okx in v0 — other venues have no structured cancel
route yet and return a clear error (same limitation as place_order).
Args:
venue — binance | okx
order_id — the venue id returned by place_order
symbol — required (canonical BTC or venue-native; translated exactly like place_order) — both venues' REST cancel routes need it alongside order_id
Requires SIGNER_API_TOKEN.
A trustworthy Signer is one whose enclave measurement matches a build you can audit. The workflow:
Call get_attestation and copy the returned pcr0_sha384 (or, stricter, read PCR0 out of the signed attestation_doc_b64 itself).
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.
If the published PCR0 doesn't match what get_attestation returns, don't trade. Open an issue.
v0 keeps the surface deliberately tight:
No multi-tenant: one account per venue per token.
No UPL editing UI: policies are set out-of-band on usenami.io/signer.
No WebSocket / streaming tools — REST only.
No cross-venue routing (place_order takes one venue; the only multi-venue tool is the fixed 2-leg place_hedge).
No leverage configuration (set_leverage) — uses account defaults.
No withdrawals / transfers (closest is cancel_order).
No TWAP / iceberg — single-shot orders only.
stdio transport only — no SSE or remote HTTP.
If you need any of the above, file an issue describing the use case. v0 keeps the surface tight on purpose.
# 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 devThe transport is stdio; you'll need an MCP-aware client to actually exercise the tools. The Anthropic mcp-inspector is the fastest way to poke at it locally.
MIT. See LICENSE.
Cancel an outstanding order by its venue order_id. Signed inside the enclave just like place_order. Returns the cancellation receipt from the venue. Idempotent: cancelling a non-existent / already-filled order returns ok=false with a reason from the venue.
| Name | Required | Description | Default |
|---|---|---|---|
| venue | Yes | Venue identifier. Must match an entry returned by list_venues — any other value will be rejected by the gateway. | |
| order_id | Yes | Venue-native order identifier returned by place_order. | |
| symbol | No | Venue-native symbol — REQUIRED for binance + okx cancels (their REST APIs need the symbol on the cancel route). Optional for venues that derive it from order_id alone. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behavioral traits beyond annotations: it explains the return value (cancellation receipt), confirms idempotency behavior with ok=false and venue reason, and notes the enclave signing. These details add value over the idempotentHint annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, each serving a distinct purpose: stating the action, providing context, and explaining idempotency. No wasted words, and key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains return value (cancellation receipt) and idempotent behavior, which is appropriate for a tool without an output schema. However, it does not detail the receipt's structure, which might be needed for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3, but the description significantly enriches parameter understanding: it links venue to list_venues, order_id to place_order, and clarifies symbol requirement per venue. This goes well beyond the schema's descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool cancels an outstanding order by its venue order_id, which is a specific verb+resource combination. It distinguishes itself from sibling tools like place_order and get_account.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context by mentioning 'Signed inside the enclave just like place_order' and describes idempotent behavior including handling of non-existent orders. However, it does not explicitly state when not to use this tool or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return equity, free margin, and open positions for a venue. Read-only (does not sign anything that mutates state). Use BEFORE place_order to confirm the account has margin. Requires SIGNER_API_TOKEN.
| Name | Required | Description | Default |
|---|---|---|---|
| venue | Yes | Venue identifier. Must match an entry returned by list_venues — any other value will be rejected by the gateway. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds 'does not sign anything that mutates state' and 'Requires SIGNER_API_TOKEN', which provide extra behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, then usage context. No fluff, every sentence earns its place. Under 30 words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter and rich annotations, the description covers purpose, usage context, and auth. Missing details about return format could be improved, but overall sufficient for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with a clear description for the 'venue' parameter (enum, must match list_venues). The tool description does not add additional meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Return equity, free margin, and open positions for a venue.' The verb 'return' and resource 'account snapshot' are specific. It distinguishes from siblings like place_order or list_venues.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use BEFORE place_order to confirm the account has margin.' Provides clear context and a specific use case. Also mentions read-only and auth requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the Signer enclave's AWS Nitro attestation document (PCR0, PCR1, PCR2 measurements + AWS-issued signature). This proves the code currently signing your orders matches the published source. The enclave's signing key NEVER leaves attested code. Verify the PCR0 against https://usenami.io/signer/attestations before trusting any place_order.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by explaining that the signing key never leaves attested code, and that the attestation proves code matches published source. It does not contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first sentence states what is returned, second sentence explains significance and provides verification instructions. Every sentence is meaningful and there is no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description clearly states the contents (PCR0, PCR1, PCR2 measurements + signature), explains the trust chain, and provides a verification URL. For a parameterless tool, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema coverage, the baseline is 4. The description adds no parameter info but is not needed. It effectively describes what the returned document contains.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns the AWS Nitro attestation document with specific PCR measurements and signature. It explains the purpose in the context of proving code integrity for signing. This distinguishes it from sibling tools like cancel_order or place_order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to use this tool before trusting place_order and provides a verification step using a URL. While it gives good context for when to use, it doesn't explicitly list when not to use or mention alternatives, though none seem needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the venues this Signer can sign trades for. Returns the venue id, asset class (perp / spot / margin), and auth scheme (hmac / eip712 / ed25519). Read-only static manifest — does NOT need the Signer gateway to be reachable. Call this first to discover what's signable.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, etc. The description adds context: 'Read-only static manifest — does NOT need the Signer gateway to be reachable.' This provides useful behavioral insight beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff, front-loaded with the core purpose and key differentiators. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no output schema, and rich annotations, the description adequately covers the tool's purpose, behavior, and usage context. It mentions the returned fields, which is sufficient even without a structured output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters (100% schema coverage by default), so baseline is 4. Description adds no parameter details, which is appropriate as none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists venues the Signer can sign trades for, specifies the output fields (venue id, asset class, auth scheme), and distinguishes it from siblings by noting it's a read-only static manifest that doesn't need the Signer gateway to be reachable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to 'Call this first to discover what's signable' and notes the tool doesn't require the Signer gateway, implying safe usage even if gateway is down. However, it doesn't explicitly contrast with sibling tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Place a single order on the named venue. The Signer enclave will sign the venue-native payload using a key that has never been exported. Policy enforced server-side: orders that exceed per-asset caps are rejected by the enclave before signing. Returns the venue's order_id on success. Side effect: real or testnet trade depending on venue env.
| Name | Required | Description | Default |
|---|---|---|---|
| venue | Yes | Venue identifier. Must match an entry returned by list_venues — any other value will be rejected by the gateway. | |
| symbol | Yes | Venue-native trading symbol. Examples: BTCUSDT (binance, bybit), BTC-USDT-SWAP (okx), BTC-USD (asterdex), XBTUSDTM (kucoin futures), BTC (hyperliquid_main). Case-sensitive. | |
| side | Yes | buy = long open / short close; sell = short open / long close. | |
| qty | Yes | Order quantity in base asset (e.g. BTC), NOT in USD-notional. Some venues require a minimum (Binance: 0.001 BTC). Refer to venue docs. | |
| type | Yes | market = immediate fill at venue best; limit = resting order at `price`. | |
| price | No | Limit price in quote asset. Required for type=limit, ignored for type=market. | |
| policy_id | No | Optional policy id override. If omitted, the gateway uses the default policy bound to the provided SIGNER_API_TOKEN. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true. The description adds valuable context: the Signer enclave signs the payload with a never-exported key, policy enforcement, and the side effect of real or testnet trade. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, front-loaded with the primary purpose, and no filler. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no output schema, and annotations present, the description covers purpose, key behaviors, and parameter nuances. Could mention rate limits or error handling, but overall complete enough for a trading tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description adds meaning beyond the schema, such as examples for symbols, side definitions (long/short), quantity base asset, and policy_id override guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Place') and resource ('a single order on the named venue'), clearly distinguishing it from siblings like cancel_order, list_venues, get_account, and get_attestation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when the tool can be used (single order) and mentions policy enforcement and side effects (real/testnet trade). It does not explicitly state when not to use it, but the context is clear enough for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: placing orders, canceling orders, checking account state, verifying enclave attestation, and listing venues. No two tools could be confused for the same operation.
All tool names follow a consistent verb_noun pattern (e.g., cancel_order, get_account, list_venues) using snake_case, making the naming predictable and easy to understand.
With 5 tools, the set is well-scoped for a signing service. Each tool covers a necessary aspect: order lifecycle (place/cancel), account info, venue discovery, and attestation verification.
The core workflow (place and cancel orders) is covered, along with auxiliary tools for account and venue info. A minor gap is the lack of an explicit order status retrieval tool, though get_account provides some position info.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
No-KYC managed MCP for AI agents: sandboxed TypeScript trading SDK, isolated sub-accounts, futures.
Non-custodial trading for AI agents: 1,900+ assets — US stocks, treasuries, gold, 250+ perps.
Give your AI hands. Identity, credential vault, and API gateway for autonomous agents.
Security gateway for AI agents: policy, approval, and audited execution, no secrets shared.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/namixai/signer-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
