Insight MCP

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

With no annotations, the description carries the full burden and does disclose meaningful behavior: it produces signed attestations, issues verdicts, and constrains tolerance to a fixed 50 bps band. It does not disclose authorization requirements, whether the handle is single-use or idempotent, whether state persists on the server, or failure modes, which matter for a signing/certification call.

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 action, then usage constraints, then return payload. The return-value enumeration is dense but every item is load-bearing given there is no output schema, and no sentence is redundant.

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 10 params, a nested object, no annotations, and no output schema, the description compensates well by enumerating the returned identifiers, hashes, asset ids, rate, band, verdicts, and attestations. The remaining gap is operational: no explanation of the action enum semantics, the optional provider/protocol inputs, or how verdicts should be interpreted.

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?

It adds real meaning for a few inputs: asset fields are returned as CAIP-19 ids and max_slippage_bps is described as a pre-committed tolerance fixed at 50, beyond the schema's const. But at 50% schema coverage with 10 params, it leaves the action enum, amount_usd, providers, protocol_id, source_group_count, and the nested decision_input quote shape essentially 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?

The description names a specific action and resource: certify a swap/DeFi intent and open a verifiable pre-trade evidence handle. It also states what the tool is NOT ("not trade authorization") and positions it temporally before execution, which separates it from prepare_swap and issue_execution_receipt in the sibling set.

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 trigger conditions ("when a principal needs a signed pre-trade handle to bind an execution receipt later") and explicit exclusions ("do not use it as trade authorization and do not call it after the trade"). It stops short of naming a concrete alternative sibling such as check_trade_safety for safety checks or issue_execution_receipt for the post-trade step, leaving that mapping implicit.

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?

No annotations are provided, so the description carries the full burden. It discloses the return payload (verdict with ALLOW/CAUTION/DANGER/BLOCK, reason codes, oracle evidence, signed attestation) and the important caveat that ALLOW is not principal authorization. It does not state whether the call is read-only, whether it records evidence, or what its cost or rate limits are.

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 text is front-loaded with purpose, then timing, exclusions, and the return shape. Four dense sentences all earn their place, though the laundry list of venues and chains in sentence one is slightly heavy.

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?

This is a complex, 32-parameter, polymorphic tool with nested objects and no output schema, and the description does cover the return values and the pre-trade gate's role. However, because it does not map the `action` values to the required parameter subsets (position, order, borrows, collaterals, market/side), an agent must infer this from the schema alone.

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 56%, so half the parameters rely on the description. The description adds real meaning only for `guard` (a family-native exact-call payload) and `mode`, and it does not explain which parameters each `action` enum value requires. That mapping is the main thing an agent needs, yet it is missing, 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 and resource: a pre-trade oracle safety gate. It names the covered action families (swaps, lending, perps, vault deposits, stress tests) and the chains (Base, Monad, EVM, Solana, Hyperliquid), which is enough for an agent to tell it apart from sibling tools such as get_oracle_price or prepare_swap.

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 timing ('immediately before an agent trades or signs'), an explicit exclusion ('do not use it after execution'), names the alternative to use instead (issue_execution_receipt), and warns that its ALLOW result is not principal authorization.

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?

No annotations are present, so the description carries the full disclosure burden. It states the tool is a read ('Read one reviewed venue market'), scopes it to 'reviewed venues', and describes what is returned, but says nothing about quote staleness, caching, auth or permission prerequisites, or failure behavior for unsupported venue/market combinations — meaningful gaps for a pre-trade data source.

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 front-loaded sentences with the core action first, followed by usage and boundaries, then return values. It is slightly dense and repeats 'reviewed' four times, but no sentence is 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 4-parameter read tool with full schema coverage and no output schema, the description supplies the trigger, the scope limits, and a summary of what comes back. Only the relationship among the overlapping venue/market/profile parameters and the freshness of the quote context remain unaddressed.

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 venue, market, venues, and profile_id are already documented, and the enums constrain values. The description adds only contextual framing ('reviewed profile ids', 'market id') and does not clarify how the plural 'venues' array relates to the singular 'venue' parameter or when profile_id is required — the one genuinely ambiguous interaction a caller would want explained.

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 concrete verb and resource — 'Read one reviewed venue market' — and enumerates the payload (pool/market metadata, pinned quote context, venue constraints) plus the supported chains, which distinguishes it from price-only siblings like get_oracle_price. The only softness is the tension between the tool name 'get_market_quote' and the description's emphasis on returning a market record rather than a standalone quote.

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 both a positive trigger ('Use it before preparing or gating a trade when the agent needs the reviewed profile or market id') and a negative boundary ('Do not use it as execution authorization or for prices outside the reviewed venues'). It does not explicitly name the sibling to use instead for execution or for non-reviewed prices, so routing is implied rather than 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?

