On September 8th, Aave Labs launched the official MCP server mcp.aave.com, allowing AI assistants that support model context protocols to read real-time data from Aave V3 and V4 through a single connection, and to facilitate transactions such as supply, borrowing, repayment, and withdrawal. The most critical aspects of the product are outlined in the official documentation: all transactions returned by the server are unsigned requests or EIP-712 typeized data, and the private keys remain in the users' wallets; the MCP server cannot transfer funds on behalf of users. While it connects the natural language interface to the DeFi protocol, it does not hand over control of the assets to the models as well.
In the past, AI assistants answering questions about Aave interest rates or health factors often relied on training data, web scraping, or third-party encapsulations. Interest rates, collateral ratios, supply caps, and trading positions would continue to change, and static answers might have become outdated by the time they were generated. The official MCP has organized information on the blockchain, market conditions, reserves, interest rates, risk parameters, historical APY, protocol-based deposits and loans, wallet health factors, and transaction history into tools that can be called by models. For V4, it also provides individual position health status, as well as liquidity and accounting data at the Liquidity Hub level.
From query to rehearsal, the official interface attempts to shorten but not hide the transaction chain.
The server supports building supply, borrowing, withdrawal, repayment, collateral switching, eMode, reward collection, and settlement transactions. The `preview_action` tool simulates the actions before submission and returns the health factor after execution. The exchange process is divided into quoting, preparing, submitting, and status querying; governance tools can search for proposals, read the status of the quorum, and list voters by voting rights. This division allows assistants to not only answer questions like “What is my position now?” but also to prepare for the next steps, such as “What would be the risk if I borrowed 1000 USDC?”
The official emphasizes that V3, V4 or both should be queried simultaneously, and most tools accept the `version` parameter. The server is based on Aave Kit and uses the same calculation logic as the official interface, including V4 Hub to and-Spoke for accounting and risk premiums. What was originally about 17KB of reserve details is compressed into about 1KB of fields required by the model. If incorrect input is provided, the reason for rejection will be returned as is, allowing the assistant to correct the parameters. This structured approach can reduce the chances of the model misinterpreting fields on long web pages, but it cannot guarantee that the model will definitely understand the user's intent correctly.
The most straightforward scenario is to compare the returns of stablecoins across markets, and then prepare deposit transactions for the user's wallet. A more complex example involves monitoring health factors: when a metric falls below 1.5, the agent reads the positions, simulates repayments, prepares for transactions, and waits for the user's signature. This cycle demonstrates the appropriate role of the AI agent within DeFi—continuous monitoring and calculations can be automated, while the final step of asset transfer is confirmed by the wallet. If the user is offline, the transaction will not be automatically executed just because the model “deems it necessary.”
This design also comes with its own trade-offs in terms of user experience. Liquidation risks can deteriorate rapidly within minutes, and waiting for manual signature may result in missing the optimal window. If users opt for automatic signature wallets to speed up the process, the security model changes fundamentally. In such cases, it becomes necessary to set separate limits, asset allowlists, permitted protocols, maximum slippage, health factor thresholds, and validity periods. It is no longer possible to grant a regular wallet all its usual permissions to a general assistant. MCP itself only specifies the method of tool connection and does not perform these financial security controls on behalf of the application.
"Official data" reduces information errors, but it cannot eliminate the risks associated with contracts, oracles, and signatures.
The greatest advantage of using official links is that the source of data and the calculation methods are clearer. When users inquire about the best supply rates for USDC, the assistant can provide up-to-date information rather than repeating content from articles written weeks ago; when querying health factors, it can also take into account the user's current wallet positions and protocol parameters. However, real-time data may still change between block confirmation, quote validity periods, and user signatures. The interface must display the time of the query, network status, token address, amount, expected results, and simulated blocks to prevent users from mistaking a single snapshot for a continuous guarantee.
Transaction rehearsals are not a guarantee of security either. A successful simulation does not necessarily mean that a transaction will be completed later; prices, liquidity, interest rates, and network congestion on the blockchain can all change. Malicious tokens, faulty networks, assets with the same name, and phishing links can also pose risks. Users should verify the contract addresses and methods displayed in the wallet pop-ups, rather than relying solely on the natural language summaries generated by AI. For large-value transactions, hardware wallets and multi-signature approval processes are still valuable; for enterprises, audit logs should record model requests, tool responses, simulation results, and the final signatories.
MCP also brings new supply chain issues. Clients need to confirm that the connection is indeed `https :// mcp.aave.com` to prevent servers with the same name from returning forged data or conducting malicious transactions. Assistant developers should restrict the context that servers can access to avoid wallet addresses, strategies, and historical operations being obtained by unrelated tools. It is an important defense that the Aave server does not hold private keys; however, a tampered tool may still induce users to sign unfavorable transactions. Therefore, deterministic decoding and risk warnings before signing cannot be omitted.
For developers, having a single endpoint that covers V3 and V4 can reduce the cost of maintaining two sets of SDK and accounting logic, and also make the prototyping process faster. However, convenience does not mean that all products should directly adopt the generic MCP. High-frequency trading, institutional risk control, and automated settlement have strict requirements for latency, availability, version locking, and disaster recovery; therefore, it may still be necessary to build custom nodes, indexers, and rule engines. The official MCP is more suitable for interactive queries, decision support, and human-machine collaborative transactions, rather than unassessed replacements for critical production infrastructure.
Aave This release represents a change in the front-end of DeFi: Users may not necessarily open the protocol website first; they could also enter through the chat assistant. The protocol provides complex data and transaction construction capabilities to AI, while the wallet retains the signature boundaries. Whether the usage can truly be expanded depends on whether the client clearly explains the risks, fees, network issues, and transaction consequences, rather than hiding the complexity behind a simple statement like "already prepared for you." AI can reduce the friction in querying and assembling transactions, but asset security still comes from verifiable data, minimal permissions, and the user's understanding of the final signature.
