Aave

Get user positions

get_user_positions

Read-only

A wallet's Aave positions (supplies and borrows) on v3, v4, or both. Omit chainId and both versions cover every chain they serve, stating which under 'chainsCovered'; there is no need to loop over chains yourself. 'chainsNotServed', when present, lists chains this API holds no market on: Aave supports the chain, there is nothing here to read, so an empty result for one of them is not an answer about that chain, and asking again returns the same nothing. v4 returns 'positions', each with its own health factor; v3 returns 'supplies' and 'borrows'. These are Aave-side positions only: a wallet's own token balances are not here, and an empty result means nothing is supplied or borrowed rather than that the wallet is empty. For what it holds, pass 'user' to get_markets, which returns walletBalance per reserve.

Input Schema

TableJSON Schema

Name	Required	Description
`user`	Yes	Wallet address, 0x-prefixed (40 hex chars).
`chainId`	No	Chain id to restrict to, e.g. 1 for Ethereum. Omit the argument entirely to cover every chain.
`version`	No	Protocol version (default all).

TDQS

A4.9/5.0

Behavior5/5

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

Annotations only provide readOnlyHint=true, so the description carries the load and does an exceptional job: it explains cross-version behavior, response naming differences, chainsNotServed semantics, empty-result meaning, and the wallet-balance exclusion. This far exceeds what annotations already convey.

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?

Four sentences, every one earns its place: scope, chain coverage semantics, version response differences, and empty-result interpretation with an alternative tool pointer. Despite density, it is well-organized and front-loads the core purpose before caveats.

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?

Complete for a read-only query tool with no output schema. It covers all salient behaviors: which chains, which versions, response shape differences, empty-result meaning, and the boundary with wallet balances. An agent can likely call and interpret results correctly based entirely on this description.

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 schema already documents all three parameters. The description still adds behavior-level meaning: 'Omit chainId ... cover every chain' and 'v4 returns positions, v3 returns supplies and borrows' go beyond the schema field descriptions. One small gap: it doesn't restate the exact enum default 'all', though the schema covers that.

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 states a clear verb+resource: reading a wallet's Aave positions (supplies/borrows) on v3/v4/both. It distinguishes from most siblings by scoping to Aave positions and explicitly says wallet token balances are not included. It also contrasts with get_markets, demonstrating differentiation rather than overlap.

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?

Extremely direct usage guidance: omit chainId and both versions cover every chain, no need to loop; lists chainsNotServed meaning; distinguishes v3 vs v4 response shapes; warns that empty results mean no Aave positions, not an empty wallet, and directs users to get_markets for wallet balances. This includes both when-to-use and when-not-to-use.

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

All Aave 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

A4.1/5.0

Disambiguation4/5

The tool set is organized into clear read/prepare/action families, and cross-references like get_user_positions vs get_user_summary or get_markets vs get_reserve_details keep purposes distinct. A couple of generic names—prepare_action vs prepare_order, preview_action vs prepare_action—could cause misselection, but the descriptions explicitly separate them.

Naming Consistency4/5

Names overwhelmingly follow a verb_noun snake_case pattern: get_* for reads, prepare_* for transaction builders, plus cancel_order and submit_signed_order. The pattern is consistent overall, though a few generic exceptions like get_started, get_aave_guide, and preview_action break the strict resource-noun convention.

Tool Count2/5

With 40 tools, the set is well past the 25+ threshold and feels heavy even though the domain is broad. Most tools are distinct and justified, but an agent must navigate a very large list, and the server could reasonably be split into protocol, governance, and swap/order surfaces.

Completeness4/5

The surface covers v3/v4 reads, positions, health factors, simulations, transaction building, collateral, eMode, liquidation, rewards, sGHO, swaps/orders, and governance proposal reads, with clear sequencing between preview, prepare, and submit. Minor gaps exist—governance has no voting transaction and stkGHO balance/cooldown state is not readable—but they do not block the core Aave workflows.

Resources

Need Help?