No annotations are supplied, so the description carries the behavioral burden. 'Read' and 'Returns the matching health rows, verdicts, counts and timestamps' establish read-only semantics and a rough return shape, which is valuable given there is no output schema. However, for a 15-parameter tool it says nothing about permissions, data freshness/caching, result ordering, or how limit/offset interact, which an agent needs to call it confidently.

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 purpose, then usage, then return shape — a sound ordering with no filler. The middle sentence is a long enumeration of question types, which is dense but each item maps to a real metric in the schema, so it earns its place; minor trim possible.

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 15-parameter, annotation-free tool with no output schema, the description covers purpose, alternatives, scope selection and return contents, which is most of what is needed. Remaining gaps are pagination guidance (limit/offset behavior) and the ambiguous 'period' semantics, which the description could have resolved.

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 93%, so the schema already documents nearly every parameter and the baseline of 3 applies. The description adds scope-selection framing ('the selected scope') and the notion of matching 'rows, verdicts, counts and timestamps', but does not resolve genuine ambiguities the schema leaves — notably the 'period' unit ('hours or days') and how 'metric' defaults interact with 'scope'.

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 and resource ('Read oracle ecosystem, feed, provider, protocol or asset health') and enumerates the distinct surfaces covered, which maps directly onto the scope enum. It also explicitly names the two siblings it is not (get_oracle_price, check_trade_safety), so an agent can separate it from adjacent tools 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?

States the positive invocation context concretely — freshness, uptime, latency, anomaly, coverage, peg, exposure, incident and daily-report questions, and the framing 'before trusting a price or a protocol'. It then gives explicit exclusions with named alternatives for each ('Do not use it for a price quote (get_oracle_price) or for a trade gate (check_trade_safety)'), leaving nothing 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?

With no annotations provided, the description carries the full burden and does well: it discloses the cache dimension ("fresh or cached"), that results expose cache status and a source timestamp, and enumerates the returned fields including confidence/decimals. It stops short of describing error behavior, rate limits, or what happens when an asset is unsupported by a provider, which keeps it from 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?

Three sentences, front-loaded with the core action, then usage boundaries, then return shape. Every sentence earns its place with no restating of the tool name or 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 4-param read tool with no annotations and no output schema, the description supplies purpose, exclusions, an alternative, and an explicit list of returned fields. The remaining gap is failure-mode coverage (unknown provider, unsupported asset/chain combination), which is a minor omission for a read-only lookup.

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 all four parameters including force_refresh and chain are already documented in the schema. The description reinforces the single-provider semantics of "provider" and the cache concept behind force_refresh, but adds no syntax, format, or edge-case detail beyond the structured fields; 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 opens with a precise verb and scoped resource: "Read the current price one oracle provider reports for one asset." It immediately narrows the scope to a single provider, which distinguishes it from the cross-provider sibling get_price_analytics named later.

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 an explicit positive case ("a single fresh or cached provider read ... when a route quote needs a reference price") and explicit exclusions (cross-provider consensus, historical series, deviation/risk analytics) with the correct alternative tool named. Nothing is left 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses the intended analytical nature and return contents, but does not state permissions, rate limits, latency, data freshness, force_refresh behavior, failure modes, or an explicit read-only guarantee. For a 13-parameter analytics tool, those omissions are a meaningful but not fatal gap.

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 phrasing. Purpose, usage/exclusion, and return information are front-loaded in a logical order, and the dense enumeration in the first sentence is justified by the tool's broad analytical surface.

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 covers selection criteria, sibling alternatives, and the return shape, which is important because no output schema exists. Given the high schema coverage, it is largely complete for a complex 13-parameter tool, though it leaves out operational constraints and some parameter interaction details.

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 92%, so the schema already documents most parameters and sets the baseline at 3. The description adds conceptual grouping around consensus, history, spreads, deviation, correlation, and risk, but it does not clarify key interactions such as metric overriding mode, first-asset behavior for some modes, provider requirements for risk, or force_refresh semantics beyond what the schema already 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 names a specific verb and resource: 'Run multi-oracle price analytics,' then enumerates consensus, batch reads, historical series, cross-chain spreads, deviation, correlation, and risk summary. It also explicitly distinguishes the tool from get_oracle_price and get_oracle_health, so an agent can identify its scope without opening the 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?

