The Spice Melange Trading Desk: DeepBook market data connector

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

Annotations give the safety profile (readOnlyHint=true, destructiveHint=false), and the description adds genuinely new context: the transaction is simulated against mainnet, returned unsigned, never executed, and the service is non-custodial and holds no keys. This explains why a 'deposit' is correctly flagged read-only rather than contradicting it. It stops short of describing constraints like slippage/expiry or the returned tx format.

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 action and output type are front-loaded in the first two sentences. The tail clauses repeat the custody/unsigned message ('never sees or holds keys and never moves funds' vs. 'UNSIGNED transactions only') and the boilerplate 'Education only' line, which is slightly redundant but not wasteful enough to hurt.

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 build-transaction tool with no output schema, the description covers the essentials an agent needs: what it produces (unsigned bytes), that it is a mainnet simulation, and the non-custodial safety model. It omits what the caller must do with the bytes (sign/submit) and any assumption about the sender owning the BalanceManager, which would have made it 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 all four parameters (sender, balance_manager_id, coin, amount) are already documented with formats and bounds. The description adds no additional parameter meaning beyond restating the coin source; baseline 3 applies when the schema does the heavy lifting.

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 ('Deposit a coin from your wallet into your own BalanceManager') with an explicit scope qualifier ('your own'), which cleanly separates it from the sibling build_bm_withdraw_tx. It also pins the output artifact ('Returns UNSIGNED tx bytes').

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?

Implied usage is clear: you deposit into a BalanceManager you already own, and the schema notes the id comes from build_create_balance_manager_tx effects. However, the description never names the alternative tools (e.g. build_bm_withdraw_tx for the reverse, build_create_balance_manager_tx as the prerequisite) or states when not to use 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?

Adds meaningful context beyond the annotations: it returns UNSIGNED tx bytes simulated against mainnet, never signs or submits, and never moves funds or holds keys, which reconciles the readOnlyHint=true on a transaction-building tool. It stops short of covering auth requirements or rate limits, but the safety/return profile is well disclosed.

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 correctly with the action, but the 'UNSIGNED' return point is repeated twice and the closing 'Non-custodial...' plus 'Education only, not financial advice' boilerplate is generic across the toolset, diluting the concise core.

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 carries the return contract (unsigned tx bytes, simulated against mainnet) plus custody and scope limits. For a build-tx tool this is nearly complete, missing only submission/usage flow 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?

Schema description coverage is 100%, so the schema already documents all four parameters (coin symbols, amount in human units, sender address, BalanceManager id). The description adds no parameter-level detail, 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+resource+scope: 'Withdraw a coin from your own BalanceManager back to your address (always to the owner).' The direction (withdraw) and destination (owner) cleanly separate it from build_bm_deposit_tx without needing to open 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?

The purpose implies when to use it (to pull funds out of a BalanceManager), but there is no explicit when-to-use guidance, no prerequisites, and no reference to the sibling build_bm_deposit_tx as the reverse alternative. Usage is only inferable.

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/destructive, so the fact that this returns bytes rather than executing is partly covered. The description adds genuinely non-redundant context: it returns UNSIGNED transaction bytes simulated against mainnet, keys are never held, and funds are never moved by the desk. It does not, however, note whether cancelling is reversible or what happens to partially-filled orders.

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 action and scope, then the return contract and safety caveats. The 'Spot only, no leverage' and 'Education only, not financial advice' clauses are near-boilerplate, but the sentence count is small and nothing is buried.

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 exists, and the description carries the key return contract (unsigned tx bytes, mainnet simulation) plus the non-custodial safety model, which is what an agent needs before calling. Remaining gaps — error/edge behavior and the exact downstream signing step — are minor for a tx-builder 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 75%, with order_id carrying no schema description beyond maxLength. The description compensates by explaining that order_id selects the single-order mode versus the all-orders mode, adding semantic meaning the schema lacks. Pool/balance_manager_id semantics are left entirely to the schema, which covers them adequately.

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 ('Cancel one order (order_id) or all your orders in a pool') plus the side effect (withdraw settled amounts into BalanceManager) and the return shape (UNSIGNED tx bytes). It is immediately distinguishable from read-side siblings like get_order_book or quote tools, though it never names a sibling (e.g. build_limit_order_tx) to contrast against.

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 implies the call-time mode switch — pass order_id to cancel one order, omit it to cancel all orders in the pool — which is useful framing. However there is no explicit when-to-use/when-not guidance, no prerequisite ordering relative to build_create_balance_manager_tx or build_bm_deposit_tx, and no stated alternative tool for related flows.

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 flag readOnlyHint=true, and the description reinforces rather than contradicts this by stressing it returns UNSIGNED tx bytes and never moves funds. It adds real behavioral context: simulated against mainnet, non-custodial (keys never seen/held), spot only, no leverage. A bit more on what the returned bytes are meant for would push it higher.

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 ('Create and share...'), followed by return format and risk qualifiers. Mostly tight, though the trailing 'Education only, not financial advice' is boilerplate that slightly dilutes the focus.

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 exists, and the description correctly explains the return (unsigned, simulated tx bytes) plus the non-custodial and spot-only constraints. An agent has enough to call it and interpret the result, though nothing states whether sender must already have funds/setup.

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 one fully documented parameter (schema coverage 100%), the schema already carries the meaning of 'sender'. The description's 'owned by your address' loosely maps to it but adds no syntax or format detail beyond the schema. 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+resource (create and share a DeepBook v3 BalanceManager), scopes ownership to your address, and ties it to its role (needed for limit orders). This clearly distinguishes it from siblings like build_limit_order_tx, build_bm_deposit_tx, and build_swap_tx 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?

