Skip to main content
Glama

ava_lend_execute

Execute a REAL lend against one of your mandates. Routes Ava has already settled a mainnet transaction on: Morpho Blue on Base, and Aave v3 on Monad, BNB Chain and Avalanche. Aave v3 on Arbitrum One is wired through the identical pipeline and address-verified, but nothing has ever settled there, so do not describe it as proven. Aave v3 on Optimism and Base, and Compound v3 on Base and Arbitrum, are wired and address-verified but operator-disabled until each settles a real transaction, so calls on those routes refuse at the capability gate. This is the only MCP tool that moves live capital. Two-phase by design: call it once WITHOUT previewHash to receive the exact artifact a human must approve plus its hash, show that to the human, then call again WITH that previewHash. Your call is never treated as the human's confirmation, because you are not the person whose money moves. Only a settlement verified against the venue's own on-chain event returns a txHash; anything else has no txHash field at all, so a draft can never be narrated as a fill.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
opNoSupply into the venue or withdraw from it. Defaults to supply.
venueNoVenue selector for chains carrying more than one wired lend venue. Absent keeps the chain's default: Base -> Morpho, every Aave v3 chain -> Aave v3. On Base, name aave_v3 or compound to reach those routes; naming a venue the chain does not carry refuses rather than rerouting.
amountNoHuman decimal amount of the mandate's asset. Defaults to the mandate's full capital when omitted.
portalNo
userIdYes
mandateIdYesThe mandate authorising this capital. Required: Ava will not choose which of the user's authorisations to spend. From ava_create_mandate or ava_list_mandates.
previewHashNoThe hash returned by the first call, after a human approved that exact artifact. Omit on the first call.
idempotencyKeyNoYour own key for this economic action. Supply the SAME key when retrying: a fresh key per attempt makes every retry look new, which is exactly what defeats single-flight protection. Required for the compound route, whose reservation is durable.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it meets it thoroughly. It explains the two-phase approval requirement, that the agent's call is never treated as human confirmation, and the critical return contract: only a settlement verified against the venue's on-chain event yields a txHash, otherwise no txHash field exists, preventing drafts from being narrated as fills.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but information-dense, and every sentence serves a purpose. It front-loads the core purpose ('Execute a REAL lend') and then systematically covers routing, provenance, the two-phase design, and return behavior. It is appropriately sized for the tool's complexity; while not terse, it avoids redundancy.

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?

Given no output schema and no annotations, the description must fully specify call behavior and return semantics, and it does. It explains the two-phase protocol, the absence of a txHash for drafts, the per-route refusal behavior, and the exact rules for venue selection and idempotency keys. Nothing an agent needs to correctly invoke the tool is missing.

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 75%, so the baseline is 3, but the description adds meaningful context beyond the schema for several parameters. It explains the venue parameter's default behavior and refusal semantics, details the previewHash lifecycle, and clarifies the idempotencyKey requirement for the compound route, including why a fresh key on retry defeats single-flight protection. This elevates it above baseline.

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 states a specific verb and resource: it executes a real lend against a mandate. It immediately distinguishes itself from siblings by declaring it is the only MCP tool that moves live capital, and it details the exact venues and their provenance. This unambiguously differentiates it from the 14 sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit when-to-use guidance: it is the only tool for executing real capital moves, and it details the two-phase invocation pattern (call without previewHash, then with). It also warns against describing unproven routes as proven and clarifies that operator-disabled routes refuse at the capability gate, so an agent knows whether a call will succeed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources