Aave

Prepare supply / borrow / withdraw / repay

prepare_action

Read-only

Build an unsigned transaction to supply, borrow, withdraw, or repay on Aave (v3 or v4). Returns an execution plan (a transaction to sign, or an approval step first). Non-custodial: the user's wallet signs and submits; nothing is sent here, so building one is free and commits the user to nothing. Choose sensible values, build it, and say what you chose - do not stop to ask the user first, because they see the transaction before they sign it. Send only the arguments that apply and leave every other one out: v4 takes 'reserve'; v3 takes 'market' + 'token' + 'chainId'; 'max' is for withdraw and repay; 'enableCollateral' is for supply. Never send 'permitSignature' or 'permitDeadline' on a first call: they exist only to re-issue a call after an approval step handed you a permit to sign under 'bySignature', so if you have not been handed one, leave both out. Two things that catch callers out: a supply does NOT become collateral unless you pass enableCollateral:true, and without collateral the borrowing power is zero so any later borrow is refused; and collateral pinned by an open borrow cannot be withdrawn, so a withdraw has to repay first. After sending any transaction, poll get_transaction_processed before building the dependent next one.

Input Schema

TableJSON Schema

Name	Required	Description
`max`	No	Withdraw/repay only: use the entire balance/debt.
`token`	No	v3 only: underlying token address.
`action`	Yes	Which action to build.
`amount`	No	Amount in MAIN units (e.g. '10.5'), never base units: 100000 base units of a 6-decimal token is '0.1', not '100'. Convert before sending if the user stated base units. Omit only if max=true.
`market`	No	v3 only: market pool address, from a get_markets row in this session. It cannot be recalled: an Aave pool address you already recognise belongs to another deployment (v2, or another chain) and is rejected.
`native`	No	Use the chain's native gas token instead of an ERC-20.
`sender`	Yes	Sender wallet address, 0x-prefixed (40 hex chars).
`chainId`	No	v3 only: chain id (positive integer).
`reserve`	No	v4 only: the opaque reserveId, copied verbatim from a get_markets row or a get_position_items item in this session (e.g. 'MTo6MHg5NGU3...Ojo1') - it cannot be constructed or recalled, so fetch one before the first call rather than after a refusal. The 'spokeId' from get_user_positions is NOT this: it is the same encoding one segment short, names the spoke rather than a reserve inside it, and is rejected. A token symbol such as 'USDC' is rejected too.
`version`	Yes	Protocol version (v3 or v4; required, no 'all' for actions).
`permitDeadline`	No	Unix seconds, the 'deadline' from the permit message that was signed. Required with permitSignature.
`permitSignature`	No	Send this only to replay a call after an approval handed you a permit to sign: the user's signature (0x...) over the PermitTypedData that approval carried under 'bySignature', on either version. It replaces the approval transaction, so the action comes back in one step. Requires permitDeadline.
`enableCollateral`	No	supply only: also enable the asset as collateral (default false). Leave it off and the supply earns yield but backs no borrowing, so a following borrow fails for exceeding a borrowing power of zero. Pass true whenever the plan is to borrow against it.

TDQS

A4.8/5.0

Behavior5/5

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

Annotations declare readOnlyHint=true, and the description aligns by explaining building is non-custodial, sends nothing, is free, and commits the user to nothing. It goes further by disclosing behavioral consequences: supply without enableCollateral gives zero borrowing power, collateral pinned by a borrow cannot be withdrawn, and permit fields only replay a prior approval step. This is exactly the kind of context beyond annotations that prevents misuse.

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?

Although long, the description is dense with high-value guidance and every sentence earns its place. Core purpose is front-loaded, followed by return semantics, non-custodial behavior, user-interaction instruction, parameter compatibility rules, and the two most common failure modes. The length is justified by the complexity of a 13-parameter tool with two protocol versions.

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?

For a complex tool with no output schema, the description covers the essential call-decoding information: required fields, version-specific fields, action-specific booleans, permit replay flow, where to source opaque IDs, unit conversion, and post-call polling. It even warns about the two most common caller mistakes. Nothing an agent needs to call this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/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 adds significant cross-parameter meaning: v4 takes 'reserve' while v3 takes 'market'+'token'+'chainId', 'max' applies only to withdraw/repay, 'enableCollateral' applies only to supply, and permit fields must never be sent on the first call. It also explains the behavioral consequences of omitting enableCollateral and how to obtain reserve/market values from prior calls.

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 opens with a specific verb and resource: 'Build an unsigned transaction to supply, borrow, withdraw, or repay on Aave (v3 or v4).' It clearly states what the tool returns ('an execution plan') and is easily distinguished from sibling prepare_* tools like prepare_cancel_order or prepare_claim_rewards.

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 strong operational guidance: send only applicable args, never include permit fields on a first call, poll get_transaction_processed after sending, and don't stop to ask the user because they see the transaction before signing. It does not explicitly name alternatives such as preview_action or submit_signed_order, but the intended usage context is clear.

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?