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: check a wallet for a drain: tokens pulled out in transactions it did not send

check_wallet_drain

Read-onlyIdempotent

chainpeek: Check a wallet for a drain: find tokens pulled out without its signature. For live approvals with revoke transactions use audit_token_approvals. Returns a verdict (drained | review | clean) for wallet over the latest 2,000 blocks: each transfer out of USDC and USDT (or up to 5 tokens) is sent, authorized (EIP-3009, as x402 uses), wallet_code, pulled (someone else's transaction) or unknown, with the puller and its live allowance, the nonce before and after, and evidence. Drained: a pull to an address the wallet did not pay itself, or pulls of half of a token's holding. Review: other pulls, a balance that fell with an unmoved nonce, smart-account or EIP-7702 wallets. Gasless orders look like pulls. Bad input is a 422, a failed read a 502 (neither charged). Typically 2-10 s. Price: USD 0.002. Free: 10 chain reads per IP per UTC day. Docs: https://tanod.dev/learn/wallet-drain-check-api.html

Input Schema

Name	Required	Description
`chain`	Yes	base or ethereum (the chains with built-in USDC and USDT here).
`tokens`	No	1 to 5 tokens: USDC, USDT or contract addresses. Default: USDC and USDT.
`wallet`	Yes	The wallet to check (0x + 40 hex).
`lookback_blocks`	No	Latest blocks read (1-2,000; default 2,000, about 67 minutes on Base and 6.7 hours on Ethereum).

Output Schema

Name	Required	Description
`risk`	No
`chain`	No
`error`	No	Only on an error result: an object {code, message}, or the reason string of an x402 PaymentRequired object.
`nonce`	No
`rules`	No
`counts`	No
`limits`	No
`tokens`	No
`wallet`	No
`history`	No
`reasons`	No
`verdict`	No
`rpc_calls`	No
`transfers`	No
`wallet_code`	No
`transfers_total`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedNov 3, 2026
- addedOutput schema / properties / history / properties / tx_lookup_cap
```
Added value: +{
+  "type": [
+    "integer",
+    "null"
+  ]
+}
```
- addedOutput schema / properties / tokens / items / properties / authorized_raw
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```
- addedOutput schema / properties / tokens / items / properties / held_raw
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```
- addedOutput schema / properties / tokens / items / properties / pulled
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```
- addedOutput schema / properties / tokens / items / properties / start_balance
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```
- addedOutput schema / properties / tokens / items / properties / unknown_raw
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```
First observedOct 22, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description goes well beyond them: verdict taxonomy with the exact drained/review criteria, error semantics (422 bad input, 502 failed read, neither charged), latency (2-10 s), price and free-tier limits, and a false-positive caveat about gasless orders. That is unusually rich behavioral context for an agent deciding whether to call it.

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-loads purpose and the sibling routing in the first two sentences, then layers verdict semantics, errors, latency and price. It is dense but nearly every clause carries information; the verdict definitions could be split into bullets for faster scanning, which is the only real structural weakness.

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?

An output schema exists, yet the description still explains how to interpret the verdict values, which is the decision-relevant part. With costs, latency, error behavior, scope limits and known false positives all covered, an agent has everything needed to call it and read the result correctly.

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 each parameter already carries a description (chain enum, tokens pattern and default, lookback bounds with time equivalents), so the schema does the heavy lifting. The description only adds that up to 5 tokens are checked and echoes the 2,000-block default, which is marginal value over the structured data.

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?

States a specific verb and resource (check a wallet for a drain) plus the precise scope: tokens pulled out without the wallet's signature, over the latest 2,000 blocks. It explicitly separates itself from the sibling audit_token_approvals by naming the condition (live approvals with revoke transactions) that selects the sibling.

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 one explicit routing rule to an alternative tool (audit_token_approvals) and clear context for what this tool covers, including that gasless orders look like pulls. It does not enumerate other exclusions or prerequisites, so it is clear but not exhaustive.

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?