'needed for limit orders' gives a concrete precondition that tells an agent when this build step is required. It is clear context but offers no explicit exclusions or named alternatives beyond the implicit prerequisite relationship.

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 supply safety hints; the description adds substantial behavior: it returns UNSIGNED tx bytes simulated against mainnet, validates tick/lot/min size, charges fees in the input coin (no DEEP), and is non-custodial. These disclosures go well beyond what readOnlyHint/destructiveHint provide, and they reinforce rather than contradict the read-only 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 core action is front-loaded, but the text is padded with redundancy: 'No leverage' and 'Spot only, no leverage' repeat, and 'Returns UNSIGNED tx bytes' is restated as 'returns quotes and UNSIGNED transactions only.' The 'Education only, not financial advice' disclaimer is boilerplate rather than tool guidance.

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 exists, so the description correctly states the return (unsigned tx bytes). For a 10-parameter tx-building tool it covers the essential behavioral facts (constraints, fees, custody model), though it omits per-parameter detail on several fields.

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% (10 params, several undocumented). The description clarifies deposit_first ('funds it in the same tx') and the fee-coin semantics, but pool/side/price/quantity/post_only/expire_hours/client_order_id are left entirely to the schema. It adds partial value but does not compensate for the coverage 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 specific verb and resource ('Place a spot limit order on a DeepBook v3 pool from your BalanceManager') with clear scope (spot only, v3). An agent can distinguish it from build_swap_tx, build_cancel_order_tx, and the deposit/withdraw siblings 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 scope constraints (spot only, no leverage, from BalanceManager) and mentions the deposit_first option, which implies when it applies. However, it never names an alternative tool or an explicit when-not condition, so routing versus build_swap_tx 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?

Adds substantial context beyond the annotations: the returned bytes are simulated against mainnet before return, nothing is executed by the desk, the caller signs locally and submits, and the desk is non-custodial. This clarifies the readOnlyHint=true profile (no world mutation, no key access) rather than contradicting 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?

Purpose and mechanics are front-loaded in the first two sentences; the remainder is compliance boilerplate. The non-custodial point is made twice ('nothing is executed', 'never moves funds') which is mildly redundant but not wasteful enough to derail the definition.

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 correctly discloses the return artifact (base64 unsigned tx bytes) and its simulation status, plus the submit-yourself flow. 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?

Schema description coverage is 88%, so the schema already documents from/to/amount/sender/venue/route/simulate/slippage_bps. The description re-states sender and min-out semantics ('on-chain minimum-out from slippage_bps') without adding format or edge-case detail beyond the schema, so the 3 baseline 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+resource (build unsigned Sui swap transaction bytes) and names the scope constraints (chosen venue, sender address, min-out from slippage_bps). An agent can distinguish this from sibling builders like build_limit_order_tx or build_bm_deposit_tx purely from the text.

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 implied usage constraints ('Spot only, no leverage', 'the chosen venue') but never explicitly says the venue/route must come from get_swap_quote first, nor names an alternative tool for different order types. The when-to-use context exists but is left for the agent to infer.

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 context beyond the annotations: output is UNSIGNED tx bytes simulated against mainnet, the tool is non-custodial and never moves funds, content resembling a secret is rejected, and the fee is paid in WAL by the caller. This is exactly the behavioral detail an agent needs before invoking a tx-building 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?

The actionable content is front-loaded and efficient, but the trailing 'Spot only, no leverage. Education only, not financial advice.' sentences are boilerplate that does not help an agent select or call the tool. Roughly a third of the text is non-functional.

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 exists, so the description carries the return burden and does so reasonably (blob_id plus unsigned tx bytes). Combined with the refusal behavior and the pointer to walrus_store_guide, an agent has enough to act, though the epochs parameter remains unexplained.

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 33%: 'sender' is documented in the schema and 'content' is loosely implied by 'public text (receipt/note)'. The description adds no guidance for 'epochs' (range 1-53, default 3), leaving one of three parameters 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?

States a specific verb (build) and resource (Walrus register-blob tx), names the payment asset (WAL), and declares the primary return value (blob_id). It is easily distinguished from sibling builders like build_swap_tx or build_bm_deposit_tx, which target entirely different protocol actions.

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 the follow-on step explicitly ('Then upload+certify locally (see walrus_store_guide)'), routing the agent to the correct companion tool. It also states an input precondition ('Refuses content that looks like a secret'), but never spells out when-not-to-use against siblings such as read_walrus_blob.

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, destructiveHint=false and openWorldHint, and the description is consistent with them, adding that the check is an on-chain mainnet lookup. The remaining behavioral claims (non-custodial, never holds keys, returns unsigned transactions, spot only) describe the desk generally, not this read-only check, and add little for this tool specifically.

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 and gating behavior are front-loaded correctly, but roughly half the text is trailing boilerplate ('non-custodial... never moves funds', 'Spot only, no leverage', 'Education only, not financial advice') that is not actionable for a holder check and dilutes the signal.

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 single-parameter gating probe with no output schema, the description covers what the call means and what the result gates, but never states the return shape (e.g., a boolean held/not-held), which an agent must know to branch on the result.

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 one parameter at 100% schema description coverage, the schema already documents 'address' as the caller's public Sui address with the warning never to send a key. The description adds no further syntax, format, or constraint detail beyond that baseline.

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 ('check'), a specific resource (the Secret Journals license token), and the exact chain (Sui mainnet), so the agent knows this is an on-chain license-gating probe rather than a balance or market call. No sibling tool does this, so it is unmistakable in the toolset.

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 explains the consequence of each result: holders unlock the extra read-only tool golden_path_market_read, non-holders retain all basic tools, which is genuinely useful routing information. It stops short of saying when in a workflow to call it (e.g., before attempting gated tools), so it is clear context rather than 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?