It gives explicit when-to-use guidance: 'when one price is not enough' and the caller needs to 'compare, stress or trend oracle data.' It also gives explicit when-not-to-use guidance by naming get_oracle_price for single-provider spot reads and get_oracle_health for feed uptime.

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 no annotations, the description carries the full burden and does substantial work: it discloses the return shape (signed receipt, FAITHFUL/DEVIATED/NOT_EXECUTED/UNDETERMINED verdicts, price delta, binding ids, verify URL) and warns the verdict is not authorization to act. It does not state auth requirements, idempotency/replay behavior, or whether a receipt is persisted on failure — gaps for a signing tool.

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, then conditions, then return values — a sensible ordering in three sentences. The 'Use it only after the trade settled. Do not use it before execution' pair is mildly redundant, and the parenthetical '(or settlement status)' is a hedge that could be stated more crisply.

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?

Five parameters with nested objects, one enum, no output schema — the description compensates well by enumerating the returned fields and verdict values. It is still thin on the provenance of the 'pre-trade handle' and the 'signed guard decision', which an agent needs in order to assemble valid inputs across a multi-step flow.

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 60% and the schema already documents receipt/decision as mode-conditional and signature as a Solana signature. The description adds the mapping of modes to their inputs (pre-trade handle plus settlement transaction vs. guarded swap), but contributes no format, shape, or constraint detail for the nested receipt/decision objects beyond what the schema 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 opens with a specific verb+resource pair — 'issue a signed execution-price receipt' — and names both operating modes (receipt from a pre-trade handle + settlement tx, or settle a guarded Base/Solana swap). An agent can tell this is a post-execution close-out tool distinct from prepare_swap or check_trade_safety without opening the 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?

It gives an explicit gate — 'Use it only after the trade settled. Do not use it before execution' — plus a negative constraint that the verdict is not principal authorization. What's missing is naming the upstream sibling (e.g. prepare_swap / begin_trade_evidence) that produces the pre-trade handle, so the agent must infer which tool precedes 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?

No annotations are supplied, so the description carries the burden itself. It labels the operation as a read, discloses the response payload ("current trust signal ... with provider participation and freshness"), and clarifies the snapshot-versus-history behavior, but it says nothing about rate limits, cost, or authentication for a data-fetching tool that sells adjacent windows.

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: capability first, usage scope second, exclusion and alternative third. No restatement of the name, no filler, and the most decision-relevant information is 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?

There is no output schema, so the description must describe returns, and it does name the trust signal plus provider participation and freshness. The remaining gap is the three undocumented optional parameters, which matters because `days` and `interval` drive what the history mode actually returns.

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 20%, with just `symbol` documented, so the description needs to compensate. It does explain the `op` distinction between snapshot and history and hints at the history series, but `days`, `interval`, and `chain` are left entirely unexplained, and `chain` is undocumented in both places.

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: "Read one oracle-trust snapshot or historical series for an asset." It also explicitly separates the tool from its closest sibling, oracle_watch_window_begin, so an agent can choose between them without inspecting either 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?

It states both the positive case ("a one-off check of whether a symbol is currently trustworthy or how its recent history looks") and the exclusion ("Do not use it for continuous monitoring"), then names the alternative tool to use instead. That is the full when/when-not/alternative triad.

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 no annotations, the description carries the full burden and does substantial work: it discloses that the call is a purchase that charges credits, that the control token is one-time and must never be shared, that re-purchasing the same window is discouraged, and what the response contains. It does not state funding/payment prerequisites, whether a failed or duplicate purchase is refunded, or what happens if the token is lost, which is the main remaining gap for a paid mutation.

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?

