AgentWallet MCP Server

get_allowance

Check how many ERC-20 tokens a spender is approved to transfer, returned in raw and human-readable format. Use it to verify whether an approval is needed before a DeFi transaction.

Instructions

Check how many ERC-20 tokens a spender is approved to transfer. Returns the allowance in both raw and human-readable format. Use this to check if an approval is needed before a DeFi transaction.

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>",
      "chain_id": "<chain_id>"
    },
    "name": "get_allowance"
  }
}

Input Schema

Name	Required	Description
`token`	Yes	ERC-20 token contract address
`spender`	Yes	Spender contract address to check
`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 (used to determine the owner address)

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv1.14.8Oct 27, 2026
- 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.8/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden. It implies a read-only check and says the allowance is returned in raw and human-readable form, but it does not explicitly state that the call has no side effects, what permissions it needs, or how failures are reported.

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

Conciseness5/5

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

The description is three tight sentences, front-loads the core action, then adds the return format and the intended usage context. There is no observable 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 simple read-only allowance lookup, the description covers purpose, usage context, and the shape of the result at a high level. With no output schema, it could say more about the exact response shape, but the key information an agent needs to select and invoke it is present.

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 description coverage is 100%, so all five parameters are already documented in the schema. The description reinforces the token/spender concept but adds no additional parameter-level semantics beyond what the schema provides.

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?

The description uses a specific verb and resource: checking an ERC-20 allowance for a spender, and it clarifies that the result is the approved transfer amount. It is clear on its own, but it does not distinguish itself from the sibling tool check_approval, which appears to overlap in purpose.

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?

It gives a concrete usage context: use it to check whether an approval is needed before a DeFi transaction. It does not state when not to use it or explicitly route the agent to check_approval or other approval-related siblings, so some ambiguity remains.

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