Annotations already cover the mutation profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), and the description adds genuinely new context: the token travels only in a header to the store and is never persisted, and the connector holds no keys or funds. It still omits failure behavior (unmatched digest, unpaid order) and any retry/rate-limit notes.

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 mode logic is front-loaded and well ordered, which is exactly right. However, two sentences of transactional legal boilerplate ('not financial advice', 'all sales final') do not help an agent select or invoke the tool and dilute an otherwise tight definition.

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 does carry return-value burden and handles part of it (signed download link plus add-ons; status plus a fresh link once paid). For a payment-verification tool it still leaves error and partial-payment outcomes unspecified, so it is strong 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?

Schema coverage is 100%, so a baseline of 3 applies, but the description goes further by explaining the semantic role of 'digest' as the mode switch rather than just 'a Sui transaction digest'. The 'plus add-ons' phrase slightly enriches the intended output of the digest path.

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 ('verify your on-chain payment for an order and get the signed download link') and clearly splits the tool into two modes based on the presence of the digest parameter. An agent can tell it apart from create_template_order or list_templates 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?

Gives an explicit conditional: use with a digest to verify a payment and mint the download link, omit it to poll order status. It does not name siblings (e.g. create_template_order) or state when this tool should *not* be used, so it falls short of a full when/when-not/alternatives statement.

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 declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false, but the description adds materially beyond them: nothing is charged by this call, the private token is shown once and must be kept secret, the payee and exact amount must be paid from the caller's own wallet before expiry, and the connector never holds keys or funds. This is exactly the kind of safety and side-effect context a write-path tool 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?

The most important facts are front-loaded: purpose, then return values, then payment obligations and limits. It runs long as a single paragraph, and the legal boilerplate ('no returns promised. All sales final...') is lower-value filler for an agent selecting a tool, but nothing is genuinely 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?

With no output schema, the description carries the return-value burden and does so fully (order id, PRIVATE token shown once, payee, exact USDC amount, expiry). Combined with payment mechanics, custody disclaimer, and rate limits, an agent has everything needed to call and follow up 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 sku documented as sourced from list_templates and email as an optional receipt address. The description adds no parameter-level detail (no mention of the sku pattern or the email field), so it neither compensates for nor extends the schema. Baseline 3 applies when the schema carries parameters.

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 opening sentence states a specific verb and resource ('Create a store order for one template') and immediately follows with the concrete artifacts returned (order id, private token, payee, exact Sui USDC amount). This is clearly distinguishable from siblings like list_templates (enumeration) and check_template_order (status lookup).

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 lays out the usage flow well: create the order, then send the exact USDC amount from your own wallet before expiry, implying check_template_order as a subsequent step. It also states the rate limit context ('a few orders per client per hour'). It stops short of explicitly naming an alternative tool or stating when NOT to use it, so it is clear context without exclusions.

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, yet the description goes well beyond them: free tier of 100 calls/day per client, 0.002 USDC per call thereafter, prepaid batches of ~0.01 USDC, a payment-required response carrying an exact amount and payment_token, and a data-staleness disclaimer. That is exactly the extra behavioral context (cost, rate limits, auth flow, reliability) 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?

Two sentences, front-loaded with the core purpose and the input-token-vs-DEEP comparison before the disclaimers and pricing mechanics. The payment-tier sentence is long and detail-dense, but every clause (amount, batch size, payment_token) earns its place for a paid 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?

For a 6-parameter, no-output-schema tool the description covers purpose, the two fee outputs being compared, the maker/taker dimension, and the full paid-tier flow. It stops short of describing the response shape (e.g. whether both fee figures are returned), which matters slightly more given there is no output 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 coverage is 83% so the baseline is 3, and the description adds genuine meaning on top: it explains the maker/taker role as the fee-mode switch and frames payment_tx/payment_token as post-free-tier inputs tied to the payment-required response. It does not add format or syntax detail for qty/price beyond the schema, so it stops short of a 5.

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 (estimate) and resource (DeepBook fee for a fill of qty at price), and states the exact computation basis: input-token rate x 1.25 versus DEEP base rate, using live on-chain rates and the DEEP_USDC mid. This is unmistakably distinct from siblings like get_mid_price or get_pool_params, so an agent can select it 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?

