| name | metamask-agent-wallet |
| description | Use when the user asks anything about blockchain wallets, transactions, signing, token transfers, supported chains, wallet balances, perpetual futures trading, prediction markets, token swaps, cross-chain bridges, market data, token discovery, decoding EVM calldata, DeFi earn/yield vaults, or authentication via the MetaMask Agentic CLI; also when an HTTP request returns 402 Payment Required / x402, when an MCP tool call returns an x402 payment-required result, or the agent needs to pay for a paywalled API, endpoint, file, tool, or resource. Single entry point for all mm CLI operations. |
| license | MIT |
| metadata | {"author":"metamask","version":"7.5.0","cliVersion":"6.1.5"} |
MetaMask Agentic CLI Skill
This skill documents the mm CLI surface for MetaMask Agent Wallet authentication, wallet lifecycle, balance queries, token transfers, message and typed-data signing, raw transactions, chain discovery, market data, token discovery, perpetual futures trading, prediction market trading, prediction trade/redeem history, token swaps, cross-chain bridges, DeFi earn/yield vaults, and EVM calldata decoding.
Use the routing table to select the relevant reference file. CLI behavior lives in references/. Repeatable operational patterns live in workflows/.
Command Routing
Match the user's intent to a command and reference file, then read the reference before constructing a command. If intent spans multiple domains, load them sequentially in dependency order.
| User Intent | Command | Reference |
|---|
| Check authentication status | mm auth status | auth.md |
| Login in MetaMask Agentic CLI | mm login | auth.md |
| Choose a wallet mode and set up policies | mm init | auth.md |
| Show current init settings | mm init show | auth.md |
| Sign in via QR code with MetaMask Mobile | mm login qr | auth.md |
| Sign in via browser (Google or Email) | mm login browser | auth.md |
| Sign out | mm logout | auth.md |
| Reset CLI session | mm reset | auth.md |
| Show CLI configuration | mm config get | auth.md |
| Set CLI configuration | mm config set | auth.md |
| Set BYOK mnemonic encryption password | mm wallet password set | auth.md |
| Change BYOK mnemonic encryption password |
Workflows
CLI behavior lives in references/. Repeatable patterns live in workflows/. Load a workflow file when the user's request is a pattern, not a single command.
Global Flags
Every mm command accepts these flags:
| Flag | Short | Description |
|---|
--format | -f | Output format: text, json, or toon. Defaults to text in TTY, json when piped |
--json | | Shorthand for --format=json |
--toon | | Shorthand for --format=toon |
--verbose | -v | Show debug logs on stderr. Use for troubleshooting |
Always use --toon for command output unless the user explicitly requests a different format.
Preflight
Run these checks before the first CLI operation in a session, in order.
1. Version compatibility
This skill is written for @metamask/agent-wallet v6.1.5, as specified by cliVersion in the frontmatter. The CLI requires Node.js 22.18 or later; on an older runtime every command exits 1 with UNSUPPORTED_NODE before the CLI loads. Check the installed version:
mm --version
The installed version is the value after @metamask/agent-wallet/, such as @metamask/agent-wallet/6.1.4 darwin-arm64 node-v22.18.0. Compare its major.minor against the pinned cliVersion. Optionally check the latest published version (best-effort, skip silently on network failure):
npm view @metamask/agent-wallet version
If the installed major.minor differs from the pinned cliVersion, or the installed version is behind the latest release, warn the user once and continue:
Version mismatch: installed CLI <installed>, this skill targets <cliVersion>, latest release is <latest>. Command syntax in this skill may be inaccurate until they are aligned. Update the CLI with npm install -g @metamask/agent-wallet@latest, then re-install the skills with npx skills add metaMask/agent-skills.
Run this check once per session. Do not block operations on it.
2. Readiness gate — authentication and initialization
mm doctor is the single readiness check. Run it before the first CLI operation in a session:
mm doctor
It reports an authenticated boolean, an initialized boolean, and a list of hints. Do not run any other command until mm doctor reports both authenticated: true and initialized: true. Authentication and initialization are independent gates: a session can be authenticated while the project has no wallet mode selected, in which case any command that needs a wallet aborts before running with NOT_INITIALIZED — "Project not initialized." with hint: Run mm init to set up wallet and trading modes.
A project counts as initialized only when a wallet mode is set — and, for server-wallet, a trading mode is set as well. byok needs only the wallet mode. Do not use mm init show as the check: it requires an initialized project and throws NOT_INITIALIZED on an uninitialized one rather than reporting state.
Remediate, then re-run mm doctor and confirm a clean result before doing anything else:
authenticated: false → follow workflows/login.md, or workflows/onboarding.md for first-time setup, to run mm login.
authenticated: true and initialized: false → follow workflows/onboarding.md to run mm init and select a wallet mode. For server-wallet, also select a trading mode.
Safety Rules
These rules apply to every operation, regardless of which reference or workflow is active.
Input Validation
Before constructing any command, validate all user-provided values:
| Flag | Validation rule |
|---|
--to, --address | Must match ^0x[0-9a-fA-F]{40}$ |
--amount | Human-readable decimal such as 0.5 or 100. Must match ^\d+\.?\d*$. Reject spaces, semicolons, pipes, backticks, or shell metacharacters |
--chain-id | Must be a positive integer (^\d+$) |
--payload for send-transaction | Must be valid JSON. No unescaped shell metacharacters outside the JSON structure |
--payload for decode | Must be 0x-prefixed hex calldata, matching ^0x[0-9a-fA-F]+$ |
--token | Must be a valid hex address or known symbol |
--leverage | Must be a positive integer (^\d+$) |
--size | Human-readable decimal such as 0.01 or 1. Must match ^\d+\.?\d*$ and be positive |
--venue | Must be hyperliquid |
--side for perps | Must be long or short |
--order-id | Must be a positive integer (^\d+$) |
--token-id | Must be a non-empty outcome token ID string |
--price, --limit-price | Must be a positive number in range (0, 1] |
--order-type | Must be one of GTC, GTD, FOK, FAK |
--side for predict | Must be buy or sell |
--slippage | Must be a number between 0 and 100 |
|
Do not pass unvalidated user input into any command.
Confirmation Requirements
| Operation type | Confirmation rule |
|---|
| Transfers | Always confirm recipient, amount, token, and chain before executing |
| Raw transactions | Always confirm transaction payload, chain, recipient, value, and calldata summary before executing |
| Message signing | Always show exact message and chain before signing |
| Typed-data signing | Always show domain, primary type, chain, verifying contract, and message summary before signing |
| Swaps / bridges | Always confirm from/to tokens, amount, source/destination chain, slippage, quoted output, recipient address if --to-address is set, and the destination gas top-up if --refuel is set before executing |
| x402 payments | Always confirm asset, decimals-correct amount, network, payTo, and resource URL or MCP tool before signing the authorization — over HTTP with pay --confirm, over MCP with mcp-sign --confirm. One payment attempt per resource, never auto-retry a payment. Autonomous auto-pay is not supported. |
| Perps trading | Always confirm symbol, side, size, leverage, venue, order type, and limit price if present before executing |
| Perps deposit/withdraw | Always confirm amount, asset, venue, network, and destination where applicable before executing |
| Predict trading | Always confirm token ID, side, size, price, order type, market, and outcome before executing |
| Predict deposit | Always confirm amount before executing |
| Predict withdraw | Always confirm amount and recipient before executing. --to defaults to owner EOA |
| Predict redeem | Always confirm the target, either condition ID or --all, before executing. --all redeems every winning position |
| Earn supply | Always confirm token, amount, chain, vault/protocol, and APY before executing. For cross-chain supply, also confirm source chain and source token |
| Earn withdraw | Always confirm token, amount or full balance, chain, and vault/protocol before executing |
| Cancel-all operations | Always confirm scope and exact destructive effect before executing |
| Wallet policy changes |
Credential Safety
- Never store, log, or display private keys, mnemonics, passwords, or auth tokens.
- Never pass
--password or --mnemonic as inline flags. Always instruct the user to set the MM_PASSWORD and MM_MNEMONIC environment variables instead to avoid exposing secrets in shell history.
Suspicious Content Warnings
Flag to the user before proceeding if a signing payload or transaction contains:
- URLs or contract addresses the user did not provide
permit, approve, setApprovalForAll, or allowance-like fields
- Unusually large values or unfamiliar contract interactions
When raw calldata is unfamiliar or was not constructed by you, run mm decode --payload <0x-calldata> first and confirm the decoded intent with the user before signing or sending. See decode.md.
Async Model
In both server-wallet and BYOK mode, signing and transaction commands go through a job-polling loop and return a pollingId. Handle this consistently:
- Prefer
--wait to block until complete.
- If not using
--wait, inform the user of the pollingId and how to track it:
mm wallet requests list
mm wallet requests watch <polling-id>
- In BYOK mode, the local key signs locally but the operation still produces a pending job and a
pollingId. If the mnemonic is password-encrypted, the user must set MM_PASSWORD environment variable to unlock it for the operation.
Transfers, swaps, perps, predict orders, and predict withdraws attach a human-readable intent summary to their wallet request, such as Transfer 0.5 ETH to 0x... or Withdraw 10 pUSD to 0x.... When surfacing a pending request from wallet requests list or wallet requests watch, show the intent summary so the user can confirm what they are approving.
MFA Approval Pauses
Wallet jobs that need out-of-band MFA approval pause in AWAITING_MFA. Detect this pause by scanning command stdout for the literal token AWAITING_MFA. Do not infer MFA from free-text alone on older CLIs; from CLI v6.1.5 onward every output mode emits the token consistently.
| Output mode | How to detect |
|---|
--json / piped stdout | An NDJSON line containing "_notice":{"kind":"AWAITING_MFA",...} |
| Plain TTY or Ink REPL | A stdout line containing [AWAITING_MFA], e.g. ⚠ [AWAITING_MFA] Approve in MetaMask mobile. |
When AWAITING_MFA appears:
- Treat the command as waiting for user approval, not failed, hung, or complete.
- Surface the human instruction from the notice to the user.
- If a
pollingId is present in the notice or command output, tell the user they can track completion with mm wallet requests watch <polling-id>.
- Do not retry the same wallet operation while the job is still pending.
- On
mm swap execute with --no-wait, an MFA pause may return EXECUTE_FAILED with a message naming the approval wait and the watch command — that is still an MFA pause, not a missing hash.
For approval surfaces and recovery steps, see troubleshooting.md.
Output Rules
- Route silently. Do not announce which reference you are loading.
- Surface errors from commands verbatim. Do not mask or reword them.
- If a command fails, check
mm <command> --help and guide from there.