Aave
by avara.xyz(Community)
Visitor takeaway
58/100
Fair AI-discovery coverage across description, prompts, keywords, visuals, tool metadata, health, and freshness.
Routing category
Needs category
This listing is missing a primary category, which weakens browse placement and AI recommendation routing.
Connector evidence
Reachable
Tedix can reach this MCP endpoint and can show live capability evidence when tools are discovered.
Directory freshness
15h ago
Catalog metadata was refreshed 15h ago (September 7, 2026).
Description
Aave helps users explore live Aave V3 and V4 markets, review wallet positions and DAO governance, simulate lending actions, and prepare non-custodial transactions or signed-order workflows through ChatGPT.
Capabilities
No special capabilities listed
AI Agent Discovery
Aave is indexed by Tedix as a structured ai application listing for AI assistants, search crawlers, and users comparing agent-ready apps.
- Aave has no primary catalog category yet; Tedix treats this as a routing gap for browse and recommendation surfaces.
- Developer: avara.xyz.
- Connector type: AI-Powered App.
- Current connector status: Connected.
- Observed distribution channels: chatgpt.
- Available regions: US, FR, GB, ES, KR, IN.
Use this page to understand whether Aave is relevant for general AI app workflows in AI assistants.
For MCP discovery, this listing helps crawlers connect Aave to tool, resource, prompt, and server-health signals instead of treating it as a generic directory entry.
The canonical Tedix directory URL is https://tedix.dev/apps/aave/.
Crawlable Profile
Source and availability
Tedix identifies Aave from Upstream Mcp tool source; Store sources: ChatGPT app store; Distribution: Ecosystem Directory; Tenant install: A platform catalog operator must create or reconcile the base app before tenants can install this entry.. Availability is reported for US, FR, GB, ES, KR, IN.
- ChatGPT app storeAuth not flagged · RELEASED · US, FR, GB, ES, KR, IN
Auth, tools, and actions
Authentication: Open Access. No special capability flags are currently listed. Current MCP inventory reports 40 tools, 16 resources, and 5 prompts.
- Cancel an order · High-impact write action
No version argument. Cancel an open order. Two routes: pass 'signature' (signed over what prepare_cancel_order returned) to relay a gasless cancellation - state-changing, and the route an intent order takes; omit 'signature' entirely for the on-chain route, which returns the cancel transaction for the user to sign and send, the route an order that went on chain (a native-token sell) takes. The server never signs.
- Aave protocol & usage guide · Read-only action
Applies to both versions. Protocol and usage guidance for building Aave flows correctly. Read the relevant topic before constructing an action. Topics: overview, v4, v3, positions, health-factor, risks, ids, amounts, prices, signing, swaps, gho, governance, rewards, tools, docs. Also the place to come when no tool seems to fit what you were asked for: send 'lookingFor' and this answers with the full capability list rather than leaving you to guess from tool names. For deep protocol docs, point the user to https://docs.aave.com.
- Get APY history · Read-only action
Historical supply or borrow APY for a reserve over time, on v3 or v4. Returns a time-series of {date, apyPct}, where apyPct is a percent ('3.32' means 3.32%). Each point is an average over its sampling interval, and the interval widens with the window (hourly for 'day', coarser above that), so a series is not directly comparable to the instantaneous rate from get_reserve_details. Use get_markets first for the reserveId (v4) or market+token (v3). When comparing v3 against v4 for the same asset (a migration decision), read the history on both sides: a spot-rate gap can be one side's momentary spike.
- Get supported chains · Read-only action
List chains Aave supports, on v3, v4, or both. A chain carrying 'notServed': true is one this API holds no market on: every market, position and rewards read comes back empty for it, and that emptiness says nothing about the chain itself. Its gateway addresses read 0x0 for the same reason, so do not send a transaction to one. Every chain without the flag has markets to read.
- Get v3 eMode categories · Read-only action
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.
- Get an Aave DAO proposal · Read-only action
Takes no 'version' argument (DAO governance is not per-market; Governance V3 is unrelated to Aave v3/v4 markets). Full detail for one Aave DAO governance proposal: state, author, vote tallies, quorum, timings and the transaction hash of each lifecycle step. 'quorumMet' and 'differentialMet' are the two conditions a proposal must meet to pass. Vote tallies and quorum are both in AAVE, so they compare directly. The long IPFS write-up is omitted unless includeDescription is true.
- Get the assets a v4 hub carries · Read-only action
v4 only. The assets held by one Aave v4 hub, with hub-wide supplied and borrowed totals, rates and utilisation. Get hubId from get_hubs (or the hubAddress on get_reserve_details). This is hub-level accounting; for what a user can actually supply or borrow, use get_markets, which is per spoke.
- Get v4 hubs · Read-only action
v4 only. Aave v4 hubs: a hub holds the liquidity and global accounting that user-facing spokes draw from. Returns each hub's hubId, address, chain and totals. Pass a hubId to get_hub_assets for the assets it carries. Omit chainId to cover every supported v4 chain.
Plus 32 additional actions in the full tool inventory.
Verification freshness
- Catalog synced15h ago (September 7, 2026)
- Connector checked14h ago (September 7, 2026)
- MCP scanned14h ago (September 7, 2026)
- Directory updated14h ago (September 7, 2026)
Publisher Intelligence
Public trust signals for visitors and practical recommendations for publishers. Use this section to understand what Tedix can verify today and what would make the app easier for AI agents to find.
Visitor takeaway
58/100
Fair AI-discovery coverage across description, prompts, keywords, visuals, tool metadata, health, and freshness.
Routing category
Needs category
This listing is missing a primary category, which weakens browse placement and AI recommendation routing.
Connector evidence
Reachable
Tedix can reach this MCP endpoint and can show live capability evidence when tools are discovered.
Directory freshness
15h ago
Catalog metadata was refreshed 15h ago (September 7, 2026).
Server Statusaave-mcp v1.0.0
https://mcp.aave.comLast checked: 14h ago
Server Instructions
Aave MCP: one endpoint serves both Aave V3 and V4. Pass a 'version' argument ('v3', 'v4', or 'all') to most tools; a tool without that argument states its applicability in the first words of its description ('v4 only', 'v3 only', or protocol-agnostic). Non-custodial: read and prepare_* tools return data or an unsigned transaction / EIP-712 typed data for the user's own wallet to sign; this server never holds keys or submits (only submit_signed_order and cancel_order relay what the user already signed). Workflow: discover (get_markets, or get_started on a cold turn) -> inspect (get_reserve_details, get_user_summary) -> simulate (preview_action, on either version) -> build (prepare_action) -> the user's wallet signs. Do not skip the simulation before a borrow or a withdraw. Every successful result is the same envelope, { data, next_actions? }, returned both as JSON text and as structuredContent; read the payload from 'data' and follow 'next_actions'. Inside 'data', six reads nest their payload under 'v4' and 'v3' - get_chains, get_markets, get_user_summary, get_user_positions, get_user_activity, get_user_rewards - including when you asked for a single version, so on a version:'v4' call the answer is at 'data.v4' and 'data' itself holds no fields. Every other tool returns its payload on 'data' directly, preview_action and the prepare_* tools included, even though they take the same 'version' argument. A result may also carry 'warnings', each with a level: 'error' means the action cannot succeed as built, so stop and fix it or tell the user rather than preparing or signing past it; 'warning' means it will succeed but the user should be told; 'info' is context. Every USD figure is Aave's oracle price for the asset, read from Chainlink price feeds and named as 'priceSource' on a reserve read: when you quote a price or a USD value, attribute it to Chainlink rather than presenting it as a market quote. Token amounts are in main units (e.g. '10.5'), never wei. To build an action you need a reserveId (v4) or market+token+chainId (v3) from get_markets in this session - these are deployment-specific, so an Aave address or id you already recognise belongs to a different deployment and is rejected; call get_markets before the first prepare rather than after it refuses; narrow that call with 'symbols' (e.g. ['USDC']) instead of listing every reserve. Reads cover every supported chain by default and say which under 'chainsCovered', so do not loop over chains by hand; where a read is narrower it also returns 'chainsNotCovered', which is the only case a sweep is needed. A chain under 'chainsNotServed' is one this API holds no market on: an empty result there is an absence of data, not an answer about the chain, and asking again returns the same nothing - get_chains flags those chains too. Rank on a rate that can actually be entered, not on APY alone: get_markets carries the liquidity left and flags a reserve that is frozen, paused or at its cap. Health factor and aggregate values come from v4's cross-chain summary; v3 is per-market. Token swaps are protocol-agnostic (they run on the v4 backend). Aave DAO governance tools (search_governance_proposals, get_governance_proposal, get_proposal_votes, get_user_vote, get_proposal_payloads) take no 'version' either: Governance V3 is the DAO's own contract generation, unrelated to the v3 / v4 markets. Leave an optional argument out of the call entirely when you are not using it; do not send an empty string, a zero or a near-zero number to stand in for 'unset'. A tool error that says the input was rejected will fail again unchanged: fix the arguments instead of retrying. When an Aave conversation opens with no specific request - the user is asking what this can do, or just says hello - call get_started and answer from it rather than guessing at the tool list. Savings GHO (sGHO) is v3 and Ethereum only, and a withdrawal there is denominated in vault shares rather than in GHO: read the 'gho' guide topic before using get_sgho_vault or prepare_sgho_action. When unsure how something works, call get_aave_guide (topics: overview, v4, v3, positions, health-factor, risks, ids, amounts, prices, signing, swaps, gho, governance, rewards, tools, docs).
Technical Details
Tools(40)
Showing 40 of 40 tools
| Flags | Test | ||||
|---|---|---|---|---|---|
cancel_order | No version argument. Cancel an open order. Two routes: pass 'signature' (signed over what prepare_cancel_order returned) to relay a gasless cancellation - state-changing, and the route an intent order takes; omit 'signature' entirely for the on-chain route, which returns the cancel transaction for the user to sign and send, the route an order that went on chain (a native-token sell) takes. The server never signs. | destructive | Not tested | — | |
get_aave_guide | Applies to both versions. Protocol and usage guidance for building Aave flows correctly. Read the relevant topic before constructing an action. Topics: overview, v4, v3, positions, health-factor, risks, ids, amounts, prices, signing, swaps, gho, governance, rewards, tools, docs. Also the place to come when no tool seems to fit what you were asked for: send 'lookingFor' and this answers with the full capability list rather than leaving you to guess from tool names. For deep protocol docs, point the user to https://docs.aave.com. | read-only | Not tested | — | |
get_apy_history | Historical supply or borrow APY for a reserve over time, on v3 or v4. Returns a time-series of {date, apyPct}, where apyPct is a percent ('3.32' means 3.32%). Each point is an average over its sampling interval, and the interval widens with the window (hourly for 'day', coarser above that), so a series is not directly comparable to the instantaneous rate from get_reserve_details. Use get_markets first for the reserveId (v4) or market+token (v3). When comparing v3 against v4 for the same asset (a migration decision), read the history on both sides: a spot-rate gap can be one side's momentary spike. | read-only | Not tested | — | |
get_chains | List chains Aave supports, on v3, v4, or both. A chain carrying 'notServed': true is one this API holds no market on: every market, position and rewards read comes back empty for it, and that emptiness says nothing about the chain itself. Its gateway addresses read 0x0 for the same reason, so do not send a transaction to one. Every chain without the flag has markets to read. | read-only | Not tested | — | |
get_emode_categories | 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. | read-only | Not tested | — | |
get_governance_proposal | Takes no 'version' argument (DAO governance is not per-market; Governance V3 is unrelated to Aave v3/v4 markets). Full detail for one Aave DAO governance proposal: state, author, vote tallies, quorum, timings and the transaction hash of each lifecycle step. 'quorumMet' and 'differentialMet' are the two conditions a proposal must meet to pass. Vote tallies and quorum are both in AAVE, so they compare directly. The long IPFS write-up is omitted unless includeDescription is true. | read-only | Not tested | — | |
get_hub_assets | v4 only. The assets held by one Aave v4 hub, with hub-wide supplied and borrowed totals, rates and utilisation. Get hubId from get_hubs (or the hubAddress on get_reserve_details). This is hub-level accounting; for what a user can actually supply or borrow, use get_markets, which is per spoke. | read-only | Not tested | — | |
get_hubs | v4 only. Aave v4 hubs: a hub holds the liquidity and global accounting that user-facing spokes draw from. Returns each hub's hubId, address, chain and totals. Pass a hubId to get_hub_assets for the assets it carries. Omit chainId to cover every supported v4 chain. | read-only | Not tested | — | |
get_markets | List Aave markets/reserves (symbol, APY, caps, liquidity) on v3, v4, or both. Chain coverage: omit chainId and every response states the chains it read as 'chainsCovered', plus 'chainsNotCovered' when it read fewer than all of them. '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 always covers every chain it serves; v3 covers every chain when you pass 'symbols' and Ethereum alone when you do not, because an unfiltered 21-chain listing is hundreds of kilobytes. So to compare one asset across chains, pass symbols and no chainId. Every rate is a percent ('3.32' means 3.32%), named with a Pct suffix. Do not rank on APY alone: 'suppliable'/'borrowable' (v4), 'availableLiquidity' and 'totalSuppliedUsd' (v3) say whether a rate can actually be entered, and isFrozen / isPaused / supplyCapReached / borrowCapReached appear only when set, so a reserve with none of them is not flagged. Both versions return one row per reserve under 'reserves', carrying supplyApyPct and borrowApyPct together plus canSupply / canBorrow for the sides that are actually open, so the two versions read the same way. On v4 one asset appears once per spoke, so rows are labelled with 'spoke' and 'hub'; spokes sharing a hub share its rate, so identical APYs across rows are expected rather than duplicates. 'canSwapFrom' (v4) says whether that token can be the sell side of a token swap, which is the per-reserve form of what get_swappable_tokens answers per chain. | read-only | Not tested | — | |
get_order_status | No version argument. Status of an order by id: open, pending signature, fulfilled, cancelled or expired, with the operation it performs and an explorer link. 'order' comes back null when the API cannot see that id, which a wrong id and a just-submitted order both produce - poll again briefly before concluding. | read-only | Not tested | — | |
get_pending_orders | No version argument: orders run on the v4 backend, so this covers the chains that backend serves and names them under 'chainsCovered'; a chain under 'chainsNotCovered' could not be read and is worth asking about again. A wallet's orders, newest first. Despite the name it returns every status unless 'statuses' narrows it - pass ['open','pending_signature'] for what is still actionable. Each chain returns its newest 50 orders; 'more: true' on a chain means older history exists beyond what was returned. Use this to recover an orderId you no longer have. | read-only | Not tested | — | |
get_position_items | v4 only. The individual supplies or borrows inside one v4 spoke: principal, accrued interest and what is withdrawable right now, per item, which the per-spoke aggregate from get_user_positions cannot show. Get 'spokeId' from get_user_positions. | read-only | Not tested | — | |
get_proposal_payloads | Takes no 'version' argument (DAO governance is not per-market; Governance V3 is unrelated to Aave v3/v4 markets). What an Aave DAO proposal actually executes: one payload per target chain, each with its execution state, timelock delay, grace period and the contract calls it makes. Use this to tell whether a passed proposal has landed on every chain yet: a proposal can be 'executed' on mainnet while a payload is still 'queued' elsewhere. | read-only | Not tested | — | |
get_proposal_votes | Takes no 'version' argument (DAO governance is not per-market; Governance V3 is unrelated to Aave v3/v4 markets). Who voted on an Aave DAO proposal and with how much power, largest voter first. Pass support=true or false to list only one side. 'totals' covers every vote on the proposal, not just the page returned. Voting power is in AAVE. | read-only | Not tested | — | |
get_protocol_history | v4 only. Aave v4 protocol-wide history: market size, total borrows and available liquidity per sample over a window. Omit chainId to cover every supported v4 chain. Use this for 'is the protocol growing', not for one wallet (get_user_summary_history) or one reserve (get_apy_history). | read-only | Not tested | — | |
get_reserve_details | Deep detail for a single reserve (rates, caps, risk parameters, utilisation, the interest-rate curve, token addresses) on v3 or v4. Every rate and percentage is a percent ('3.32' means 3.32%), named with a Pct suffix. On v4, utilisation and the rate curve are hub-wide, shared by every spoke drawing on the asset. Two v4 fields whose meaning the numbers do not give away: 'collateralFactorPct' is the liquidation boundary itself, because v4 has no separate liquidation threshold - do not look for one - so a position drawn to its full borrow limit sits at health factor 1.0; and 'liquidityFeePct' is the protocol's share of borrower interest, already netted out of supplyApyPct, so treating it as a user cost double-counts it (supplyApy = borrowApy x utilisation x (1 - liquidityFee), if you want to check). This is also where the asset's price lives: 'priceUsd', with 'priceSource' naming who priced it, and no listing carries either - get_markets quotes no price at all, so what an asset is worth on Aave is answered here. Use get_markets first to get the reserveId (v4) or market+token (v3). | read-only | Not tested | — | |
get_sgho_preview | v3 only, Ethereum only. Convert between GHO and sGHO shares at the vault's current index, without building anything. Which unit 'amount' is in depends on the action: 'deposit' takes GHO and returns the shares it would mint; 'withdraw' takes sGHO SHARES and returns the GHO they would return. Call this with action 'withdraw' before prepare_sgho_action, because that withdrawal is denominated in shares and not in GHO - passing a GHO figure there withdraws the wrong amount. When quoting what a user-named amount converts to, use this preview rather than multiplying by the rate: the index moves. | read-only | Not tested | — | |
get_sgho_vault | v3 only, Ethereum only. Savings GHO (sGHO) is an ERC-4626 vault that pays a target rate on deposited GHO. Returns the vault's targetRatePct, totalAssets, supplyCap and paused flag; pass 'user' to add that wallet's shares, their GHO value, its GHO wallet balance, and the maxDeposit / maxWithdraw the contract allows right now. Two things this rate is not: it is set by governance rather than by utilisation, so it does not move with borrowing demand, and it is not a lending position - sGHO earns yield but is not Aave collateral and cannot be borrowed against. Deposits and withdrawals are instant, with no cooldown. | read-only | Not tested | — | |
get_started | Applies to both versions. What this Aave server can do: the tool families, the ready-made prompts, and the guide topics. Call this when an Aave conversation opens with no specific request and answer from it, rather than guessing from tool names. | read-only | Not tested | — | |
get_swap_quote | No version argument: token swaps are protocol-agnostic and run on the v4 backend, so the chains and tokens they cover are that backend's and not every chain Aave holds a market on - a chain it does not serve is rejected outright rather than quoted badly. Call get_swappable_tokens first if you do not already know the chain is covered, or read 'canSwapFrom' on the reserve from get_markets. Quote a token swap: returns the quote with a quoteId to prepare and sign through prepare_order. | read-only | Not tested | — | |
get_swappable_tokens | No version argument: token swaps are protocol-agnostic and run on the v4 backend, so they cover the chains that backend serves rather than every chain Aave has a market on. Call this before get_swap_quote to see where a swap can be quoted: with no arguments it sweeps the chains v4 serves and returns each one with how many tokens are swappable there, which is the cheap answer; pass 'chainIds' to get the actual token list, and to ask about a chain the sweep does not reach. A chain under 'chainsNotCovered' could not be read and is worth asking about again; a chain present with 0 swappable tokens answered, and the answer is that nothing can be swapped there. Per reserve, get_markets also returns 'canSwapFrom'. | read-only | Not tested | — | |
get_transaction_processed | v4 only. After sending a transaction, ask whether the Aave API has processed it. Use this instead of sleeping or polling an RPC: the API lags the chain, and prepare_action will not issue a dependent follow-up (the supply after an approval, the withdraw after a repay) until it has caught up. Pass the txHash you sent plus the 'operations' array that came back on that transaction. Poll until processed is true, then continue. | read-only | Not tested | — | |
get_user_activity | A wallet's Aave transaction history (supply, borrow, repay, withdraw, collateral changes) on v3, v4, or both. Most recent first. v4 covers every chain; v3 reads one market on one chain at a time, because upstream paginates per market, so it states its scope as 'chainsCovered' and 'market' and you pass chainId to read another. Use get_user_positions, not this, to find out where a wallet holds anything. | read-only | Not tested | — | |
get_user_positions | 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. | read-only | Not tested | — | |
get_user_rewards | A wallet's claimable Aave rewards on v3, v4, or both. Covers incentive programmes distributed through Merit as well as the protocol's own, so a GHO or sGHO incentive shows up here rather than anywhere separate. Omit chainId and both versions cover every chain they serve, stating which under 'chainsCovered' and tagging each row with its own chainId. '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. On v3 the response also carries the transaction that claims them. | read-only | Not tested | — | |
get_user_summary | A wallet's aggregate position and health factor. 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. Ask for one of those chains on its own and the reply is the scope alone, with no totals: a zero would read as a real balance. v4 returns a cross-chain summary (lowest health factor, totals, net APY). v3 has no cross-market aggregate, so it returns one entry per market the wallet actually holds a position in, each with its own health factor; 'marketsWithPosition': 0 means the wallet holds no v3 position anywhere, not that the read was narrow or that the wallet is empty: token balances are not here. For what it holds, pass 'user' to get_markets, which returns walletBalance per reserve. | read-only | Not tested | — | |
get_user_summary_history | v4 only. How one wallet's net worth, supplied, debt and health factor moved over a window on Aave v4. Use it to answer 'how has my position changed' or to see how close to liquidation a wallet has been. Omit chainId to cover every supported v4 chain. | read-only | Not tested | — | |
get_user_vote | Takes no 'version' argument (DAO governance is not per-market; Governance V3 is unrelated to Aave v3/v4 markets). How one wallet voted on one Aave DAO proposal, and with how much power. Returns voted:false when that wallet did not vote, which is an answer rather than an error. Voting power is in AAVE. | read-only | Not tested | — | |
prepare_action | 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). For a borrow or a withdraw, call preview_action first and read its warnings: the simulation is free, it commits nothing, and it is the cheapest way to learn the position cannot take the action - a withdraw of collateral pinned by an open borrow is the case that catches callers out. 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. | read-only | Not tested | — | |
prepare_cancel_order | No version argument. From an orderId, return the EIP-712 cancellation for the user to sign; cancel_order relays the result. This is the gasless route for an intent order; an order that went on chain (a native-token sell) is cancelled with cancel_order's transaction route instead, which needs no signature and no prepare. Non-custodial: this returns what the user signs, and commits nothing. | read-only | Not tested | — | |
prepare_claim_rewards | v4 only. Build an unsigned transaction to claim a wallet's V4 rewards. If 'ids' is omitted, claims everything currently claimable. Non-custodial. There is no v3 equivalent because a v3 claim needs no second call: get_user_rewards already returns the transaction. | read-only | Not tested | — | |
prepare_liquidation | Build an unsigned transaction to liquidate an unhealthy position: repay part of someone else's debt and receive their collateral plus the liquidation bonus. Only viable while that position's health factor is below 1 (check get_user_summary for the target). v4 takes collateral and debt as reserveIds; v3 takes collateralToken and debtToken addresses plus chainId. Non-custodial: the liquidator signs and submits. | read-only | Not tested | — | |
prepare_order | No version argument: every order runs on the v4 backend. Which optional arguments apply is decided by the quote that minted the quoteId, so decide before emitting any: a quote that offered a 'bySignature' permit takes permitSignature + permitDeadline once that permit is signed; route:'transaction' applies only to a SwapByTransaction... quote (a native-token sell) and takes no signatures at all. Never send a signature argument unsolicited - it exists to carry back a signature the quote explicitly asked for. Non-custodial: this returns what the user signs, and commits nothing. | read-only | Not tested | — | |
prepare_set_collateral | Build an unsigned transaction to change whether a supplied asset is used as collateral (v3 or v4). On v4 'enable' sets the state; on v3 it toggles the current state, and a toggle that would invert a stated 'enable' is refused. The wallet must already hold a supply in that reserve: this sets a flag on it, nothing moves. Disabling can leave a position liquidatable, so it is simulated first: a health factor under 1 after is refused, just above 1 carries a warning to relay, and a build whose simulation could not run says so under 'warnings'. Enabling needs no check. Non-custodial. | read-only | Not tested | — | |
prepare_set_emode | v3 only. Build an unsigned transaction to switch a wallet's Aave v3 eMode category. 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. Take categoryId from get_emode_categories for that market; pass 0 to turn eMode off. v3 only: v4 replaces eMode with risk premium and dynamic config. | read-only | Not tested | — | |
prepare_sgho_action | v3 only, Ethereum only. Build an unsigned transaction to deposit GHO into the sGHO vault or withdraw from it. Non-custodial: the user's wallet signs and submits, so building one commits them to nothing. Choose sensible values, build it, and say what you chose rather than stopping to ask. Send only the arguments that apply and leave every other one out. On 'deposit', 'amount' is GHO. On 'withdraw', 'amount' is a number of sGHO SHARES, not GHO - get_sgho_preview converts - or pass max:true to redeem the whole position and omit 'amount'. 'recipient' is only for sending the result to a different address than the sender. A deposit needs a GHO allowance: when the result is ApprovalRequired, submit its 'approval' transaction and then the 'originalTransaction' beside it, in that order. | read-only | Not tested | — | |
prepare_stkgho_migrate | v3 only, Ethereum only. Build an unsigned transaction that moves a wallet's stkGHO out of the Safety Module and into the sGHO vault. All-or-nothing: it covers the entire stkGHO position and takes no amount. This server cannot read a stkGHO balance or cooldown state, so say that the migration is for the whole position and let the user check its size in their wallet before signing. Non-custodial, so build it rather than asking permission first. | read-only | Not tested | — | |
preview_action | Simulate a supply/borrow/withdraw/repay against a wallet's position WITHOUT executing, on v3 or v4. Always do this before a borrow or a withdraw. Send only the arguments that apply: v4 takes 'reserve'; v3 takes 'market' + 'token' + 'chainId'; 'max' is for withdraw and repay; 'native' works on both; 'enableCollateral' is v4 only. Both versions answer with 'healthFactorBefore' and 'healthFactorAfter'; v4 also returns net APY, risk premium, net collateral, net balance, projected earnings and both borrowing-power figures, each as a matching Before/After pair, plus 'rewardsAcquired' / 'rewardsAbandoned' when the action changes rewards. v3 has the two health factors and nothing else. Either version also returns 'warnings' when the action would not actually succeed - an error level there means the prepare step will refuse it, so fix the inputs rather than building it. Simulate first even when you intend to build immediately: this is the cheapest way to find out that an action cannot succeed, and it commits nothing. It reports the position's own limits and not token allowances, so a clean simulation says the position allows this, not that no approval step remains. | read-only | Not tested | — | |
search_governance_proposals | Takes no 'version' argument (DAO governance is not per-market; Governance V3 is unrelated to Aave v3/v4 markets). List or search Aave DAO governance proposals. Filter by 'state' to answer "what is live right now" (state 'active') or "what is waiting to execute" (state 'queued'). Pass 'search' for full-text over title, author and description, ranked by relevance. Vote tallies are in AAVE. | read-only | Not tested | — | |
submit_signed_order | No version argument: every order runs on the v4 backend. Relay an order the user already signed (quoteId + signature from prepare_order's PreparedOrder). State-changing: this posts the order. The server never signs. | destructive | Not tested | — |
Discoverability Score
Fair
58 / 100
How easily AI agents can find this app from its current catalog metadata.
- Description quality20/20
- Example prompts0/20
- Keyword coverage0/15
- Category clarity0/5
- Tool metadata20/20
- Visual assets8/20
- Endpoint health10/10
- Data freshness15/15
How to Improve
Add at least 2 example prompts. Prompt examples strongly improve app matching and click-through intent.
Increase keyword coverage (discovery + trigger) to improve retrieval for long-tail queries.
Choose a primary catalog category so visitors and AI agents can route this app into the right browse and recommendation surfaces.
Add at least 2 screenshots that show real workflows to increase confidence and conversion.
Technical Details
- Status
- ENABLED
- Type
- AI-Powered App
- Auth
- Open Access
- Listed on
- ChatGPT
- Added
- September 7, 2026
- Last synced
- 15h ago
- Last checked
- 14h ago
- Version
- 1.0.0
- Distribution
- Ecosystem Directory