Usage is implied (fee estimation for a prospective fill) and the payment-tier conditions are spelled out, but there is no explicit when-to-use versus alternatives, nor any stated exclusions such as 'do not use for actual order pricing' beyond the education-only disclaimer. Adequate but leaves the routing decision 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 readOnlyHint, idempotentHint and destructiveHint=false, but the description adds real context beyond them: a concrete rate-limit/cost model (100 calls/day free, then 0.002 USDC per call, prepaid in ~0.01 USDC batches), the payment-required handshake, and an explicit data-quality caveat ('may be delayed or wrong'). It stops short of describing pagination or truncation behavior at the 200-limit cap.

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 purpose and scope are front-loaded and the paragraph wastes little space on the mechanics an agent needs. The 'Education/information only; not financial advice' clause is boilerplate that does not help tool selection and slightly bloats an otherwise dense single paragraph.

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 correctly carries the return-shape burden, listing the fields and newest-first ordering, and it covers the payment workflow end to end. What is missing is behavior at the limit boundary (truncation/pagination) and the meaning of the hours window.

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 71%, so most fields are documented, yet the description still adds meaning: it clarifies the maker/taker framing behind the role parameter and the exact pricing/batching mechanics behind payment_tx and payment_token, which the schema only sketches. It adds nothing for hours or limit, which remain undocumented defaults.

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 ('Fills (OrderFilled) where a given DeepBook BalanceManager was the maker or the taker in one pool') and specifies return contents (time, side, price, qty, fee, tx) plus ordering ('newest first'). The balance-manager-plus-pool scoping cleanly separates it from sibling market-wide tools like get_recent_trades or get_order_book.

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 by scope (fills tied to one BalanceManager in one pool) but there is no explicit when-to-use / when-not guidance and no sibling is named as an alternative. The one genuinely directive element is the two-step payment flow (free tier first, then payment_tx/payment_token after the payment-required response), which is a retrieval precondition rather than a use-vs-alternatives rule.

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/non-destructive, so the safety profile is covered. The description usefully adds the on-chain source and return shape (bids/asks [price, qty]), but the non-custodial/keys/unsigned-tx boilerplate is nearly meaningless for a read tool and does not add behavioral insight.

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 clause is well front-loaded, but roughly half the text is compliance boilerplate ('Non-custodial... never sees or holds keys...', 'Education only, not financial advice') that does not help an agent select or invoke this 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?

Return format is stated, which compensates for the absent output schema, but one of two parameters (ticks) is unexplained and the boilerplate crowds out real gaps. Adequate but with clear omissions for a 2-param 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 50%: 'pool' is documented but 'ticks' (default 10, range 1-50) has no schema description and the description never explains it. 'Around mid' vaguely implies depth levels, but the depth-count parameter and its bounds are left 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?

States a specific verb+resource+scope: 'Level-2 depth around mid read on chain from a DeepBook v3 pool (bids/asks [price, qty])'. An agent knows exactly what data comes back. However, it does not differentiate itself from the sibling get_order_book, which sounds like the same capability, so it falls 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?

No when-to-use guidance, no mention of when to prefer get_order_book, get_mid_price, or get_pool_stats instead. The only conditions given ('Spot only, no leverage', 'Education only') are product disclaimers, not invocation 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds a non-custodial statement, but the claim that it 'returns quotes and UNSIGNED transactions only' is generic desk boilerplate that does not describe this read-only state lookup and could confuse an agent about what the call actually returns.

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 statement is front-loaded and the field list is efficient. The trailing sentences ('Non-custodial... never moves funds', 'Education only, not financial advice') are disclaimer boilerplate that does little for an agent deciding whether to call a read-only pool-state 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?

With 3 parameters, none required, no output schema and no enum constraints, the description covers the broad shape of the response and the two input modes. It does not say what happens when both optional modes are omitted, nor how route discovery is scoped to 'current' pools, leaving a gap for a parametrically loose 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%: from/to carry enum-like symbol lists, but pool_id has no description at all. The description usefully clarifies the either/or semantics (pool_id lookups vs. from->to route discovery), which the schema does not express, but it adds no format or validity detail for pool_id itself.

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 ('Read-only Cetus CLMM pool state ... by pool_id') and enumerates the returned fields (coins, fee rate, tick spacing, liquidity, tick, price). It is clear what the tool does, though it does not name the near-neighbour siblings (get_pool_params, get_pool_stats, list_pools) to sharpen the boundary.

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 implies two usage modes — look up one pool by pool_id, or discover pools on the current from->to route — which is real guidance. But it never states when to prefer this over list_pools, get_pool_params or get_pool_stats, so the agent must infer the split from the sibling names alone.

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 readOnly/idempotent/openWorld annotations: the data source URL, ed25519 signature verification against a pinned release key, fail-closed behavior on signature mismatch, and explicit content constraints (no orders, no monetary sizes, no promised returns, not financial advice). The fail-closed semantics are exactly the kind of trait annotations cannot 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?

A single dense sentence plus two short disclaimer clauses, front-loaded with the source and payload contents. Every clause carries information, though the disclaimer tail could be trimmed slightly.

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 the returned content categories and stating the integrity guarantee and failure mode. Nothing an agent needs to call and interpret this tool correctly appears to be 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 takes zero parameters, so the schema has nothing to document and the description needs to add no parameter meaning. Baseline 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?

States a specific resource and enumerates its payload (focus pools, ladder windows, rung guidance, rebalance ranges, projects, lessons), which lets an agent distinguish it immediately from the market-data siblings like get_ohlcv or get_order_book. The verb is implicit in the tool name but the purpose is 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 establishes context ('guidance only: no orders, no sizes in money, no promised returns') but never states when to call it versus alternatives, nor any prerequisites for invoking it. Usage is only implied by the content summary.

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, destructiveHint=false and openWorldHint, so the safety profile is covered structurally. The description adds genuinely new context beyond that: the data is public and 'may be delayed or wrong', which tells the agent how much to trust the result. The 'education only / not financial advice' line is boilerplate but not contradictory.

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, front-loaded with what is returned and followed by when to use it. It is well-sized, though the legal disclaimer sentence is padding that does not help the agent invoke 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?

