Otto Intel

Submit an Otto-prepared swap under a CDP end-user delegation

otto_submit_under_delegation

Destructive

Submit a verified otto_prepare_swap envelope on Base under the end user's CDP delegation. Arguments: { userId, envelope (the otto_prepare_swap result), prepareInput (the exact otto_prepare_swap request, with slippage.minAmountOut) } — validated strictly AFTER the caller is authenticated, so the listed input schema is intentionally permissive. Server-to-server only: the caller presents Otto's delegation secret in the x-otto-delegation-auth request header (never in arguments); a call without it is refused before anything is read. Before any send the server confirms, in this order: the Model-B project policy is installed and reads back by name and rules digest; the user's grant is active past the envelope's valid_until; the account is one of that end user's own CDP accounts as CDP reports them; the envelope passes the 13-check verifier for exactly the request that produced it; the plan is inside the fence (allow-listed input token, reviewed spender, gross at or below the 5000 USD engine ceiling); and the plan is at or below the per-swap cap THIS user chose when they minted, which is recorded against their grant on this server. A delegation with no recorded cap is REFUSED (DELEGATION_CAP_UNRECORDED) rather than defaulted to the ceiling — mint the permission again to set one. Then the three steps (allowance reset, approval, swap) are submitted in order under the delegation, each waited to a sealed canonical block; a halt clears the allowance and reports the read-back. One delegated plan at a time per user. Coinbase's engine bounds the delegated key to Model-B swap shapes through LI.FI up to the 5000 USD ceiling, which is shared by every delegated user and cannot be narrowed per user by the engine; the user's own lower cap and the receiver binding are Otto's server-side checks, and the user can revoke at any time.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description	Default
`fence`	Yes
`steps`	Yes
`status`	Yes
`address`	Yes
`user_id`	Yes
`chain_id`	Yes
`replayed`	No
`delegation`	Yes
`artifact_id`	Yes
`verification`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 3, 2026

addedOutput schema / properties / fence / properties / user_cap_usd

Added value: +{
+  "maximum": 5000,
+  "minimum": 1,
+  "type": "integer"
+}

changedOutput schema / properties / fence / required

Previous value: -[
-  "policy_id",
-  "policy_name",
-  "rules_digest",
-  "per_swap_cap_usd"
-]New value: +[
+  "policy_id",
+  "policy_name",
+  "rules_digest",
+  "per_swap_cap_usd",
+  "user_cap_usd"
+]

AddedSep 1, 2026

TDQS

A4.8/5.0

Behavior5/5

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

The description goes far beyond the annotations by detailing the strict post-authentication validation order, the refusal behavior when no cap is recorded, the three-step execution sequence, halt behavior clearing the allowance, and the shared 5000 USD engine ceiling. It also clarifies that the user's lower cap and receiver binding are server-side checks, and that the user can revoke at any time. No contradiction exists with the destructiveHint/openWorldHint annotations.

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

Conciseness5/5

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

The description is dense but every sentence earns its place: purpose, arguments, authentication, validation order, failure modes, execution steps, concurrency limits, and engine constraints. It is front-loaded with the core action and arguments before diving into behavioral details, and it avoids marketing fluff or repetition of the title.

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?

For a destructive, server-to-server submission tool with zero schema-declared parameters, this description is unusually complete. It covers prerequisites, authentication, validation semantics, failure codes, execution order, cleanup on halt, per-user cap behavior, engine limits, and revocation. The presence of an output schema means return-value documentation is not required here, so nothing material is missing.

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

Parameters5/5

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

The input schema is intentionally empty and permissive, so the description carries the full parameter burden. It explicitly names userId, envelope, and prepareInput, defines envelope as the otto_prepare_swap result, and requires prepareInput to be the exact original request including slippage.minAmountOut. It also clarifies that the delegation secret must go in the header, never in arguments, which is essential semantic guidance absent from the schema.

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 opens with a specific verb and resource: 'Submit a verified otto_prepare_swap envelope on Base under the end user's CDP delegation.' It clearly identifies the tool as the submission counterpart to otto_prepare_swap and distinguishes it from preparation, delegation management, and information-gathering siblings.

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?

The description makes the prerequisite relationship explicit by requiring an otto_prepare_swap result and the exact otto_prepare_swap request as inputs. It also states server-to-server-only usage, the required x-otto-delegation-auth header, and the one-plan-at-a-time constraint. However, it does not directly name alternatives such as otto_delegation_cap or otto_delegation_revoke for related but different actions, leaving some routing inference to the agent.

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?