Four short sentences, front-loaded with the action and the return, then the usage condition, the prohibitions, and the response shape. Every sentence carries distinct information with no restatement of the name.

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 two-parameter paid mutation with no annotations and no output schema, the description covers purpose, cost, return fields, and token hygiene. The omissions are the undocumented 'chain' parameter and the lack of any statement about payment source or failure/refund behavior.

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 'symbol' is documented in the schema (50% coverage), and the description adds no parameter-level meaning at all beyond the phrase 'for one asset'. The 'chain' parameter is undocumented in both the schema and the description, so an agent gets no guidance on whether chain is required, defaults, or which values are accepted.

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: 'Buy a 24h Oracle Watch window for one asset and return the one-time control token.' It immediately distinguishes the tool from the per-snapshot sibling by contrasting 'poll throughout a window' with 'paying per snapshot', so an agent can differentiate it from oracle_watch and oracle_watch_window_control without opening either 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?

It gives an explicit when-to-use condition ('an agent will poll throughout a window instead of paying per snapshot') and an explicit when-not ('Do not use it repeatedly for the same window'). The alternative is described functionally rather than named, so the agent must infer that oracle_watch is the pay-per-snapshot path and that oracle_watch_window_control is the follow-up for an existing window.

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 no annotations, the description carries the full burden and does well: it discloses the credit model (poll is zero extra credits after purchase), the one-time token constraint, and that close destroys the window's usability for future polls. It does not cover failure behavior (e.g. polling a token after close, expired tokens) or latency, which keeps it below 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?

Four short sentences, front-loaded with the verb+resource and followed by cost, precondition, and exclusions. Slightly redundant: the return values are stated twice ("Poll returns a fresh signal... close returns the complete window summary and the final signal" then "Returns the signal (poll) or the combined summary (close)").

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?

There is no output schema, so the description must describe returns, and it does for both operations. With no annotations it also supplies the safety/lifecycle context (one-time token, no reuse, zero-credit polling). Only error and expiry behavior is left unstated for what is a token-gated two-mode 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 coverage is 67% and the schema itself explains only op and window_token. The description adds real meaning beyond that: the token is one-time, poll costs no extra credits while close finalizes the window, and window_id is implicitly the purchased window identifier. The op enum semantics are largely restated rather than extended.

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 pair of verbs (poll/close) against a named resource (an already purchased Oracle Watch window) plus the credential used (one-time oww_ token). It is clearly distinguishable from oracle_watch_window_begin (purchase) and oracle_watch (one-off snapshot).

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 names the required precondition ("only with a window token from oracle_watch_window_begin"), names the sibling to avoid and why ("Do not use it for a one-off snapshot (oracle_watch)"), and adds a lifecycle rule ("never reuse a token after close"). When, when-not, and alternatives are all covered.

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 no annotations, the description carries the disclosure burden and does well: it reveals the prepaid 24h window, one-time token semantics, that credits are charged, and a don't-share security rule. It stops short of stating what happens to unused credits or whether the bundle expires mid-flow.

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?

Four tight sentences, front-loaded with the action and followed by usage boundary, exclusion, security rule, and return fields — nothing redundant.

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 token-issuing mutation tool with no annotations and no output schema, it covers cost, lifetime, returns, and safety. The remaining gap is the unexplained chain parameter and failure/expiry edge behavior.

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 only 50%, and the description clarifies that symbol is the 'position subject' but says nothing about the chain parameter or accepted symbol formats. It adds partial meaning over the schema rather than fully compensating for the undocumented chain field.

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 ('Buy a 24h Position Lifecycle bundle for one position subject') plus the one-time return value, which lets an agent separate it from position_lifecycle_step and check_trade_safety without inspecting 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?

Explicitly names the when ('agent needs guard, execution-receipt and close steps inside one prepaid window') and the when-not with the alternative to use instead ('single guard -> check_trade_safety'), plus a security constraint on the token.

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 no annotations, the description carries the full burden and does disclose meaningful behavior: guard and receipt are free inside the bundle (credit implications), the lifecycle_token is one-time, and it must not be reused after close (a mutation side effect). It does not state whether close itself costs credits, whether close invalidates lifecycle_id, or what errors occur on token misuse — notable gaps for a stateful mutation tool.

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 op enumeration, then cost, then return, then constraints — a sensible order. The sentences are dense and multi-clause, but nearly every clause carries information; there is little 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?

