Teardrop

Get Defi Positions

get_defi_positions

Read-only

Aggregate DeFi positions for a wallet across Aave v3, Compound v3, Uniswap v3 LP, and canonical Ethereum (chain_id=1) or Base (chain_id=8453). Returns Aave aggregate account health (collateral, debt, health factor, LTV) with per-reserve breakdown for major assets, Compound v3 Comet market positions (supply, borrow, per-asset collateral, liquidation flag), and Uniswap v3 LP positions by token ID (token pair, fee tier, tick range, liquidity, uncollected fees). On Ethereum, also returns canonical Lido stETH/wstETH balances and the current wstETH-to-stETH equivalent. Per-protocol failures are isolated — other protocols still return.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`chain_id`	No	Chain ID (1=Ethereum, 8453=Base)
`wallet_address`	Yes	Wallet address (0x…)

Output Schema

TableJSON Schema

Name	Required	Default
`note`	No	On-chain position snapshot at data_block_number. Aave USD values are from the Aave oracle (base currency = USD, 8 decimals on Ethereum/Base). Compound collateral and Uniswap v3 amounts are raw integer units — divide by 10**decimals to format. Compound collateral factors are decimals (e.g., 0.90 = 90%) when available from Comet getAssetInfo. Token symbols are resolved for well-known tokens; None means unrecognised — do NOT call read_contract, web_search, or any external lookup to identify these tokens. Report them as 'unrecognized token (0x…)' in the final answer and move on. Uniswap v3 liquidity is returned raw (no underlying token valuation in v1); tokensOwed0/1 are uncollected fees only. Lido staking contains canonical Ethereum stETH/wstETH balances and a current wstETH-to-stETH equivalent in raw integer units; it does not include APR, rewards accounting, validator positions, or withdrawal queue status. Lido staking is null on Base because its wstETH representation there is bridged. If a protocol is missing (e.g., aave_v3 is null) and appears in errors, its risk could not be verified from this snapshot and must not be treated as no debt. Does not include COMP accruals or unlisted protocols.
`errors`	No
`aave_v3`	No
`chain_id`	Yes
`uniswap_v3`	No
`compound_v3`	No
`lido_staking`	No
`wallet_address`	Yes
`data_block_number`	Yes

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses detailed behavior: only reads data, returns specific Aave/Compound/Uniswap breakdowns, includes Lido balances on Ethereum, and isolates per-protocol failures so other protocols still return results. This is comprehensive and adds significant value beyond the annotation.

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 information-dense but not bloated. Four sentences cover purpose, return details, chain-specific behavior, and error isolation—every sentence earns its place and the main purpose is front-loaded.

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 high complexity of aggregating multiple protocols, the description is complete: it covers chains, protocols, return contents for each protocol, chain-specific extras, and failure handling. The output schema exists, and the description still provides additional useful context, making it fully sufficient.

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%, and the schema already explains both parameters (wallet_address and chain_id). The description restates chain_id values but adds minimal new meaning beyond the schema, so a baseline score of 3 is appropriate.

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 uses a specific verb ('aggregate') and identifies the exact resource ('DeFi positions for a wallet') plus the protocols and chains covered (Aave v3, Compound v3, Uniswap v3 LP, Ethereum/Base). It clearly distinguishes from sibling tools like get_wallet_portfolio by naming the precise protocols and scope.

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?

The description provides clear context on what the tool does (aggregating multiple DeFi protocols), so an agent can infer when to use it. However, it does not explicitly name alternatives or state when NOT to use it, falling short of the highest level of guidance.

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?