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.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

First observedAug 31, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already mark this as read-only and non-destructive, and the description adds valuable behavioral details beyond that: markets without matching categories are omitted from results, unfiltered calls return every category on every chain, and the returned categoryId is specifically what prepare_set_emode consumes. This gives the agent accurate expectations about response scope and edge cases.

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?

Every sentence earns its place: version restriction, conceptual context, return contents, filtering guidance, omission behavior, and v4 contrast. The description is dense but well organized, front-loading the critical v3-only constraint before operational details.

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?

Despite having no output schema, the description explains the key return fields (categoryId, LTV, liquidation thresholds, symbols), scoping behavior, and filtering semantics. For a read-only lookup tool with optional parameters, this is sufficient for an agent to select and invoke it correctly.

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 baseline is 3, but the description enriches both parameters: it explains that omitting chainId covers all chains and that filtering by symbols returns only the categories containing that asset, with a strong preference hint due to response size. This goes beyond the schema's basic descriptions without being redundant.

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 ('Returns') and clearly identifies the resource: eMode categories per market, including categoryId, LTV, liquidation thresholds, and symbols. It also distinguishes itself by noting v3-only applicability and contrasting with v4's replacement of eMode, making it unambiguous versus sibling tools like prepare_set_emode.

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 gives clear context for when to use the tool: only for v3 chains, with v4 explicitly called out as not having eMode. It also provides practical guidance on using the 'symbols' filter and notes the large unfiltered response, though it does not explicitly name alternative tools or say when not to use this one beyond the v4 exclusion.

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.2/5.0

Disambiguation4/5

The tool set splits into clean families (get_ reads, prepare_ transaction builders, direct state-changing verbs) and the descriptions aggressively cross-reference each other to draw explicit boundaries, e.g. get_user_positions vs get_user_summary vs get_user_activity. A few clusters could still prompt misselection: the four get_user_* tools share a naming shape, get_started and get_aave_guide both claim the 'when nothing fits' role, and get_hub_assets vs get_markets both return rate data at different aggregation levels.

Naming Consistency5/5

Every tool follows a verb_noun pattern with a highly predictable convention: get_ for all read operations, prepare_ for every unsigned-transaction builder, and direct imperatives (cancel_order, submit_signed_order, preview_action) for the rest. search_governance_proposals is the only read not named get_, but search_ is semantically apt for full-text lookup. The get_/ prepare_ split is instantly legible across all 40 tools.

Tool Count2/5

40 tools is well past the 25+ 'too many' threshold, and even Aave's genuinely wide scope (v3 and v4 lending, governance, sGHO, rewards, intent orders) does not fully justify the surface. get_started and get_aave_guide overlap as guidance entry points, the three history tools and the get_user_* cluster add near-duplicate reads, and the paragraph-long descriptions compound the agent's context burden. Most tools earn their place individually, but the set would be stronger consolidated to roughly 25-30 tools.

Completeness4/5

Core workflows are fully covered with no dead ends: preview_action simulation, prepare_action and prepare_set_* builders, get_transaction_processed polling, plus the complete order lifecycle (quote, prepare, submit, status, cancel) and sGHO/rewards coverage. Minor gaps remain: governance is read-only with no way to cast a vote, the server cannot read a stkGHO balance or cooldown state for the migration flow, and there is no stkAAVE staking surface. These are workaroundable, and the v3/v4 dual-version handling is unusually thorough.

Resources

Need Help?