Loading ToolBench
A powerful MCP server built with Osiris SDK for interacting with Aave V3 lending protocol
The aave-mcp server provides 7 DeFi-specific tools with visible Zod schemas and descriptions. However, quality is inconsistent: naming follows verb-noun conventions (chooseWallet, getUserAccountData, supply, withdraw, borrow, repay, approveToken), but descriptions lack LLM-optimized detail about preconditions, return values, and error scenarios. Schemas are present for all tools and include proper type definitions (string, number, enum), but parameter descriptions are terse and do not document constraints, expected formats, or recovery paths. Output schemas are completely undocumented, callers have no explicit definition of what fields to expect. Error handling exists but is generic (createErrorResponse/createSuccessResponse wrappers) and does not provide actionable guidance. Tool descriptions mention 'REQUIRES WALLET SELECTION' in caps, which is good, but most do not explain prerequisites systematically. Parameter descriptions like 'The EVM token contract address (must start with 0x)' are adequate but lack examples of valid formats or links to chain-specific address books. No pagination, batching, or multi-step patterns observed. This places the server in the fair-to-good range, functional but with significant gaps in LLM-facing clarity.
Approves an ERC20 token for use with the Aave V3 pool.
Borrows an ERC20 asset from the Aave V3 pool. REQUIRES WALLET SELECTION.
Choose a wallet address to use for the current session.
Fetches the user's Aave V3 account data, like health factor and debt, from the Polygon network.
Repays a borrowed ERC20 asset to the Aave V3 pool. REQUIRES WALLET SELECTION.
Supplies (deposits) an ERC20 asset into the Aave V3 pool. REQUIRES WALLET SELECTION.
Output schemas are not documented. Tools return structured responses (totalCollateralUSD, healthFactor, etc. for getUserAccountData; hash for write operations), but LLMs have no schema to parse what fields are available. This forces LLMs to guess or fail at extracting return values.
Parameter descriptions lack format and constraint details. E.g., 'amount' is described as string but does not state whether this is raw decimals (1000000 for 1 USDC) or human-readable (1.0). The code calls getAssetDecimals() internally, but LLMs cannot infer this. Descriptions should state 'amount as string, e.g. "1.5" (human-readable with decimals)'.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 54 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 48 | - | v1 |
Withdraws an ERC20 asset from the Aave V3 pool. REQUIRES WALLET SELECTION.
No error recovery guidance. Error responses use generic createErrorResponse() which likely returns only 'isError: true' and a message. No indication of whether to retry, whether to adjust input, or how to recover. E.g., if borrow fails due to health factor, error should suggest 'You may need to supply more collateral first. Call getUserAccountData to check your health factor.'
Tool descriptions lack prerequisite clarity. 'REQUIRES WALLET SELECTION' is mentioned in caps, but not for chooseWallet itself (which presumably succeeds without a wallet already selected). For write operations (supply, withdraw, borrow, repay, approveToken), the description should state 'You must call chooseWallet() first with your wallet address, then call this tool. If you have not selected a wallet, you will receive an error asking you to choose one.'
No enum constraint on chainId. Code supports chainId 1 (Ethereum), 137 (Polygon), 42161 (Arbitrum), but the schema uses a plain number type. Descriptions mention 'chain ID (1 for Ethereum, 137 for Polygon, 42161 for Arbitrum)' but schema should enforce this via an enum to prevent LLMs from passing invalid values like 56 (BSC).
Descriptions are below optimal length for LLM reasoning. Most are 50 - 110 characters; Arcade baseline is 194 chars (p10=34, p90=392). Current descriptions are terse and force LLMs to infer context. E.g., 'Borrows an ERC20 asset from the Aave V3 pool.' does not explain why someone would borrow, what interest accrues, or when this might fail.
No batching or multi-call patterns. If a user wants to supply 3 assets, the agent must call supply() 3 times sequentially. No batch_supply() or bulk_approve() tool exists. Token cost grows quadratically with each asset.