Otto Intel

Prepare a Yield Copilot vault deposit (Morpho USDC on Base) as a delegable swap pair

otto_prepare_yield_deposit

Read-only

Prepare the EXACT otto_prepare_swap pair (envelope + prepareInput) that deposits USDC into one of the executable Morpho vaults from the Yield Copilot registry, as a LI.FI position-acquisition route (which may buy shares or compose a protocol deposit) whose output token is the vault's ERC-4626 share token and whose receiver is the signing account. The vault comes from the registry row named by executableMarketId and is never an input; the caller's registryCommitment must equal the commitment recomputed over the current record. The quoted shares are checked against the vault's own previewDeposit and refused when they fall short by more than the pinned tolerance. Returns the pair unchanged plus a preview; never signs or submits — submit the pair through otto_submit_under_delegation under the end user's per-swap cap. Every envelope from this server is valid for 300 seconds from construction (valid_until); a stale envelope is refused by the verifier — request a fresh one.

Input Schema

TableJSON Schema

Name	Required	Description
`amount`	Yes	Exact USDC amount to deposit, in atomic units (6 decimals).
`slippage`	Yes
`client_ref`	No
`accountProfile`	Yes
`executableMarketId`	Yes	The executable market id the READ half served (`GET /api/yield-copilot` rows with deployable:true), e.g. base-usdc-morpho-gauntlet-prime.
`registryCommitment`	Yes	The registry commitment served with that row. It must equal the commitment this server recomputes over the CURRENT record; a stale or foreign row is refused by name.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`preview`	Yes
`envelope`	Yes
`prepareInput`	Yes
`registry_commitment`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 11, 2026

addedOutput schema / properties / preview / properties / route_semantics

Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "action": {
+      "enum": [
+        "deposit",
+        "withdraw"
+      ],
+      "type": "string"
+    },
+    "classification": {
+      "enum": [
+        "share-purchase",
+        "share-sale",
+        "protocol-composition",
+        "mixed",
+        "unclassified"
+      ],
+      "type": "string"
+    },
+    "evidence": {
+      "const": "provider-quote-steps",
+      "type": "string"
+    },
+    "protocol_action_verified": {
+      "const": false,
+      "type": "boolean"
+    },
+    "tools": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "transport": {
+      "const": "lifi",
+      "type": "string"
+    }
+  },
+  "required": [
+    "transport",
+    "action",
+    "classification",
+    "evidence",
+    "protocol_action_verified",
+    "tools"
+  ],
+  "type": "object"
+}

changedOutput schema / properties / preview / required

Previous value: -[
-  "market_id",
-  "venue",
-  "protocol",
-  "chain_id",
-  "vault",
-  "asset",
-  "amount",
-  "expected_shares",
-  "min_shares",
-  "preview_deposit_shares",
-  "parity_shortfall_bps",
-  "parity_tolerance_bps",
-  "quoted_fees"
-]New value: +[
+  "market_id",
+  "venue",
+  "protocol",
+  "chain_id",
+  "vault",
+  "asset",
+  "amount",
+  "expected_shares",
+  "min_shares",
+  "preview_deposit_shares",
+  "parity_shortfall_bps",
+  "parity_tolerance_bps",
+  "quoted_fees",
+  "route_semantics"
+]

AddedSep 3, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Beyond the annotations, it discloses several behavioral contracts: the pair is returned unchanged plus a preview, the envelope is valid for 300 seconds and a stale one is refused, quoted shares are re-checked against previewDeposit and refused beyond the pinned tolerance, and the vault id is never an input. This is rich context that annotations alone do not convey.

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 a dense but front-loaded single paragraph that leads with the core action and puts constraints and the submission path after it. Almost every clause earns its place, though the run-on density slightly hurts scanability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex preparation tool with an output schema (so return values needn't be explained), it covers the source of the vault, the commitment check, tolerance refusal, envelope TTL, and the submission path. Minor gaps remain around accountProfile kinds and client_ref purpose.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

At 50% schema coverage the description must compensate, and it does add meaning for registryCommitment (must equal the recomputed current commitment; stale rows refused by name) and executableMarketId (comes from the deployable registry row). However, slippage.maxBps, client_ref, and accountProfile fields receive no added semantics in the description.

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 precise verb+resource ("Prepare the EXACT otto_prepare_swap pair that deposits USDC into a Morpho vault") and pins the output artifact (ERC-4626 share tokens to the signing account). It explicitly roots itself against siblings by defining itself as the vault-deposit variant versus plain otto_prepare_swap and otto_prepare_yield_withdraw.

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

Usage Guidelines4/5

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

It routes the agent downstream ("submit the pair through otto_submit_under_delegation under the end user's per-swap cap") and states the tool never signs or submits, so the when-to-use boundary is clear. It lacks an explicit when-not/alternative clause (e.g., use otto_prepare_yield_withdraw to exit a vault), which keeps it short of a 5.

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

All Otto Intel tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?