Agent wallets · MCP operations · 13 September 2026
Tether WDK MCP wallet safety: dryRun, unlock TTL and write-tool guardrails
Tether's current WDK tooling can give an MCP-compatible AI client access to a self-custodial wallet. The important operator question is not merely whether the agent can call wallet tools, but which controls are actually enforced at the wallet boundary. The bundled WDK CLI MCP server and the programmatic MCP Toolkit have different control surfaces, so “the agent asked for confirmation” is not a complete security model.
Published 13 September 2026 · sources checked 13 September 2026
Unlock
is the human authorization boundary in the bundled CLI wallet flow
dryRun
defaults to true for send_token, but the CLI daemon does not enforce preview first
call_method
can invoke write methods with no dry-run or daemon-enforced confirmation
The key distinction
A default, a prompt and an authorization control are not the same thing
In the bundled WDK CLI MCP server, send_token defaults to dryRun: true. Tether recommends previewing the transaction, showing the exact network, token, recipient, amount and estimated fee, asking the user to confirm those values, and only then calling send_token with dryRun: false.
That sequence is valuable, but the CLI documentation is explicit that it is guidance for the AI client rather than an authorization rule enforced by the daemon. If the wallet is already unlocked, a valid direct call with dryRun: false can broadcast. The separate call_method path is sharper still: methods marked write can move funds or mutate state, and the CLI guide says there is no dry-run or daemon-enforced confirmation for that path.
This makes the operator's real control stack layered: wallet scope limits the blast radius, unlock TTL limits the exposure window, tool selection limits what the client can request, and a client-side approval workflow reduces accidental writes. None of those layers should be silently promoted into a stronger guarantee than the implementation provides.
Operator checklist
Build the safety boundary before connecting the funded wallet
| Control | Operator action | Why it matters |
|---|---|---|
| Wallet scope | Use a dedicated development or agent wallet with limited funds. | Limits the value exposed if the agent or local process boundary fails. |
| Unlock window | Unlock with a finite TTL and lock the wallet when the task ends. | WDK documents the TTL as absolute; activity does not extend it. |
| Tool surface | Expose only the tools the agent actually needs. | The MCP Toolkit can register read-only wallet tools separately from write tools. |
| Transfer preview | Preview send_token first and show network, token, recipient, amount and fee. | In the CLI MCP path, dryRun is a default and workflow convention, not a daemon policy. |
| Write methods | Treat every call_method entry marked write as transaction authority. | The CLI guide says call_method has no dry-run or daemon-enforced confirmation. |
| Process boundary | Do not treat MCP configuration as an OS sandbox. | A same-user process or agent with separate shell access can cross outside the narrow MCP tool surface. |
CLI MCP server
The wallet must already be unlocked, and the TTL is an exposure window
The bundled wdk-mcp server does not expose wallet administration commands such as create, import, export, unlock, lock, delete, rename or default. Tether deliberately describes wdk wallet unlock as the human authorization moment. The agent operates a wallet the person has already unlocked rather than receiving the passphrase through an MCP tool call.
The current CLI guide recommends a short, finite unlock TTL. The timer is absolute from unlock; MCP activity does not extend it. During that window an unlocked wallet behaves like a local hot wallet: read, signing and send operations do not ask for the passphrase again. Setting --ttl 0 disables automatic expiry and therefore removes that time-bound safeguard.
On Unix-like systems, the daemon socket is owner-only, but that protects against other OS users rather than every process running as the wallet owner. Tether also warns that the MCP tool list is not an operating-system sandbox: an AI client that separately has shell access sits outside the narrow wdk-mcp boundary and may be able to invoke the CLI directly.
MCP Toolkit versus CLI
Do not copy one product's confirmation semantics onto the other
| Surface | Current documented control | Operator implication |
|---|---|---|
| Bundled WDK CLI MCP server | Wallet unlock stays human-side; send_token defaults to dryRun true; call_method can expose catalog-declared write methods. | Preview/confirm must be implemented and respected by the client; the daemon does not turn the prompt into a per-transaction authorization gate. |
| Programmatic WDK MCP Toolkit | Current beta documentation says built-in write operations use MCP elicitations for explicit user approval; read/write tool sets can be selected separately. | Use the Toolkit when you need application-level control over tool registration and the MCP server implementation. Verify custom tools separately rather than assuming built-in behavior applies to them. |
These descriptions are not contradictory: they refer to two different WDK surfaces. The Toolkit is an embeddable MCP-server package; the CLI server is a local interface to the WDK wallet daemon. Confirm which one your agent actually runs before designing the approval flow.
Qualified next step
Verify the trust boundary before granting transaction authority
If the wallet agent also connects to third-party MCP servers, verify those endpoints and permission requests before granting credentials or state-changing authority with the MCP server verification checklist. If the agent is buying machine services over HTTP 402, separate quote, verification, settlement and delivery evidence with the x402 buyer verification guide. Qualified machine buyers can inspect zFinia's current service catalogue at /api.
Primary sources