AgentWallet MCP Server

approve_token

Approve a spender contract to transfer ERC-20 tokens on your behalf, required before DeFi protocol interactions. Specify an exact amount; unlimited approvals are refused by default.

Instructions

Approve a spender contract to transfer ERC-20 tokens on your behalf. Required before interacting with any DeFi protocol (DEXs, lending, etc.). Specify an exact amount. "max" (an unlimited allowance) is refused by default and always under a spend policy; only the operator can allow it, with AGENTWALLET_ALLOW_UNLIMITED_APPROVAL=1 while no policy is set. Under a spend policy an approval is a spend: it counts against the budgets and the spender is checked as a recipient.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "wallet_id": "<wallet_id>",
      "token": "<token>",
      "spender": "<spender>",
      "amount": "<amount>",
      "chain_id": "<chain_id>"
    },
    "name": "approve_token"
  }
}

Input Schema

Name	Required	Description
`token`	Yes	ERC-20 token contract address
`amount`	Yes	Amount to approve in human-readable format (e.g. "1000"); "max" means unlimited and is refused unless the operator allowed it
`spender`	Yes	Contract address to approve as spender
`chain_id`	Yes	Chain ID
`decimals`	No	Token decimals. Resolved from the registry or the token contract when omitted; if given, it must match
`wallet_id`	Yes	Wallet ID

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv1.14.8Oct 27, 2026

changedInput schema / properties / amount / description

Previous value: -"Amount to approve in human-readable format (e.g. \"1000\"), or \"max\" for unlimited"New value: +"Amount to approve in human-readable format (e.g. \"1000\"); \"max\" means unlimited and is refused unless the operator allowed it"

addedInput schema / properties / chain_id / maximum
```
Added value: +9007199254740991
```
addedInput schema / properties / chain_id / minimum
```
Added value: +-9007199254740991
```
addedInput schema / properties / wallet_id / maximum
```
Added value: +9007199254740991
```
addedInput schema / properties / wallet_id / minimum
```
Added value: +-9007199254740991
```

Changed4 schema fields changedv1.14.2Oct 14, 2026
- removedInput schema / properties / decimals / default
```
Removed value: -18
```
- changedInput schema / properties / decimals / description
```
Previous value: -"Token decimals (6 for USDC, 18 for most tokens)"New value: +"Token decimals. Resolved from the registry or the token contract when omitted; if given, it must match"
```
- addedInput schema / properties / decimals / maximum
```
Added value: +36
```
- addedInput schema / properties / decimals / minimum
```
Added value: +0
```
First observedv1.7.3Mar 11, 2026

TDQS

A3.9/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 discharges most of it: unlimited approvals are refused by default, are gated behind an operator env var and only when no policy is set, and under a policy the approval counts as a spend against budgets with the spender checked as a recipient. It does not say what on-chain effect occurs (overwrite vs. increment of an existing allowance) or what is returned.

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?

Front-loaded with the core action, then the gating rules. Dense but every sentence carries real information; the final sentence is a long run-on bundling spend-policy and recipient-check behavior, which costs a little readability.

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?

Without annotations or an output schema, the description covers the risky parts well: unlimited-approval refusal, operator gating, and spend-policy accounting. It is thinner on execution details an agent would want for a state-changing on-chain call, such as whether the approval replaces an existing allowance and what success looks like.

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

Parameters3/5

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

Schema coverage is 100% and every parameter already carries a description, including the 'max' semantics for amount. The description only reinforces 'specify an exact amount' and adds no format or resolution detail beyond the schema, so baseline 3 applies.

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

Purpose4/5

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

States a specific verb and resource: approve a spender contract to transfer ERC-20 tokens. The ERC-20 qualifier implicitly separates it from approve_permit2, but no sibling is named, so an agent must infer the distinction rather than being routed.

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?

Gives explicit when-to-use ('Required before interacting with any DeFi protocol') and when-not ('max' is refused by default). It doesn't point to check_approval or get_allowance for verifying an existing allowance, so the alternative-selection guidance is clear but incomplete.

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