Otto Intel

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

The description goes well beyond annotations, disclosing that new reservations are refused before any claim is written, that it re-reads CDP and confirms only the exact current claim and reserved expiry, and that it does not issue new permissions. It also explains the authentication requirement and the permissive input schema behavior, all without contradicting the annotations (readOnlyHint=false, idempotentHint=true).

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

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

The description is dense but every sentence adds value, starting with the core purpose, then usage constraints, behavioral details, and authentication. It is structured logically—purpose, exclusions, confirmation logic, fallback behavior, and security—without padding or repetition. It is appropriately sized for the complexity of the tool.

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

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

Given the tool's complexity (legacy behavior, security, and branching logic) and the presence of an output schema, the description is remarkably complete. It covers what the tool does, when to use it, side effects, authentication, and validation nuances. The existence of an output schema means return values need not be described, and nothing critical is missing for correct invocation.

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

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

With zero parameters in the schema, the description adds critical meaning by explaining that the listed schema is intentionally permissive and that the strict schema is validated only after authentication. It also clarifies that authentication is via the request header, not arguments. This fully compensates for the empty schema and provides guidance an agent would otherwise lack.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool confirms an in-flight legacy Model B cap, specifying it does not issue new permissions and that new reservation requests are retired. This distinguishes it from sibling tools that handle reservations or permissions. The verb 'confirm' plus the specific resource 'legacy Model B cap' makes the purpose unambiguous.

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

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

The description explicitly states when to use this tool—for confirming a permission minted against a prior reservation—and when not to, such as for new reservations or when a mismatch or Stop overlap occurs, directing the agent to use a fresh explicit Stop instead. It also details the server-to-server authentication requirement through the x-otto-delegation-auth header, providing comprehensive usage guidance.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

Even with readOnlyHint, openWorldHint, idempotentHint, and destructiveHint already present, the description adds real behavioral value: no authentication header is required, mint_enabled is false on the serving retirement build because new trade-permission creation is retired, and no user/grant/address/policy contents are exposed. These details go beyond the annotations and are directly useful to 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.

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

The first sentence front-loads the core purpose and outputs, while the remaining sentences add only relevant context: retirement of new trade-permission creation, availability of related operations, and the privacy boundary. The description is appropriately sized for a zero-parameter tool and avoids filler.

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

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

For a zero-parameter read-only tool with an output schema, the description supplies everything an agent needs: authentication posture, privacy scope, the meaning of mint_enabled, and the tool's place in the delegation workflow. Because an output schema exists, the description does not need to explain return values.

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

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

The tool has zero parameters and the schema coverage is 100%, so the schema is already exhaustive. The description's 'Arguments: {}' is redundant but harmless, and no parameter-level semantics are needed beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb, 'reports', and names a precise resource: whether the Model B project policy still fences existing delegated sends, along with the fence name, rules digest, shared cap ceiling, and mint_enabled. It is clearly scoped away from delegation mutation tools by saying 'No user, grant, address or policy contents are exposed.' The title and description align well.

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

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

The description clearly establishes when this tool is appropriate: it is PUBLIC, read-only, requires no header, and reports fence status rather than performing revokes or exits. It also states 'Existing status, revoke and exits remain available,' which points toward complementary operations. It does not explicitly name sibling tools as alternatives, but the usage context is clear.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds substantial behavioral context beyond them: null semantics for unscheduled reports, variable history length, vendor units because Finnhub names no currency, drift reported as 'unavailable' rather than inferred, and the paid x402 cost model with free-allowance preservation.

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

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

Front-loaded with the core purpose and dense with facts that each earn their place. The one flaw is redundancy: paid-only status is stated twice ('Paid-only, including the first call' and 'Hosted access: paid-only; each call costs $0.003 USDC...'), which slightly bloats an otherwise efficient block.

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

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 full burden of describing returns, and it does so thoroughly — enumerating the fields, their null/windowed behavior, and unit caveats. Combined with annotations covering safety, an agent has everything needed to call this correctly.

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

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

Schema coverage is 100%, so both parameters are already documented, including x_payment's challenge-then-retry flow. The description adds only marginal parameter-level value (the funds/ETF coverage caveat) and does not extend ticker syntax beyond the schema, so the baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Read') and resource ('earnings calendar and surprise history') scoped to a ticker, then enumerates the exact payload: next report date/session, estimates, latest reported EPS vs estimate with surprise percentage, and up to four quarters of history. This is clearly distinguishable from sibling tools like otto_equity_news or otto_financial_statements.

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

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

Provides an explicit when-not ('Funds and ETFs have no earnings coverage') and repeats the paid-only prerequisite, which helps an agent decide whether calling is worthwhile. It does not, however, name an alternative sibling for the cases it doesn't cover, so routing guidance is incomplete.

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

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.

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.

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.

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.

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.

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.

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), yet the description adds substantial behavior: primary/mentioned labelling, the ticker-as-English-word false-match caveat (ON, IT), withheld redirect URLs, no sentiment generation, the paid x402 cost of $0.003 per call including the first, and the no-charge refusal on empty results.

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

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

Purpose and scope lead the text, and most sentences carry distinct information. It loses a point for redundancy: the paid-only status appears twice ('Paid-only, including the first call' and 'Hosted access: paid-only; each call costs $0.003'), which could be one sentence.

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

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

With no output schema, the description takes on the return-value burden and does so adequately: it names the returned fields, the labelling scheme, the refusal case, and the withheld redirect URLs. Nothing an agent needs to call this correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real semantic meaning for `ticker` — it warns that a legitimate ticker that is also an English word can match an unrelated upper-case headline — and reinforces the `x_payment` retry flow with the cost amount.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — read licensed Finnhub company headlines for a ticker over the trailing seven days — and enumerates the returned fields (publication time, source, summary). This clearly separates it from sibling news tools like otto_crypto_news and otto_news_recaps.

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

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

Sets boundaries well: 'News context only; not a recommendation', paid-only on every call, and a defined empty-result path (`no_recent_news`, nothing charged). It does not explicitly route the agent to or away from specific siblings (e.g. otto_news_recaps, otto_equity_intel), so it stops short of full when/when-not guidance.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), and the description adds substantial behavior beyond them: provenance per figure (XBRL concept, filing, date), how figures were derived (filed, reconstructed from year-to-date, computed from named lines), restatement handling with the earlier value retained, and the explicit-null-never-carried-forward rule. It also discloses the refusal mode and its cost consequence and the x402 billing/free-cache mechanics.

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

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

The capability, scope and return shape are front-loaded in the first sentence, with provenance rules, filing index, refusal mode and pricing following in a logical order. Dense but nearly every clause carries distinct information; the pricing/legal disclaimer sentences are the closest to padding, keeping it short of a 5.

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

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 full burden of describing returns and does so thoroughly: statement coverage, period count, provenance metadata, derivation flags, restatement and null semantics, plus the filing index contents. Combined with the refusal and payment behavior, an agent has everything needed to call and interpret this tool.

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

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

Schema description coverage is 100% for both parameters, so the schema already documents the ticker format and the x_payment challenge/retry flow. The description adds no ticker syntax or payment-format detail beyond what the schema states, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Read the SEC statement set for a US-listed company') and enumerates exactly what is returned: income statement, balance sheet, cash flow, up to five fiscal periods, annual and quarterly, plus the 10-K/10-Q/8-K filing index. An agent can tell this apart from sibling tools such as otto_equity_intel or otto_material_events without opening any schema.

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

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

The description gives eligibility context (a fund vehicle or non-USD-only filer is refused as `not_applicable`, nothing charged) and the payment path (first eligible cached result is free, otherwise $0.003 USDC via x402), which is useful operational guidance. However it never names an alternative tool or states when to prefer this over otto_equity_intel, otto_catalog, or other sibling research tools; usage is implied from the topic rather than routed.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open world), and the description adds materially beyond them: truncation is flagged, the list may legitimately be empty, empty answers are still charged, the first cached result is free, otherwise $0.003 USDC via x402. Event date vs filing date separation, amendment labeling, and EDGAR links are disclosed output behavior.

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

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

Front-loaded with the core action and window, then detail; every sentence carries information. The first sentence is dense but readable, and the pricing/legal notes are compressed into a short final clause. Minor density cost, not waste.

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

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