No output schema and no annotations, so the description must cover everything, and it does state what is returned ('guard verdict, signed receipt, or the combined lifecycle summary'). Still missing are which parameters apply to which op (e.g. family for guard, receipt for receipt), the purpose of `transaction`, and lifecycle state behavior after close — substantial gaps for a 7-parameter, nested-object 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 coverage is only 43%, and the description compensates partially: it defines the three op values and the one-time nature of lifecycle_token, and implies lifecycle_id identifies the bundle. However, `family` (enum of six families, presumably required for guard), `params`, `receipt`, and especially `transaction` (which has no schema description at all) are never explained in the description, so several parameters remain opaque.

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 ('Run one step inside a purchased Position Lifecycle bundle') and enumerates the three operations with one-line meanings: guard as a family-specific safety assessment, receipt as a signed execution receipt, close as a combined summary. It is clearly distinct from position_lifecycle_begin, but it does not distinguish guard from the sibling check_trade_safety, leaving one obvious overlap unresolved.

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?

Explicit preconditions and exclusions are given: 'Use it only with a lifecycle token from position_lifecycle_begin', 'Do not use it for unrelated positions', and 'never reuse a token after close'. What is missing is routing guidance for an agent that wants a safety assessment without a purchased bundle, i.e. no statement to use check_trade_safety instead.

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 no annotations supplied, the description carries the full burden and does well: it discloses that the output is unsigned and short-expiry, that no sign/submit side effects occur, and that bounded validation gates (lot/tick, impact, mark-oracle) must all pass. It stops short of describing what happens when a gate fails (error shape) or any permission/auth requirements, so it is strong but not exhaustive.

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 purpose and immediately followed by the usage boundary and the return contract. The long middle sentence is dense but each clause (preconditions, three named gate types) earns its place; no redundant restatement of the tool name.

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 tool is complex (13 params, 10 required, nested builder_fee object, no annotations, no output schema), and the description covers the return payload in one line. However, it omits gate-failure behavior, defaults for optional params like expires_after_seconds and require_full_fill, and any explanation of the notional/impact cap semantics that an agent must set 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 only 23% across 13 parameters, so the description must compensate and largely does not. It names market, side, size, and limit price and gestures at impact and mark-oracle thresholds, but leaves max_notional_usd, reduce_only, require_full_fill, client_order_id, expires_after_seconds, and builder_fee with no added meaning, defaults, or interaction rules.

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 gives a specific verb plus a precisely scoped resource: an 'unsigned Hyperliquid BTC/ETH/HYPE perpetual IOC order envelope for local wallet signing'. Venue, instrument set, order type, and the non-signing boundary are all stated, which cleanly separates it from siblings like prepare_swap and issue_execution_receipt.

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 exact precondition for use ('when an agent has decided on market, side, size and limit price and needs reviewed lot/tick, impact and mark-oracle checks') and explicitly excludes three adjacent actions: nonce creation, signing, and submission. Nothing about when to call or when not to call is left 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?

With zero annotations, the description carries the burden and does disclose key behavior: it produces unsigned calldata only, never signs or submits, requires a reviewed pool and policy, and returns to/value/calldata plus quote and an optional signed decision. It does not cover operational traits an agent would want — whether repeated calls are idempotent, whether a safety gate must be called first in a specific order, or authorization/wallet-binding requirements.

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?

Four sentences, each doing distinct work: capability and venue scope first, then the use condition, then the exclusions, then the return contract. No restatement of the title and no filler; the return-value sentence is necessary because no output schema 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 18 parameters, four heterogeneous venues, nested policy object, no annotations and no output schema, the description covers the purpose and return contract well but is incomplete on the two things that most affect correct invocation: which parameters each venue requires and how this tool sequences with the safety-gate and evidence siblings.

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 11% on 18 parameters, so the description must compensate and largely does not: it adds no per-parameter meaning beyond the venue names and a vague reference to a 'reviewed pool and policy'. Critically, it never explains that parameters are venue-dependent (vault/loan_symbol/principal_amount/collateral_* for Loopscale, direction/min_lp_amount for the V3-style venues, max_slippage_bps/deadline_unix_seconds generally), leaving the agent to guess which of the 18 fields apply to its chosen venue.

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 (prepare) and a specific artifact (unsigned, reviewed swap calldata), then enumerates the four supported venues by name (Aerodrome Slipstream, PancakeSwap V3, agent swap guard, Loopscale vault). An agent can distinguish this from quote, safety-check, and receipt siblings immediately; output is described as a calldata envelope for local signing.

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?