For a zero-parameter read-only status endpoint with no output schema, the description is nearly complete: it says what comes back, when to call it, and how reliable the data is. Annotations carry the safety profile. Nothing essential is missing, though return-value structure is only sketched rather than detailed.

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, so there is no parameter semantics to document and the baseline is 4. The parenthetical list of returned fields (status, latest checkpoint, server time) is a useful stand-in for the absent output 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 resource (the public DeepBook indexer) and enumerates what it reports: status, latest checkpoint, server time. That is much more concrete than a generic 'health check'. It does not explicitly differentiate itself from the many market-data siblings, keeping it 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?

'Use when data looks stale' gives a clear triggering condition for invoking the tool, so the agent knows when it is relevant. There is no explicit when-not guidance or reference to an alternative diagnostic tool, but for a single-purpose status endpoint the context is sufficient.

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 (which cover readOnly/idempotent/openWorld safety), it discloses rate limits (100 calls/day), per-call cost (0.002 USDC), the prepaid batch model, and a data-quality caveat ('may be delayed or wrong'). That is substantive operational context an agent cannot get from the structured fields.

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 return payload is front-loaded in the first sentence, followed by a compact compliance line and a pricing/access sentence. The 'not financial advice' line is boilerplate but short and relevant; overall density is good with no redundancy between sentences.

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 correctly enumerates the return fields (bid, ask, mid, spread abs/bps, last trade), and it also covers cost, access tiers, and data reliability. An agent has everything needed to call this and interpret the result without opening anything else.

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 pool, payment_tx, and payment_token are already fully documented in the schema, including format examples and the plb_ pattern. The description's mention of payment_token and the payment-required response restates schema content rather than adding new semantics, 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 names a specific verb ('get') and enumerates exactly what is returned: best bid, best ask, mid price, spread in absolute and bps, plus last trade price, scoped to a DeepBook pool. That precision separates it cleanly from siblings like get_order_book (full depth) and get_pool_stats (pool-level metrics).

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 implies the tool is for top-of-book price information and states the tiered access model (free 100 calls/day, then paid via payment_token), but never explicitly says when to prefer this over get_order_book or get_recent_trades. The 'only after the free tier' phrasing is conditional guidance tied to a parameter rather than a use-case routing statement.

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 context beyond that: data 'may be delayed or wrong', exact rate limit (100 calls/day per client), per-call price, prepaid batch size, and the payment-required handshake that yields a payment_token. That is exactly the operational behavior an agent needs to handle the paid path.

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 capability, then intervals, then units, then the operating constraints — a sensible order. The boilerplate disclaimer ('Education/information only; not financial advice') is padding for an agent, but everything else 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 7-parameter tool with no output schema, the description covers ordering, granularity, units, rate limits, and the full paid-retry flow. It does not describe the shape of each candle record, but OHLCV is a well-known format and the key semantics (ordering, units) are given.

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 86%, so the baseline is 3 and the schema already documents pool format, limit range, and timestamps. The description adds value the schema does not: it ties interval choices to candle granularity, clarifies that results are oldest-first (disambiguating start_time/end_time ordering), states volume is in the base asset, and explains the relationship between payment_token and payment_tx.

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?

Names the exact resource (OHLCV candles for a DeepBook pool), the ordering (oldest first), the supported intervals, and the volume denomination (base asset). This is unmistakably distinct from siblings like get_volume, get_recent_trades, and get_order_book, which return different data shapes.

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 guidance is implied through the payment flow: free 100 calls/day then 0.002 USDC, with payment_tx/payment_token required only after the free tier — that tells the agent when those params become relevant. However, the description never says when to prefer this over get_volume or get_recent_trades, so the alternative-selection guidance 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds genuinely new behavioral context: data may be delayed or wrong, a free tier of 100 calls/day, then 0.002 USDC per call prepaid in ~0.01 USDC batches, and that the payment-required response carries an exact amount and payment_token. It does not explain error/retry behavior beyond the payment path.

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?

