Tanod MCP Server (Deprecated)

by dev.tanod

Overview Discussions Admin

This connector has been deprecated

The correct URL is https://tanod.dev/mcp and NOT https://tanod.dev/mcp/ (CORRECT: NO TRAILING SLASH)

Correct Glama listing: https://glama.ai/mcp/connectors/dev.tanod/tanod

WRONG Glama listing: https://glama.ai/mcp/connectors/dev.tanod/tanod-mcp-server/

chainpeek: list a wallet's live token approvals (ERC-20 and Permit2) with revoke transactions

audit_token_approvals

Read-onlyIdempotent

chainpeek: List a wallet's live token approvals and get revoke transactions. For tokens already pulled out use check_wallet_drain; for one allowance use get_allowance. Returns the live ERC-20 and Permit2 allowances of wallet: amount, unlimited, spender code (key-controlled, contract, new contract), newest approval and pull, stale, flags with evidence, and revoke, the unsigned transaction that sets it to 0. Candidates: approval events in the latest 6,000 blocks, Permit2, and spenders. High: unlimited to a key-controlled account. Medium: limited to one, or unlimited to a contract with no code 30 days ago. Low: other unlimited or stale. Older approvals are found only via spenders or Permit2. Bad input is a 422, a failed read a 502 (neither charged). Nothing is signed or sent. Typically 3-15 s. Price: USD 0.005. Free: 10 chain reads per IP per UTC day. Docs: https://tanod.dev/learn/token-approval-audit-api.html

Input Schema

Name	Required	Description
`chain`	Yes	base or ethereum (the chains with built-in USDC and USDT here).
`tokens`	No	Up to 50 token contracts to audit. Default: USDC, USDT and up to 18 tokens the wallet has sent (from its transfer history).
`wallet`	Yes	The wallet whose approvals are audited (0x + 40 hex).
`spenders`	No	Up to 50 spender addresses whose ERC-20 and Permit2 allowances are read directly on every audited token, however old (tokens x spenders at most 200). The full-coverage path for spenders you know.
`stale_days`	No	An allowance is stale when the spender pulled nothing from the wallet in this many days (1-3,650; default 90).
`lookback_blocks`	No	Latest blocks scanned for approval events (0-6,000; default 6,000, about 3.3 hours on Base and 20 hours on Ethereum). 0 scans nothing and checks `spenders` and Permit2 only.

Output Schema

Name	Required	Description
`risk`	No
`block`	No
`chain`	No
`error`	No	Only on an error result: an object {code, message}, or the reason string of an x402 PaymentRequired object.
`rules`	No
`limits`	No
`tokens`	No
`wallet`	No
`checked`	No
`history`	No
`reasons`	No
`rpc_calls`	No
`allowances`	No
`stale_days`	No
`block_timestamp`	No
`allowances_total`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedNov 3, 2026
- addedOutput schema / properties / history / properties / approval_events
```
Added value: +{
+  "type": [
+    "integer",
+    "null"
+  ]
+}
```
- addedOutput schema / properties / history / properties / code_reads
```
Added value: +{
+  "type": [
+    "integer",
+    "null"
+  ]
+}
```
- addedOutput schema / properties / history / properties / contracts_not_scanned
```
Added value: +{
+  "type": [
+    "integer",
+    "null"
+  ]
+}
```
- addedOutput schema / properties / history / properties / contracts_scanned
```
Added value: +{
+  "type": [
+    "integer",
+    "null"
+  ]
+}
```
- addedOutput schema / properties / history / properties / permit2_events
```
Added value: +{
+  "type": [
+    "integer",
+    "null"
+  ]
+}
```
- addedOutput schema / properties / history / properties / transfer_history_rows
```
Added value: +{
+  "type": [
+    "integer",
+    "null"
+  ]
+}
```
- addedOutput schema / properties / history / properties / transfer_history_truncated
```
Added value: +{
+  "type": [
+    "boolean",
+    "null"
+  ]
+}
```
- addedOutput schema / properties / history / properties / transfers_out_in_window
```
Added value: +{
+  "type": [
+    "integer",
+    "null"
+  ]
+}
```
- addedOutput schema / properties / history / properties / tx_lookup_cap
```
Added value: +{
+  "type": [
+    "integer",
+    "null"
+  ]
+}
```
First observedOct 22, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the read-only/non-destructive annotations it discloses that nothing is signed or sent, the 3-15 s latency, pricing (USD 0.005), free quota (10 reads/IP/day), error semantics (422 bad input, 502 failed read, neither charged), and the risk-tier logic (high/medium/low). These are precisely the operational traits annotations cannot carry.

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 purpose and alternatives, and the pricing/error/latency facts each earn their space. The mid-paragraph risk-tier enumeration is telegraphic and dense, slowing comprehension slightly, but no sentence is filler.

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

Completeness5/5

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

For a 6-parameter, paid, open-world read with an output schema, everything an agent needs is present: scope, default behavior, coverage limits, failure codes, cost, latency, and a docs link. Return-value shape is correctly left to the output schema.

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. The description adds real meaning on top: it explains what the default scan actually covers (approval events in the latest 6,000 blocks plus Permit2 and `spenders`) and frames `spenders` as the full-coverage path for known spenders, which clarifies intent beyond the field text.

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?

The opening sentence gives a specific verb and resource ('List a wallet's live token approvals and get revoke transactions') and immediately names the two siblings it is not: check_wallet_drain and get_allowance. An agent can distinguish it from neighbors without opening the schema.

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

Usage Guidelines5/5

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

Explicit routing is given: check_wallet_drain for tokens already pulled, get_allowance for a single allowance. It also states a coverage boundary ('Older approvals are found only via `spenders` or Permit2'), which tells the agent when this tool will miss things and how to compensate.

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

All Tanod MCP Server (Deprecated) tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?