Coding agents run multi-leg cross-chain DeFi. Legs re-derived from your sentence before signing.
| Endpoint | https://api.getava.xyz/mcp (streamable-http) |
|---|---|
| Registry version | 0.5.1 |
| Now | 15 tools · grade D (59) · pin ts_efddcf1c30f4af7a6f3a50e9a40621a0 · protocol 2024-11-05 |
| First / last listed | 2026-11-14 01:22 UTC / 2026-11-14 01:22 UTC |
| Grade over time | 2026-11-14: D (59), 15 tools |
Is this your server? Own a server? ToolFit hosted watch re-checks it every 24 h ($0.25 per 30 days) or 6 h ($0.60) and sends you an HMAC-signed webhook when its tools or grade change: POST https://api.youraitools.co/toolfit/v1/watch. To opt out, see About & opt-out.
Tools: ava_copilot_turn ava_approve_execute ava_lend_execute ava_portfolio ava_session ava_create_agent ava_provision_wallet ava_preview_tx ava_plan_workflow ava_plan_standing ava_create_mandate ava_list_mandates ava_eval_mandate ava_agent_record ava_get_receipt
ava_copilot_turn | Natural-language copilot turn: message → intent → plan → testnet quote. Example: Swap 10 USDC to SUI on sui with 50 bps slip. Returns actions with approve_execute + executionId. Optional agentId/agentCredential for KYA gate (fail closed on reject). Does NOT fill until ava_approve_execute. params: message*, portal, userId, mode, agentId, agentCredential |
ava_approve_execute | Human-in-the-loop approve: the one call that actually settles a plan from ava_copilot_turn. It is gated by the bound mandate's status and constraints and by server-side policy limits, and it CAN REFUSE (e.g. mandate paused/cancelled, a policy violation, a stale preview hash); a refusal means no funds moved and no success receipt was written, only a refusal record. Testnet mode settles against simu params: executionId*, userId*, portal*, mode, previewHash |
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, ar params: mandateId*, op, amount, venue, previewHash, idempotencyKey, userId*, portal |
ava_portfolio | Simulated testnet portfolio for a userId (same data as GET /v1/portfolio): seeded balances, fills, optional portal. Requires userId. Does not invent live chain balances. params: portal, userId* |
ava_session | Create or resume a human/org identity (userId), the first call in the loop. One human can own many agent instances (Claude + Cursor + OpenClaw + Ava-hosted). Moves no money and provisions no wallet by itself; call once and reuse the returned userId on every other tool. params: userId, displayName |
ava_create_agent | Register an agent instance under userId, before it has a wallet or a mandate. Mode A (multi-agent): agentId=byo-external + label (e.g. claude-workspace, cursor-arb) for a coding agent that already exists elsewhere. Mode B (hosted): agentId=defi-lend|defi-swap|defi-perp|portfolio hires an Ava-run agent. One userId may own many agent instances; this call alone never touches funds. params: userId*, portal*, agentId*, label |
ava_provision_wallet | Provision a Turnkey-custodied wallet address for this userId, scoped to one chain family (evm | solana | sui). Requires ava_session first. Returns the address for funding and later signing; it does not fund the wallet and does not move any money. If Turnkey is not configured server-side, the wallet comes back with status pending_provision rather than a fabricated active address, and cannot sign or params: userId*, family* |
ava_preview_tx | Pre-sign preview: build the exact venue artifact (CoW EIP-712 order or unsigned Solana transaction) for a pending plan against the provisioned Turnkey wallet, simulate it where supported, and return it UNSIGNED. Nothing is signed or submitted. Show the artifact to the human, then pass the returned previewHash to ava_approve_execute so the signature covers exactly what was reviewed. params: executionId*, userId*, portal* |
ava_plan_workflow | Turn ONE natural-language DeFi request into the dependent actions it actually contains, across one chain or several. Example: "Supply 300 USDC to Morpho on Base, bridge no more than 200 to Avalanche, then supply what arrives to Aave" returns three legs with the third depending on the second and taking its amount from what the bridge actually delivered, not a plan-time guess. Same-chain works ident params: message*, userId* |
ava_plan_standing | Turn a request for REPEATED autonomous action into an envelope of bounds the user signs once. Use this instead of ava_plan_workflow when the request describes a cadence: "every hour, rotate my USDC into the best yield on Base using Aave and Morpho, never move more than 200 per rotation, never exceed 1000 total, stop after 30 days". Asking a human to approve each rotation would defeat the point, so params: message*, minGainBps, userId* |
ava_create_mandate | Create a capital mandate: the objective, capital and constraints an agent is allowed to act under, optionally scoped to an agentInstanceId. Example: "Earn on 500 USDC on Base, max 5% drawdown". Or pass structured capital {asset,amount,chain}. Creating a mandate moves no money by itself and is not yet signed by an external wallet: it is Ava's own record of what was asked for, not a user-authorised params: portal*, message, capital, objective, constraints, conditions, userId, name, agentInstanceId |
ava_list_mandates | List capital mandates for a userId (optional filter by agentInstanceId). params: portal, userId*, status, agentInstanceId |
ava_eval_mandate | Read-only: check a mandate's exit conditions against a market snapshot and record the result. Omit snapshot to pull a live CoinGecko price for the condition asset. Never executes and never moves money; ava_approve_execute is the only tool that does. params: mandateId*, snapshot |
ava_agent_record | Read an agent's track record before delegating capital to it. Returns mandates held, executions attempted, refusals by typed code, and receipts with their proof standing. Distinguishes CLAIMED from PROVEN: receiptsProven counts only chain-confirmed receipts; unconfirmed receipts prove nothing. AP2-aligned (each receipt's ap2.reference is the hash of the closed mandate) so an AP2-aware verifier can params: agentInstanceId*, userId |
ava_get_receipt | Retrieve the receipt for a prior ava_approve_execute by executionId, the loop's final step. Returns the stored receipt plus its honest proof.standing: none (nothing submitted), unconfirmed (an identifier exists but nothing independent confirmed it), chain-confirmed (the declared chain returned the transaction and it matches what the receipt claims), or chain-contradicted (the chain disagrees with params: executionId*, userId |
Entries describe changes in tool definitions. They are not statements about a server, its quality or its author. The grade measures how the tool definitions fit model providers (token cost, schema compatibility, confusable names) as scored by the ToolFit engine at the time of the listing. JSON: append .json. Opt-out: how or hello@youraitools.co.