One dense paragraph, front-loaded with the core capability before the pricing/payment detail. The 'Education/information only; not financial advice' clause does not aid tool selection but is a defensible compliance note, so only minor 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 does state what is returned (per-side price levels plus cumulative base-quantity and quote-notional liquidity) and explains the payment path. It is nearly complete, missing only error/failure semantics beyond the payment-required response.

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 five parameters including pool format, levels range, and the payment_token/payment_tx flow. The description restates 'top N price levels' and '±X% of mid' but adds no syntax or format detail 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 resource and scope: 'Order book for a DeepBook pool: top N price levels per side and cumulative liquidity (base qty and quote notional) within ±X% of mid.' This clearly distinguishes it from siblings like get_mid_price, get_recent_trades, and get_volume, though it does not name them.

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 frames the tool as 'Education/information only; not financial advice' and notes data may be delayed, which implies when it is appropriate to use, but it never says when to choose this over siblings such as get_mid_price or get_pool_stats. Usage is left to inference from the purpose statement.

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/openWorld annotations, the description discloses the GraphQL-to-indexer fallback path, the staleness and correctness caveat ('may be delayed or wrong'), and concrete rate-limit and pricing behavior including the exact free-tier threshold, per-call cost, prepaid batch size, and the fact that the payment-required response supplies the exact amount and payment_token. That is unusually rich behavioral context.

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 substantive answer (what fields, how fetched, fallback) is front-loaded before the compliance and billing sentences, and no sentence is redundant. The 'Education/information only; not financial advice' clause is boilerplate, but it is a single short clause rather than padding.

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 telling the agent what comes back, and it does so by enumerating the returned field groups. Combined with the fallback behavior and the billing/payment flow for repeat calls, an agent has everything needed to invoke it correctly without further documentation.

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 already 100%, so the pool format (BASE_QUOTE, case-insensitive, '/' or '-' accepted) is fully documented in the schema. The description still adds value by explaining the conditional lifecycle of payment_tx and payment_token — they only apply 'after the free tier' and are only obtainable from the payment-required response — which clarifies when those two optional params are actually required.

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 the resource (a DeepBook pool's parameters) and enumerates exactly which fields it returns — fees, DEEP stake requirement, tick/lot/min size, whitelist/stable flags, vault balances — which is far more than a restatement of the name. It does not, however, differentiate itself from the nearby get_pool_stats or get_mid_price siblings, so an agent must infer the boundary between them.

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 stated: an agent can infer this is the tool for static pool configuration, but there is no explicit 'use X instead when you need Y' against get_pool_stats, get_order_book, or estimate_fees. The payment-tier paragraph describes how to pay on repeat calls, which is procedural guidance, not tool-selection 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?

Annotations cover the safety profile (readOnly, idempotent, non-destructive, open-world), and the description layers on genuinely new behavior: a 100 calls/day free tier, 0.002 USDC per call after that, prepaid batches of ~0.01 USDC, and the payment_token/payment_tx handshake driven by the payment-required response. It also flags data may be delayed or wrong.

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 returned metrics, then appends the necessary disclaimers and pricing mechanics. Slightly long on the payment paragraph, but every clause (quota, price, prepay batch, token source) drives agent behavior, so little is wasted.

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 metrics, which largely substitutes for one, and it fully covers the payment flow and data-quality caveats. Only the precise response shape and pagination/limit behavior 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?

Schema coverage is 75%, with the schema itself documenting pool format and the two payment parameters. The description adds real meaning by explaining that payment_tx/payment_token are only used after the free tier and that the token holds prepaid calls, plus implying the hours window — enough to compensate for the residual coverage 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 specific verb+resource ('scorecard-style stats for one pool') and enumerates the exact metrics returned (trade count, taker buy/sell split, VWAP, spread, etc.), which cleanly distinguishes it from siblings like get_ohlcv, get_volume, and get_recent_trades.

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 only implied: 'one pool over the last N hours' suggests a per-pool rolling window, and the free-tier/payment paragraph tells the agent how to proceed after quota exhaustion. It never states when to prefer this over get_volume, get_ohlcv, or get_recent_trades, nor any exclusion 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 cover the read-only/idempotent safety profile, and the description goes well beyond them: it discloses rate limits (100 free calls/day then 0.002 USDC/call), the prepaid batch payment flow, the payment-required response and payment_token handshake, and the caveat that data may be delayed or wrong. This is rich operational context 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 returned fields, then the payment mechanics. Mostly earns its place, though 'Education/information only; not financial advice' is boilerplate that adds little operational value.

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 helpfully enumerates the returned fields and ordering, and fully explains the payment flow that several schema params depend on. An agent has everything needed to call it 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%, so pool, limit, start_time/end_time, include_tx, and the payment params are already fully documented. The description adds no format or syntax detail 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 and resource ('most recent fills in a DeepBook pool'), plus the exact returned fields (time, taker side, price, base/quote size) and ordering (newest first). The 'DeepBook pool' scoping also implicitly distinguishes it from the balance-manager sibling get_bm_fills.

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?

'Optional time range' implies the start_time/end_time use case, but no alternative tool is ever named and there is no when-not-to-use guidance (e.g., use get_ohlcv/volume for aggregates rather than raw fills). Usage is only 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 declare readOnly/openWorld/non-destructive, and the description adds genuinely new behavioral context: it never sees or holds keys, never moves funds, and returns only quotes and UNSIGNED transactions. The disclaimers and safety posture materially extend beyond the structured hints.

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 quote-and-compare purpose in the first sentence, followed by return values, then safety/scope notes. It is efficient, though the trailing 'Education only, not financial advice' disclaimer is padding relative to the operational content.

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 names what comes back (best route, expected output, price impact, fees) and covers custody/safety constraints. It is complete enough to call correctly, though it omits any hint about rate limits or the unsigned-transaction handoff to build_swap_tx.

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 75% (from/amount/sender documented), so the schema carries most parameter meaning. The description restates the supported coin set and confirms returns are unsigned, but adds little syntax or format detail beyond the schema — the baseline 3 fits.

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 (quote) and resource (spot swap) plus the exact venue comparison: DeepBook v3 direct/2-hop vs the Cetus aggregator, and enumerates the tradable set. It is clearly distinct from build_swap_tx by being a read-only quote, though it never names that sibling explicitly, so differentiation is inferred rather than stated.

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?

Scope boundaries are given (spot only, no leverage, non-custodial), which implies usage, but there is no explicit when-to-use statement or routing to alternatives like build_swap_tx or get_cetus_pool. An agent must infer that this is the pre-trade quoting step.

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 read-only, open-world, idempotent, and non-destructive traits, so the bar is lower. The description still adds real value: free tier of 100 calls/day, then 0.002 USDC per call on Sui mainnet with prepaid batches, the payment-required response flow, and a data-quality caveat ('may be delayed or wrong'). This goes well beyond 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?

It is correctly front-loaded, leading with the returned signal before caveats and pricing. However, two adjacent sentences repeat the same disclaimer ('Information only, not a trading instruction' / 'Education/information only; not financial advice'), and the payment paragraph is long relative to its value. Some pruning is warranted.

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 must carry return-value semantics, and it does: it enumerates the ranges, volatility, regime buckets with numeric thresholds, and the rung count, plus the payment response handling. It is nearly complete, missing only finer response-shape 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 coverage is 100%, so the schema already documents pool, payment_tx, and payment_token fully, making 3 the baseline. The description only gestures at payment_token indirectly ('the payment-required response gives an exact amount and a payment_token') and adds no syntax or format detail beyond the schema. Adequate but not additive.

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 derived resource: 1h/4h/24h high-low range, realized volatility, a regime classification with thresholds, and a suggested ladder rung count. This clearly distinguishes it by content from raw-data siblings like get_ohlcv or get_volume. It stops short of naming a sibling alternative, so it lands at 4 rather than 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?

There is no guidance on when to use this versus get_ohlcv, get_volume, or get_mid_price, nor any exclusions. The only contextual rules are the free-tier/payment constraints, which govern cost rather than tool selection. An agent gets no help choosing among the signal-oriented siblings.

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, open-world, non-destructive behavior, and the description still adds substantial context beyond them: a 100 calls/day free limit, 0.002 USDC per call afterward, prepaid batches of ~0.01 USDC, and a payment-required response carrying an exact amount plus payment_token. It also warns data may be delayed or wrong and is not financial advice.

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 behavior is front-loaded in the first sentence, followed by scoping and payment terms. It is dense but every sentence carries operational information; the payment sentence is long but necessary given the prepaid model.

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 carries the return-value burden, and it does: it enumerates the metrics per pool and the top-pools list. Combined with the payment flow explanation, an agent has everything needed to call it 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 the baseline is 3; the description adds the mutual-exclusivity relationship (top only when no pool is given, custom window_hours only for a single pool) and frames payment_tx/payment_token as a post-free-tier workflow tied to the payment-required response, which is more than the schema's field-level text.

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?

Names the exact resource and metrics returned — '24h volume, high/low, last price and % change' — and the alternate branch ('top pools by 24h quote volume if no pool is given'). This is far more specific than siblings like get_pool_stats or get_ohlcv, so an agent can route to it 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?

Gives clear branch conditions: pool omitted returns top pools, and window_hours applies only to a single pool. It also explains the payment path when the free tier is exhausted. It stops short of naming an alternative sibling (e.g., get_pool_stats) for when a different metric view is wanted.

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 (readOnlyHint=true, openWorldHint=true, destructiveHint=false), and the description still adds real behavioral detail: an on-chain holder eligibility check keyed on the address, non-custodial operation that never sees keys or moves funds, and a spot-only/no-leverage constraint. The line about returning 'quotes and UNSIGNED transactions only' is blanket desk boilerplate that does not really apply to a read-only market snapshot and mildly muddies expectations, which keeps this 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?

The purpose and data payload are front-loaded in one dense, information-rich sentence, and nothing substantive is buried. It loses a point for the duplicated disclaimer ('Education only, not a signal to buy or sell' followed by 'Education only, not financial advice'), which is pure repetition rather than new 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?

With no output schema, the description has to describe the return payload, and it does so concretely across all five data points plus the checklist. The precondition (holder check) and non-custodial posture are covered. The remaining gap is the failure mode for a non-holder address, which an agent would need to handle gracefully.

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 single 'address' parameter is already fully documented in the schema, including the 'never send a key' warning. The description adds only the fact that the address is used for an on-chain holder check, a marginal but real clarification. Baseline 3 is appropriate when the schema carries the semantics.

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 deliverable: a compact DeepBook market read over SUI, WAL and DEEP (mid, spread, 24h volume, 1h/4h/24h range, regime) plus a pre-trade checklist, gated on Secret Journals holder status. That scope clearly separates it from the narrow siblings (get_mid_price, get_ohlcv, get_volume, get_book_depth), which each return a single slice rather than a combined multi-asset desk read.

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?

'For The Secret Journals holders (checked on chain from address)' and the mention of a 'pre-trade checklist' imply when this tool is appropriate, so usage is inferable. However, it never states what happens for a non-holder (error, empty result, or downgraded output), nor does it route the agent to sibling tools when only one metric is needed. Usage 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?

Goes well beyond the readOnly/openWorld annotations by disclosing the pricing model (100 free calls/day per client, then 0.002 USDC per call), the prepaid batch mechanism (~0.01 USDC), and the two-step flow where a payment-required response returns the exact amount and a payment_token. It also warns that data 'may be delayed or wrong.' Annotations already cover safety, and this adds rate limits, cost, and a payment handshake the agent must sequence 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?

Single dense paragraph with the core purpose front-loaded and the operational/payment caveats following. The disclaimers ('education/information only; not financial advice') consume space without helping tool selection, but nothing is redundant enough to be disqualifying.

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 correctly previews the return payload (base/quote assets, tick, lot, min size) and explains the payment-required response shape. Combined with rich annotations, this is nearly complete; only the lack of any pagination or result-volume hint keeps it from 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%, so all four parameters are already documented in the schema. The description adds only marginal meaning (human units, asset filter framing) and largely restates the payment flow the schema already describes. 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 and resource: 'List Sui DeepBook v3 spot pools with base/quote assets and trading params (tick, lot, min size in human units).' An agent knows exactly what comes back. It does not, however, distinguish itself from near-neighbors like get_pool_params or get_pool_stats, so the differentiation half of the 5-bar is unmet.

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 tells the agent the asset filter is optional and that payment params apply only after the free tier, which is genuine usage context. But it never says when to choose this over get_pool_params/get_pool_stats, so the when-not/alternatives bar is not reached.

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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new context: that this connector never holds keys or funds and that the user pays from their own wallet, which is useful auth/custody information. It stops short of describing pagination or the return shape.

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 sentence is bloated with legal boilerplate ('Educational templates, not financial advice; no returns promised. All sales final, except where the law requires otherwise.') that consumes space without helping tool selection. Roughly half the text is disclaimer rather than invocation guidance.

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 listing tool with no output schema and annotations covering safety, the description is largely sufficient: it names the data source URL and states the fields returned (prices in Sui USDC, versions). It could say more about the response structure, but the essential information for correct invocation 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 tool takes zero parameters, so the baseline is 4 per the rubric. The description does not need to add parameter meaning, and nothing contradicts the 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?

The description opens with a specific verb+resource ('List ... templates') and enumerates what is included (prices in Sui USDC, versions, buying flow), so an agent can tell this is the catalog-reading tool. It does not explicitly name its siblings (create_template_order, check_template_order), so differentiation is only implied by the 'List' verb.

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?

There is no explicit statement of when to use this tool versus create_template_order or check_template_order, and no prerequisites or exclusions. The phrase 'no-checkout agent buying flow' gestures at a downstream purchase path but never tells the agent which sibling to call for 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 declare readOnly/idempotent/openWorld/non-destructive, so the safety profile is covered. The description usefully adds the 64 KB cap and the text-vs-base64 binary preview behavior, but the trailing custody/leverage/advice sentences are irrelevant boilerplate for a blob read.

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 is dense and front-loaded, but the two following sentences about non-custodial keys, spot-only, and education-only are entirely off-topic template padding for a read tool, roughly halving the signal-to-noise ratio.

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 rich annotations and no output schema, the description appropriately describes the return format (text or base64 preview, capped at 64 KB). It is close to complete, missing only error/availability behavior when the aggregator is unreachable.

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 0%, so the description must carry the load; it conveys the id lookup ('by id') and the byte cap ('max 64 KB'), which maps to max_bytes' maximum. It does not explain truncation behavior, the default of 8000, or the blob_id length bounds.

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: read a public Walrus mainnet blob by id via the public aggregator. This distinguishes it cleanly from siblings like walrus_store_guide (a guide) and build_walrus_register_tx (a write).

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 establishes context (public mainnet blobs via the aggregator) but never says when to prefer this tool over walrus_store_guide or other read tools, nor any prerequisites or exclusions. The agent must infer usage from the name alone.

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 (readOnlyHint, destructiveHint=false, idempotentHint, openWorldHint=false), so the bar is lower. The description still adds real context beyond the annotations: non-custodial, the desk never sees or holds keys, returns quotes and UNSIGNED transactions only, and is education-only. It is a static guide, so return-format disclosure is minor.

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 definition is dense but front-loaded: the core action (create keypair, fund, sign) leads, followed by scoping constraints. Every sentence adds value, though the single long opening sentence packs several clauses together.

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 guide with no output schema, the description sufficiently explains what it produces (steps and code) and the non-custodial constraints that matter to an agent. Nothing critical to calling it correctly appears 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 takes zero parameters, which sets the baseline at 4. The description correctly carries no parameter semantics because there are none to explain.

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 deliverable (exact steps and @mysten/sui code) and a concrete outcome: creating a Sui Ed25519 keypair locally, funding it with SUI/USDC, and signing/submitting transactions. This is unambiguous and clearly distinct from the many build_*_tx and get_* market tools that make up 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 establishes the context of use ('for an agent to create its OWN ... keypair') and clarifies the scope ('Spot only, no leverage'), which routes an agent here when it needs first-time wallet bootstrapping. It does not, however, give an explicit when-not or name an alternative sibling, so it stops short of full 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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds that the desk is non-custodial and returns unsigned transactions, but this is generic compliance boilerplate that applies to nearly every sibling rather than behavior specific to a guide tool (e.g. whether it returns steps, code, or a schema example).

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 is well front-loaded and specific. The remaining clauses ('Non-custodial... Spot only, no leverage. Education only, not financial advice') read as copy-pasted disclaimers that add little to correct invocation of a read-only guide, so not 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?

With no parameters, no output schema, and read-only annotations, the description carries little remaining burden. It signals the content (receipt schema and @mysten/walrus code), which is enough for an agent to know what the guide will contain, though it stops short of describing the return format or length.

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, so there is nothing for the description to disambiguate and the baseline is 4. The schema is empty and fully described, confirming no hidden inputs.

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 (store) and resource (public trade receipt or strategy note) plus the mechanism (receipt schema + @mysten/walrus code). It implicitly contrasts with read_walrus_blob (read vs store) and build_walrus_register_tx (guide vs transaction), but never names those siblings explicitly.

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 by the phrasing 'How to store a PUBLIC trade receipt or strategy note,' so an agent can infer this is the guide to consult before storing. However, there is no explicit when-to-use statement and no routing to build_walrus_register_tx or read_walrus_blob, leaving the agent to guess the ordering of the workflow.

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