Explicit when-to-use ('user wants an executable transaction bound to a reviewed pool and policy') and explicit when-not ('do not use it to sign, submit or route arbitrary calldata', 'do not skip the matching safety gate'), which implicitly routes to the safety-gate sibling. What is missing is naming the concrete alternatives for the adjacent cases (get_market_quote for pricing only, check_trade_safety for gating, issue_execution_receipt for recording), so the agent must infer those routes.

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 no annotations, the description carries the full behavioral burden. It does disclose the return shape ("matching registry rows or one lookup record, with ids and reviewed metadata"), which is genuinely useful, but it never states that the call is read-only and side-effect free, nor how limit/offset pagination behaves or what happens when a lookup finds nothing.

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 short sentences, each doing distinct work: scope, intended use, exclusion, and return shape. The most decision-relevant content (what it searches and the id-discovery purpose) is front-loaded with no filler or restated title.

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 an eight-parameter, one-required discovery tool with no output schema, the description covers scope, purpose, exclusions, and the rough return shape well enough to call it correctly. The remaining gap is that applicability of filters by kind (chain_id only for feeds, verify_onchain only for RWA lookups) is left entirely to the 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?

Schema description coverage is 100%, so the schema already documents all eight parameters and the enum values for kind and category, making 3 the baseline. The description adds only that results may be "one lookup record" versus multiple rows, and it does not explain that filters such as chain_id, category, and is_active are kind-conditional.

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 ("Search") plus the exact resource families it covers, enumerating them (symbols, feeds, protocols, stablecoins, protocol risk parameters, RWA instruments/context, settlement-evidence packs, setup recommendations). It also names what it is not ("Do not use it to read live prices or health"), which separates it cleanly from get_oracle_price, get_oracle_health, and the prepare/verify 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?

Gives an explicit positive use case — discover the exact ids that a price, safety or execution tool expects — which routes the agent here as a first step before calling check_trade_safety or get_oracle_price. It also gives an explicit exclusion ("Do not use it to read live prices or health"), so both the when and the when-not are stated rather than 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?

With no annotations, the description carries the full burden, and it does disclose that this is a non-authorizing, non-risk-assessment check and describes the response payload (valid/invalid, closed-loop or settlement status, binding assertions, machine-readable reasons). It leaves unstated whether verification has any side effects (e.g. recording a verification), any auth/permission requirements, or limits on evidence size — relevant for a tool ingesting large nested objects.

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 scope first, then the use case, then the exclusions and return shape. No filler and nothing redundant with the title or schema.

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?

There is no output schema, but the description summarizes the return payload, and it clearly fences off the sibling risk/trading tools, which covers a lot of ground. However, for a nine-parameter, four-variant, nested-object tool with no annotations and zero schema descriptions, the definition never explains the per-kind parameter contract, leaving a real gap an agent must guess around.

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% across nine parameters, including five free-form nested objects (settlement, expected_order, execution_receipt, pre_trade_attestation, destination_pre_trade_attestation), so the description must compensate and largely does not. It never says which parameters belong to which `kind` — e.g. that execution_pair needs expected_order + execution_receipt + pre_trade_attestation while hyperliquid_perp needs user + order_id — nor what shape the attestation objects must take. Only a loose mapping is inferable from the enumerated artifact 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?

States a specific verb (verify) and resource (signed evidence) and then enumerates exactly the four artifact classes that match the `kind` enum: pre-trade/execution pair, Base agent-swap settlement, Solana swap settlement, Hyperliquid order/fill record. This lets an agent distinguish it from siblings like issue_execution_receipt (produces evidence) or check_trade_safety (assesses risk) 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?

Gives an explicit trigger ('when a third party needs to check binding and signatures before trusting a claim') and two explicit exclusions ('do not use it to re-assess oracle risk or to authorize trading'), which implicitly routes to the oracle_* and begin_trade_evidence/check_trade_safety families. It stops short of naming the alternative tools, so the agent must infer the routing from function descriptions.

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