With no output schema, the description fully specifies the return shape (item codes plus titles, separate event and filing dates, amendment labels, EDGAR links, truncated flag, possible empty list) as well as the payment path. An agent has everything needed to call and interpret it.

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

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

Schema coverage is 100% for both parameters, so the schema already documents ticker format and the x402 payment-retry flow. The description adds the payment economics and the 'US-listed company' constraint but no additional parameter syntax or semantics beyond what the schema states; baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a precise verb+resource+scope: reads up to 20 Form 8-K material events a US-listed company filed in the last 90 days. The enumerated item codes (1.01, 1.05, 2.06, 3.01, 5.02) and the explicit exclusion of earnings-only filings make it unmistakable versus siblings like otto_equity_news or earnings tools.

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

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

Usage context is implied by the scope (material corporate events, 90-day window, 20-item cap) and it explicitly excludes earnings-only filings, which helps routing. However, it names no alternative sibling tool and gives no explicit when-not-to-use guidance beyond that single exclusion.

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

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

Annotations already provide readOnly/openWorld/idempotent/non-destructive hints. The description adds valuable behavioral details beyond those hints: the one-time capability return, the CDP-authenticated reservation prerequisite, and the no-logging requirement for secrets. These do 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.

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

The description is two sentences and stays on point, with the security constraint placed at the end. It is compact, though the first sentence could have used the space to name the exact operation instead of the generic 'Manage.'

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

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

For a parameterless, read-only tool, the description covers the prerequisite, output behavior, and logging constraint. But with no output schema it leaves the returned 'capability' undefined, and the lack of sibling differentiation means an agent must infer relationship to status/enroll/revoke. This is minimum viable but not fully complete.

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

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

The input schema has zero parameters and coverage is 100%, so there are no parameters the description must explain. No additional parameter semantics are needed; the description's mention of secret-bearing input/output is a security constraint rather than a parameter definition.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description identifies a resource, 'same-wallet research autopay,' and hints at a flow, but the verb 'Manage' is an umbrella that does not state the tool checks/returns availability. It does not mention 'availability' or differentiate from otto_muse_autopay_status/enroll, so the core action is vague rather than specific.

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

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

The prerequisite 'Enrollment needs a CDP-authenticated pending reservation; capability is returned once' implies where the tool fits in the enrollment workflow. However, it never explicitly says when to call this tool versus status, enroll, prepare, or revoke, so the guidance is only inferred.

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

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

Annotations already indicate a non-read-only, non-idempotent, non-destructive operation. The description adds valuable behavior beyond that: the need for a CDP-authenticated pending reservation, the one-time capability return, and the security requirement that secret-bearing input/output must not be logged. 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.

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

The description is two sentences: the first states the broad purpose, the second packs in the prerequisite and a security warning. It is concise and front-loaded, with no wasted words, though the first sentence could be slightly more specific.

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

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

Given a mutation tool with no output schema, the description covers the key prerequisite and security constraint, but it is thin on what enrollment actually accomplishes (e.g., enabling autopay, subsequent steps like signing) and how the returned capability is used. In the broader autopay workflow (prepare→enroll→sign), more context would help an agent act correctly.

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

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

Schema description coverage is 100%, with both parameters already well-documented (accessToken as a secret credential, enrollmentId as a session ID from prepare). The tool description does not add meaningful parameter-specific semantics beyond echoing the 'never log' constraint already present in the schema, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description says 'Manage same-wallet research autopay' which is broad, but the second sentence clarifies this tool performs enrollment ('Enrollment needs...'), and the tool name/title confirm the action. It distinguishes from siblings like revoke/status by mentioning the one-time capability return, though it doesn't explicitly name alternatives.

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

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

The description gives a clear prerequisite: 'Enrollment needs a CDP-authenticated pending reservation,' which tells the agent when to use it (after prepare). It also implies a one-time action with 'capability is returned once.' It doesn't explicitly say when not to use it or name sibling tools, but the condition provides enough context.

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

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

Annotations already mark the tool as non-read-only and non-idempotent, but the description adds useful behavior beyond them: a one-time returned capability and a 'must not be logged' security rule. It does not contradict annotations, though it leaves other side effects unspecified.

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

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

The description is short and each sentence adds a distinct piece (purpose, prerequisite/output, security). The first sentence is somewhat vague, but there is no filler or redundancy.

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

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

