Skip to main content
Glama
nexus-xyz

nexus-exchange-mcp

Official
by nexus-xyz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

register_agent

Delegate trading authority to an AI agent with an owner-signed key so it can trade on a wallet's behalf without holding the wallet's private key.

Instructions

Register a delegated agent key so an AI agent can trade on a wallet's behalf without holding the wallet key. Authorized by an EIP-712 signature from the OWNER WALLET over RegisterAgent{agent, expiresAt, nonce} (domain Nexus Exchange v1). Sign it in the wallet and pass wallet and signature, or omit both to have the stdio server sign with its own wallet (see create_wallet; testnet and local only, expiry defaulting to now+30d). No API credentials are needed; the signature is the authorization.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
agentYesAgent Ethereum address (0x-prefixed, 20 bytes) to delegate to.
labelNoOptional human-readable label for the agent.
nonceYesMonotonic nonce. Use the current Unix time in ms as a safe start.
walletNoOwner wallet address (0x-prefixed, 20 bytes). Required with `signature`; defaults to this server's wallet without one.
signatureNoEIP-712 signature over RegisterAgent{agent, expiresAt, nonce} from the wallet private key (0x-prefixed). Omit it to have this server sign with its own wallet.
expires_atNoExpiry as Unix ms. Optional — defaults to now+30d. Must be in [now+1d, now+90d].

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.4.0
    • changedInput schema / properties / signature / description
      Previous value: -"EIP-712 signature over RegisterAgent{agent, expiresAt, nonce} from the wallet private key (0x-prefixed)."New value: +"EIP-712 signature over RegisterAgent{agent, expiresAt, nonce} from the wallet private key (0x-prefixed). Omit it to have this server sign with its own wallet."
    • changedInput schema / properties / wallet / description
      Previous value: -"Owner wallet address (0x-prefixed, 20 bytes)."New value: +"Owner wallet address (0x-prefixed, 20 bytes). Required with `signature`; defaults to this server's wallet without one."
    • changedInput schema / required
      Previous value: -[
-  "wallet",
-  "agent",
-  "nonce",
-  "signature"
-]New value: +[
+  "agent",
+  "nonce"
+]
  2. Changed7 schema fields changed
    • changedInput schema / properties / agent / description
      Previous value: -"Agent public key/address to delegate to. Optional."New value: +"Agent Ethereum address (0x-prefixed, 20 bytes) to delegate to."
    • addedInput schema / properties / expires_at
      Added value: +{
+  "description": "Expiry as Unix ms. Optional — defaults to now+30d. Must be in [now+1d, now+90d].",
+  "type": "integer"
+}
    • addedInput schema / properties / label
      Added value: +{
+  "description": "Optional human-readable label for the agent.",
+  "type": "string"
+}
    • addedInput schema / properties / nonce
      Added value: +{
+  "description": "Monotonic nonce. Use the current Unix time in ms as a safe start.",
+  "type": "integer"
+}
    • addedInput schema / properties / signature
      Added value: +{
+  "description": "EIP-712 signature over RegisterAgent{agent, expiresAt, nonce} from the wallet private key (0x-prefixed).",
+  "type": "string"
+}
    • changedInput schema / properties / wallet / description
      Previous value: -"Owner wallet address (0x...). Optional."New value: +"Owner wallet address (0x-prefixed, 20 bytes)."
    • changedInput schema / required
      Previous value: -[]New value: +[
+  "wallet",
+  "agent",
+  "nonce",
+  "signature"
+]
  3. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and largely meets it: it discloses the authorization mechanism (EIP-712 over a named struct/domain), that no API credentials are required, that the server-signing fallback is restricted to testnet/local, and the default expiry. It does not state that this is a state-mutating, persistent delegation, nor what happens on nonce reuse or how failure surfaces.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded and every sentence carries information (authorization, two signing paths, fallback constraints). It is dense in places — the third sentence packs the alternative mode, the create_wallet reference, the network restriction, and the expiry default into one clause chain — but there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no annotations and no output schema, the description covers authorization, the fallback path, network scoping, and expiry bounds. It leaves the agent guessing about the success response and error/undo behavior, and never ties itself to the revoke_agent counterpart.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it maps `agent`/`expiresAt`/`nonce` into the signed EIP-712 struct, defines the pairing rule for `wallet`+`signature` (both or neither), and names the default expiry source. That is semantic guidance the schema does not convey.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Register a delegated agent key') plus the outcome ('trade on a wallet's behalf without holding the wallet key'). This clearly separates it from siblings like revoke_agent, list_agents, and create_api_key without the agent needing to open any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explains both invocation paths precisely: sign the EIP-712 payload and pass `wallet`+`signature`, or omit both to let the server sign (testnet/local only), and routes to `create_wallet`. It states the conditions that select each mode but does not contrast this tool against other auth/credential tools (e.g. create_api_key), so no explicit exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools