Aave

Get v3 eMode categories

get_emode_categories

Read-only

v3 only. eMode groups correlated assets (ETH-correlated, stablecoins) so they borrow against each other at a higher LTV, raising borrowing power at the cost of restricting which assets the position may hold. Returns each market's categories with the 'categoryId' that prepare_set_emode takes, its LTV and liquidation thresholds, and which symbols are in it. Narrow with 'symbols' (e.g. ['USDC']) to get just the categories that asset is in - unfiltered this is every category on every chain. Markets with no matching category are left out entirely. v4 has no eMode: it replaces it with risk premium and dynamic config.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`chainId`	No	Chain id to restrict to, e.g. 1 for Ethereum. Omit the argument entirely to cover every chain.
`symbols`	No	Optional token symbols to return, e.g. ['USDC','GHO']. Case-insensitive. Strongly preferred when you know the asset: a chain has ~70 reserves and listing them all is a large response.

TDQS

A4.3/5.0

Behavior4/5

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

Beyond the readOnlyHint annotation, the description discloses meaningful behavior: v3-only availability, omission of markets with no matching category, the categoryId/LTV/liquidation threshold return contents, and the broad unfiltered response across every chain. This gives the agent a realistic expectation of scope and output without relying solely on 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is slightly longer than average, but the front-loaded 'v3 only' scoping and the eMode explanation earn their place. The sentences flow from definition to output to filtering behavior, with no redundant restatement of the tool name or title.

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

Completeness4/5

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

There is no output schema, so the description compensates by listing the key returned fields (categoryId, LTV, liquidation thresholds, symbols) and explaining what happens when no category matches. It is sufficient for an agent to call the tool correctly, though a precise response shape or chain-grouping structure would make it fully complete.

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?

The schema already documents both parameters fully, so the baseline is satisfied. The description adds extra meaning by explaining filtering behavior, such as how omitting chainId covers all chains, how symbols narrow the result, and that markets without a matching category are excluded.

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 specific action and resource: it returns each market's eMode categories, including the categoryId consumed by prepare_set_emode, LTV and liquidation thresholds, and member symbols. It clearly scopes the tool to v3 only and explains the relationship to eMode, making it easy to distinguish from the large sibling list.

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?

It gives clear usage context: v3 only, v4 has no eMode, and filtering by symbols is recommended when the asset is known. It does not name an alternative tool to use instead, but the v4 exclusion and filtering guidance are enough for an agent to decide when this tool is appropriate.

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?