With no output schema and a complex autopay flow, the description should explain how prepare fits with availability/enroll/sign, what the returned capability is for, and error behavior without a pending reservation. It only hints at these, leaving significant gaps.

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

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

Input schema coverage is 100%, so the baseline is 3. The description's secret-logging warning reinforces the accessToken documentation but adds no new meaning to individual parameters or their relationships.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description says 'Manage same-wallet research autopay' and mentions enrollment requiring a pending reservation, but it never states a specific verb/resource such as 'prepare a one-time autopay capability.' It adds context but remains vague and does not clearly differentiate from siblings like otto_muse_autopay_enroll or _sign.

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

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

It gives a prerequisite condition ('Enrollment needs a CDP-authenticated pending reservation') but no explicit guidance on when to call this tool versus alternatives. No sibling names, exclusions, or sequencing hints are provided, so an agent cannot confidently route to it.

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

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

Annotations already convey read-only/destructive/idempotence hints, and the description adds meaningful context: the CDP-authenticated pending reservation requirement, the one-time return of the capability, and the rule that secret-bearing input/output must not be logged. This 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.

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

The description is short and contains no filler, with the security instruction clearly stated. It is not perfectly front-loaded because it opens with the vague verb 'Manage' instead of leading with the revoke operation.

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

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

For a three-parameter tool with rich annotations and full schema coverage, the definition provides the required auth model, secret-handling rule, and operation scope. It does not describe return values or what happens to the capability after use, but the idempotent and non-destructive hints cover part of that gap.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters. The root schema description adds the important 'Use capability OR accessToken plus sessionId' relationship, but the top-level description contributes no additional parameter-level meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The top-level description says only 'Manage same-wallet research autopay', which is a generic verb that could apply to enroll, status, or revoke. The revoke action is explicit only in the schema-level description ('Revokes this research session') and in the tool name/title, so the description itself does not clearly state the specific operation.

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

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

The description provides a useful prerequisite ('Enrollment needs a CDP-authenticated pending reservation; capability is returned once') and the schema scopes the operation to 'this research session, not the global provider grant'. However, it never explicitly states when to use this tool versus sibling tools such as otto_muse_autopay_enroll, otto_muse_autopay_status, or otto_muse_autopay_prepare.

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

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

Annotations already indicate this is not read-only, not idempotent, and not destructive. The description adds valuable behavioral context: it never sends the payment, and it warns against retrying an uncertain signing attempt with a new nonce. This goes beyond the annotations by disclosing the non-retry rule and the non-sending behavior, which are critical for an agent to avoid double-signing or accidental payment execution.

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

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

The description is two sentences with no wasted words. The core action is front-loaded, and the two most important behavioral constraints (never sends, never retry with new nonce) are stated immediately. Every sentence earns its place.

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

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

For a signing tool with 9 required parameters and no output schema, the description covers the critical behavioral constraints: exactness, non-sending, non-retry, and secret handling. It does not explain the full signing flow or what the return value looks like, but the schema covers parameter details and the description covers the operational cautions. The lack of an output schema is partially mitigated by the clear behavioral guidance.

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

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

Schema description coverage is 89%, so the schema already documents most parameters. The description adds meaning by emphasizing 'exact' for tool, resource, and amountAtomic, and by warning that capability is a secret credential that must never be logged or persisted. It also clarifies that validAfter must be '0' and validBefore is at most 300 seconds ahead, which reinforces the schema. The description does not add much beyond the schema, but the security warning and exactness emphasis are valuable.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Sign'), a precise resource ('one exact allowlisted Base-USDC research payment'), and a scope ('under an existing bounded capability'). It also distinguishes itself from related autopay tools by emphasizing it only signs and never sends, which is a clear differentiator among the otto_muse_autopay_* siblings.

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

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

The description gives clear context: use this tool to sign a single exact allowlisted payment under an existing bounded capability. It implies this is the signing step after preparation and before any send, and it warns against retrying uncertain attempts. It does not explicitly name alternatives like otto_muse_autopay_prepare or otto_muse_autopay_enroll, but the 'existing bounded capability' and 'exact allowlisted' phrasing effectively scopes when it should be used.

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

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

Beyond the readOnly/idempotent/destructive annotations, the description adds two meaningful behaviors: enrollment requires a CDP-authenticated pending reservation and the capability credential is returned only once. The explicit warning that secret-bearing input/output must not be logged is useful security context. The word 'Manage' is slightly in tension with readOnlyHint, but it is not a direct contradiction.

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

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

Three terse sentences with no repetition; the secret-handling warning and enrollment prerequisite each add useful information. It loses a point because the first sentence uses 'Manage' instead of a precise operation, which forces the reader to infer meaning.

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

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

For a tool with six optional parameters and no output schema, the description is not complete enough: it doesn't describe what a caller receives back, what a status operation means, how operationId is used, or which sibling prepare/enroll/revoke calls should precede or follow. The schema and annotations fill some gaps, but the core invocation flow is underspecified.

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

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

Schema coverage is 67%, so the schema already explains capability, accessToken, sessionId, and enrollmentId. The description adds the same-wallet constraint and the once-only nature of the capability, but it does not explain wallet or operationId beyond their names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

There is no tautology, but the description's verb is generic: 'Manage same-wallet research autopay' never says 'status', 'check', or 'query', so an agent cannot tell whether this performs a read or a management action. The name/title supply 'status', but the description itself fails to state the operation it performs.

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

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

The description gives a prerequisite ('Enrollment needs a CDP-authenticated pending reservation') but never says when to call this tool rather than otto_muse_autopay_prepare, otto_muse_autopay_enroll, otto_muse_autopay_sign, otto_muse_autopay_revoke, or otto_muse_autopay_availability. There are no explicit when-to-use or when-not-to-use conditions.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, but the description adds genuinely new behavioral facts: an empty result is still charged, a first eligible cached call is free, and paid calls cost $0.001 USDC via x402. It does not cover rate limits or retry/pagination semantics, so it stops short of a 5.

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

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

Front-loaded with purpose and scope, then returns, then the empty-result edge case, then cost. Every sentence carries information, though the payment sentence is dense and could be split for scannability.

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

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

With no output schema, the description usefully enumerates the return fields (pool address, DEX, USD price, volume, TVL, FDV, price change, tx count) and disclaims the empty case. Missing result caps/pagination and any explicit chain-filtering hint, so not fully complete.

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

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

Schema description coverage is 100%, so both parameters are already documented, including the x_payment challenge/retry flow. The description restates the match keys (symbol/name/address) already present in the query schema and adds no format or syntax detail beyond it — the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Search DEX pools"), enumerates the eight supported chains, and names the three match keys (symbol, name, contract address). This is unambiguous against siblings like otto_stock_pools or otto_holder_analytics without opening any schema.

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

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

The description sets a boundary ("Pool discovery only; not a recommendation") but never names an alternative tool or a when-not condition, so the agent must infer routing from the name alone. The x402 free-vs-paid rule does describe a cost-driven usage condition, which lifts it above bare minimum.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

Annotations already declare readOnly/openWorld/no-destructive, and the description adds substantial behavior beyond them: worst-permissible-fill is checked against the equity's Chainlink total-return mark and refused when over tolerance or when the feed is frozen (>24h), the pair is returned unchanged plus a preview, and nothing is signed or submitted. It also discloses the 300-second envelope validity window and that stale envelopes are refused by the verifier.

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

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

Front-loads the core purpose and organizes the many constraints (fill check, refusal conditions, no signing, delegation retirement, 300s TTL) in a single dense paragraph. Every sentence carries information, though the density borders on a wall of text that could be split for faster scanning.

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

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

For a preparation tool with an output schema already documenting return values, the description still covers the important operational facts: authorization status, timing (valid_until), refusal conditions (fill over tolerance, frozen feed), and non-custodial behavior (never signs/submits). Nothing essential to correct invocation is missing.

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

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

With 50% schema coverage, the description compensates for the undocumented fields: executableEquityId is explained as naming the registry row and never being an input, and registryCommitment is clarified as having to equal the value recomputed over the CURRENT record (stale/foreign rows refused by name). client_ref and accountProfile remain unaddressed in both schema and description, leaving a modest gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a precise verb+resource: it prepares the exact otto_prepare_swap pair (envelope + prepareInput) that buys one of the executable Coinbase B20 tokenized equities on Base with USDC. It explicitly contrasts with the generic otto_prepare_swap sibling and names the exact scope (B20 on Base only), so an agent can distinguish it without opening schemas.

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

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

Gives clear context for use: buying tokenized equities where the equity comes from a registry row rather than as an input, and notes the related otto_submit_under_delegation path refuses this pair and delegated trading is retired. It never states an explicit when-to-use-this-vs-otto_prepare_swap exclusion, but context is strong enough to route correctly.

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

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.

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.

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.

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.

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.

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.

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

Beyond the annotations (readOnly/openWorld/non-idempotent/non-destructive), it discloses that it never signs or submits, that preparation does not authorize execution, that shares are checked against the vault's previewDeposit and refused past a pinned tolerance, and that every envelope is valid for 300 seconds before the verifier refuses it. That is rich operational context the annotations alone cannot convey.

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

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

Purpose and the core commitment/tolerance constraints are front-loaded, and nearly every sentence carries a distinct constraint. It is a dense single block with several long clauses, so it loses a little on scannability but wastes little.

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

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

For a complex 6-parameter mutation-preparation tool, it covers the essential safety story: registry sourcing, commitment freshness, previewDeposit tolerance, non-authorization, non-submission, and envelope expiry. An output schema exists, so return values need not be restated.

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

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

At 50% schema coverage, the description compensates by explaining that executableMarketId must name a registry row (not a vault) and that registryCommitment must equal the commitment recomputed over the current record or the row is refused as stale/foreign. It also clarifies the receiver is the signing account (relating to accountProfile) and refers to the pinned slippage tolerance, though slippage.maxBps and client_ref remain undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a precise verb+resource: it prepares the exact otto_prepare_swap envelope+prepareInput pair that deposits USDC into an executable Morpho vault on Base, with the vault's ERC-4626 share token as output. It explicitly differentiates itself from otto_prepare_swap (same pair shape), the withdraw counterpart, and the retired delegation path, so an agent can tell the siblings apart.

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

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

Clearly scopes use to vaults pulled from the Yield Copilot registry rows and notes that otto_submit_under_delegation refuses this pair, which steers the agent away from the execution path. It does not explicitly state when to prefer this over otto_prepare_swap or otto_prepare_yield_withdraw, so the exclusions are implied rather than fully enumerated.

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

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.

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.

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.

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.

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.

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.

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

Annotations already cover safety (readOnly, idempotent, non-destructive), and the description adds real operational context on top: the 20-notice cap, the 90-day lookback, the possibility of an empty result that is still charged, and the pricing model (first cached result free, otherwise $0.005 USDC via x402). This is exactly the beyond-annotation detail an agent needs.

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

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

Front-loaded with the core purpose and the returned fields, then the lookback/cap limits, then pricing. Dense but each sentence carries information; the pricing and disclaimer sentences are somewhat ancillary but justifiable for a paid endpoint.

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

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

With no output schema, the description enumerates the returned fields (who intends to sell, units, filer market-value estimate, broker, approximate sale date, Rule 10b5-1 dates), discloses coverage limits and empty-result behavior, and explains payment — covering everything needed to call and interpret the response correctly.

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

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

Schema description coverage is 100% — ticker format and the x_payment challenge/retry flow are both documented in the schema itself. The description adds no parameter-level syntax or constraints beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Read') and resource (SEC Form 144 notices of proposed insider sales) scoped to a US ticker, and implicitly separates it from the sibling otto_insider_trades by explaining Form 144 precedes the Form 4 executed-trade filing. An agent can identify this as the pre-trade intent feed rather than the executed-trade feed.

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

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

Gives clear context for when this applies — pre-execution intent notices, distinct from executed trades — and warns a notice may never be executed, which is genuine usage guidance. It does not name the alternative tool (otto_insider_trades) explicitly as the counterpart, so it stops short of a full routing instruction.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

Annotations only declare the write/destructive/open-world profile; the description adds the refused-operation error code, the required `x-otto-delegation-auth` header, the withdrawal fence and ruleset-v2 consent conditions, sequential reset/approval/call submission with canonical receipts and allowance clearing on halt, and an explicit no-retry policy for uncertain prior operations. This is far more behavioral context than the annotations supply.

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

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

