Teardrop

Get Token Approvals

get_token_approvals

Read-only

Audit ERC-20 token allowances for a wallet address. By default, returns all non-zero approvals for assets in the shared tracked-asset registry across curated DeFi protocol spenders (Uniswap, Aave, Compound, 1inch, 0x, OpenSea). Flags unlimited approvals with risk levels: high=unknown spender, medium=trusted protocol, low=bounded amount. Use before swaps to verify approval state, or after security incidents to detect active exploit vectors. Ethereum mainnet and Base only.

Input Schema

TableJSON Schema

Name	Required	Description
`tokens`	No	Token contract addresses to check (max 50). Defaults to the platform tracked token list.
`chain_id`	No	Chain ID (1=Ethereum, 8453=Base)
`spenders`	No	Spender contract addresses to check (max 20). Defaults to the curated DeFi protocol list.
`wallet_address`	Yes	Wallet address (0x…)

Output Schema

TableJSON Schema

Name	Required	Description	Default
`note`	Yes
`error`	No
`chain_id`	Yes
`approvals`	Yes
`risk_summary`	Yes
`wallet_address`	Yes

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses default behavior (returns non-zero approvals from tracked-asset registry and curated protocol spenders) and output semantics (flags unlimited approvals with risk levels). It also provides network limitations, giving substantial behavioral context.

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 concise, front-loaded with the primary purpose, and each sentence adds value: purpose, defaults, risk flags, use cases, and network restrictions. No wasted words.

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?

Given the output schema exists and all parameters are described, the description fully covers the tool's behavior, use cases, and limitations. No critical information is missing.

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% as all four parameters have detailed descriptions in the schema. The description adds minimal extra meaning, mostly reinforcing defaults (e.g., 'shared tracked-asset registry' vs schema's 'platform tracked token list'). No significant new parameter semantics are introduced.

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 description clearly states the tool's purpose with a specific verb ('Audit') and resource ('ERC-20 token allowances for a wallet address'). It distinguishes itself from sibling tools by focusing on approvals/allowances and risk flagging, rather than balances or transactions.

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?

The description provides explicit usage scenarios: 'Use before swaps to verify approval state, or after security incidents to detect active exploit vectors.' It also states an exclusion: 'Ethereum mainnet and Base only,' clarifying when the tool is not applicable.

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

All Teardrop tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0

Disambiguation4/5

Most tools target distinct blockchain/DeFi resources and actions. A few pairs like get_lending_rates vs get_yield_rates and get_defi_positions vs get_liquidation_risk have overlapping boundaries, but detailed descriptions and explicit redundancy notes (e.g., get_eth_balance vs get_wallet_portfolio) reduce confusion.

Naming Consistency5/5

All tools follow a consistent snake_case verb_noun pattern (e.g., get_block, convert_currency, decode_transaction). The only minor deviations are noun-first names like http_fetch and web_search, but the style is uniform and predictable.

Tool Count2/5

At 27 tools, the server exceeds the 25-tool threshold for 'too many' and feels heavy. While the breadth of DeFi and crypto features justifies some size, the number is unwieldy for an agent to scan efficiently and could be consolidated (e.g., merging balance-related tools).

Completeness4/5

The tool surface covers a wide range of blockchain data: balances, prices, TVL, yields, DEX quotes, gas, block/transaction details, approvals, and DeFi positions. Gaps include lack of wallet transaction history and NFT support, but these are beyond the server's clear focus on read-only DeFi analytics.

Resources

Need Help?