F
licenseNot graded
qualityD
maintenance56 pay-per-call MCP endpoints for AI agents. Market signals, macro economics, crypto/DeFi, geopolitical intelligence, SEC filings, GitHub velocity, sanctions screening. USDC on Base Mainnet via x402.
-
Otto Intel
Server Details
Otto AI hosted MCP: 16 pay-per-call market-intelligence tools, USDC via x402 on Base, no API keys.
If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
A3.7/5.0
Scored across 34 tools
Disambiguation4/5
Most tools have clearly distinct purposes, with detailed descriptions disambiguating similar areas (e.g., delegation vs. fence status). Some overlap exists between otto_pm_crypto and otto_pm_markets, and among the several equity/news scanners, but the descriptions are specific enough to avoid major misselection.
Naming Consistency4/5
All tools share the otto_ prefix and use snake_case, which is a strong unifying pattern. However, naming style mixes noun-only names (otto_catalog, otto_delegation_cap) with verb-led names (otto_prepare_swap, otto_submit_under_delegation), creating minor inconsistency.
Tool Count2/5
At 34 tools, the server exceeds the comfortable 25-tool threshold and presents a large surface area for agents to navigate. The breadth is justified by covering intelligence, preparation, and delegation workflows, but the count remains heavy and harder to reason about as a set.
Completeness4/5
The tool surface covers the main workflows well: market intelligence, news, equity filings, Polymarket data, and transaction preparation across multiple venues. Minor gaps exist (e.g., no direct submission path for several prepared order types), but these are often by design since the caller signs externally.
Available Tools
34 toolsotto_base_seasonOtto Base seasonARead-onlyIdempotentInspect
Scan quality-screened Base tokens with current social-intelligence and trusted-KOL context. Market context only; not a pick, recommendation, or trade instruction. Hosted access: the first eligible cached intelligence result is free; otherwise calls cost $0.002 USDC through x402.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| x_payment | No | Signed x402 payment payload. Omit it to receive the machine-actionable payment challenge, then retry with the signed payload. |
TDQS
A3.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond annotations: it discloses the cost ($0.002 USDC via x402), the free first cached result, and clarifies the output is market context only, not a recommendation. These are not in the annotations (which already cover readOnly/idempotent/destructive hints), so the description provides added value.
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 concise and front-loaded: the first sentence states the core purpose, the second adds critical context (not a pick) and cost details. Every sentence earns its place with zero redundancy.
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 tool with one optional parameter and no output schema, the description covers the core purpose, cost, and non-recommendation stance. It does not describe the result format or what 'social-intelligence' entails, but given the simplicity and that the payment flow is already in the schema, it is nearly complete.
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?
The sole parameter (x_payment) is fully described in the schema (100% coverage), including the challenge-retry flow. The tool description itself does not add parameter-level detail, but since the schema already carries the full meaning, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear purpose: scanning quality-screened Base tokens with social-intelligence and trusted-KOL context. It uses a specific verb ('Scan') and resource ('Base tokens'), and adds a clarifying note that it is market context only, not a pick or recommendation. However, it does not explicitly differentiate from sibling tools like otto_rh_season or other scan tools, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It implies a use case (scanning Base tokens with social context) but does not state exclusions or mention sibling tools. Given the large sibling list, this is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
otto_catalogotto x402 catalogARead-onlyIdempotentInspect
Return the full live otto x402 menu with endpoint paths, descriptions, prices, and Base-USDC payment instructions. Always free; does not consume the free intelligence call.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, open-world, idempotent, and non-destructive behavior. The description adds useful behavioral context beyond that: the menu is 'live' and the tool is 'always free; does not consume the free intelligence call.' This cost/usage trait is not visible in the annotations and helps the agent decide when to invoke it.
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 two short sentences with no filler. The first sentence front-loads the action, resource, and what is returned; the second adds a distinct, useful cost-behavior note. Every word earns its place.
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 zero-parameter, annotated read-only tool with no output schema, the description is complete: it states what is returned, that it is live, and that it carries no cost. The agent has enough information to select and invoke the tool correctly without needing further detail.
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?
The tool has zero parameters and the schema is empty, so there are no parameter semantics to clarify. Per the rubric, this is a baseline 4; the description correctly focuses on the returned content instead of inventing unnecessary parameter details.
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 names a specific verb ('Return'), a distinct resource ('full live otto x402 menu'), and explicitly lists the contents: endpoint paths, descriptions, prices, and Base-USDC payment instructions. This clearly differentiates the tool from its otto_* siblings, which target specific actions like orders, bridges, or equity intel.
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 gives clear context for when to call it: whenever the agent needs the live menu, endpoint paths, prices, or Base-USDC payment instructions. It also adds the practical note that it is always free and does not consume the free intelligence call, which signals this is the low-cost discovery tool among the otto family. It does not explicitly exclude alternatives, but none of the siblings provide this catalog function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
otto_crypto_newsOtto crypto newsARead-onlyIdempotentInspect
Read importance-ranked crypto headlines with source links and publication times, plus a sentiment-scored market brief. The hourly snapshot reports its analysis window and freshness; missing source links remain unknown. Paid-only, including the first call: this tool preserves the hosted free intelligence allowance. Market context only; not a recommendation. Hosted access: paid-only; each call costs $0.001 USDC through x402 and preserves the free allowance.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| x_payment | No | Signed x402 payment payload. Omit it to receive the machine-actionable payment challenge, then retry with the signed payload. |
TDQS
A4.1/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint, the description discloses payment requirements (paid-only, $0.001 USDC per call), the payment flow (omit x_payment for challenge), freshness reporting, and the behavior of missing source links. It also states the tool preserves the free allowance, adding valuable context not in annotations.
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 concise and front-loaded with the core function, followed by payment details and a disclaimer. It is slightly redundant in repeating 'paid-only' and the cost, but overall well-structured and not overly verbose.
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 tool with no output schema, the description sufficiently outlines the return content (headlines, links, times, sentiment brief, analysis window, freshness). It also covers payment flow and disclaimers, making it complete enough for an agent to call correctly, though output format specifics are left unspecified.
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?
The input schema already fully describes the x_payment parameter with instructions on omission and retry. The tool description adds no additional parameter meaning, so it relies on the high schema coverage (100%). Baseline 3 is appropriate.
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 clearly states the tool reads importance-ranked crypto headlines with source links, publication times, and a sentiment-scored market brief. It distinguishes itself from siblings by focusing on current crypto news rather than recaps or other market data, and the 'not a recommendation' disclaimer clarifies its non-advisory role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when current crypto news is needed but does not explicitly contrast with alternatives like otto_news_recaps or otto_pm_crypto. It does provide practical constraints (paid-only, hourly snapshot) but lacks explicit when-to-use vs. when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
otto_delegation_capReserve the expiry a delegation is minted with, record the chosen per-swap cap against it, then confirm the mintAIdempotentInspect
TWO PHASES, both header authed, both resolving the end user from the access token. { phase: "reserve", accessToken, perSwapCapUsd, requestedDays, mintKey } takes a generation-bound unified mint claim, picks a whole-second expiry instant at or BEFORE the requested duration that no durable row for this user already occupies, writes the chosen cap (whole USD, 1…5000) against it, and answers { expires_at, mint_expires_at, per_swap_cap_usd, recorded }. Call createDelegation with mint_expires_at EXACTLY as given — it is the reserved instant plus a one-millisecond filler, because CDP refuses an expiry ending .000 and truncates the filler away — and with mintKey as the idempotencyKey. Then { phase: "confirm", accessToken, mintKey } re-reads the grant from CDP and promotes only the exact still-current claim whose reported instant IS the reserved one. A mismatch, Stop overlap, or stale claim remains unconfirmed and authorises nothing; no confirm path issues CDP's user-wide revoke because that could delete a newer permission, so use a fresh explicit Stop to revoke whichever permission is current. Why this shape: Coinbase issues no grant id and a send can learn nothing about a live grant except its expiry, so the expiry is made an identity BY CONSTRUCTION — reserved server-side, recorded before the mint, asserted after it. Until a reservation is successfully confirmed active, otto_submit_under_delegation refuses that delegation (DELEGATION_CAP_UNCONFIRMED) rather than falling back to the 5000 USD ceiling. A reservation is IMMUTABLE per mint key — pressing again returns the same instant and cap, and an older revoke generation cannot be revived. Coinbase's engine cannot hold this number: end-user accounts are fenced by ONE project-scope policy shared by every delegated user, so a lower per-user cap is enforced by Otto's server alone. 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. The listed input schema is intentionally permissive — the strict schema is validated after the caller is authenticated.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| phase | Yes | |
| state | Yes | |
| user_id | Yes | |
| recorded | Yes | |
| expires_at | Yes | |
| mint_expires_at | No | |
| ruleset_version | Yes | |
| per_swap_cap_usd | Yes |
TDQS
A5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the annotations: it discloses authentication via x-otto-delegation-auth, immutability per mint key, idempotent re-invocation behavior, the CDP one-millisecond filler workaround, and the absence of any user-wide revoke path. This richly supplements the sparse annotations without contradicting them.
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 long, but every section earns its place, and the two-phase structure is front-loaded. It uses clear naming, constant-width argument names, and separates behavior, rationale, and auth. The density is appropriate for a tool with this much operational nuance.
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 complex tool with an empty schema and rich side effects, the description covers invocation order, return fields, auth, rejection behavior, idempotency, edge cases, and the rationale for the design. Nothing an agent needs to correctly invoke and interpret this tool 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?
Although the input schema is intentionally empty/permissive, the description fully documents the phase-dependent parameters: accessToken, perSwapCapUsd, requestedDays, mintKey, and mint_expires_at, including constraints like whole USD in 1..5000 and the requirement to pass mint_expires_at exactly. With zero schema parameters, the description carries and exceeds the full burden.
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 multi-phase purpose: reserving an expiry, recording a per-swap cap, and confirming the mint. It names concrete resources and actions and clearly distinguishes this tool from revocation/status siblings by explaining what it does not do, such as no confirm-path revoke.
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 explicitly explains when this tool is required, including the refusal behavior of otto_submit_under_delegation until confirmation, server-to-server auth requirements, and the explicit alternative of using a fresh Stop to revoke. It also explains the two phases and the exact order of invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
otto_delegation_exitPrepare, submit, and recover an exact Base USDC exitADestructiveInspect
Move an authenticated CDP end user's own Base USDC only through a server-held durable reservation. prepare returns one exact EIP-1559 transaction for client-side signing; the client must never broadcast it. submit validates and durably records the signed bytes and computed hash before the server broadcasts. status is read-only and cross-device. reconcile proves a canonical receipt without broadcasting, or returns the exact finalized sender+nonce replacement proof when another transaction consumed the reserved nonce. retry_same is explicit and can broadcast only the already-stored byte-identical transaction after reconciling first. cancel is accepted only before signed bytes were recorded. The caller presents Otto's delegation secret in x-otto-delegation-auth; user identity is always derived from accessToken.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| epoch | No | |
| phase | Yes | |
| state | No | |
| account | No | |
| receipt | No | |
| user_id | Yes | |
| has_exit | Yes | |
| created_at | No | |
| updated_at | No | |
| destination | No | |
| owner_token | No | |
| replacement | No | |
| transaction | No | |
| operation_id | No | |
| amount_atomic | No | |
| lease_expires_at | No | |
| transaction_hash | No | |
| broadcast_attempts | No |
TDQS
A4.5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even with destructiveHint already set, the description adds substantial behavioral detail: durable recording before broadcast, client never broadcasting the prepared transaction, cross-device read-only status, nonce-replacement proof behavior, and the delegation-auth/accessToken mechanism. There is no contradiction with the annotations.
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 dense but purposeful and front-loaded with the core purpose. Every sentence adds a real constraint or phase behavior; however, it is a single wall of text and would be easier to scan if the phases were structured as bullets or separate labeled paragraphs.
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?
Given the tool's complexity, the description covers auth, phase ordering, broadcast safety, cancel conditions, and nonce-conflict recovery, and an output schema exists so return values do not need to be enumerated. The main remaining gap is that it never explains how the caller selects among prepare/submit/status/reconcile/retry_same/cancel given the empty input schema.
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?
The input schema defines zero parameters, so the 0-parameter baseline of 4 applies. The description adds useful invocation context by naming x-otto-delegation-auth and explaining that user identity comes from accessToken, even though no request payload or phase-selection parameter is documented.
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 clearly states the tool's purpose: moving an authenticated CDP end user's own Base USDC through a server-held durable reservation. It enumerates the exact workflow phases (prepare, submit, status, reconcile, retry_same, cancel), which distinguishes it from the broader delegation and prepare/swap 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 gives strong phase-specific usage context: prepare is client-side signing only and must never be broadcast, submit is the server broadcast point, reconcile handles nonce-conflict recovery, and cancel is only valid before signed bytes exist. It does not explicitly name alternative sibling tools, so it stops 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.
otto_delegation_fenceEnsure the Model-B project policy (the delegation fence) is installed and reads back as v-currentAIdempotentInspect
Idempotent ensure-by-digest of the ONE CDP project-scope policy that fences every delegated send, then a read-back. Writes only when no project policy exists (creates it) or when the existing one is Otto's own lineage with stale rules (updates it in place). REFUSES BY NAME if a different project-scope policy is installed — it is never overwritten or deleted. Never downgrades a newer fence. An OPS action: at most one ensure runs project-wide at a time, never during a rolling deploy, never from the dApp (the mint gate reads fence.present from otto_delegation_status). Arguments: {}. Output: the policy id, versioned name, rules digest and the per-swap cap; the tool fails unless the fence reads back present under the written id. 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. The listed input schema is intentionally permissive — the strict schema is validated after the caller is authenticated.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| action | Yes | |
| status | Yes | |
| policy_id | Yes | |
| policy_name | Yes | |
| rules_digest | Yes | |
| per_swap_cap_usd | Yes |
TDQS
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already state idempotentHint=true, readOnlyHint=false, and destructiveHint=false, and the description is fully consistent with those. It adds substantial behavioral detail: it creates only when missing, updates in place only Otto's own lineage with stale rules, refuses by name any other installed policy, never downgrades a newer fence, and fails unless the read-back returns present under the written id.
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?
Although the description is long, each sentence adds distinct operational value: idempotency conditions, refusal behavior, downgrade protection, OPS restrictions, auth requirement, and output contract. It front-loads the core ensure-by-digest purpose before diving into constraints.
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?
The description is complete for an operation with no parameters: it specifies the auth header, when writes happen, when the tool refuses, the output fields, and the failure condition. Because an output schema exists, the return-value description is a bonus rather than a necessity.
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?
There are zero parameters, so there is nothing to explain in the input schema itself; the description explicitly confirms 'Arguments: {}'. It also explains why the listed schema is permissive: the strict schema is validated after the caller is authenticated, which prevents an agent from assuming the empty schema means no validation at all.
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: 'Idempotent ensure-by-digest of the ONE CDP project-scope policy that fences every delegated send, then a read-back.' This clearly distinguishes the ensure/mutate action from read-style siblings like otto_delegation_fence_status. The title reinforces the same purpose: installed and reads back as v-current.
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 gives strong usage context: it is an OPS action, never runs during a rolling deploy, never runs from the dApp, and runs at most one at a time project-wide. It does not explicitly say 'use otto_delegation_fence_status for inspection,' but it does distinguish the write path from the read path by mentioning the mint gate reads fence.present from otto_delegation_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
otto_delegation_fence_statusRead the Model-B delegation fence (public promise: present, name, rules digest, per-swap cap)ARead-onlyIdempotentInspect
PUBLIC and read-only, no header: whether the Model-B project policy that fences every delegated send is installed and v-current on this server, with its versioned name, rules digest, the per-swap cap ceiling in USD (shared by every delegated user — a person may choose any whole-dollar cap from per_swap_cap_min_usd up to it, enforced server-side and recorded against their own grant), and Otto's PUBLIC CDP project id (a UUID — the authority an agent binds its mint to). Exposes ONLY the fence's public promise — never an end user, a grant, an address or a policy's contents. An agent about to mint a delegation (otto-execute delegate) reads this first, mints to the published project_id and no other, and refuses to mint when the fence is not present; the server enforces fence-before-authority on every delegated send regardless. Arguments: {}.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| reason | No | |
| present | Yes | |
| project_id | No | |
| policy_name | Yes | |
| mint_enabled | Yes | |
| rules_digest | No | |
| ruleset_version | Yes | |
| per_swap_cap_usd | Yes | |
| per_swap_cap_min_usd | Yes |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds significant context beyond those: it is PUBLIC, requires no header, exposes only the fence's public promise and never end users/grants/addresses, defines the shared cap semantics, and states an enforcement guarantee ('the server enforces fence-before-authority on every delegated send regardless'). No contradiction with annotations exists.
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 single dense paragraph that front-loads the core purpose before providing operational details. Each clause adds value: public scope, cap ceiling semantics, project id authority, usage before minting, and server-side enforcement. It is slightly long, but the density is justified by the need to convey the fence's contract accurately.
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?
The combination of a clear purpose, explicit usage context, privacy/scope limitations, enforcement behavior, and the presence of an output schema makes the definition complete for an agent. The description explains all returned conceptual fields, the required action before minting, and the safety net, so nothing necessary for correct invocation 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?
The input schema has zero properties and the description explicitly states 'Arguments: {}.' With no parameters, there is no semantic burden on the description, and the 0-param baseline of 4 applies. The description appropriately does not invent parameter details.
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 clear statement: it tells whether the Model-B delegation fence is installed and current on the server, and it names the exact returned data: versioned name, rules digest, per-swap cap ceiling, and Otto's public CDP project id. It also explicitly scopes what it exposes ('Exposes ONLY the fence's public promise'), making it clearly distinguishable from sibling tools like otto_delegation_fence and otto_delegation_status.
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 gives explicit when-to-use guidance: 'An agent about to mint a delegation (otto-execute delegate) reads this first, mints to the published project_id and no other, and refuses to mint when the fence is not present.' It also notes the server enforces the policy regardless, providing useful safety context. It does not name sibling alternatives or state when not to use the tool, so it falls 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.
otto_delegation_operationsRead one end user's delegated operation history and recovery stateARead-onlyIdempotentInspect
Read the durable Base delegated-operation journal for the end user resolved from { accessToken }. Optional artifactId selects one exact own-user operation; without it, the result includes a bounded recent terminal history and every unresolved operation regardless of age. The global unresolved flag is fail-closed: it is true when the store is unavailable, journal coverage is not rollout-ready, or any operation has a prepared/submitted/unknown outcome. Stored serialized transactions and CDP idempotency keys are never returned, and this tool never submits or retries anything. Server-to-server only: the caller also presents Otto's delegation secret in the x-otto-delegation-auth request header; no userId argument is accepted.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| journal | Yes | |
| user_id | Yes | |
| operations | Yes | |
| unresolved | Yes | |
| store_available | Yes |
TDQS
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial behavior beyond the readOnlyHint/openWorldHint/idempotentHint annotations: the fail-closed unresolved flag semantics, exclusion of stored serialized transactions and idempotency keys, no submission/retry guarantee, and the required x-otto-delegation-auth header with server-to-server constraint. This is exactly the kind of context that changes how an agent should interpret results.
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?
Dense but every sentence earns its place: the first sentence defines scope, the second explains optional filtering and result shape, the third clarifies fail-closed semantics, and the fourth covers security and exclusions. No redundant restatement of the title or schema; the length is justified by the operational and security nuances.
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 zero-parameter read tool with an output schema and rich annotations, the description is complete. It covers auth requirements, result scope, failure semantics, data-privacy exclusions, and the no-mutation guarantee. Nothing an agent needs to invoke this correctly 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 schema declares zero explicit parameters, which sets a baseline of 4. The description further clarifies that accessToken resolves the end user and that artifactId is an optional selector with meaningful behavioral consequences (exact operation versus history plus unresolved operations). This is valuable semantic context about parameters that live outside the JSON 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?
States a specific verb ('Read') with a precise resource ('durable Base delegated-operation journal') and the owning entity. The title reinforces 'history and recovery state,' and the description explicitly excludes submission/retry behavior, making it clearly distinguishable from sibling tools like otto_submit_under_delegation and otto_delegation_reconcile.
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 read-only, server-to-server intent explicit and explains the effect of including artifactId versus omitting it. It does not name specific sibling alternatives or state 'use this instead of X,' but the behavioral boundaries (never submits, never retries, requires delegation auth, no userId) give an agent enough context to select this over mutation or status tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
otto_delegation_reconcileReconcile one end user's known-hash delegated operationAIdempotentInspect
Acquire the artifact's permanent process-liveness guard, then check Base for finalized canonical receipts of already-stored transaction hashes. Every chain transaction must match the stored chain, hash, sender, target, calldata, value, nonce, gas and EIP-1559 fee fields before its receipt is recorded. This tool never calls CDP, never retries a request, never builds or submits a later step, and leaves prepared/unknown no-hash steps unresolved. It returns the same token-bound operation snapshot as otto_delegation_operations. Server-to-server only: the caller also presents Otto's delegation secret in x-otto-delegation-auth.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| journal | Yes | |
| user_id | Yes | |
| operations | Yes | |
| unresolved | Yes | |
| store_available | Yes |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond annotations by disclosing the liveness-guard acquisition, the Base receipt-checking behavior, the exact field-matching requirement, and the explicit limitations on retries and later steps. This materially informs an agent about side effects and non-effects even though annotations already indicate idempotence and non-destructiveness.
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 dense but each sentence carries meaningful information: the workflow, the validation criteria, the behavioral constraints, and the response shape plus auth requirement. It is slightly heavy with jargon like 'permanent process-liveness guard,' but it is well structured and front-loaded.
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 zero parameters, an existing output schema, and rich annotations, the description covers all needed operational context: what it does, what it verifies, what it never does, what it returns, and the required server-to-server auth. Nothing critical for invoking it correctly 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?
The tool has zero parameters and the schema is empty, so there are no parameter semantics to document. The description adds relevant context by mentioning the x-otto-delegation-auth secret, though this is an auth header rather than a schema parameter.
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?
Title and description name a specific verb ('reconcile') and resource ('one end user's known-hash delegated operation'), then explain the concrete workflow: acquire a liveness guard, check Base for finalized receipts, and validate fields. It also distinguishes itself from siblings by stating it never calls CDP, never retries, and never builds or submits later steps.
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 gives clear context: this is server-to-server only and requires Otto's delegation secret in x-otto-delegation-auth. It also clarifies what it does not do (no retries, no later-step submission, leaves no-hash steps unresolved), but it does not explicitly name an alternative sibling for cases where those behaviors are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
otto_delegation_revokeRevoke one end user's delegation, developer-side, confirmed by read-backADestructiveIdempotentInspect
Revoke the end user's delegation from Otto's side and confirm by read-back that it no longer exists; from then on this server submits nothing for that user (fail-closed, even if the read-back had failed). Arguments: EITHER { accessToken } (the user path — the server resolves the user from the token) OR { userId, support_reason } (the support path, for an operator holding the server secret; the reason is logged, the token never is). 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. The listed input schema is intentionally permissive — the strict schema is validated after the caller is authenticated.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| path | Yes | |
| revoked | Yes | |
| user_id | Yes | |
| reads_back | Yes |
TDQS
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral context beyond the annotations: it states the fail-closed behavior even if read-back fails, notes that the server will submit nothing for that user afterward, and explains that unauthenticated calls are refused before any read. This goes well beyond the destructive and idempotent hints already present.
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?
Every sentence earns its place: the core operation, fail-closed consequence, argument alternatives, authentication requirement, and schema note are all necessary and front-loaded. The description is dense but not bloated.
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 revocation tool, the description covers invocation paths, authentication, side effects, fail-closed behavior, and the intentionally permissive schema. With an output schema present, return-value documentation is not needed, and nothing essential to calling the tool correctly 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?
Although the input schema is empty and permissive, the description fully compensates by defining the two mutually exclusive argument sets: accessToken, or userId plus support_reason. It also clarifies authentication is via header, not arguments, and that strict validation occurs after authentication.
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: 'Revoke the end user's delegation from Otto's side' and 'confirm by read-back.' It clearly identifies the action and its effect, distinguishing this revocation operation from read-only or status tools like otto_delegation_status.
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 gives explicit usage paths and context: the user path with accessToken versus the support path with userId and support_reason, plus server-to-server-only authentication via the x-otto-delegation-auth header. It does not explicitly name sibling alternatives or state when not to use this tool, so it stops short of full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
otto_delegation_statusRead one end user's delegation status (token-bound)ARead-onlyIdempotentInspect
Read back, for the end user identified by a CDP access token, their CDP accounts, whether the Model-B fence is present, and whether an active delegation reads back (with its expiry and the per-swap cap recorded for it). Arguments: { accessToken } — the server resolves the user from the token; a client-sent user id is refused. delegation.per_swap_cap_usd is the number THIS user chose at mint time; it is ABSENT when no cap is recorded for the grant, which means the delegated send will refuse it — say so rather than showing the shared ceiling. fence.per_swap_cap_usd is that shared ceiling and is never a per-user number. Output is bound to that user; nothing about any other user is returned. 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. The listed input schema is intentionally permissive — the strict schema is validated after the caller is authenticated.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| fence | Yes | |
| user_id | Yes | |
| addresses | Yes | |
| delegation | Yes | |
| mint_enabled | Yes | |
| ruleset_version | Yes | |
| revocation_requested_here | Yes |
TDQS
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and idempotent, but the description goes well beyond that: it explains authentication requirements, token-based user resolution, refusal of client-sent user ids, output scoping to the authenticated user, and the subtle difference between `delegation.per_swap_cap_usd` and `fence.per_swap_cap_usd`. This is rich behavioral disclosure that meaningfully informs an agent.
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: core read behavior, token semantics, cap-value disambiguation, output scoping, and auth requirements are each covered without redundancy. It is front-loaded with the primary purpose before layering in necessary caveats.
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 that an output schema exists and annotations cover safety, the description supplies all remaining context an agent needs: authentication, user resolution, per-cap semantics, and output isolation. Nothing critical is missing for correct invocation and interpretation.
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 schema lists zero properties, but the description explains that the effective input is an `accessToken` resolved server-side, that a user id will be refused, and that the listed permissive schema is intentionally loose with strict validation occurring post-auth. For a zero-parameter tool, this is strong semantic guidance beyond 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 names a specific verb ('Read back'), a specific resource (one end user's delegation status), and enumerates exactly what is returned: CDP accounts, Model-B fence presence, active delegation with expiry and per-swap cap. The title and description together clearly distinguish this read-oriented delegation tool from the other delegation 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit invocation context: server-to-server only, required `x-otto-delegation-auth` header, and refusal without it. It also states that a client-sent user id is refused and that the server resolves the user from the token. It does not explicitly name sibling tools as alternatives, so there is no direct 'use this instead of X' guidance, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
otto_equity_intelOtto equity intelligenceARead-onlyIdempotentInspect
Read SEC-EDGAR fundamentals and filings context for a US ticker: revenue and net-income trends, margins, EPS, leverage, recent 10-K/10-Q/8-K filings, and a guarded AI summary. Fundamentals scanner only; not a price feed or recommendation. Hosted access: the first eligible cached intelligence result is free; otherwise calls cost $0.003 USDC through x402.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | US-listed stock ticker, for example NVDA, AAPL, or JPM. | |
| x_payment | No | Signed x402 payment payload. Omit it to receive the machine-actionable payment challenge, then retry with the signed payload. |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already declaring readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, the description adds valuable behavioral context beyond them: the payment model ('first eligible cached intelligence result is free; otherwise calls cost $0.003 USDC through x402'), the x402 challenge flow, and the nature of the output ('guarded AI summary'). This goes beyond the safety profile covered by 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?
Three sentences, each earning its place: the first states purpose and content, the second scopes the tool and differentiates it, and the third explains the payment mechanism. Information is front-loaded and there is no fluff.
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?
Despite no output schema, the description adequately tells an agent what data to expect (trends, margins, EPS, leverage, recent filings, AI summary) and how to handle payment (x402 challenge). For a read-only tool with only two parameters, nothing essential is missing for correct invocation.
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?
Schema description coverage is 100%, so both parameters (ticker, x_payment) are already thoroughly documented in the schema. The tool description does not add param-level semantics beyond implicitly referencing output fields, so the baseline 3 applies.
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 clearly states the verb ('Read') and specific resource ('SEC-EDGAR fundamentals and filings context for a US ticker'), and lists exact data points (revenue, net-income trends, margins, EPS, leverage, filings). It explicitly differentiates from other tools with 'Fundamentals scanner only; not a price feed or recommendation,' which helps an agent distinguish it from siblings like otto_equity_smart_money.
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 gives clear context for when to use it (when SEC-EDGAR fundamentals are needed) and includes an explicit exclusion ('not a price feed or recommendation'). However, it does not name alternative sibling tools directly, so the guidance is strong but not fully explicit about routing to specific alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
otto_equity_smart_moneyOtto equity smart-money scannerARead-onlyIdempotentInspect
Read a public-domain SEC bundle for a US ticker: Form 4 insider activity plus trailing-twelve-month XBRL fundamentals. Scanner context only; not a pick or recommendation. Hosted access: the first eligible cached intelligence result is free; otherwise calls cost $0.006 USDC through x402.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | US-listed stock ticker, for example NVDA, AAPL, or JPM. | |
| x_payment | No | Signed x402 payment payload. Omit it to receive the machine-actionable payment challenge, then retry with the signed payload. |
TDQS
A3.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. On top of that, the description adds valuable non-obvious behavior: the first eligible cached result is free, otherwise calls cost $0.006 USDC through x402, and this is scanner context rather than investment advice. It does not contradict the annotations.
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 concise: three sentences that front-load the primary action and data scope before covering context and pricing. Every sentence contributes useful information, though the phrase 'Scanner context only' is somewhat redundant with 'not a pick or recommendation' in the same sentence.
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 read-only tool with rich annotations, two well-described parameters, and a clear data scope, this is largely complete. It also covers the payment/caching flow and clarifies that the result is informational. There is no output schema, and the description does not explain the shape of the returned SEC bundle, but the stated selector and contents give an agent enough to decide to invoke it.
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?
Schema description coverage is 100%, and both parameters already have descriptive meanings in the schema: ticker is a US-listed stock ticker, and x_payment is a signed x402 payment payload with challenge-and-retry behavior. The description adds general context about SEC bundle contents and cost, but it does not materially deepen the parameter semantics beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Read a public-domain SEC bundle for a US ticker' and specifies the contents: 'Form 4 insider activity plus trailing-twelve-month XBRL fundamentals.' This makes the core purpose clear. However, it does not explicitly distinguish itself from sibling tools like otto_insider_trades or otto_equity_smart_money_brief, so it misses the sibling-differentiation that would earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when a scanner-style view of Form 4 activity and TTM fundamentals for a US ticker is needed. It also adds a restriction: 'Scanner context only; not a pick or recommendation.' But it gives no explicit when-not-to-use guidance or references to alternative tools, leaving the routing logic mostly inferential.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
otto_equity_smart_money_briefOtto equity smart-money briefARead-onlyIdempotentInspect
Read one guarded AI brief over observed SEC Form 4 flow, 13D/13G ownership events, and fundamentals for a US ticker. Filing scanner only; generation rejects buy/sell advice and the result is not a recommendation. Hosted access: the first eligible cached intelligence result is free; otherwise calls cost $0.10 USDC through x402.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | US-listed stock ticker, for example NVDA, AAPL, or JPM. | |
| x_payment | No | Signed x402 payment payload. Omit it to receive the machine-actionable payment challenge, then retry with the signed payload. |
TDQS
A3.8/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering safety and mutability. The description adds valuable context: it specifies the cost structure ($0.10 USDC via x402, with a free first cached result) and reiterates that it is not a recommendation. It also mentions the 'guarded' nature, though not fully explained. No contradiction with annotations; the description enhances behavioral understanding.
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 three sentences with no fluff. It front-loads the core purpose, then adds constraints (filing scanner only, not a recommendation) and cost details. Every sentence earns its place, and the structure is clear and efficient.
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 read-only tool with no output schema, the description covers the essential operational details: what it reads, that it is not advice, the cost model, and the payment mechanism. It does not explicitly describe the return format, but given the name 'brief' and the nature of the tool, this is likely understood. The absence of an output schema is mitigated by the description's clarity, though a mention of the result format would make it more complete.
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?
Schema coverage is 100%, so both parameters (ticker and x_payment) are fully described in the schema. The description does not add any new parameter-specific meaning beyond what the schema already provides, such as the payment challenge flow or ticker format. With full schema coverage, the baseline of 3 is appropriate; the description adds no extra semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Read'), a resource ('guarded AI brief over observed SEC Form 4 flow, 13D/13G ownership events, and fundamentals'), and a target ('US ticker'). It clearly conveys the tool's function and hints at differentiation by noting 'Filing scanner only' and that it does not give buy/sell advice, distinguishing it from advisory tools. However, it does not explicitly name sibling tools like otto_equity_smart_money, so it is clear but not maximally distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating it is a filing scanner and that it rejects buy/sell advice, suggesting it is for intelligence rather than recommendations. It also mentions the x402 payment flow. However, it does not explicitly state when to use this tool versus siblings like otto_equity_intel or otto_insider_trades, nor does it provide exclusions. Guidance is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
otto_insider_tradesOtto insider tradesARead-onlyIdempotentInspect
Read parsed SEC Form 4 insider transactions for a US ticker, including purchase/sale counts, dollar values, roles, and net P/S balance. Filing scanner only; not a recommendation. Hosted access: the first eligible cached intelligence result is free; otherwise calls cost $0.003 USDC through x402.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | US-listed stock ticker, for example NVDA, AAPL, or JPM. | |
| x_payment | No | Signed x402 payment payload. Omit it to receive the machine-actionable payment challenge, then retry with the signed payload. |
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context: the cost structure ('first eligible cached intelligence result is free; otherwise calls cost $0.003 USDC through x402') and the 'Filing scanner only' caveat. This goes beyond the annotations and informs the agent about payment requirements and data scope.
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?
Two sentences with no fluff. The first sentence front-loads the purpose and data fields; the second adds the caveat and cost. Every clause earns its place, and the structure is scannable for an agent.
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?
The description specifies the output data (purchase/sale counts, dollar values, roles, net P/S balance) despite the absence of an output schema. It also covers payment and the 'filing scanner' nature. It omits error handling or edge cases, but for a read-only tool with well-documented parameters, the essential information is present.
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?
The input schema covers both parameters with clear descriptions (ticker format and x_payment purpose/flow). Since schema_description_coverage is 100%, the baseline is 3. The description adds only marginal context about the cost tied to x_payment, but does not clarify parameter usage further, so a 3 is appropriate.
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 ('Read') and resource ('parsed SEC Form 4 insider transactions') and enumerates the data fields (purchase/sale counts, dollar values, roles, net P/S balance). It clearly distinguishes itself from sibling tools like otto_equity_intel or otto_equity_smart_money, which cover different equity intelligence, leaving no ambiguity about what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes 'Filing scanner only; not a recommendation,' which gives some context on what the tool is not (a recommendation), but it does not explicitly name alternatives or provide when-to-use vs. when-not-to-use guidance. The purpose is clear enough that an agent could infer usage, but explicit routing to siblings is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
otto_institutional_holdingsOtto institutional holdingsARead-onlyIdempotentInspect
Read the latest SEC 13F-HR top positions for an institutional manager by CIK or manager ticker, with amendments applied. Ownership data only; not a recommendation. Hosted access: the first eligible cached intelligence result is free; otherwise calls cost $0.003 USDC through x402.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| manager | Yes | SEC manager CIK, such as 1067983, or listed manager ticker, such as BLK. | |
| x_payment | No | Signed x402 payment payload. Omit it to receive the machine-actionable payment challenge, then retry with the signed payload. |
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, openWorld, idempotent, destructive. The description adds valuable context: amendments applied, ownership-only disclaimer, and the x402 payment requirement with cost. It does not contradict annotations and provides extra behavioral info beyond safety.
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?
Two sentences with zero waste. Purpose and key constraints are front-loaded, and the cost/payment note is placed at the end without diluting the main action.
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 simple read tool with full schema coverage and no output schema, the description covers the main action, data scope, and cost. It doesn't detail output format or pagination, but given the simplicity and that annotations carry safety, it's sufficiently complete.
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?
Schema coverage is 100%, with clear descriptions for both parameters (manager CIK/ticker and x_payment flow). The description adds no additional parameter-level semantics, so baseline 3 is appropriate.
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?
States a specific verb (read) + resource (SEC 13F-HR top positions) + scope (institutional manager by CIK or ticker), and clarifies it's ownership data only, not a recommendation. This clearly distinguishes it from generic equity data tools among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its usage via a clear purpose but provides no explicit when-to-use vs alternatives. It does note the cost model and first-cached-result-free policy, which is context but not usage guidance against siblings. No exclusions or alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
otto_lp_collect_useropReview or recover sponsored LP collectionADestructiveInspect
Protected same-account Uniswap V3 guarded collection on Base. Read availability, prepare and explicitly confirm one operation, or read/reconcile it. May collect owed principal and fees; profit remains unknown. Account upgrade is separate. Current owner authority, reviewed guard and provider policy are required. Unknown delivery retains the original operation; no replacement is allowed. Preparation and simulation are not funded execution.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| gas | No | |
| kind | Yes | |
| pool | No | |
| state | No | |
| action | No | |
| reason | No | |
| status | No | |
| account | No | |
| chainId | No | |
| tokenId | No | |
| protocol | No | |
| attention | No | |
| retrySafe | No | |
| collection | No | |
| configured | No | |
| settlement | No | |
| userOpHash | No | |
| failureCode | No | |
| operationId | No | |
| confirmation | No | |
| validUntilMs | No | |
| schemaVersion | Yes | |
| reviewConsumed | No | |
| transactionHash | No | |
| executionEnabled | No | |
| reviewCommitment | No | |
| supportedActions | No | |
| recoveryAvailable | No | |
| envelopeCommitment | No | |
| replacementPermitted | No | |
| protocolActionVerified | No | |
| requiresReconciliation | No | |
| requiresOperationReview | No | |
| automaticExecutionEnabled | No | |
| supportedSameAddressChains | No | |
| requiresSeparateWalletUpgrade | No | |
| walletAuthorityChangeIncluded | No |
TDQS
A3.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare non-readonly, destructive, non-idempotent, open-world behavior, so the bar is lower. The description nonetheless adds real behavioral context: profit remains unknown, no replacement is allowed, unknown delivery retains the original operation, and preparation/simulation are not funded execution. It does not restate annotation fields and does not contradict them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
It is appropriately short at roughly six sentences with no filler, and the domain is front-loaded. But several sentences are heavily compressed jargon that an agent must decode ('Unknown delivery retains the original operation', 'Preparation and simulation are not funded execution'), trading clarity for terseness.
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?
An output schema exists so return values need not be described, and the annotations carry the safety profile. The description still supplies the prerequisites, lifecycle modes, and failure/uncertainty handling an agent needs for this destructive, non-idempotent operation. It is nearly complete, with only the sibling-routing gap remaining.
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?
The tool takes zero parameters (empty schema, 100% coverage), so there is nothing for the description to gloss — baseline 4 applies. No parameter meaning is asserted or lost.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific domain action — a guarded Uniswap V3 LP collection on Base with read/prepare/confirm/reconcile modes — so the resource and operation are inferable. However, it never crisply states what the tool does in one clear verb+object phrase, and it does not distinguish itself from close siblings such as otto_native_yield_userop or otto_delegation_reconcile, which an agent must choose between.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Phrases like 'prepare and explicitly confirm one operation, or read/reconcile it' imply a prepare-then-confirm-then-reconcile workflow, and prerequisites ('Account upgrade is separate', 'owner authority, reviewed guard and provider policy are required') are given. But no explicit when-to-use vs alternatives or when-not guidance is offered, and no sibling is named as the alternative path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
otto_native_yield_useropReview or recover an account native yield actionBDestructiveInspect
Protected native protocol action. Read availability, review and confirm native scope, prepare, reviewGas for current payer and network estimate, and explicitly confirm one operation, or read/reconcile/revoke native consent. Account upgrade is separate. Source activation and current owner authority are required. Unknown delivery retains the original operation; no replacement is allowed. A preparation or simulation is not funded execution.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| gas | No | |
| kind | Yes | |
| input | No | |
| scope | No | |
| state | No | |
| action | No | |
| output | No | |
| reason | No | |
| status | No | |
| account | No | |
| chainId | No | |
| consent | No | |
| marketId | No | |
| attention | No | |
| retrySafe | No | |
| configured | No | |
| settlement | No | |
| userOpHash | No | |
| failureCode | No | |
| operationId | No | |
| confirmation | No | |
| scopeConsent | No | |
| validUntilMs | No | |
| schemaVersion | Yes | |
| reviewConsumed | No | |
| transactionHash | No | |
| estimatedOttoFee | No | |
| executionEnabled | No | |
| perDepositCapUsd | No | |
| reviewCommitment | No | |
| recoveryAvailable | No | |
| envelopeCommitment | No | |
| nativeConsentRevoked | No | |
| replacementPermitted | No | |
| requiresNativeConsent | No | |
| protocolActionVerified | No | |
| requiresReconciliation | No | |
| requiresOperationReview | No | |
| automaticExecutionEnabled | No | |
| supportedSameAddressChains | No | |
| requiresSeparateWalletUpgrade | No | |
| walletAuthorityChangeIncluded | No | |
| requiresSeparateOperationReview | No | |
| existingOperationRequiresReconciliation | No |
TDQS
B3.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructive=true, openWorld=true, and idempotent=false. The description adds real value beyond them: no-replacement semantics for unknown delivery ('retains the original operation; no replacement is allowed'), the distinction that 'A preparation or simulation is not funded execution', and the auth prerequisite. These are meaningful behavioral traits the annotations do not encode.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The core sentence is a dense run-on that packs availability reading, scope review, prepare, reviewGas, confirm, and read/reconcile/revoke into one comma chain. It is not front-loaded around a single purpose, so the agent must parse the whole list to understand the tool. Several clauses do earn their place, but the structure obscures rather than clarifies.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained and safety hints are covered by annotations. Still, for a complex multi-mode user-operation tool with zero parameters, the description never enumerates or defines the selectable operations as a clean list, leaving the agent to infer the mode set from a prose sentence.
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?
There are zero parameters and schema coverage is 100% (vacuously), so the parameter bar is minimal and the description correctly adds no param detail. Baseline for a 0-param tool is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The title and opening ('Protected native protocol action') plus a run-on list of modes ('prepare, reviewGas..., confirm one operation, or read/reconcile/revoke native consent') convey the general area but not a single crisp verb+resource. The jargon 'native yield action/userop' is never grounded, and it does not distinguish itself from siblings like otto_prepare_yield_deposit or otto_prepare_yield_withdraw. An agent can guess the domain but not the tool's core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives prerequisites ('Source activation and current owner authority are required') and one exclusion ('Account upgrade is separate'), which is useful context. However, it never states when to choose this tool over the obvious yield siblings, nor how the enumerated modes relate to each other as a decision path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
otto_news_recapsOtto crypto market recapARead-onlyIdempotentInspect
Read a concise crypto market recap with ranked stories, source links where available, analysis window and freshness. A cached result can use the hosted free allowance; a cold or unavailable read returns a payment challenge without generating a recap for free. Stale-but-servable cached results retain their upstream freshness and degraded indicators. Market context only; not a recommendation. Hosted access: the first eligible cached intelligence result is free; otherwise calls cost $0.003 USDC through x402.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| x_payment | No | Signed x402 payment payload. Omit it to receive the machine-actionable payment challenge, then retry with the signed payload. |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, but the description adds substantial non-obvious behaviors: the payment challenge on cold/unavailable reads, the free allowance for cached results, stale caching semantics, and the $0.003 USDC cost. This goes well beyond the annotations and is crucial for the agent to call correctly.
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?
Three sentences, front-loaded with the core purpose, then payment behavior, then a caution. No filler words, every sentence carries essential information. The structure is efficient and scannable.
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 tool with one optional parameter and no output schema, the description covers everything an agent needs: what the recap contains, payment behavior, caching nuances, and the non-advice nature. The lack of an output schema is compensated by describing the content (ranked stories, links, window, freshness). No critical gaps.
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?
The input schema's description for x_payment already explains the signed payload and the challenge/retry flow (100% coverage). The tool description adds value by clarifying the free allowance and per-call cost, which are not in the schema, so it enriches the parameter's meaning beyond the schema. This is more than a baseline 3 but not a 5 because the core semantics are already well-documented.
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 ('Read') and a precise resource ('concise crypto market recap with ranked stories, source links where available, analysis window and freshness'). It clearly distinguishes this from a news tool (it's a recap, not live news) and includes the informational caveat 'not a recommendation,' making the tool's purpose unambiguous even among many 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 gives clear context: it is for market context, not advice, and it explains when cached results are free vs when a payment challenge is issued. It does not explicitly mention alternatives or when-not-to-use relative to sibling tools, so it stops short of a 5, but the context is clear enough for an agent to decide usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
otto_pm_cryptoOtto crypto prediction-market contextARead-onlyIdempotentInspect
Read high-volume open BTC, ETH, and crypto Polymarket markets with current outcome probabilities and market context. Event-probability data only; not a recommendation. Hosted access: the first eligible cached intelligence result is free; otherwise calls cost $0.001 USDC through x402.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| x_payment | No | Signed x402 payment payload. Omit it to receive the machine-actionable payment challenge, then retry with the signed payload. |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds valuable context beyond annotations: 'the first eligible cached intelligence result is free; otherwise calls cost $0.001 USDC through x402' discloses cost and caching behavior. It also clarifies that output is 'event-probability data only,' which helps set expectations. No contradiction with 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 three sentences with no wasted words. The core purpose is front-loaded, followed by an important caveat and a concise payment note. Every sentence earns its place.
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 read-only tool with one optional parameter and no output schema, the description covers the essential operational details: what is read, the data type returned, the recommendation disclaimer, and the payment cost. It is slightly vague about what 'market context' includes, but the overall guidance is sufficient for an agent to invoke the tool correctly.
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?
The input schema has 100% coverage for x_payment, explaining the signed payload and challenge/retry flow. The description adds complementary detail by revealing the payment cost and cached-result eligibility, giving the agent a clearer sense of when to expect charges. This exceeds the baseline for high schema coverage.
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 uses a specific verb 'Read' with a clear resource: 'high-volume open BTC, ETH, and crypto Polymarket markets with current outcome probabilities and market context.' It further narrows scope with 'Event-probability data only; not a recommendation,' and the crypto focus differentiates it from broader siblings like otto_pm_markets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than explicit: the description signals when to use the tool (for high-volume open BTC/ETH/crypto Polymarket markets) and provides a boundary ('not a recommendation'). However, it does not name alternatives or state when NOT to use this tool versus sibling tools like otto_pm_markets or otto_crypto_news.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
otto_pm_marketsOtto prediction-market contextARead-onlyIdempotentInspect
Read the highest-volume open Polymarket markets with live outcome probabilities, bid/ask context, liquidity, volume, and end dates. Event-probability context only; not a recommendation. Hosted access: the first eligible cached intelligence result is free; otherwise calls cost $0.001 USDC through x402.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| x_payment | No | Signed x402 payment payload. Omit it to receive the machine-actionable payment challenge, then retry with the signed payload. |
TDQS
A3.8/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior, and the description aligns with those. It adds valuable behavioral context beyond annotations: the cost model, the free first cached result, x402 payment requirement, and the disclaimer that this is event-probability context only.
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?
Three sentences with no redundancy: the first states the data scope, the second sets expectations, and the third explains cost. The most decision-relevant facts are front-loaded.
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 simple, read-only tool with one optional parameter and no output schema, the description covers the key output fields and the payment behavior. It lacks exact output formatting and details on "eligible cached intelligence," but those are minor given the tool's simplicity.
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?
Schema description coverage is 100% for the single optional x_payment parameter, so the schema already documents the payment flow. The description adds cost-related context but no additional parameter syntax or format, matching the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: "Read the highest-volume open Polymarket markets" with concrete data fields like probabilities, liquidity, volume, and end dates. It clearly conveys the tool's core purpose, though it does not explicitly differentiate itself from sibling tools like otto_pm_crypto.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by covering live event-probability data and explicitly states "not a recommendation." However, it does not say when to prefer this tool over siblings or when not to use it, leaving some routing decisions to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
otto_prepare_bridgePrepare an Otto-attributed LI.FI cross-chain USDC bridgeARead-onlyInspect
Prepare, decode, and verify an unsigned cross-chain native-USDC bridge construction aid for the caller-owned EOA or Safe, over the enumerated v1 Circle-CCTP route set (Ethereum, Polygon, Base, Arbitrum, Avalanche); any other chain, token, or bridge route is refused by name. The envelope's valid_until bounds freshness and is committed to the artifact digest; the signer account nonce is the on-chain replay boundary, and this tool cannot guarantee single execution. Returns ordered allowance-reset, approval, and call steps on the source chain only; never signs or submits. 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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| toToken | Yes | Native USDC on the destination chain; the v1 bridge route set is USDC-only. | |
| slippage | Yes | ||
| fromToken | Yes | Native USDC on the source chain; the v1 bridge route set is USDC-only. | |
| toChainId | Yes | ||
| client_ref | No | ||
| fromAmount | Yes | Exact gross input amount in atomic token units. | |
| fromChainId | Yes | ||
| accountProfile | Yes | ||
| destinationRecipient | No | Where the destination mint lands. Optional for an EOA, whose address is identical on every EVM chain; REQUIRED for a Safe, whose address is not guaranteed to be the same contract on the destination chain. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| rail | Yes | |
| payload | Yes | |
| operation | Yes | |
| assertions | Yes | |
| submission | Yes | |
| artifact_id | Yes | |
| valid_until | Yes | |
| intent_digest | Yes | |
| schema_version | Yes | |
| account_binding | Yes | |
| fee_attribution | Yes | |
| replay_disclosure | Yes | |
| required_capabilities | Yes |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses that the tool never signs or submits, returns only source-chain steps, cannot guarantee single execution due to nonce boundaries, and issues envelopes valid for 300 seconds after which the verifier rejects them. These are material behavioral caveats that align with readOnlyHint=true and idempotentHint=false.
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 dense and front-loaded with the core action, and the later sentences add necessary constraints and caveats rather than filler. It is longer than minimal but appropriate for a high-risk bridging operation; only slight redundancy around valid_until/stale-envelope exists.
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 the nine parameters, nested objects, safety annotations, and an output schema, the description covers the essential operational context: route set, chain/token refusal, EOA/Safe recipient behavior, non-execution guarantee, replay risk, and envelope freshness. Nothing critical is left unexplained for a caller to safely request a bridge construction.
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?
With only 44% schema coverage, the description compensates by clarifying that tokens are native USDC, amounts are exact gross atomic units, chains are restricted to the enumerated set, and destinationRecipient is optional for EOAs but required for Safes. Some params still rely on schema names, but the key non-obvious meanings are covered.
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 names a specific action ('Prepare, decode, and verify') on a specific resource ('unsigned cross-chain native-USDC bridge construction aid') and bounds it to the v1 Circle-CCTP route set. It also states the concrete deliverable (ordered allowance-reset, approval, and call steps on the source chain), making it easy to distinguish from the swap/perp prepare 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?
It gives clear eligibility signals: caller-owned EOA or Safe, native USDC only, only the five listed chains, and explicitly refuses any other chain/token/bridge route. It does not, however, point to a sibling tool for out-of-scope cases, so the when-not guidance is complete but alternative routing is left to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
otto_prepare_perp_orderPrepare an unsigned Hyperliquid perp order L1 actionARead-onlyInspect
Prepare and verify an unsigned Hyperliquid perpetuals order (limit, with optional reduce-only take-profit and stop-loss triggers bundled as normalTpsl) for the caller-owned Hyperliquid account, returned as the canonical L1 action plus the exact EIP-712 Agent domain, struct, and connectionId recipe the caller's own signer needs. The asset id, size grid, and price grid come from the live perp universe: an unknown or delisted perp, a size finer than the asset's szDecimals, or a price off the venue's 5-significant-digit / (6 - szDecimals) decimal grid is refused by name rather than rounded to a different order. There is no market order — name your own aggressive limit price with 'Ioc'. Otto's builder attribution is spec'd and valueless today, so the action carries no builder field and the envelope says so. The nonce is chosen by the signer, never here; the envelope's valid_until is committed to the artifact digest AND placed inside the signed digest as expiresAfter, so the venue itself rejects a stale action, while the Hyperliquid signer nonce remains the replay boundary and this tool cannot guarantee single execution. This tool never signs or submits, holds no key, and derives no agent wallet. 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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| side | Yes | ||
| size | Yes | Order size in base units, e.g. '0.01'. At most szDecimals fractional digits for this perp. | |
| asset | Yes | Perp symbol exactly as the venue names it, e.g. 'BTC', 'kPEPE'. Case-sensitive. | |
| client_ref | No | ||
| limitPrice | Yes | Limit price. Must sit on the venue grid: at most 5 significant digits unless integer, and at most (6 - szDecimals) decimals. | |
| reduceOnly | No | ||
| timeInForce | No | Gtc rests, Ioc fills-or-cancels, Alo posts only. There is no market order: name your own aggressive limit price with 'Ioc' instead. | Gtc |
| vaultAddress | No | Trade on behalf of this vault or sub-account. A declared profile fact only. | |
| stopLossPrice | No | Optional reduce-only market stop-loss trigger, bundled with grouping normalTpsl. | |
| tradingSigner | No | The address that will sign, when it is not the master account itself: a user-held approved API wallet. Declared, never derived. | |
| accountProfile | Yes | The Hyperliquid master account. `chainId` must be 1337, the signature chain id Hyperliquid pins for every L1 action. | |
| takeProfitPrice | No | Optional reduce-only market take-profit trigger, bundled with grouping normalTpsl. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| rail | Yes | |
| payload | Yes | |
| operation | Yes | |
| assertions | Yes | |
| submission | Yes | |
| artifact_id | Yes | |
| valid_until | Yes | |
| intent_digest | Yes | |
| schema_version | Yes | |
| account_binding | Yes | |
| fee_attribution | Yes | |
| replay_disclosure | Yes | |
| required_capabilities | Yes |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and non-destructive, and the description strongly reinforces this by stating it never signs, submits, holds a key, or derives a wallet. It adds valuable context beyond annotations: 300-second envelope validity, stale-envelope rejection, signer-chosen nonce, valid_until mapped to expiresAfter, and the absence of a single-execution guarantee. None of this contradicts the 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, covering purpose, validation behavior, signing responsibilities, timeouts, and exclusions. The core purpose and most important constraint are front-loaded before the detailed behavioral warnings. Given the complexity of the tool, this length is justified rather than bloated.
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?
With a rich input schema, annotations, and an output schema present, the description still adds essential invocation context: live perp universe validation, nonce ownership, envelope expiry, builder-field omission, and the never-signing guarantee. The combination of description plus structured data is sufficient for an agent to call the tool correctly.
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%, and the description adds meaningful validation context: unknown or delisted perps are refused, size must honor szDecimals, and price must sit on the venue's significant-digit grid. It also clarifies the Ioc-as-market-order substitute and the accountProfile chainId constraint. Some parameters like client_ref still rely on schema alone, but the description clearly exceeds the 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 opens with a specific verb and resource: prepare and verify an unsigned Hyperliquid perpetuals order, and explicitly states what is returned (canonical L1 action plus EIP-712 recipe). It is unmistakably differentiated from sibling tools like prepare_swap, prepare_bridge, and prepare_polymarket_order by naming the Hyperliquid perp domain and the exact signing artifacts.
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 gives strong operational guidance: there is no market order, so the caller should use an aggressive limit price with 'Ioc', and stale envelopes should be replaced with fresh ones. It does not explicitly name alternative sibling tools or say 'use X instead', but the domain and constraints are clear enough that an agent can decide when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
otto_prepare_polymarket_orderPrepare an Otto-attributed Polymarket CLOB limit orderARead-onlyInspect
Prepare and verify an unsigned Polymarket CTF Exchange V2 limit order (GTC) for the caller-owned Polygon EOA, with Otto's builder code stamped inside the EIP-712 order struct and re-asserted on the exact digest the signer will sign. The price must be an exact multiple of the market's live minimum tick size and the size at or above its published minimum. The envelope's valid_until bounds freshness and is committed to the artifact digest; the exchange's own order hash is the replay boundary, and this tool cannot guarantee single execution. Returns order args and typed data only; never signs or submits, holds no CLOB credentials, and touches no collateral or allowance. 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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| side | Yes | ||
| size | Yes | Order size in outcome-token shares. | |
| price | Yes | Limit price as a probability, e.g. '0.045'. Must be an exact multiple of the market's minimum tick size. | |
| tokenId | Yes | Outcome-token id (NOT the condition id): YES and NO are different token ids. | |
| client_ref | No | ||
| accountProfile | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| rail | Yes | |
| payload | Yes | |
| operation | Yes | |
| assertions | Yes | |
| submission | Yes | |
| artifact_id | Yes | |
| valid_until | Yes | |
| intent_digest | Yes | |
| schema_version | Yes | |
| account_binding | Yes | |
| fee_attribution | Yes | |
| replay_disclosure | Yes | |
| required_capabilities | Yes |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses meaningful behavioral details: no signing, no submission, no CLOB credentials, no collateral touching, 300-second envelope validity, replay-boundary semantics, and no single-execution guarantee. This substantially helps the agent set expectations and avoid misuse.
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 front-loaded with the primary purpose. Every sentence carries essential operational or safety context; minor verbosity around 'stamped' and 're-asserted' keeps it from being maximally concise.
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 nested objects, an output schema, and complex exchange-specific constraints, the description covers what the tool returns, what it never does, freshness requirements, validation rules, and replay boundaries. An agent has enough context to call it safely and correctly.
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?
With only 50% schema description coverage, the prose adds important parameter-level semantics: price must be an exact multiple of the live minimum tick size, size must meet the published minimum, and token IDs are outcome-specific. It does not fully elaborate on client_ref or accountProfile, but the schema already documents several parameters and the added constraints are high-value.
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 names a highly specific verb-resource pair: prepare and verify an unsigned Polymarket CTF Exchange V2 limit order. It is immediately distinguishable from sibling tools like otto_prepare_swap, otto_prepare_perp_order, and otto_prepare_bridge by naming the exact exchange and order type.
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 clearly conveys the context: this only prepares and verifies order data, never signs or submits, and requires a fresh envelope within 300 seconds. It does not explicitly name alternatives or when-not-to-use conditions, but the specialized domain and non-goals give an agent enough context to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
otto_prepare_stock_buyPrepare a tokenized-stock buy (Coinbase B20 on Base) as a delegable swap pairARead-onlyInspect
Prepare the EXACT otto_prepare_swap pair (envelope + prepareInput) that buys one of the executable Coinbase B20 tokenized equities on Base with USDC, as a LI.FI route through the fenced diamond whose receiver is the signing account. The token comes from the registry row named by executableEquityId and is never an input; the caller's registryCommitment must equal the commitment recomputed over the current record. The WORST PERMISSIBLE FILL (amount over the route's own floor) is checked against the equity's own Chainlink total-return mark and refused when it exceeds the pinned tolerance, or when the feed is frozen (> 24 h). 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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | Exact USDC amount to spend, in atomic units (6 decimals). | |
| slippage | Yes | ||
| client_ref | No | ||
| accountProfile | Yes | ||
| executableEquityId | Yes | The executable equity id the READ half served, e.g. b20-nvda (Coinbase B20 on Base only). | |
| 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
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| preview | Yes | |
| envelope | Yes | |
| prepareInput | Yes | |
| registry_commitment | Yes |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint/destructiveHint annotations, the description discloses refusal conditions (worst-permissible-fill over pinned tolerance, frozen feed >24h, stale commitment), the 300-second envelope expiry, that the token is never an input, that it never signs or submits, and that it returns the pair unchanged plus a preview. There is no contradiction with annotations; the idempotentHint=false aligns with the fresh-envelope requirement.
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?
Although long, every clause carries operational weight — mechanism, validation rules, failure modes, return shape, follow-up tool, and expiry policy. The structure is logical and front-loaded with the core purpose, with no filler and no redundant restating of schema text.
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 security-sensitive, delegation-aware tool with nested parameters and an output schema, this is a complete operational contract: it covers what is produced, what is refused and why, the 300s validity window, the non-mutating guarantee, and the required next step. Nothing an agent needs to call it correctly 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?
With 50% schema coverage, the description adds real meaning to the domain-critical parameters: executableEquityId names a registry row and is never the token input, registryCommitment must equal the commitment recomputed over the current record, and amount/slippage feed into the worst-permissible-fill check against the equity's Chainlink mark. accountProfile and client_ref remain undocumented in both schema and description, which prevents a 5.
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 opening sentence names a specific verb ('prepare'), a precise resource (the otto_prepare_swap envelope + prepareInput pair), and a narrow scope (Coinbase B20 tokenized equities on Base bought with USDC via a LI.FI route through the fenced diamond). This unambiguously differentiates it from siblings such as otto_prepare_swap, otto_prepare_bridge, and otto_prepare_perp_order without needing to open their schemas.
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 gives clear operational context: the tool only prepares and previews, the pair must be submitted via otto_submit_under_delegation under the end user's per-swap cap, and a fresh envelope must be requested when one goes stale. It stops short of explicitly stating when NOT to use this versus the generic otto_prepare_swap, though the B20-only scope and 'never an input' phrasing make that exclusion largely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
otto_prepare_swapPrepare an Otto-attributed LI.FI swapARead-onlyInspect
Prepare, decode, and verify an unsigned same-chain EVM ERC20 swap construction aid for the caller-owned EOA or Safe. The envelope's valid_until bounds freshness and is committed to the artifact digest; the signer account nonce is the on-chain replay boundary, and this tool cannot guarantee single execution. Returns ordered allowance-reset, approval, and call steps only; never signs or submits. 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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| chainId | Yes | ||
| toToken | Yes | ERC20 output token address; native-token routes are out of v1. | |
| slippage | Yes | ||
| fromToken | Yes | ERC20 input token address; native-token routes are out of v1. | |
| client_ref | No | ||
| fromAmount | Yes | Exact input amount in atomic token units. | |
| accountProfile | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| rail | Yes | |
| payload | Yes | |
| operation | Yes | |
| assertions | Yes | |
| submission | Yes | |
| artifact_id | Yes | |
| valid_until | Yes | |
| intent_digest | Yes | |
| schema_version | Yes | |
| account_binding | Yes | |
| fee_attribution | Yes | |
| replay_disclosure | Yes | |
| required_capabilities | Yes |
TDQS
A3.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides rich behavioral detail beyond the readOnlyHint annotation: it never signs or submits, returns only ordered steps, has a 300-second validity window, and is committed to an envelope digest with nonce as replay boundary. It also notes inability to guarantee single execution, which complements the openWorldHint. This goes well beyond the basic annotation.
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 dense but not verbose; it front-loads the core purpose and then layers critical behavioral constraints (validity, nonce, no signing, stale refusal). Each sentence adds value, and the 4-sentence length is appropriate for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, nested objects, output schema exists), the description provides strong behavioral context but omits parameter-level guidance entirely. It explains the envelope lifecycle and return format but does not help an agent understand what inputs mean or how they map to the output. The output schema partially offsets this, but a description for a complex tool like this should cover parameter intent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 43%, so the description must compensate for unexplained parameters. It does not explain accountProfile, slippage, chainId, client_ref, or fromAmount semantics beyond what the schema already says. The description focuses on envelope freshness and nonce, not on input parameters, leaving significant ambiguity for an agent.
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 ('prepare, decode, verify') and resource ('same-chain EVM ERC20 swap construction aid') and distinguishes it from sibling tools like bridge or perp order by explicitly saying 'same-chain' and 'swap'. It clearly identifies what the tool does and for whom (caller-owned EOA or Safe).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for same-chain ERC20 swaps and mentions it's for the 'caller-owned EOA or Safe', but it does not explicitly name alternatives or state when not to use this tool. There is no direct contrast with the bridge, perp, or polymarket sibling tools, so guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
otto_prepare_yield_depositPrepare a Yield Copilot vault deposit (Morpho USDC on Base) as a delegable swap pairARead-onlyInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| 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
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| preview | Yes | |
| envelope | Yes | |
| prepareInput | Yes | |
| registry_commitment | Yes |
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.
otto_prepare_yield_withdrawPrepare a Yield Copilot vault withdraw (Morpho USDC on Base) as a delegable swap pairARead-onlyInspect
Prepare the EXACT otto_prepare_swap pair (envelope + prepareInput) that redeems vault shares from one of the executable Morpho vaults in the Yield Copilot registry back to USDC in the signing account, as a LI.FI exit route (which may sell shares or compose a protocol redemption) whose input token is the vault's ERC-4626 share token. The vault and the asset come from the registry row named by executableMarketId and are never inputs; the caller's registryCommitment must equal the commitment recomputed over the current record. The quoted USDC is checked against the vault's own previewRedeem and refused when it falls 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, which admits a withdraw only under fence v2 and a permission minted under cap ruleset v2, values it at zero against the per-swap cap (it returns the person's own assets), and bounds it by the engine's share 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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| shares | Yes | ||
| slippage | Yes | ||
| client_ref | No | ||
| accountProfile | Yes | ||
| executableMarketId | Yes | ||
| registryCommitment | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| preview | Yes | |
| envelope | Yes | |
| prepareInput | Yes | |
| registry_commitment | Yes |
TDQS
A4.3/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, openWorld, non-idempotent, non-destructive), and the description adds substantial non-obvious behavior: the previewRedeem cross-check with a pinned tolerance refusal, the registryCommitment recomputation requirement, the 300-second envelope validity window, and how the withdraw is valued (zero against the per-swap cap) and bounded (engine share cap). This is far more than the annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded, but the text is a single dense paragraph that mixes construction semantics, safety checks, submission routing, and cap rules into one run-on block, and repeats the otto_prepare_swap framing. Everything roughly earns its place, yet the lack of structure makes it harder to scan than it needs to be.
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?
An output schema exists, so return values need not be described, and the description still supplies the prerequisites (registry commitment match, previewRedeem tolerance), the lifecycle constraint (300s validity), and the downstream submission path. For a prepare-only tool, nothing an agent needs to invoke it correctly is missing.
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?
Schema description coverage is 0%, so the description must carry the burden. It explains executableMarketId (names the registry row supplying vault and asset) and registryCommitment (must equal the recomputed commitment) and alludes to the slippage tolerance, but shares, accountProfile, slippage.maxBps bounds, and client_ref are left entirely to the schema's structural constraints.
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?
States a specific verb+resource (prepare the swap pair that redeems Yield Copilot Morpho vault shares back to USDC), names the exact artifact produced (envelope + prepareInput), and pins the route type (LI.FI exit whose input token is the ERC-4626 share token). An agent can distinguish it from otto_prepare_swap and otto_prepare_yield_deposit from the text alone.
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?
Explicitly routes the agent: the returned pair must be submitted through otto_submit_under_delegation, and it states the operation is admitted only under fence v2 with a cap-ruleset-v2 permission. However, it never states when NOT to use this tool (e.g. versus a direct swap or deposit), so the alternative-selection is implied rather than fully spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
otto_rh_seasonOtto Robinhood Chain seasonARead-onlyIdempotentInspect
Scan rug-screened Robinhood Chain (4663) movers with honeypot filters and per-token risk flags. Market context only; not a pick, recommendation, or trade instruction. Hosted access: the first eligible cached intelligence result is free; otherwise calls cost $0.001 USDC through x402.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| x_payment | No | Signed x402 payment payload. Omit it to receive the machine-actionable payment challenge, then retry with the signed payload. |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and idempotentHint annotations, the description discloses the payment model: first eligible cached result is free, otherwise calls cost $0.001 USDC via x402. It also clarifies the output is market context only, which helps prevent misuse.
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?
Three sentences cover function, scope, risk flags, caveat, and cost model with no filler. The core purpose is front-loaded, and every sentence adds decision-relevant information.
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?
The description is sufficient for a one-optional-parameter read-only tool with strong annotations: it explains what is scanned, what filters and flags are applied, the non-advice nature, and the payment behavior. The only notable gap is the lack of any output-shape or result-format detail, which prevents a 5.
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?
Schema description coverage is 100%, and the x_payment parameter is already well documented in the schema with the challenge/retry flow. The tool description adds cost and caching context, but that is not essential to understanding the parameter semantics themselves, so the baseline score of 3 is appropriate.
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 uses a specific verb ('Scan') and identifies the exact resource: rug-screened Robinhood Chain (4663) movers with honeypot filters and per-token risk flags. This clearly distinguishes it from sibling chain season tools like otto_base_season.
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 clearly frames when this is appropriate: when you need market context on Robinhood Chain movers. It also provides an explicit when-not by stating it is 'not a pick, recommendation, or trade instruction,' though it does not name alternative sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
otto_sponsored_accountReview or recover an account transactionBDestructiveInspect
Protected account action: availability, prepare, reviewGas for current gas payer and estimate, explicit submit, owned read or reconcile. Gas refresh is read-only planning and requires new confirmation before any send. Wallet upgrade is separate. Sponsorship requires a reviewed source activation; current availability is authoritative. A missing submission response is unknown and must never cause a replacement submission.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| gas | No | |
| input | No | |
| state | No | |
| terms | No | |
| output | No | |
| reason | No | |
| status | No | |
| account | No | |
| chainId | No | |
| ottoFee | No | |
| receipt | No | |
| attention | No | |
| configured | No | |
| settlement | No | |
| userOpHash | No | |
| failureCode | No | |
| operationId | No | |
| validUntilMs | No | |
| schemaVersion | Yes | |
| reviewConsumed | No | |
| transactionHash | No | |
| executionEnabled | No | |
| reviewCommitment | No | |
| recoveryAvailable | No | |
| replacementPermitted | No | |
| requiresReconciliation | No | |
| requiresOperationReview | No | |
| automaticExecutionEnabled | No | |
| supportedSameAddressChains | No | |
| requiresSeparateWalletUpgrade | No | |
| walletAuthorityChangeIncluded | No |
TDQS
B3.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (destructive, non-idempotent, open-world), so the bar is lower, and the description adds real value beyond them: gas refresh is a read-only planning step requiring fresh confirmation, and critically 'a missing submission response is unknown and must never cause a replacement submission.' That idempotency caution is exactly the kind of hazard disclosure annotations can't express.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a dense, list-like block with no wasted filler and the protected-action framing is front-loaded, but it reads as terse internal jargon rather than structure an agent can parse order-of-operations from.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values needn't be explained, and annotations carry the safety profile. What remains unclear for a complex multi-mode mutation tool is how the agent selects a mode and what each requires, which the description only partially covers.
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?
The schema declares zero parameters (empty properties, additionalProperties true), so baseline is 4. The description compensates somewhat by naming the action modes that function as an implicit selector, though it never states that selection is how inputs are chosen.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies this as a 'Protected account action' and enumerates modes (availability, prepare, reviewGas, submit, owned read, reconcile), so the agent knows the domain. But it is opaque jargon that never cleanly states the resource or verb, and it does not distinguish this multiplexed tool from the many otto_* siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives some routing: 'Gas refresh is read-only planning and requires new confirmation before any send' and 'Wallet upgrade is separate', which steers the agent away from a related action. However, it never names an alternative tool or states explicit when-not conditions for the remaining modes, leaving usage largely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
otto_stock_poolsOtto tokenized-stock pool discoveryARead-onlyIdempotentInspect
Find the DEX pools a tokenized US stock or ETF is actually a member of, on Robinhood Chain, Base, BNB Chain or Solana. Returns each pool id (Uniswap v4 pool ids kept distinct from v3 pool addresses), DEX and version, which side the asset is on, the counterpart token with an evidence-backed classification (verified stock, verified stablecoin, or unclassified), reported USD liquidity and 24h volume, 24h transaction count, pool creation time, and the source coverage limits. Membership discovery only: a provider-covered observation rather than a complete census, no APR and no execution support, and the asset’s own 24h return is reported only from pools where it is the base token. Identify the asset by address when a ticker names two deployments on one chain — that spelling is refused rather than resolved to one of them. Not a pairing recommendation. Hosted access: the first eligible cached intelligence result is free; otherwise calls cost $0.001 USDC through x402.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| stock | Yes | Network-qualified tokenized-stock identity: "<network>:<TICKER>" or "<network>:<token address>", where network is robinhood, base, bsc or solana. Example: robinhood:MU. A bare ticker is rejected, and so is a ticker that names two deployments on one chain — give the token address for those. | |
| x_payment | No | Signed x402 payment payload. Omit it to receive the machine-actionable payment challenge, then retry with the signed payload. |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark read-only/open-world/idempotent, and the description adds substantial behavioral context beyond them: source-coverage limits, ambiguous-ticker refusal, base-token-only return reporting, hosted-access pricing, and x402 challenge flow. No contradiction with annotations.
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 and dense, but almost every sentence adds a distinct operational detail or caveat. It front-loads the core purpose before layering constraints, though a tighter structure would improve scanability.
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?
With no output schema, the description compensates by enumerating returned fields, edge cases (ambiguous tickers, base-token-only returns), coverage limits, and payment mechanics. An agent has enough information to call the tool correctly.
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 100%, so baseline is 3. The description adds valuable semantics around the stock parameter, especially the ticker-vs-address ambiguity rule and the x_payment challenge-and-retry behavior, exceeding what the schema alone states.
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 ('Find') and resource ('DEX pools a tokenized US stock or ETF is actually a member of'), and enumerates exactly what is returned. It also draws boundaries against sibling concerns such as APR and execution, making its purpose distinct.
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 gives strong when-not guidance: it is membership discovery only, not a complete census, and not a pairing recommendation. It does not name a specific alternative sibling tool, but the exclusions are clear enough for an agent to avoid misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
otto_submit_under_delegationSubmit an Otto-prepared swap under a CDP end-user delegationADestructiveInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| fence | Yes | |
| steps | Yes | |
| status | Yes | |
| address | Yes | |
| user_id | Yes | |
| chain_id | Yes | |
| replayed | No | |
| delegation | Yes | |
| artifact_id | Yes | |
| verification | Yes |
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.
otto_tokenized_equitiesOtto tokenized equitiesARead-onlyIdempotentInspect
Scan the live registry of US equities and ETFs tokenized on Robinhood Chain (4663): symbol, canonical token address, decimals, the executable buy price a live route returns, the catalog reference price and the deviation between them, plus a verifiable tradability signal. An optional thesis returns a relevance-ranked shortlist with a match reason per row. Data only; not a recommendation or executable quote. Hosted access: the first eligible cached intelligence result is free; otherwise calls cost $0.001 USDC through x402.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| thesis | No | Natural-language screening thesis, for example "AI infrastructure chips". | |
| x_payment | No | Signed x402 payment payload. Omit it to receive the machine-actionable payment challenge, then retry with the signed payload. |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the core safety profile is covered. The description adds meaningful behavioral context beyond annotations: it explicitly states 'Data only; not a recommendation or executable quote,' discloses the cost model ($0.001 USDC via x402) and that the first cached result is free, and describes the live nature of the registry. This goes beyond what annotations alone provide.
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 concise, about three sentences, and front-loads the core purpose and data fields. It avoids redundancy and every sentence adds value: purpose/data list, optional thesis behavior, and cost/disclaimer. No filler or unnecessary elaboration.
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 tool with only two optional parameters, 100% schema coverage, no output schema, and read-only/idempotent/non-destructive annotations, the description is exceptionally complete. It specifies the exact data returned, the optional thesis behavior, cost, and the data-only nature. An agent has everything needed to decide to call it and to understand its output expectations.
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?
The schema provides 100% description coverage for both parameters, with clear definitions for 'thesis' and 'x_payment'. The description adds extra semantic value: it explains that an optional thesis yields a relevance-ranked shortlist with a match reason per row, and it provides context on the payment mechanism ('calls cost $0.001 USDC through x402'). These details enrich the parameter meaning beyond the schema's basic definitions.
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 clear verb ('Scan'), a specific resource (live registry of US equities and ETFs tokenized on Robinhood Chain), and enumerates the exact data returned (symbol, token address, decimals, prices, tradability). It also distinguishes itself from sibling tools by focusing on tokenized equities and clarifying it is data-only, not a recommendation or executable quote. This fully differentiates it from tools like otto_equity_intel.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (to scan the tokenized equities registry) and mentions the optional thesis for a relevance-ranked shortlist, but it does not explicitly state when to use this tool over alternatives or when not to use it. No sibling tools are named or contrasted. The 'Data only' disclaimer sets expectations but does not guide selection among the many otto_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
otto_x_recipesotto x layer recipesARead-onlyIdempotentInspect
Return Otto X's live X Layer recipe menu — each recipe's path, price, and the X Layer (eip155:196) payment requirement decoded from its unpaid 402 challenge: token asset, issuer name/version, payTo, and a copy-paste curl. Settles in USD₮0 / USD Coin / Global Dollar on X Layer via the PAYMENT-SIGNATURE header. Always free and read-only; never signs or pays and does not consume the free intelligence call.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and non-destructive, and the description adds substantial behavioral detail: it decodes unpaid 402 challenges, identifies settlement currencies and the PAYMENT-SIGNATURE header, never signs or pays, and does not consume the free intelligence call. This goes well beyond the structured hints without contradicting them.
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 main action is front-loaded in the first sentence, and every subsequent clause adds necessary detail about payment requirements, settlement assets, and safety behavior. There is no filler, and the description is information-dense without being bloated.
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?
With no output schema, the description carries the burden of explaining what the agent will receive, and it does: each recipe's path, price, token asset, issuer name/version, payTo, and a copy-paste curl, plus settlement context. Given zero parameters and rich annotations, nothing essential 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?
The tool accepts zero parameters and the schema fully captures that with an empty properties object and additionalProperties false. Since there are no parameters to document, the description does not need to add parameter semantics; the baseline of 4 applies.
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: 'Return Otto X's live X Layer recipe menu.' It enumerates the returned fields (path, price, payment requirement, token asset, issuer, payTo, curl), making the tool's purpose unambiguous and distinguishing it from sibling tools like otto_catalog or otto_prepare_*.
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 gives clear context: the tool is always free, read-only, never signs or pays, and does not consume the free intelligence call, so an agent knows when it is safe to invoke. It does not explicitly name alternatives or when-not conditions, but the unique recipe-menu scope provides sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
- Added
otto_crypto_news - Added
otto_news_recaps
1 tool update
- Changed
otto_stock_pools1 field changed- changed
Input schema / properties / stock / descriptionPrevious value: -"Network-qualified tokenized-stock identity: \"<network>:<TICKER>\" or \"<network>:<token address>\", where network is robinhood, base, bsc or solana. Example: robinhood:MU. A bare ticker is rejected, and so is a ticker that names two deployments on one chain (eight Solana tickers exist on both xStocks and Backpack) — give the token address for those."New value: +"Network-qualified tokenized-stock identity: \"<network>:<TICKER>\" or \"<network>:<token address>\", where network is robinhood, base, bsc or solana. Example: robinhood:MU. A bare ticker is rejected, and so is a ticker that names two deployments on one chain — give the token address for those."
3 tool updates
- Changed
otto_lp_collect_userop8 fields changed- removed
Output schema / properties / confirmation / constRemoved value: -"I reviewed this position collection and sponsored atomic batch" - added
Output schema / properties / confirmation / enumAdded value: +[ + "I reviewed this position collection and sponsored atomic batch", + "I reviewed this position collection and account-paid atomic batch" +] - removed
Output schema / properties / gas / additionalPropertiesRemoved value: -false - added
Output schema / properties / gas / oneOfAdded value: +[ + { + "additionalProperties": false, + "properties": { + "activationChainHalted": { + "const": true, + "type": "boolean" + }, + "actualCostWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]{0,77})$", + "type": "string" + }, + "maximumActivationCostWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]{0,77})$", + "type": "string" + }, + "maximumCostWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]{0,77})$", + "type": "string" + }, + "maximumUserCostWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]{0,77})$", + "type": "string" + }, + "payer": { + "const": "sponsor", + "type": "string" + }, + "paymentReview": { + "additionalProperties": false, + "properties": { + "payer": { + "enum": [ + "sponsor", + "account" + ], + "type": "string" + }, + "quote": { + "additionalProperties": false, + "properties": { + "account": { + "pattern": "^0x[0-9a-f]{40}$", + "type": "string" + }, + "balance": { + "additionalProperties": false, + "properties": { + "callValueWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "depositAppliedToGasWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "entryPointDepositWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "gasShortfallWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "nativeAvailableForGasWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "nativeWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "requiredNativeWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "shortfallWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "walletGasRequirementWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + } + }, + "required": [ + "nativeWei", + "entryPointDepositWei", + "callValueWei", + "depositAppliedToGasWei", + "walletGasRequirementWei", + "nativeAvailableForGasWei", + "gasShortfallWei", + "requiredNativeWei", + "shortfallWei" + ], + "type": "object" + }, + "blockHash": { + "pattern": "^0x[0-9a-f]{64}$", + "type": "string" + }, + "blockNumber": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "blockTimestampMs": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "callsCommitment": { + "pattern": "^[0-9a-f]{64}$", + "type": "string" + }, + "chainId": { + "anyOf": [ + { + "const": 1, + "type": "number" + }, + { + "const": 8453, + "type": "number" + }, + { + "const": 42161, + "type": "number" + }, + { + "const": 10, + "type": "number" + }, + { + "const": 137, + "type": "number" + } + ] + }, + "entryPoint": { + "pattern": "^0x[0-9a-f]{40}$", + "type": "string" + }, + "estimatedGasCostUsdMicros": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "expiresAtMs": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "gas": { + "additionalProperties": false, + "properties": { + "callGasLimit": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "estimatedPrefundWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "estimatedRequiredWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "maxFeePerGasWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "maxPriorityFeePerGasWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "preVerificationGas": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "reserveBps": { + "const": "2500", + "type": "string" + }, + "reserveWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "verificationGasLimit": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + } + }, + "required": [ + "callGasLimit", + "verificationGasLimit", + "preVerificationGas", + "maxFeePerGasWei", + "maxPriorityFeePerGasWei", + "estimatedPrefundWei", + "reserveWei", + "estimatedRequiredWei", + "reserveBps" + ], + "type": "object" + }, + "kind": { + "const": "estimate", + "type": "string" + }, + "nativeAsset": { + "additionalProperties": false, + "properties": { + "decimals": { + "const": 18, + "type": "number" + }, + "symbol": { + "enum": [ + "ETH", + "POL" + ], + "type": "string" + } + }, + "required": [ + "symbol", + "decimals" + ], + "type": "object" + }, + "nonce": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "observedAtMs": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "payer": { + "const": "user", + "type": "string" + }, + "providerEstimate": { + "additionalProperties": false, + "properties": { + "blockAnchor": { + "const": "unanchored", + "type": "string" + }, + "completedAtMs": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "elapsedMs": { + "maximum": 30000, + "minimum": 0, + "type": "number" + }, + "startedAtMs": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + } + }, + "required": [ + "blockAnchor", + "startedAtMs", + "completedAtMs", + "elapsedMs" + ], + "type": "object" + }, + "simulation": { + "const": "sender-balance-override", + "type": "string" + }, + "sponsoredEstimate": { + "additionalProperties": false, + "properties": { + "entryPointVersion": { + "const": "0.6", + "type": "string" + }, + "estimatedGasCostUsdMicros": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "gas": { + "additionalProperties": false, + "properties": { + "callGasLimit": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "estimatedPrefundWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "estimatedRequiredWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "maxFeePerGasWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "maxPriorityFeePerGasWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "preVerificationGas": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "reserveBps": { + "const": "2500", + "type": "string" + }, + "reserveWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "verificationGasLimit": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "verificationGasMultiplier": { + "const": "3", + "type": "string" + } + }, + "required": [ + "callGasLimit", + "verificationGasLimit", + "preVerificationGas", + "maxFeePerGasWei", + "maxPriorityFeePerGasWei", + "verificationGasMultiplier", + "estimatedPrefundWei", + "reserveWei", + "estimatedRequiredWei", + "reserveBps" + ], + "type": "object" + }, + "kind": { + "const": "estimate", + "type": "string" + }, + "paymaster": { + "pattern": "^0x[0-9a-f]{40}$", + "type": "string" + }, + "paymasterAndDataCommitment": { + "pattern": "^[0-9a-f]{64}$", + "type": "string" + }, + "providerEstimate": { + "additionalProperties": false, + "properties": { + "blockAnchor": { + "const": "unanchored", + "type": "string" + }, + "completedAtMs": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "elapsedMs": { + "maximum": 30000, + "minimum": 0, + "type": "number" + }, + "startedAtMs": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + } + }, + "required": [ + "blockAnchor", + "startedAtMs", + "completedAtMs", + "elapsedMs" + ], + "type": "object" + }, + "simulation": { + "const": "paymaster-stub", + "type": "string" + }, + "sponsorshipPolicyId": { + "pattern": "^[a-zA-Z0-9_-]{1,128}$", + "type": "string" + } + }, + "required": [ + "kind", + "simulation", + "entryPointVersion", + "paymaster", + "sponsorshipPolicyId", + "paymasterAndDataCommitment", + "providerEstimate", + "gas" + ], + "type": "object" + }, + "usdPrice": { + "additionalProperties": false, + "properties": { + "amountAtomic": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "decimals": { + "maximum": 77, + "minimum": 0, + "type": "integer" + }, + "expiresAtMs": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "observedAtMs": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + } + }, + "required": [ + "amountAtomic", + "decimals", + "observedAtMs", + "expiresAtMs" + ], + "type": "object" + }, + "version": { + "const": 1, + "type": "number" + } + }, + "required": [ + "version", + "kind", + "payer", + "account", + "chainId", + "entryPoint", + "nativeAsset", + "callsCommitment", + "nonce", + "blockNumber", + "blockHash", + "blockTimestampMs", + "observedAtMs", + "expiresAtMs", + "simulation", + "providerEstimate", + "gas", + "balance" + ], + "type": "object" + }, + "revision": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "sponsorStatus": { + "enum": [ + "eligible", + "above-limit", + "unavailable", + "price-unavailable" + ], + "type": "string" + }, + "subsidyCapUsdMicros": { + "const": "100000", + "type": "string" + }, + "version": { + "const": 1, + "type": "number" + } + }, + "required": [ + "version", + "revision", + "payer", + "sponsorStatus", + "subsidyCapUsdMicros", + "quote" + ], + "type": "object" + }, + "reviewFailure": { + "enum": [ + "ACCOUNT_GAS_REVIEW_REQUIRED", + "ACCOUNT_GAS_REVIEW_CHANGED", + "ACCOUNT_GAS_REVIEW_STALE", + "ACCOUNT_GAS_REVIEW_UNAVAILABLE", + "ACCOUNT_GAS_REVIEW_INVALID", + "ACCOUNT_GAS_FUNDING_REQUIRED", + "ACCOUNT_GAS_SPONSOR_INELIGIBLE", + "ACCOUNT_GAS_QUOTE_UNAVAILABLE" + ], + "type": "string" + }, + "reviewRequired": { + "const": true, + "type": "boolean" + } + }, + "required": [ + "payer", + "maximumCostWei", + "maximumUserCostWei", + "maximumActivationCostWei" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "actualCostWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]{0,77})$", + "type": "string" + }, + "payer": { + "const": "account", + "type": "string" + }, + "paymentReview": { + "additionalProperties": false, + "properties": { + "payer": { + "enum": [ + "sponsor", + "account" + ], + "type": "string" + }, + "quote": { + "additionalProperties": false, + "properties": { + "account": { + "pattern": "^0x[0-9a-f]{40}$", + "type": "string" + }, + "balance": { + "additionalProperties": false, + "properties": { + "callValueWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "depositAppliedToGasWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "entryPointDepositWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "gasShortfallWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "nativeAvailableForGasWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "nativeWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "requiredNativeWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "shortfallWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "walletGasRequirementWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + } + }, + "required": [ + "nativeWei", + "entryPointDepositWei", + "callValueWei", + "depositAppliedToGasWei", + "walletGasRequirementWei", + "nativeAvailableForGasWei", + "gasShortfallWei", + "requiredNativeWei", + "shortfallWei" + ], + "type": "object" + }, + "blockHash": { + "pattern": "^0x[0-9a-f]{64}$", + "type": "string" + }, + "blockNumber": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "blockTimestampMs": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "callsCommitment": { + "pattern": "^[0-9a-f]{64}$", + "type": "string" + }, + "chainId": { + "anyOf": [ + { + "const": 1, + "type": "number" + }, + { + "const": 8453, + "type": "number" + }, + { + "const": 42161, + "type": "number" + }, + { + "const": 10, + "type": "number" + }, + { + "const": 137, + "type": "number" + } + ] + }, + "entryPoint": { + "pattern": "^0x[0-9a-f]{40}$", + "type": "string" + }, + "estimatedGasCostUsdMicros": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "expiresAtMs": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "gas": { + "additionalProperties": false, + "properties": { + "callGasLimit": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "estimatedPrefundWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "estimatedRequiredWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "maxFeePerGasWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "maxPriorityFeePerGasWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "preVerificationGas": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "reserveBps": { + "const": "2500", + "type": "string" + }, + "reserveWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "verificationGasLimit": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + } + }, + "required": [ + "callGasLimit", + "verificationGasLimit", + "preVerificationGas", + "maxFeePerGasWei", + "maxPriorityFeePerGasWei", + "estimatedPrefundWei", + "reserveWei", + "estimatedRequiredWei", + "reserveBps" + ], + "type": "object" + }, + "kind": { + "const": "estimate", + "type": "string" + }, + "nativeAsset": { + "additionalProperties": false, + "properties": { + "decimals": { + "const": 18, + "type": "number" + }, + "symbol": { + "enum": [ + "ETH", + "POL" + ], + "type": "string" + } + }, + "required": [ + "symbol", + "decimals" + ], + "type": "object" + }, + "nonce": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "observedAtMs": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "payer": { + "const": "user", + "type": "string" + }, + "providerEstimate": { + "additionalProperties": false, + "properties": { + "blockAnchor": { + "const": "unanchored", + "type": "string" + }, + "completedAtMs": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "elapsedMs": { + "maximum": 30000, + "minimum": 0, + "type": "number" + }, + "startedAtMs": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + } + }, + "required": [ + "blockAnchor", + "startedAtMs", + "completedAtMs", + "elapsedMs" + ], + "type": "object" + }, + "simulation": { + "const": "sender-balance-override", + "type": "string" + }, + "sponsoredEstimate": { + "additionalProperties": false, + "properties": { + "entryPointVersion": { + "const": "0.6", + "type": "string" + }, + "estimatedGasCostUsdMicros": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "gas": { + "additionalProperties": false, + "properties": { + "callGasLimit": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "estimatedPrefundWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "estimatedRequiredWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "maxFeePerGasWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "maxPriorityFeePerGasWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "preVerificationGas": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "reserveBps": { + "const": "2500", + "type": "string" + }, + "reserveWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "verificationGasLimit": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "verificationGasMultiplier": { + "const": "3", + "type": "string" + } + }, + "required": [ + "callGasLimit", + "verificationGasLimit", + "preVerificationGas", + "maxFeePerGasWei", + "maxPriorityFeePerGasWei", + "verificationGasMultiplier", + "estimatedPrefundWei", + "reserveWei", + "estimatedRequiredWei", + "reserveBps" + ], + "type": "object" + }, + "kind": { + "const": "estimate", + "type": "string" + }, + "paymaster": { + "pattern": "^0x[0-9a-f]{40}$", + "type": "string" + }, + "paymasterAndDataCommitment": { + "pattern": "^[0-9a-f]{64}$", + "type": "string" + }, + "providerEstimate": { + "additionalProperties": false, + "properties": { + "blockAnchor": { + "const": "unanchored", + "type": "string" + }, + "completedAtMs": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "elapsedMs": { + "maximum": 30000, + "minimum": 0, + "type": "number" + }, + "startedAtMs": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + } + }, + "required": [ + "blockAnchor", + "startedAtMs", + "completedAtMs", + "elapsedMs" + ], + "type": "object" + }, + "simulation": { + "const": "paymaster-stub", + "type": "string" + }, + "sponsorshipPolicyId": { + "pattern": "^[a-zA-Z0-9_-]{1,128}$", + "type": "string" + } + }, + "required": [ + "kind", + "simulation", + "entryPointVersion", + "paymaster", + "sponsorshipPolicyId", + "paymasterAndDataCommitment", + "providerEstimate", + "gas" + ], + "type": "object" + }, + "usdPrice": { + "additionalProperties": false, + "properties": { + "amountAtomic": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "decimals": { + "maximum": 77, + "minimum": 0, + "type": "integer" + }, + "expiresAtMs": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "observedAtMs": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + } + }, + "required": [ + "amountAtomic", + "decimals", + "observedAtMs", + "expiresAtMs" + ], + "type": "object" + }, + "version": { + "const": 1, + "type": "number" + } + }, + "required": [ + "version", + "kind", + "payer", + "account", + "chainId", + "entryPoint", + "nativeAsset", + "callsCommitment", + "nonce", + "blockNumber", + "blockHash", + "blockTimestampMs", + "observedAtMs", + "expiresAtMs", + "simulation", + "providerEstimate", + "gas", + "balance" + ], + "type": "object" + }, + "revision": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "sponsorStatus": { + "enum": [ + "eligible", + "above-limit", + "unavailable", + "price-unavailable" + ], + "type": "string" + }, + "subsidyCapUsdMicros": { + "const": "100000", + "type": "string" + }, + "version": { + "const": 1, + "type": "number" + } + }, + "required": [ + "version", + "revision", + "payer", + "sponsorStatus", + "subsidyCapUsdMicros", + "quote" + ], + "type": "object" + }, + "reviewFailure": { + "enum": [ + "ACCOUNT_GAS_REVIEW_REQUIRED", + "ACCOUNT_GAS_REVIEW_CHANGED", + "ACCOUNT_GAS_REVIEW_STALE", + "ACCOUNT_GAS_REVIEW_UNAVAILABLE", + "ACCOUNT_GAS_REVIEW_INVALID", + "ACCOUNT_GAS_FUNDING_REQUIRED", + "ACCOUNT_GAS_SPONSOR_INELIGIBLE", + "ACCOUNT_GAS_QUOTE_UNAVAILABLE" + ], + "type": "string" + }, + "reviewRequired": { + "const": true, + "type": "boolean" + } + }, + "required": [ + "payer", + "paymentReview" + ], + "type": "object" + } +] - removed
Output schema / properties / gas / propertiesRemoved value: -{ - "activationChainHalted": { - "const": true, - "type": "boolean" - }, - "actualCostWei": { - "maxLength": 78, - "pattern": "^(0|[1-9][0-9]{0,77})$", - "type": "string" - }, - "maximumActivationCostWei": { - "maxLength": 78, - "pattern": "^(0|[1-9][0-9]{0,77})$", - "type": "string" - }, - "maximumCostWei": { - "maxLength": 78, - "pattern": "^(0|[1-9][0-9]{0,77})$", - "type": "string" - }, - "maximumUserCostWei": { - "maxLength": 78, - "pattern": "^(0|[1-9][0-9]{0,77})$", - "type": "string" - }, - "payer": { - "const": "sponsor", - "type": "string" - } -} - removed
Output schema / properties / gas / requiredRemoved value: -[ - "payer", - "maximumCostWei", - "maximumUserCostWei", - "maximumActivationCostWei" -] - removed
Output schema / properties / gas / typeRemoved value: -"object" - changed
Output schema / properties / reason / enumPrevious value: -[ - "SPONSOR_ACTIVATION_UNCONFIGURED", - "SPONSOR_ACTIVATION_UNAVAILABLE", - "SPONSOR_RECOVERY_ONLY", - "SPONSOR_CAPABILITY_UNAVAILABLE", - "SPONSOR_RUNTIME_UNAVAILABLE", - "SPONSOR_JOURNAL_UNAVAILABLE", - "SPONSOR_REQUEST_INVALID", - "SPONSOR_REQUEST_REFUSED", - "SPONSOR_SESSION_REQUIRED", - "SPONSOR_SESSION_INVALID", - "SPONSOR_OWNER_MISMATCH", - "SPONSOR_EXPLICIT_WALLET_UPGRADE_REQUIRED", - "SPONSOR_CURRENT_GRANT_REQUIRED", - "SPONSOR_CAP_UNAVAILABLE", - "SPONSOR_POLICY_CHANGED", - "SPONSOR_CHAIN_UNAVAILABLE", - "SPONSOR_ACCOUNT_PROOF_UNAVAILABLE", - "SPONSOR_ACCOUNT_PROOF_MISMATCH", - "SPONSOR_INPUT_OUTSIDE_REVIEWED_CAP", - "SPONSOR_REVIEW_AUTHORITY_CHANGED", - "SPONSOR_REVIEW_EXPIRED", - "SPONSOR_STOP_OR_CAP_CHANGED", - "SPONSOR_BALANCE_INSUFFICIENT", - "SPONSOR_OUTPUT_TOKEN_UNREVIEWED", - "SPONSOR_BUDGET_HALTED", - "SPONSOR_NOT_SUBMITTED", - "SPONSOR_USER_OPERATION_REVERTED", - "SPONSOR_GAS_CAP_EXCEEDED" -]New value: +[ + "SPONSOR_ACTIVATION_UNCONFIGURED", + "SPONSOR_ACTIVATION_UNAVAILABLE", + "SPONSOR_RECOVERY_ONLY", + "SPONSOR_CAPABILITY_UNAVAILABLE", + "SPONSOR_RUNTIME_UNAVAILABLE", + "SPONSOR_JOURNAL_UNAVAILABLE", + "SPONSOR_REQUEST_INVALID", + "SPONSOR_REQUEST_REFUSED", + "SPONSOR_SESSION_REQUIRED", + "SPONSOR_SESSION_INVALID", + "SPONSOR_OWNER_MISMATCH", + "SPONSOR_EXPLICIT_WALLET_UPGRADE_REQUIRED", + "SPONSOR_CURRENT_GRANT_REQUIRED", + "SPONSOR_CAP_UNAVAILABLE", + "SPONSOR_POLICY_CHANGED", + "SPONSOR_CHAIN_UNAVAILABLE", + "SPONSOR_ACCOUNT_PROOF_UNAVAILABLE", + "SPONSOR_ACCOUNT_PROOF_MISMATCH", + "SPONSOR_INPUT_OUTSIDE_REVIEWED_CAP", + "SPONSOR_REVIEW_AUTHORITY_CHANGED", + "SPONSOR_REVIEW_EXPIRED", + "SPONSOR_STOP_OR_CAP_CHANGED", + "SPONSOR_BALANCE_INSUFFICIENT", + "SPONSOR_OUTPUT_TOKEN_UNREVIEWED", + "SPONSOR_BUDGET_HALTED", + "SPONSOR_NOT_SUBMITTED", + "SPONSOR_USER_OPERATION_REVERTED", + "SPONSOR_GAS_CAP_EXCEEDED", + "ACCOUNT_GAS_REVIEW_REQUIRED", + "ACCOUNT_GAS_REVIEW_CHANGED", + "ACCOUNT_GAS_REVIEW_STALE", + "ACCOUNT_GAS_REVIEW_UNAVAILABLE", + "ACCOUNT_GAS_REVIEW_INVALID", + "ACCOUNT_GAS_FUNDING_REQUIRED", + "ACCOUNT_GAS_SPONSOR_INELIGIBLE", + "ACCOUNT_GAS_QUOTE_UNAVAILABLE" +]
- Changed
otto_native_yield_userop8 fields changed- removed
Output schema / properties / confirmation / constRemoved value: -"I reviewed this native yield action and sponsored atomic batch" - added
Output schema / properties / confirmation / enumAdded value: +[ + "I reviewed this native yield action and sponsored atomic batch", + "I reviewed this native yield action and account-paid atomic batch" +] - removed
Output schema / properties / gas / additionalPropertiesRemoved value: -false - added
Output schema / properties / gas / oneOfAdded value: +[ + { + "additionalProperties": false, + "properties": { + "activationChainHalted": { + "const": true, + "type": "boolean" + }, + "actualCostWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "maximumActivationCostWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "maximumCostWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "maximumUserCostWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "payer": { + "const": "sponsor", + "type": "string" + }, + "paymentReview": { + "additionalProperties": false, + "properties": { + "payer": { + "enum": [ + "sponsor", + "account" + ], + "type": "string" + }, + "quote": { + "additionalProperties": false, + "properties": { + "account": { + "pattern": "^0x[0-9a-f]{40}$", + "type": "string" + }, + "balance": { + "additionalProperties": false, + "properties": { + "callValueWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "depositAppliedToGasWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "entryPointDepositWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "gasShortfallWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "nativeAvailableForGasWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "nativeWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "requiredNativeWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "shortfallWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "walletGasRequirementWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + } + }, + "required": [ + "nativeWei", + "entryPointDepositWei", + "callValueWei", + "depositAppliedToGasWei", + "walletGasRequirementWei", + "nativeAvailableForGasWei", + "gasShortfallWei", + "requiredNativeWei", + "shortfallWei" + ], + "type": "object" + }, + "blockHash": { + "pattern": "^0x[0-9a-f]{64}$", + "type": "string" + }, + "blockNumber": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "blockTimestampMs": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "callsCommitment": { + "pattern": "^[0-9a-f]{64}$", + "type": "string" + }, + "chainId": { + "anyOf": [ + { + "const": 1, + "type": "number" + }, + { + "const": 8453, + "type": "number" + }, + { + "const": 42161, + "type": "number" + }, + { + "const": 10, + "type": "number" + }, + { + "const": 137, + "type": "number" + } + ] + }, + "entryPoint": { + "pattern": "^0x[0-9a-f]{40}$", + "type": "string" + }, + "estimatedGasCostUsdMicros": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "expiresAtMs": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "gas": { + "additionalProperties": false, + "properties": { + "callGasLimit": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "estimatedPrefundWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "estimatedRequiredWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "maxFeePerGasWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "maxPriorityFeePerGasWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "preVerificationGas": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "reserveBps": { + "const": "2500", + "type": "string" + }, + "reserveWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "verificationGasLimit": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + } + }, + "required": [ + "callGasLimit", + "verificationGasLimit", + "preVerificationGas", + "maxFeePerGasWei", + "maxPriorityFeePerGasWei", + "estimatedPrefundWei", + "reserveWei", + "estimatedRequiredWei", + "reserveBps" + ], + "type": "object" + }, + "kind": { + "const": "estimate", + "type": "string" + }, + "nativeAsset": { + "additionalProperties": false, + "properties": { + "decimals": { + "const": 18, + "type": "number" + }, + "symbol": { + "enum": [ + "ETH", + "POL" + ], + "type": "string" + } + }, + "required": [ + "symbol", + "decimals" + ], + "type": "object" + }, + "nonce": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "observedAtMs": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "payer": { + "const": "user", + "type": "string" + }, + "providerEstimate": { + "additionalProperties": false, + "properties": { + "blockAnchor": { + "const": "unanchored", + "type": "string" + }, + "completedAtMs": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "elapsedMs": { + "maximum": 30000, + "minimum": 0, + "type": "number" + }, + "startedAtMs": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + } + }, + "required": [ + "blockAnchor", + "startedAtMs", + "completedAtMs", + "elapsedMs" + ], + "type": "object" + }, + "simulation": { + "const": "sender-balance-override", + "type": "string" + }, + "sponsoredEstimate": { + "additionalProperties": false, + "properties": { + "entryPointVersion": { + "const": "0.6", + "type": "string" + }, + "estimatedGasCostUsdMicros": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "gas": { + "additionalProperties": false, + "properties": { + "callGasLimit": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "estimatedPrefundWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "estimatedRequiredWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "maxFeePerGasWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "maxPriorityFeePerGasWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "preVerificationGas": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "reserveBps": { + "const": "2500", + "type": "string" + }, + "reserveWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "verificationGasLimit": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "verificationGasMultiplier": { + "const": "3", + "type": "string" + } + }, + "required": [ + "callGasLimit", + "verificationGasLimit", + "preVerificationGas", + "maxFeePerGasWei", + "maxPriorityFeePerGasWei", + "verificationGasMultiplier", + "estimatedPrefundWei", + "reserveWei", + "estimatedRequiredWei", + "reserveBps" + ], + "type": "object" + }, + "kind": { + "const": "estimate", + "type": "string" + }, + "paymaster": { + "pattern": "^0x[0-9a-f]{40}$", + "type": "string" + }, + "paymasterAndDataCommitment": { + "pattern": "^[0-9a-f]{64}$", + "type": "string" + }, + "providerEstimate": { + "additionalProperties": false, + "properties": { + "blockAnchor": { + "const": "unanchored", + "type": "string" + }, + "completedAtMs": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "elapsedMs": { + "maximum": 30000, + "minimum": 0, + "type": "number" + }, + "startedAtMs": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + } + }, + "required": [ + "blockAnchor", + "startedAtMs", + "completedAtMs", + "elapsedMs" + ], + "type": "object" + }, + "simulation": { + "const": "paymaster-stub", + "type": "string" + }, + "sponsorshipPolicyId": { + "pattern": "^[a-zA-Z0-9_-]{1,128}$", + "type": "string" + } + }, + "required": [ + "kind", + "simulation", + "entryPointVersion", + "paymaster", + "sponsorshipPolicyId", + "paymasterAndDataCommitment", + "providerEstimate", + "gas" + ], + "type": "object" + }, + "usdPrice": { + "additionalProperties": false, + "properties": { + "amountAtomic": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "decimals": { + "maximum": 77, + "minimum": 0, + "type": "integer" + }, + "expiresAtMs": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "observedAtMs": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + } + }, + "required": [ + "amountAtomic", + "decimals", + "observedAtMs", + "expiresAtMs" + ], + "type": "object" + }, + "version": { + "const": 1, + "type": "number" + } + }, + "required": [ + "version", + "kind", + "payer", + "account", + "chainId", + "entryPoint", + "nativeAsset", + "callsCommitment", + "nonce", + "blockNumber", + "blockHash", + "blockTimestampMs", + "observedAtMs", + "expiresAtMs", + "simulation", + "providerEstimate", + "gas", + "balance" + ], + "type": "object" + }, + "revision": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "sponsorStatus": { + "enum": [ + "eligible", + "above-limit", + "unavailable", + "price-unavailable" + ], + "type": "string" + }, + "subsidyCapUsdMicros": { + "const": "100000", + "type": "string" + }, + "version": { + "const": 1, + "type": "number" + } + }, + "required": [ + "version", + "revision", + "payer", + "sponsorStatus", + "subsidyCapUsdMicros", + "quote" + ], + "type": "object" + }, + "reviewFailure": { + "enum": [ + "ACCOUNT_GAS_REVIEW_REQUIRED", + "ACCOUNT_GAS_REVIEW_CHANGED", + "ACCOUNT_GAS_REVIEW_STALE", + "ACCOUNT_GAS_REVIEW_UNAVAILABLE", + "ACCOUNT_GAS_REVIEW_INVALID", + "ACCOUNT_GAS_FUNDING_REQUIRED", + "ACCOUNT_GAS_SPONSOR_INELIGIBLE", + "ACCOUNT_GAS_QUOTE_UNAVAILABLE" + ], + "type": "string" + }, + "reviewRequired": { + "const": true, + "type": "boolean" + } + }, + "required": [ + "payer", + "maximumCostWei", + "maximumUserCostWei", + "maximumActivationCostWei" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "actualCostWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "payer": { + "const": "account", + "type": "string" + }, + "paymentReview": { + "additionalProperties": false, + "properties": { + "payer": { + "enum": [ + "sponsor", + "account" + ], + "type": "string" + }, + "quote": { + "additionalProperties": false, + "properties": { + "account": { + "pattern": "^0x[0-9a-f]{40}$", + "type": "string" + }, + "balance": { + "additionalProperties": false, + "properties": { + "callValueWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "depositAppliedToGasWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "entryPointDepositWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "gasShortfallWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "nativeAvailableForGasWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "nativeWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "requiredNativeWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "shortfallWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "walletGasRequirementWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + } + }, + "required": [ + "nativeWei", + "entryPointDepositWei", + "callValueWei", + "depositAppliedToGasWei", + "walletGasRequirementWei", + "nativeAvailableForGasWei", + "gasShortfallWei", + "requiredNativeWei", + "shortfallWei" + ], + "type": "object" + }, + "blockHash": { + "pattern": "^0x[0-9a-f]{64}$", + "type": "string" + }, + "blockNumber": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "blockTimestampMs": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "callsCommitment": { + "pattern": "^[0-9a-f]{64}$", + "type": "string" + }, + "chainId": { + "anyOf": [ + { + "const": 1, + "type": "number" + }, + { + "const": 8453, + "type": "number" + }, + { + "const": 42161, + "type": "number" + }, + { + "const": 10, + "type": "number" + }, + { + "const": 137, + "type": "number" + } + ] + }, + "entryPoint": { + "pattern": "^0x[0-9a-f]{40}$", + "type": "string" + }, + "estimatedGasCostUsdMicros": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "expiresAtMs": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "gas": { + "additionalProperties": false, + "properties": { + "callGasLimit": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "estimatedPrefundWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "estimatedRequiredWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "maxFeePerGasWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "maxPriorityFeePerGasWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "preVerificationGas": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "reserveBps": { + "const": "2500", + "type": "string" + }, + "reserveWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "verificationGasLimit": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + } + }, + "required": [ + "callGasLimit", + "verificationGasLimit", + "preVerificationGas", + "maxFeePerGasWei", + "maxPriorityFeePerGasWei", + "estimatedPrefundWei", + "reserveWei", + "estimatedRequiredWei", + "reserveBps" + ], + "type": "object" + }, + "kind": { + "const": "estimate", + "type": "string" + }, + "nativeAsset": { + "additionalProperties": false, + "properties": { + "decimals": { + "const": 18, + "type": "number" + }, + "symbol": { + "enum": [ + "ETH", + "POL" + ], + "type": "string" + } + }, + "required": [ + "symbol", + "decimals" + ], + "type": "object" + }, + "nonce": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "observedAtMs": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "payer": { + "const": "user", + "type": "string" + }, + "providerEstimate": { + "additionalProperties": false, + "properties": { + "blockAnchor": { + "const": "unanchored", + "type": "string" + }, + "completedAtMs": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "elapsedMs": { + "maximum": 30000, + "minimum": 0, + "type": "number" + }, + "startedAtMs": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + } + }, + "required": [ + "blockAnchor", + "startedAtMs", + "completedAtMs", + "elapsedMs" + ], + "type": "object" + }, + "simulation": { + "const": "sender-balance-override", + "type": "string" + }, + "sponsoredEstimate": { + "additionalProperties": false, + "properties": { + "entryPointVersion": { + "const": "0.6", + "type": "string" + }, + "estimatedGasCostUsdMicros": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "gas": { + "additionalProperties": false, + "properties": { + "callGasLimit": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "estimatedPrefundWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "estimatedRequiredWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "maxFeePerGasWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "maxPriorityFeePerGasWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "preVerificationGas": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "reserveBps": { + "const": "2500", + "type": "string" + }, + "reserveWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "verificationGasLimit": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "verificationGasMultiplier": { + "const": "3", + "type": "string" + } + }, + "required": [ + "callGasLimit", + "verificationGasLimit", + "preVerificationGas", + "maxFeePerGasWei", + "maxPriorityFeePerGasWei", + "verificationGasMultiplier", + "estimatedPrefundWei", + "reserveWei", + "estimatedRequiredWei", + "reserveBps" + ], + "type": "object" + }, + "kind": { + "const": "estimate", + "type": "string" + }, + "paymaster": { + "pattern": "^0x[0-9a-f]{40}$", + "type": "string" + }, + "paymasterAndDataCommitment": { + "pattern": "^[0-9a-f]{64}$", + "type": "string" + }, + "providerEstimate": { + "additionalProperties": false, + "properties": { + "blockAnchor": { + "const": "unanchored", + "type": "string" + }, + "completedAtMs": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "elapsedMs": { + "maximum": 30000, + "minimum": 0, + "type": "number" + }, + "startedAtMs": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + } + }, + "required": [ + "blockAnchor", + "startedAtMs", + "completedAtMs", + "elapsedMs" + ], + "type": "object" + }, + "simulation": { + "const": "paymaster-stub", + "type": "string" + }, + "sponsorshipPolicyId": { + "pattern": "^[a-zA-Z0-9_-]{1,128}$", + "type": "string" + } + }, + "required": [ + "kind", + "simulation", + "entryPointVersion", + "paymaster", + "sponsorshipPolicyId", + "paymasterAndDataCommitment", + "providerEstimate", + "gas" + ], + "type": "object" + }, + "usdPrice": { + "additionalProperties": false, + "properties": { + "amountAtomic": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "decimals": { + "maximum": 77, + "minimum": 0, + "type": "integer" + }, + "expiresAtMs": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "observedAtMs": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + } + }, + "required": [ + "amountAtomic", + "decimals", + "observedAtMs", + "expiresAtMs" + ], + "type": "object" + }, + "version": { + "const": 1, + "type": "number" + } + }, + "required": [ + "version", + "kind", + "payer", + "account", + "chainId", + "entryPoint", + "nativeAsset", + "callsCommitment", + "nonce", + "blockNumber", + "blockHash", + "blockTimestampMs", + "observedAtMs", + "expiresAtMs", + "simulation", + "providerEstimate", + "gas", + "balance" + ], + "type": "object" + }, + "revision": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "sponsorStatus": { + "enum": [ + "eligible", + "above-limit", + "unavailable", + "price-unavailable" + ], + "type": "string" + }, + "subsidyCapUsdMicros": { + "const": "100000", + "type": "string" + }, + "version": { + "const": 1, + "type": "number" + } + }, + "required": [ + "version", + "revision", + "payer", + "sponsorStatus", + "subsidyCapUsdMicros", + "quote" + ], + "type": "object" + }, + "reviewFailure": { + "enum": [ + "ACCOUNT_GAS_REVIEW_REQUIRED", + "ACCOUNT_GAS_REVIEW_CHANGED", + "ACCOUNT_GAS_REVIEW_STALE", + "ACCOUNT_GAS_REVIEW_UNAVAILABLE", + "ACCOUNT_GAS_REVIEW_INVALID", + "ACCOUNT_GAS_FUNDING_REQUIRED", + "ACCOUNT_GAS_SPONSOR_INELIGIBLE", + "ACCOUNT_GAS_QUOTE_UNAVAILABLE" + ], + "type": "string" + }, + "reviewRequired": { + "const": true, + "type": "boolean" + } + }, + "required": [ + "payer", + "paymentReview" + ], + "type": "object" + } +] - removed
Output schema / properties / gas / propertiesRemoved value: -{ - "activationChainHalted": { - "const": true, - "type": "boolean" - }, - "actualCostWei": { - "maxLength": 78, - "pattern": "^(0|[1-9][0-9]*)$", - "type": "string" - }, - "maximumActivationCostWei": { - "maxLength": 78, - "pattern": "^(0|[1-9][0-9]*)$", - "type": "string" - }, - "maximumCostWei": { - "maxLength": 78, - "pattern": "^(0|[1-9][0-9]*)$", - "type": "string" - }, - "maximumUserCostWei": { - "maxLength": 78, - "pattern": "^(0|[1-9][0-9]*)$", - "type": "string" - }, - "payer": { - "const": "sponsor", - "type": "string" - } -} - removed
Output schema / properties / gas / requiredRemoved value: -[ - "payer", - "maximumCostWei", - "maximumUserCostWei", - "maximumActivationCostWei" -] - removed
Output schema / properties / gas / typeRemoved value: -"object" - changed
Output schema / properties / reason / enumPrevious value: -[ - "SPONSOR_ACTIVATION_UNCONFIGURED", - "SPONSOR_ACTIVATION_UNAVAILABLE", - "SPONSOR_RECOVERY_ONLY", - "SPONSOR_CAPABILITY_UNAVAILABLE", - "SPONSOR_RUNTIME_UNAVAILABLE", - "SPONSOR_JOURNAL_UNAVAILABLE", - "SPONSOR_REQUEST_INVALID", - "SPONSOR_REQUEST_REFUSED", - "SPONSOR_SESSION_REQUIRED", - "SPONSOR_SESSION_INVALID", - "SPONSOR_OWNER_MISMATCH", - "SPONSOR_EXPLICIT_WALLET_UPGRADE_REQUIRED", - "SPONSOR_CURRENT_GRANT_REQUIRED", - "SPONSOR_CAP_UNAVAILABLE", - "SPONSOR_POLICY_CHANGED", - "SPONSOR_CHAIN_UNAVAILABLE", - "SPONSOR_ACCOUNT_PROOF_UNAVAILABLE", - "SPONSOR_ACCOUNT_PROOF_MISMATCH", - "SPONSOR_INPUT_OUTSIDE_REVIEWED_CAP", - "SPONSOR_REVIEW_AUTHORITY_CHANGED", - "SPONSOR_REVIEW_EXPIRED", - "SPONSOR_STOP_OR_CAP_CHANGED", - "SPONSOR_BALANCE_INSUFFICIENT", - "SPONSOR_OUTPUT_TOKEN_UNREVIEWED", - "SPONSOR_BUDGET_HALTED", - "SPONSOR_NOT_SUBMITTED", - "SPONSOR_USER_OPERATION_REVERTED", - "SPONSOR_GAS_CAP_EXCEEDED" -]New value: +[ + "SPONSOR_ACTIVATION_UNCONFIGURED", + "SPONSOR_ACTIVATION_UNAVAILABLE", + "SPONSOR_RECOVERY_ONLY", + "SPONSOR_CAPABILITY_UNAVAILABLE", + "SPONSOR_RUNTIME_UNAVAILABLE", + "SPONSOR_JOURNAL_UNAVAILABLE", + "SPONSOR_REQUEST_INVALID", + "SPONSOR_REQUEST_REFUSED", + "SPONSOR_SESSION_REQUIRED", + "SPONSOR_SESSION_INVALID", + "SPONSOR_OWNER_MISMATCH", + "SPONSOR_EXPLICIT_WALLET_UPGRADE_REQUIRED", + "SPONSOR_CURRENT_GRANT_REQUIRED", + "SPONSOR_CAP_UNAVAILABLE", + "SPONSOR_POLICY_CHANGED", + "SPONSOR_CHAIN_UNAVAILABLE", + "SPONSOR_ACCOUNT_PROOF_UNAVAILABLE", + "SPONSOR_ACCOUNT_PROOF_MISMATCH", + "SPONSOR_INPUT_OUTSIDE_REVIEWED_CAP", + "SPONSOR_REVIEW_AUTHORITY_CHANGED", + "SPONSOR_REVIEW_EXPIRED", + "SPONSOR_STOP_OR_CAP_CHANGED", + "SPONSOR_BALANCE_INSUFFICIENT", + "SPONSOR_OUTPUT_TOKEN_UNREVIEWED", + "SPONSOR_BUDGET_HALTED", + "SPONSOR_NOT_SUBMITTED", + "SPONSOR_USER_OPERATION_REVERTED", + "SPONSOR_GAS_CAP_EXCEEDED", + "ACCOUNT_GAS_REVIEW_REQUIRED", + "ACCOUNT_GAS_REVIEW_CHANGED", + "ACCOUNT_GAS_REVIEW_STALE", + "ACCOUNT_GAS_REVIEW_UNAVAILABLE", + "ACCOUNT_GAS_REVIEW_INVALID", + "ACCOUNT_GAS_FUNDING_REQUIRED", + "ACCOUNT_GAS_SPONSOR_INELIGIBLE", + "ACCOUNT_GAS_QUOTE_UNAVAILABLE" +]
- Changed
otto_sponsored_account7 fields changed- changed
Output schema / properties / failureCode / enumPrevious value: -[ - "SPONSOR_ACTIVATION_UNCONFIGURED", - "SPONSOR_ACTIVATION_UNAVAILABLE", - "SPONSOR_RECOVERY_ONLY", - "SPONSOR_CAPABILITY_UNAVAILABLE", - "SPONSOR_RUNTIME_UNAVAILABLE", - "SPONSOR_JOURNAL_UNAVAILABLE", - "SPONSOR_REQUEST_INVALID", - "SPONSOR_REQUEST_REFUSED", - "SPONSOR_SESSION_REQUIRED", - "SPONSOR_SESSION_INVALID", - "SPONSOR_OWNER_MISMATCH", - "SPONSOR_EXPLICIT_WALLET_UPGRADE_REQUIRED", - "SPONSOR_CURRENT_GRANT_REQUIRED", - "SPONSOR_CAP_UNAVAILABLE", - "SPONSOR_POLICY_CHANGED", - "SPONSOR_CHAIN_UNAVAILABLE", - "SPONSOR_ACCOUNT_PROOF_UNAVAILABLE", - "SPONSOR_ACCOUNT_PROOF_MISMATCH", - "SPONSOR_INPUT_OUTSIDE_REVIEWED_CAP", - "SPONSOR_REVIEW_AUTHORITY_CHANGED", - "SPONSOR_REVIEW_EXPIRED", - "SPONSOR_STOP_OR_CAP_CHANGED", - "SPONSOR_BALANCE_INSUFFICIENT", - "SPONSOR_OUTPUT_TOKEN_UNREVIEWED", - "SPONSOR_BUDGET_HALTED", - "SPONSOR_NOT_SUBMITTED", - "SPONSOR_USER_OPERATION_REVERTED", - "SPONSOR_GAS_CAP_EXCEEDED" -]New value: +[ + "SPONSOR_ACTIVATION_UNCONFIGURED", + "SPONSOR_ACTIVATION_UNAVAILABLE", + "SPONSOR_RECOVERY_ONLY", + "SPONSOR_CAPABILITY_UNAVAILABLE", + "SPONSOR_RUNTIME_UNAVAILABLE", + "SPONSOR_JOURNAL_UNAVAILABLE", + "SPONSOR_REQUEST_INVALID", + "SPONSOR_REQUEST_REFUSED", + "SPONSOR_SESSION_REQUIRED", + "SPONSOR_SESSION_INVALID", + "SPONSOR_OWNER_MISMATCH", + "SPONSOR_EXPLICIT_WALLET_UPGRADE_REQUIRED", + "SPONSOR_CURRENT_GRANT_REQUIRED", + "SPONSOR_CAP_UNAVAILABLE", + "SPONSOR_POLICY_CHANGED", + "SPONSOR_CHAIN_UNAVAILABLE", + "SPONSOR_ACCOUNT_PROOF_UNAVAILABLE", + "SPONSOR_ACCOUNT_PROOF_MISMATCH", + "SPONSOR_INPUT_OUTSIDE_REVIEWED_CAP", + "SPONSOR_REVIEW_AUTHORITY_CHANGED", + "SPONSOR_REVIEW_EXPIRED", + "SPONSOR_STOP_OR_CAP_CHANGED", + "SPONSOR_BALANCE_INSUFFICIENT", + "SPONSOR_OUTPUT_TOKEN_UNREVIEWED", + "SPONSOR_BUDGET_HALTED", + "SPONSOR_NOT_SUBMITTED", + "SPONSOR_USER_OPERATION_REVERTED", + "SPONSOR_GAS_CAP_EXCEEDED", + "ACCOUNT_GAS_REVIEW_REQUIRED", + "ACCOUNT_GAS_REVIEW_CHANGED", + "ACCOUNT_GAS_REVIEW_STALE", + "ACCOUNT_GAS_REVIEW_UNAVAILABLE", + "ACCOUNT_GAS_REVIEW_INVALID", + "ACCOUNT_GAS_FUNDING_REQUIRED", + "ACCOUNT_GAS_SPONSOR_INELIGIBLE", + "ACCOUNT_GAS_QUOTE_UNAVAILABLE" +] - removed
Output schema / properties / gas / additionalPropertiesRemoved value: -false - added
Output schema / properties / gas / oneOfAdded value: +[ + { + "additionalProperties": false, + "properties": { + "activationChainHalted": { + "const": true, + "type": "boolean" + }, + "actualCostWei": { + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "maximumCostWei": { + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "payer": { + "const": "sponsor", + "type": "string" + }, + "paymentReview": { + "additionalProperties": false, + "properties": { + "payer": { + "enum": [ + "sponsor", + "account" + ], + "type": "string" + }, + "quote": { + "additionalProperties": false, + "properties": { + "account": { + "pattern": "^0x[0-9a-f]{40}$", + "type": "string" + }, + "balance": { + "additionalProperties": false, + "properties": { + "callValueWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "depositAppliedToGasWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "entryPointDepositWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "gasShortfallWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "nativeAvailableForGasWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "nativeWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "requiredNativeWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "shortfallWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "walletGasRequirementWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + } + }, + "required": [ + "nativeWei", + "entryPointDepositWei", + "callValueWei", + "depositAppliedToGasWei", + "walletGasRequirementWei", + "nativeAvailableForGasWei", + "gasShortfallWei", + "requiredNativeWei", + "shortfallWei" + ], + "type": "object" + }, + "blockHash": { + "pattern": "^0x[0-9a-f]{64}$", + "type": "string" + }, + "blockNumber": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "blockTimestampMs": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "callsCommitment": { + "pattern": "^[0-9a-f]{64}$", + "type": "string" + }, + "chainId": { + "anyOf": [ + { + "const": 1, + "type": "number" + }, + { + "const": 8453, + "type": "number" + }, + { + "const": 42161, + "type": "number" + }, + { + "const": 10, + "type": "number" + }, + { + "const": 137, + "type": "number" + } + ] + }, + "entryPoint": { + "pattern": "^0x[0-9a-f]{40}$", + "type": "string" + }, + "estimatedGasCostUsdMicros": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "expiresAtMs": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "gas": { + "additionalProperties": false, + "properties": { + "callGasLimit": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "estimatedPrefundWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "estimatedRequiredWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "maxFeePerGasWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "maxPriorityFeePerGasWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "preVerificationGas": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "reserveBps": { + "const": "2500", + "type": "string" + }, + "reserveWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "verificationGasLimit": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + } + }, + "required": [ + "callGasLimit", + "verificationGasLimit", + "preVerificationGas", + "maxFeePerGasWei", + "maxPriorityFeePerGasWei", + "estimatedPrefundWei", + "reserveWei", + "estimatedRequiredWei", + "reserveBps" + ], + "type": "object" + }, + "kind": { + "const": "estimate", + "type": "string" + }, + "nativeAsset": { + "additionalProperties": false, + "properties": { + "decimals": { + "const": 18, + "type": "number" + }, + "symbol": { + "enum": [ + "ETH", + "POL" + ], + "type": "string" + } + }, + "required": [ + "symbol", + "decimals" + ], + "type": "object" + }, + "nonce": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "observedAtMs": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "payer": { + "const": "user", + "type": "string" + }, + "providerEstimate": { + "additionalProperties": false, + "properties": { + "blockAnchor": { + "const": "unanchored", + "type": "string" + }, + "completedAtMs": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "elapsedMs": { + "maximum": 30000, + "minimum": 0, + "type": "number" + }, + "startedAtMs": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + } + }, + "required": [ + "blockAnchor", + "startedAtMs", + "completedAtMs", + "elapsedMs" + ], + "type": "object" + }, + "simulation": { + "const": "sender-balance-override", + "type": "string" + }, + "sponsoredEstimate": { + "additionalProperties": false, + "properties": { + "entryPointVersion": { + "const": "0.6", + "type": "string" + }, + "estimatedGasCostUsdMicros": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "gas": { + "additionalProperties": false, + "properties": { + "callGasLimit": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "estimatedPrefundWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "estimatedRequiredWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "maxFeePerGasWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "maxPriorityFeePerGasWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "preVerificationGas": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "reserveBps": { + "const": "2500", + "type": "string" + }, + "reserveWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "verificationGasLimit": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "verificationGasMultiplier": { + "const": "3", + "type": "string" + } + }, + "required": [ + "callGasLimit", + "verificationGasLimit", + "preVerificationGas", + "maxFeePerGasWei", + "maxPriorityFeePerGasWei", + "verificationGasMultiplier", + "estimatedPrefundWei", + "reserveWei", + "estimatedRequiredWei", + "reserveBps" + ], + "type": "object" + }, + "kind": { + "const": "estimate", + "type": "string" + }, + "paymaster": { + "pattern": "^0x[0-9a-f]{40}$", + "type": "string" + }, + "paymasterAndDataCommitment": { + "pattern": "^[0-9a-f]{64}$", + "type": "string" + }, + "providerEstimate": { + "additionalProperties": false, + "properties": { + "blockAnchor": { + "const": "unanchored", + "type": "string" + }, + "completedAtMs": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "elapsedMs": { + "maximum": 30000, + "minimum": 0, + "type": "number" + }, + "startedAtMs": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + } + }, + "required": [ + "blockAnchor", + "startedAtMs", + "completedAtMs", + "elapsedMs" + ], + "type": "object" + }, + "simulation": { + "const": "paymaster-stub", + "type": "string" + }, + "sponsorshipPolicyId": { + "pattern": "^[a-zA-Z0-9_-]{1,128}$", + "type": "string" + } + }, + "required": [ + "kind", + "simulation", + "entryPointVersion", + "paymaster", + "sponsorshipPolicyId", + "paymasterAndDataCommitment", + "providerEstimate", + "gas" + ], + "type": "object" + }, + "usdPrice": { + "additionalProperties": false, + "properties": { + "amountAtomic": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "decimals": { + "maximum": 77, + "minimum": 0, + "type": "integer" + }, + "expiresAtMs": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "observedAtMs": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + } + }, + "required": [ + "amountAtomic", + "decimals", + "observedAtMs", + "expiresAtMs" + ], + "type": "object" + }, + "version": { + "const": 1, + "type": "number" + } + }, + "required": [ + "version", + "kind", + "payer", + "account", + "chainId", + "entryPoint", + "nativeAsset", + "callsCommitment", + "nonce", + "blockNumber", + "blockHash", + "blockTimestampMs", + "observedAtMs", + "expiresAtMs", + "simulation", + "providerEstimate", + "gas", + "balance" + ], + "type": "object" + }, + "revision": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "sponsorStatus": { + "enum": [ + "eligible", + "above-limit", + "unavailable", + "price-unavailable" + ], + "type": "string" + }, + "subsidyCapUsdMicros": { + "const": "100000", + "type": "string" + }, + "version": { + "const": 1, + "type": "number" + } + }, + "required": [ + "version", + "revision", + "payer", + "sponsorStatus", + "subsidyCapUsdMicros", + "quote" + ], + "type": "object" + }, + "reviewFailure": { + "enum": [ + "ACCOUNT_GAS_REVIEW_REQUIRED", + "ACCOUNT_GAS_REVIEW_CHANGED", + "ACCOUNT_GAS_REVIEW_STALE", + "ACCOUNT_GAS_REVIEW_UNAVAILABLE", + "ACCOUNT_GAS_REVIEW_INVALID", + "ACCOUNT_GAS_FUNDING_REQUIRED", + "ACCOUNT_GAS_SPONSOR_INELIGIBLE", + "ACCOUNT_GAS_QUOTE_UNAVAILABLE" + ], + "type": "string" + }, + "reviewRequired": { + "const": true, + "type": "boolean" + } + }, + "required": [ + "payer", + "maximumCostWei" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "actualCostWei": { + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "payer": { + "const": "account", + "type": "string" + }, + "paymentReview": { + "additionalProperties": false, + "properties": { + "payer": { + "enum": [ + "sponsor", + "account" + ], + "type": "string" + }, + "quote": { + "additionalProperties": false, + "properties": { + "account": { + "pattern": "^0x[0-9a-f]{40}$", + "type": "string" + }, + "balance": { + "additionalProperties": false, + "properties": { + "callValueWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "depositAppliedToGasWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "entryPointDepositWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "gasShortfallWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "nativeAvailableForGasWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "nativeWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "requiredNativeWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "shortfallWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "walletGasRequirementWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + } + }, + "required": [ + "nativeWei", + "entryPointDepositWei", + "callValueWei", + "depositAppliedToGasWei", + "walletGasRequirementWei", + "nativeAvailableForGasWei", + "gasShortfallWei", + "requiredNativeWei", + "shortfallWei" + ], + "type": "object" + }, + "blockHash": { + "pattern": "^0x[0-9a-f]{64}$", + "type": "string" + }, + "blockNumber": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "blockTimestampMs": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "callsCommitment": { + "pattern": "^[0-9a-f]{64}$", + "type": "string" + }, + "chainId": { + "anyOf": [ + { + "const": 1, + "type": "number" + }, + { + "const": 8453, + "type": "number" + }, + { + "const": 42161, + "type": "number" + }, + { + "const": 10, + "type": "number" + }, + { + "const": 137, + "type": "number" + } + ] + }, + "entryPoint": { + "pattern": "^0x[0-9a-f]{40}$", + "type": "string" + }, + "estimatedGasCostUsdMicros": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "expiresAtMs": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "gas": { + "additionalProperties": false, + "properties": { + "callGasLimit": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "estimatedPrefundWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "estimatedRequiredWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "maxFeePerGasWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "maxPriorityFeePerGasWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "preVerificationGas": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "reserveBps": { + "const": "2500", + "type": "string" + }, + "reserveWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "verificationGasLimit": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + } + }, + "required": [ + "callGasLimit", + "verificationGasLimit", + "preVerificationGas", + "maxFeePerGasWei", + "maxPriorityFeePerGasWei", + "estimatedPrefundWei", + "reserveWei", + "estimatedRequiredWei", + "reserveBps" + ], + "type": "object" + }, + "kind": { + "const": "estimate", + "type": "string" + }, + "nativeAsset": { + "additionalProperties": false, + "properties": { + "decimals": { + "const": 18, + "type": "number" + }, + "symbol": { + "enum": [ + "ETH", + "POL" + ], + "type": "string" + } + }, + "required": [ + "symbol", + "decimals" + ], + "type": "object" + }, + "nonce": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "observedAtMs": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "payer": { + "const": "user", + "type": "string" + }, + "providerEstimate": { + "additionalProperties": false, + "properties": { + "blockAnchor": { + "const": "unanchored", + "type": "string" + }, + "completedAtMs": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "elapsedMs": { + "maximum": 30000, + "minimum": 0, + "type": "number" + }, + "startedAtMs": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + } + }, + "required": [ + "blockAnchor", + "startedAtMs", + "completedAtMs", + "elapsedMs" + ], + "type": "object" + }, + "simulation": { + "const": "sender-balance-override", + "type": "string" + }, + "sponsoredEstimate": { + "additionalProperties": false, + "properties": { + "entryPointVersion": { + "const": "0.6", + "type": "string" + }, + "estimatedGasCostUsdMicros": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "gas": { + "additionalProperties": false, + "properties": { + "callGasLimit": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "estimatedPrefundWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "estimatedRequiredWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "maxFeePerGasWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "maxPriorityFeePerGasWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "preVerificationGas": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "reserveBps": { + "const": "2500", + "type": "string" + }, + "reserveWei": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "verificationGasLimit": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "verificationGasMultiplier": { + "const": "3", + "type": "string" + } + }, + "required": [ + "callGasLimit", + "verificationGasLimit", + "preVerificationGas", + "maxFeePerGasWei", + "maxPriorityFeePerGasWei", + "verificationGasMultiplier", + "estimatedPrefundWei", + "reserveWei", + "estimatedRequiredWei", + "reserveBps" + ], + "type": "object" + }, + "kind": { + "const": "estimate", + "type": "string" + }, + "paymaster": { + "pattern": "^0x[0-9a-f]{40}$", + "type": "string" + }, + "paymasterAndDataCommitment": { + "pattern": "^[0-9a-f]{64}$", + "type": "string" + }, + "providerEstimate": { + "additionalProperties": false, + "properties": { + "blockAnchor": { + "const": "unanchored", + "type": "string" + }, + "completedAtMs": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "elapsedMs": { + "maximum": 30000, + "minimum": 0, + "type": "number" + }, + "startedAtMs": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + } + }, + "required": [ + "blockAnchor", + "startedAtMs", + "completedAtMs", + "elapsedMs" + ], + "type": "object" + }, + "simulation": { + "const": "paymaster-stub", + "type": "string" + }, + "sponsorshipPolicyId": { + "pattern": "^[a-zA-Z0-9_-]{1,128}$", + "type": "string" + } + }, + "required": [ + "kind", + "simulation", + "entryPointVersion", + "paymaster", + "sponsorshipPolicyId", + "paymasterAndDataCommitment", + "providerEstimate", + "gas" + ], + "type": "object" + }, + "usdPrice": { + "additionalProperties": false, + "properties": { + "amountAtomic": { + "maxLength": 78, + "pattern": "^(0|[1-9][0-9]*)$", + "type": "string" + }, + "decimals": { + "maximum": 77, + "minimum": 0, + "type": "integer" + }, + "expiresAtMs": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "observedAtMs": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + } + }, + "required": [ + "amountAtomic", + "decimals", + "observedAtMs", + "expiresAtMs" + ], + "type": "object" + }, + "version": { + "const": 1, + "type": "number" + } + }, + "required": [ + "version", + "kind", + "payer", + "account", + "chainId", + "entryPoint", + "nativeAsset", + "callsCommitment", + "nonce", + "blockNumber", + "blockHash", + "blockTimestampMs", + "observedAtMs", + "expiresAtMs", + "simulation", + "providerEstimate", + "gas", + "balance" + ], + "type": "object" + }, + "revision": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "sponsorStatus": { + "enum": [ + "eligible", + "above-limit", + "unavailable", + "price-unavailable" + ], + "type": "string" + }, + "subsidyCapUsdMicros": { + "const": "100000", + "type": "string" + }, + "version": { + "const": 1, + "type": "number" + } + }, + "required": [ + "version", + "revision", + "payer", + "sponsorStatus", + "subsidyCapUsdMicros", + "quote" + ], + "type": "object" + }, + "reviewFailure": { + "enum": [ + "ACCOUNT_GAS_REVIEW_REQUIRED", + "ACCOUNT_GAS_REVIEW_CHANGED", + "ACCOUNT_GAS_REVIEW_STALE", + "ACCOUNT_GAS_REVIEW_UNAVAILABLE", + "ACCOUNT_GAS_REVIEW_INVALID", + "ACCOUNT_GAS_FUNDING_REQUIRED", + "ACCOUNT_GAS_SPONSOR_INELIGIBLE", + "ACCOUNT_GAS_QUOTE_UNAVAILABLE" + ], + "type": "string" + }, + "reviewRequired": { + "const": true, + "type": "boolean" + } + }, + "required": [ + "payer", + "paymentReview" + ], + "type": "object" + } +] - removed
Output schema / properties / gas / propertiesRemoved value: -{ - "activationChainHalted": { - "const": true, - "type": "boolean" - }, - "actualCostWei": { - "pattern": "^(0|[1-9][0-9]*)$", - "type": "string" - }, - "maximumCostWei": { - "pattern": "^(0|[1-9][0-9]*)$", - "type": "string" - }, - "payer": { - "const": "sponsor", - "type": "string" - } -} - removed
Output schema / properties / gas / requiredRemoved value: -[ - "payer", - "maximumCostWei" -] - removed
Output schema / properties / gas / typeRemoved value: -"object" - changed
Output schema / properties / reason / enumPrevious value: -[ - "SPONSOR_ACTIVATION_UNCONFIGURED", - "SPONSOR_ACTIVATION_UNAVAILABLE", - "SPONSOR_RECOVERY_ONLY", - "SPONSOR_CAPABILITY_UNAVAILABLE", - "SPONSOR_RUNTIME_UNAVAILABLE", - "SPONSOR_JOURNAL_UNAVAILABLE", - "SPONSOR_REQUEST_INVALID", - "SPONSOR_REQUEST_REFUSED", - "SPONSOR_SESSION_REQUIRED", - "SPONSOR_SESSION_INVALID", - "SPONSOR_OWNER_MISMATCH", - "SPONSOR_EXPLICIT_WALLET_UPGRADE_REQUIRED", - "SPONSOR_CURRENT_GRANT_REQUIRED", - "SPONSOR_CAP_UNAVAILABLE", - "SPONSOR_POLICY_CHANGED", - "SPONSOR_CHAIN_UNAVAILABLE", - "SPONSOR_ACCOUNT_PROOF_UNAVAILABLE", - "SPONSOR_ACCOUNT_PROOF_MISMATCH", - "SPONSOR_INPUT_OUTSIDE_REVIEWED_CAP", - "SPONSOR_REVIEW_AUTHORITY_CHANGED", - "SPONSOR_REVIEW_EXPIRED", - "SPONSOR_STOP_OR_CAP_CHANGED", - "SPONSOR_BALANCE_INSUFFICIENT", - "SPONSOR_OUTPUT_TOKEN_UNREVIEWED", - "SPONSOR_BUDGET_HALTED", - "SPONSOR_NOT_SUBMITTED", - "SPONSOR_USER_OPERATION_REVERTED", - "SPONSOR_GAS_CAP_EXCEEDED" -]New value: +[ + "SPONSOR_ACTIVATION_UNCONFIGURED", + "SPONSOR_ACTIVATION_UNAVAILABLE", + "SPONSOR_RECOVERY_ONLY", + "SPONSOR_CAPABILITY_UNAVAILABLE", + "SPONSOR_RUNTIME_UNAVAILABLE", + "SPONSOR_JOURNAL_UNAVAILABLE", + "SPONSOR_REQUEST_INVALID", + "SPONSOR_REQUEST_REFUSED", + "SPONSOR_SESSION_REQUIRED", + "SPONSOR_SESSION_INVALID", + "SPONSOR_OWNER_MISMATCH", + "SPONSOR_EXPLICIT_WALLET_UPGRADE_REQUIRED", + "SPONSOR_CURRENT_GRANT_REQUIRED", + "SPONSOR_CAP_UNAVAILABLE", + "SPONSOR_POLICY_CHANGED", + "SPONSOR_CHAIN_UNAVAILABLE", + "SPONSOR_ACCOUNT_PROOF_UNAVAILABLE", + "SPONSOR_ACCOUNT_PROOF_MISMATCH", + "SPONSOR_INPUT_OUTSIDE_REVIEWED_CAP", + "SPONSOR_REVIEW_AUTHORITY_CHANGED", + "SPONSOR_REVIEW_EXPIRED", + "SPONSOR_STOP_OR_CAP_CHANGED", + "SPONSOR_BALANCE_INSUFFICIENT", + "SPONSOR_OUTPUT_TOKEN_UNREVIEWED", + "SPONSOR_BUDGET_HALTED", + "SPONSOR_NOT_SUBMITTED", + "SPONSOR_USER_OPERATION_REVERTED", + "SPONSOR_GAS_CAP_EXCEEDED", + "ACCOUNT_GAS_REVIEW_REQUIRED", + "ACCOUNT_GAS_REVIEW_CHANGED", + "ACCOUNT_GAS_REVIEW_STALE", + "ACCOUNT_GAS_REVIEW_UNAVAILABLE", + "ACCOUNT_GAS_REVIEW_INVALID", + "ACCOUNT_GAS_FUNDING_REQUIRED", + "ACCOUNT_GAS_SPONSOR_INELIGIBLE", + "ACCOUNT_GAS_QUOTE_UNAVAILABLE" +]
1 tool update
- Added
otto_lp_collect_userop
2 tool updates
- Added
otto_native_yield_userop - Changed
otto_sponsored_account2 fields changed- changed
Output schema / properties / failureCode / enumPrevious value: -[ - "SPONSOR_ACTIVATION_UNCONFIGURED", - "SPONSOR_ACTIVATION_UNAVAILABLE", - "SPONSOR_RECOVERY_ONLY", - "SPONSOR_RUNTIME_UNAVAILABLE", - "SPONSOR_JOURNAL_UNAVAILABLE", - "SPONSOR_REQUEST_INVALID", - "SPONSOR_REQUEST_REFUSED", - "SPONSOR_SESSION_REQUIRED", - "SPONSOR_SESSION_INVALID", - "SPONSOR_OWNER_MISMATCH", - "SPONSOR_EXPLICIT_WALLET_UPGRADE_REQUIRED", - "SPONSOR_CURRENT_GRANT_REQUIRED", - "SPONSOR_CAP_UNAVAILABLE", - "SPONSOR_POLICY_CHANGED", - "SPONSOR_CHAIN_UNAVAILABLE", - "SPONSOR_ACCOUNT_PROOF_UNAVAILABLE", - "SPONSOR_ACCOUNT_PROOF_MISMATCH", - "SPONSOR_INPUT_OUTSIDE_REVIEWED_CAP", - "SPONSOR_REVIEW_AUTHORITY_CHANGED", - "SPONSOR_REVIEW_EXPIRED", - "SPONSOR_STOP_OR_CAP_CHANGED", - "SPONSOR_BALANCE_INSUFFICIENT", - "SPONSOR_OUTPUT_TOKEN_UNREVIEWED", - "SPONSOR_BUDGET_HALTED", - "SPONSOR_NOT_SUBMITTED", - "SPONSOR_USER_OPERATION_REVERTED", - "SPONSOR_GAS_CAP_EXCEEDED" -]New value: +[ + "SPONSOR_ACTIVATION_UNCONFIGURED", + "SPONSOR_ACTIVATION_UNAVAILABLE", + "SPONSOR_RECOVERY_ONLY", + "SPONSOR_CAPABILITY_UNAVAILABLE", + "SPONSOR_RUNTIME_UNAVAILABLE", + "SPONSOR_JOURNAL_UNAVAILABLE", + "SPONSOR_REQUEST_INVALID", + "SPONSOR_REQUEST_REFUSED", + "SPONSOR_SESSION_REQUIRED", + "SPONSOR_SESSION_INVALID", + "SPONSOR_OWNER_MISMATCH", + "SPONSOR_EXPLICIT_WALLET_UPGRADE_REQUIRED", + "SPONSOR_CURRENT_GRANT_REQUIRED", + "SPONSOR_CAP_UNAVAILABLE", + "SPONSOR_POLICY_CHANGED", + "SPONSOR_CHAIN_UNAVAILABLE", + "SPONSOR_ACCOUNT_PROOF_UNAVAILABLE", + "SPONSOR_ACCOUNT_PROOF_MISMATCH", + "SPONSOR_INPUT_OUTSIDE_REVIEWED_CAP", + "SPONSOR_REVIEW_AUTHORITY_CHANGED", + "SPONSOR_REVIEW_EXPIRED", + "SPONSOR_STOP_OR_CAP_CHANGED", + "SPONSOR_BALANCE_INSUFFICIENT", + "SPONSOR_OUTPUT_TOKEN_UNREVIEWED", + "SPONSOR_BUDGET_HALTED", + "SPONSOR_NOT_SUBMITTED", + "SPONSOR_USER_OPERATION_REVERTED", + "SPONSOR_GAS_CAP_EXCEEDED" +] - changed
Output schema / properties / reason / enumPrevious value: -[ - "SPONSOR_ACTIVATION_UNCONFIGURED", - "SPONSOR_ACTIVATION_UNAVAILABLE", - "SPONSOR_RECOVERY_ONLY", - "SPONSOR_RUNTIME_UNAVAILABLE", - "SPONSOR_JOURNAL_UNAVAILABLE", - "SPONSOR_REQUEST_INVALID", - "SPONSOR_REQUEST_REFUSED", - "SPONSOR_SESSION_REQUIRED", - "SPONSOR_SESSION_INVALID", - "SPONSOR_OWNER_MISMATCH", - "SPONSOR_EXPLICIT_WALLET_UPGRADE_REQUIRED", - "SPONSOR_CURRENT_GRANT_REQUIRED", - "SPONSOR_CAP_UNAVAILABLE", - "SPONSOR_POLICY_CHANGED", - "SPONSOR_CHAIN_UNAVAILABLE", - "SPONSOR_ACCOUNT_PROOF_UNAVAILABLE", - "SPONSOR_ACCOUNT_PROOF_MISMATCH", - "SPONSOR_INPUT_OUTSIDE_REVIEWED_CAP", - "SPONSOR_REVIEW_AUTHORITY_CHANGED", - "SPONSOR_REVIEW_EXPIRED", - "SPONSOR_STOP_OR_CAP_CHANGED", - "SPONSOR_BALANCE_INSUFFICIENT", - "SPONSOR_OUTPUT_TOKEN_UNREVIEWED", - "SPONSOR_BUDGET_HALTED", - "SPONSOR_NOT_SUBMITTED", - "SPONSOR_USER_OPERATION_REVERTED", - "SPONSOR_GAS_CAP_EXCEEDED" -]New value: +[ + "SPONSOR_ACTIVATION_UNCONFIGURED", + "SPONSOR_ACTIVATION_UNAVAILABLE", + "SPONSOR_RECOVERY_ONLY", + "SPONSOR_CAPABILITY_UNAVAILABLE", + "SPONSOR_RUNTIME_UNAVAILABLE", + "SPONSOR_JOURNAL_UNAVAILABLE", + "SPONSOR_REQUEST_INVALID", + "SPONSOR_REQUEST_REFUSED", + "SPONSOR_SESSION_REQUIRED", + "SPONSOR_SESSION_INVALID", + "SPONSOR_OWNER_MISMATCH", + "SPONSOR_EXPLICIT_WALLET_UPGRADE_REQUIRED", + "SPONSOR_CURRENT_GRANT_REQUIRED", + "SPONSOR_CAP_UNAVAILABLE", + "SPONSOR_POLICY_CHANGED", + "SPONSOR_CHAIN_UNAVAILABLE", + "SPONSOR_ACCOUNT_PROOF_UNAVAILABLE", + "SPONSOR_ACCOUNT_PROOF_MISMATCH", + "SPONSOR_INPUT_OUTSIDE_REVIEWED_CAP", + "SPONSOR_REVIEW_AUTHORITY_CHANGED", + "SPONSOR_REVIEW_EXPIRED", + "SPONSOR_STOP_OR_CAP_CHANGED", + "SPONSOR_BALANCE_INSUFFICIENT", + "SPONSOR_OUTPUT_TOKEN_UNREVIEWED", + "SPONSOR_BUDGET_HALTED", + "SPONSOR_NOT_SUBMITTED", + "SPONSOR_USER_OPERATION_REVERTED", + "SPONSOR_GAS_CAP_EXCEEDED" +]
1 tool update
- Added
otto_sponsored_account
2 tool updates
- Changed
otto_prepare_yield_deposit2 fields changed- added
Output schema / properties / preview / properties / route_semanticsAdded 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" +} - changed
Output schema / properties / preview / requiredPrevious 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" +]
- Changed
otto_prepare_yield_withdraw2 fields changed- added
Output schema / properties / preview / properties / route_semanticsAdded 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" +} - changed
Output schema / properties / preview / requiredPrevious value: -[ - "market_id", - "venue", - "protocol", - "chain_id", - "vault", - "asset", - "shares", - "expected_assets", - "min_assets", - "preview_redeem_assets", - "parity_shortfall_bps", - "parity_tolerance_bps", - "quoted_fees" -]New value: +[ + "market_id", + "venue", + "protocol", + "chain_id", + "vault", + "asset", + "shares", + "expected_assets", + "min_assets", + "preview_redeem_assets", + "parity_shortfall_bps", + "parity_tolerance_bps", + "quoted_fees", + "route_semantics" +]
1 tool update
- Changed
otto_delegation_exit1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "account": { + "pattern": "^0x[0-9a-fA-F]{40}$", + "type": "string" + }, + "amount_atomic": { + "pattern": "^[1-9][0-9]*$", + "type": "string" + }, + "broadcast_attempts": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "created_at": { + "format": "date-time", + "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z))$", + "type": "string" + }, + "destination": { + "pattern": "^0x[0-9a-fA-F]{40}$", + "type": "string" + }, + "epoch": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "has_exit": { + "type": "boolean" + }, + "lease_expires_at": { + "format": "date-time", + "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z))$", + "type": "string" + }, + "operation_id": { + "format": "uuid", + "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$", + "type": "string" + }, + "owner_token": { + "pattern": "^[0-9a-f]{64}$", + "type": "string" + }, + "phase": { + "enum": [ + "prepare", + "resume", + "submit", + "status", + "reconcile", + "retry_same", + "cancel" + ], + "type": "string" + }, + "receipt": { + "additionalProperties": false, + "properties": { + "block_hash": { + "pattern": "^0x[0-9a-fA-F]{64}$", + "type": "string" + }, + "block_number": { + "pattern": "^[1-9][0-9]*$", + "type": "string" + }, + "status": { + "enum": [ + "success", + "reverted" + ], + "type": "string" + }, + "transaction_hash": { + "pattern": "^0x[0-9a-fA-F]{64}$", + "type": "string" + } + }, + "required": [ + "transaction_hash", + "block_number", + "block_hash", + "status" + ], + "type": "object" + }, + "replacement": { + "additionalProperties": false, + "properties": { + "block_hash": { + "pattern": "^0x[0-9a-fA-F]{64}$", + "type": "string" + }, + "block_number": { + "pattern": "^(?:0|[1-9][0-9]*)$", + "type": "string" + }, + "finalized_head_block_hash": { + "pattern": "^0x[0-9a-fA-F]{64}$", + "type": "string" + }, + "finalized_head_block_number": { + "pattern": "^(?:0|[1-9][0-9]*)$", + "type": "string" + }, + "finalized_nonce": { + "pattern": "^[1-9][0-9]*$", + "type": "string" + }, + "transaction_hash": { + "pattern": "^0x[0-9a-fA-F]{64}$", + "type": "string" + } + }, + "required": [ + "transaction_hash", + "block_number", + "block_hash", + "finalized_head_block_number", + "finalized_head_block_hash", + "finalized_nonce" + ], + "type": "object" + }, + "state": { + "enum": [ + "preparing", + "signing", + "signed", + "submitted", + "unknown", + "confirmed", + "reverted", + "replaced", + "canceled" + ], + "type": "string" + }, + "transaction": { + "additionalProperties": false, + "properties": { + "chain_id": { + "const": 8453, + "type": "number" + }, + "data": { + "pattern": "^0x(?:[0-9a-fA-F]{2})+$", + "type": "string" + }, + "from": { + "pattern": "^0x[0-9a-fA-F]{40}$", + "type": "string" + }, + "gas": { + "pattern": "^[1-9][0-9]*$", + "type": "string" + }, + "max_fee_per_gas": { + "pattern": "^[1-9][0-9]*$", + "type": "string" + }, + "max_priority_fee_per_gas": { + "pattern": "^(?:0|[1-9][0-9]*)$", + "type": "string" + }, + "nonce": { + "pattern": "^(?:0|[1-9][0-9]*)$", + "type": "string" + }, + "sign_idempotency_key": { + "pattern": "^[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$", + "type": "string" + }, + "to": { + "const": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913", + "type": "string" + }, + "type": { + "const": "eip1559", + "type": "string" + }, + "value": { + "const": "0", + "type": "string" + } + }, + "required": [ + "type", + "chain_id", + "nonce", + "from", + "to", + "value", + "data", + "gas", + "max_fee_per_gas", + "max_priority_fee_per_gas", + "sign_idempotency_key" + ], + "type": "object" + }, + "transaction_hash": { + "pattern": "^0x[0-9a-fA-F]{64}$", + "type": "string" + }, + "updated_at": { + "format": "date-time", + "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z))$", + "type": "string" + }, + "user_id": { + "pattern": "^[a-zA-Z0-9-]{1,100}$", + "type": "string" + } + }, + "required": [ + "phase", + "has_exit", + "user_id" + ], + "type": "object" +}
1 tool update
- Added
otto_stock_pools
3 tool updates
- Added
otto_delegation_exit - Added
otto_delegation_operations - Added
otto_delegation_reconcile
1 tool update
- Added
otto_prepare_stock_buy
2 tool updates
- Added
otto_prepare_yield_deposit - Added
otto_prepare_yield_withdraw
4 tool updates
- Added
otto_delegation_cap - Changed
otto_delegation_fence_status4 fields changed- added
Output schema / properties / mint_enabledAdded value: +{ + "type": "boolean" +} - added
Output schema / properties / per_swap_cap_min_usdAdded value: +{ + "const": 1, + "type": "number" +} - added
Output schema / properties / ruleset_versionAdded value: +{ + "maximum": 9007199254740991, + "minimum": 1, + "type": "integer" +} - changed
Output schema / requiredPrevious value: -[ - "present", - "policy_name", - "per_swap_cap_usd" -]New value: +[ + "present", + "policy_name", + "per_swap_cap_usd", + "per_swap_cap_min_usd", + "ruleset_version", + "mint_enabled" +]
- Changed
otto_delegation_status4 fields changed- added
Output schema / properties / delegation / properties / per_swap_cap_usdAdded value: +{ + "maximum": 5000, + "minimum": 1, + "type": "integer" +} - added
Output schema / properties / mint_enabledAdded value: +{ + "type": "boolean" +} - added
Output schema / properties / ruleset_versionAdded value: +{ + "maximum": 9007199254740991, + "minimum": 1, + "type": "integer" +} - changed
Output schema / requiredPrevious value: -[ - "user_id", - "addresses", - "fence", - "delegation", - "revocation_requested_here" -]New value: +[ + "user_id", + "addresses", + "fence", + "delegation", + "revocation_requested_here", + "ruleset_version", + "mint_enabled" +]
- Changed
otto_submit_under_delegation2 fields changed- added
Output schema / properties / fence / properties / user_cap_usdAdded value: +{ + "maximum": 5000, + "minimum": 1, + "type": "integer" +} - changed
Output schema / properties / fence / requiredPrevious 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" +]
5 tool updates
- Added
otto_delegation_fence - Added
otto_delegation_fence_status - Added
otto_delegation_revoke - Added
otto_delegation_status - Added
otto_submit_under_delegation
16 tool updates
- First observed
otto_base_season - First observed
otto_catalog - First observed
otto_equity_intel - First observed
otto_equity_smart_money - First observed
otto_equity_smart_money_brief - First observed
otto_insider_trades - First observed
otto_institutional_holdings - First observed
otto_pm_crypto - First observed
otto_pm_markets - First observed
otto_prepare_bridge - First observed
otto_prepare_perp_order - First observed
otto_prepare_polymarket_order - First observed
otto_prepare_swap - First observed
otto_rh_season - First observed
otto_tokenized_equities - First observed
otto_x_recipes
Related MCP Connectors
Pay-per-call crypto market intelligence for AI agents. USDC on Base via x402.
63 pay-per-call tools for agents: vision, text, data, web, blockchain. USDC on Base via x402.
8 pay-per-call web intel tools over MCP. Free discovery, calls settle in USDC on Base (x402).
Market data and web intelligence for AI agents, paid per call in USDC on Base via x402.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceMCP server that provides AI agents with pay-per-call access to a suite of tools (honeypot check, token market, DeFi yields, etc.) via USDC on Base using the x402 protocol.3 npmMIT
- AlicenseAqualityBmaintenanceProvides 16 crypto market data tools for MCP-compatible AI clients with x402/USDC micropayments on Base Mainnet.1612 npmMIT
- AlicenseAqualityDmaintenance22 MCP tools for AI agents: crypto prices and trading signals (53 coins), stock prices and company financials, forex rates and conversion, and web scraping with AI summaries. All powered by x402 USDC micropayments on Base. $0.01-$0.25 per request.2219 npmMIT
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.