The opening sentence is well front-loaded, but the body is a dense run-on mixing retirement policy, argument list, fence rules, retry policy and sibling routing into long compound sentences. Most content earns its place but could be split or trimmed; density hurts scanability.

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

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 no explanation, and the description covers auth, qualifying conditions, sequencing, halt behavior, error codes and the no-retry boundary. It is nearly complete for a destructive, auth-gated submission tool, with only minor gaps such as types for the envelope/prepareInput payloads.

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

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

The declared schema has no properties, so the description carries the entire parameter burden and does name the arguments ({ userId, envelope, prepareInput } with slippage.minAmountOut) plus the validation constraints on output token, spender, share amount and receiver. It does not give types or formats for userId/envelope, but it adds real meaning beyond an empty schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: submitting a qualified Model B vault withdrawal, plus replaying an existing terminal result. It explicitly carves itself out from the retired trading path and from prepare-only tools, though the opening two sentences about retirement front-load context before the actual purpose. An agent can identify what the tool does and roughly where it sits among siblings.

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

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

Explicitly states that new delegated trading is refused (DELEGATION_TRADING_RETIRED) and that prepare-only tools remain available, and routes uncertain prior operations to 'delegation operations/reconciliation'. It also notes status/revoke/qualifying exits live elsewhere. There is no positive 'when to use this instead of X' statement, but the exclusions are unusually rich.

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

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.

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.

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.

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.

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.

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.

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

Goes well beyond the readOnly/idempotent annotations: 15-minute refresh cadence, off-hours value freezing, premium/discount versus underlying, the `excluded` naming with reasons, uncovered tokens being counted not named, per-rail coverage counts, and pay-per-call pricing. These are exactly the behaviors an agent needs before invoking.

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

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

Dense but front-loaded: the core purpose and rails come first, with behavioral detail following. Every sentence carries information, though the run-on middle section could be split for readability.

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

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 explaining the return shape (ranked gainers/losers vs prior NYSE close, coverage counts, `excluded` reasons, uncovered counting). Combined with the payment flow, an agent has enough to call correctly.

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

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

Only one parameter (x_payment) with 100% schema coverage that already explains the challenge/retry protocol. The description adds pricing context ($0.003 USDC via x402, free allowance preservation) that the schema does not, though it does not restate the omit-to-get-challenge mechanics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb ('Read') and a precisely scoped resource: day movers among tokenized US stocks and ETFs across two named rails (Robinhood Chain 4663, Base B20), keyed by token address. This is clearly distinguishable from the broad sibling otto_tokenized_equities, which covers listings rather than movers.

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

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

It states the context ('Market context only; not a recommendation') and the paid-access condition, plus the x402 retry flow. But it never names an alternative tool or says when an agent should prefer this over otto_tokenized_equities or otto_equity_intel. Usage is implied rather than routed.

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

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, so the safety profile is covered. The description goes further with non-obvious behavior: no warm cache, paid from the first call, $0.001 USDC per call via x402, and the default chain. It does not, however, describe latency or result completeness.

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

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

Purpose is front-loaded, which is good, but the paid/x402 detail is stated twice ('Paid-only, including the first call' and 'Hosted access: paid-only; each call costs $0.001 USDC through x402'), which is redundant for a relatively short description.

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

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

For a no-output-schema, 3-param read tool this is close to complete: it covers what is screened, the default chain, the payment requirement and the interpretation caveat. Only minor gaps remain, such as what a returned risk report contains and the scope of the 'free allowance'.

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

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

Schema description coverage is 100%: chain ids, the address pattern and the x_payment challenge/retry flow are all documented in the schema. The description only restates the Base default, adding no syntax or semantics beyond it, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (screen), resource (token contract), provider (GoPlus), scope (8 chains) and the exact risk classes detected (honeypot, rug-pull, hidden mint, taxes, holder concentration). An agent can distinguish this from otto_holder_analytics or otto_equity_intel without opening a schema.

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

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

Implies when the tool applies (screening a token contract before trusting it) and gives a key operational caveat ('paid-only, including the first call'), but names no alternative tool and states no explicit when-not condition beyond the 'not a guarantee, not a recommendation' disclaimer.

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

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.

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.

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.

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.

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.

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.