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 this as read-only, idempotent, non-destructive, and open-world. The description adds useful behavioral context beyond that: it relies on live on-chain fee rates and the DEEP_USDC mid, and it warns that data may be delayed or wrong. It does not cover auth or rate limits, but the annotations lower the bar.

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

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

The description is front-loaded with the core fee-estimate behavior and stays compact. The disclaimer and data-caveat sentences are relevant, though slightly boilerplate, and do not bloat 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?

There is no output schema, so the description must convey the return concept. It does so by explaining that the estimate compares payment in the input token vs DEEP and depends on live rates and the DEEP_USDC mid, while also disclosing freshness limitations. The only minor gap is that it does not explicitly describe the response shape.

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%, so the schema documents most parameters, including qty, pool, and price defaults. The description adds conceptual meaning for role ('maker or taker') and the fee formula, but it does not expand on pool naming syntax beyond what the schema already states.

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

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

The description states a specific verb and resource: estimate the DeepBook fee for a fill of qty at price as maker or taker, comparing payment in input token vs DEEP. It is clear enough to distinguish the tool from generic pool-data siblings, but it does not explicitly name an alternative tool or scope 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?

The description provides no explicit when-to-use or when-not-to-use guidance, nor does it name alternatives such as get_pool_params or get_mid_price. Usage is only implied by the phrase 'Estimated DeepBook fee'.

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 non-destructive, so the description's 'public data; no keys' is largely confirmatory. However, it adds genuinely new behavioral context: results are newest-first, includes the returned fields (time, side, price, qty, fee, tx), and warns data 'may be delayed or wrong' — useful caveats not in the annotations.

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

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

The description is front-loaded with the core purpose and returned fields, then adds compact caveats. The 'Education/information only; not financial advice' sentence is boilerplate but short and possibly compliance-required, so it does not badly hurt concision.

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

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

With no output schema, the description usefully enumerates the returned fields and ordering, and covers data-reliability caveats. However, it leaves important parameter semantics (role default vs 'maker or taker', hours window, limit) under-explained, so an agent could mis-specify a query.

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%, so the description should compensate for the gaps. It only loosely references pool and role, does not explain the role parameter's maker-by-default behavior, and says nothing about the hours look-back or limit parameters (limit has no schema description). The parameter guidance is therefore incomplete relative to the stated 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?

The description states a specific resource (OrderFilled fills) and scope (one pool, given BalanceManager, maker or taker), which lets an agent distinguish this from price/volume/order-book siblings. The wording 'maker or the taker' is slightly at odds with the role parameter's default of maker, introducing a small ambiguity about whether both roles are always returned.

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 when-to-use or when-not-to-use guidance, and no sibling alternative is named (e.g., get_recent_trades). The agent must infer from the phrase 'fills history' that this is for per-balance-manager fill queries, which is minimal guidance at best.

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?

Annotations already declare readOnly, idempotent, non-destructive and open-world, so safety is covered. The description adds one genuinely useful behavior note beyond that: the data 'may be delayed or wrong', which tells the agent not to treat values as authoritative. It says nothing about failure modes for an unknown pool name or whether the endpoint is cached/rate-limited.

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 payload the tool returns, and the three sentences are short. The disclaimer clause is boilerplate that occupies roughly a third of the text, but it is at least placed after the substantive content rather than before it.

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 by enumerating every field returned, which is the most important thing for this tool. The remaining gap is error behavior for an invalid pool identifier, minor for a read-only single-param lookup.

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

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

Schema coverage is 100% and the single 'pool' parameter is fully documented there, including the BASE_QUOTE format and slash/dash tolerance. The description adds no parameter 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?

The description names the resource (a DeepBook pool) and enumerates exactly what is returned: best bid, best ask, mid, spread in abs and bps, plus last trade price. That is a specific, checkable purpose. It does not explicitly contrast itself with get_order_book or get_pool_stats, which return overlapping market data, so sibling differentiation is left implicit.

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?

'Education/information only; not financial advice' is a legal disclaimer, not usage guidance. There is no statement of when to pick this over get_order_book (full book) or get_pool_stats (aggregates), nor any prerequisite or exclusion. An agent must infer the use case from the returned fields 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 declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely non-redundant context: results are oldest-first, volume is denominated in the base asset, and the data may be delayed or wrong — a data-quality caveat an agent cannot get from 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?

Three short sentences, front-loaded with the resource and ordering, then intervals, then caveats. The legal/educational disclaimer is boilerplate but brief enough to not crowd out 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 carries the burden of explaining returns and does so partially: OHLCV column semantics are implied by the acronym, ordering and volume unit are stated. It omits how to page backwards through history with start_time/end_time, which is the main remaining gap for a 5-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 80% — pool format, limit range, and second-based timestamps are already documented in the schema itself. The description repeats the interval list from the enum and adds no syntax or semantics beyond it, so 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 (OHLCV candles) bound to a specific object (a DeepBook pool) and adds the ordering guarantee (oldest first). It does not explicitly name which sibling it replaces, so an agent must infer the boundary versus get_volume, get_swing_range, or 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?

Enumerating the supported intervals implies the charting/time-series use case, but there is no explicit when-to-use, when-not, or pointer to an alternative such as get_recent_trades for raw fills. The guidance is implied rather than stated.

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

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

Annotations already cover readOnly/idempotent/non-destructive, and the description adds a real caveat the annotations don't: data 'may be delayed or wrong', which matters for trading-adjacent reads. No disclosure of rate limits, ordering, or whether the book is a snapshot, so not 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 core sentence is dense and front-loaded, but roughly half the text is legal boilerplate ('Education/information only; not financial advice') that does not help an agent decide or invoke. Trimmable without losing invocation-relevant information.

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

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

With no output schema, the description carries the return-shape burden and does reasonably: price levels per side plus cumulative base/quote liquidity. It stops short of saying whether mid price and the band boundaries are echoed in the response, or how levels are ordered.

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

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

Schema coverage is 100%, so baseline is 3; the description still adds value by explaining that within_pct yields cumulative base quantity and quote notional near mid – semantics the schema only hints at with 'Depth bands as % distance from mid'. It also restates 'top N levels per side' for levels, reinforcing the per-side unit.

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 a specific resource (DeepBook pool order book) and a precise scope: top N price levels per side plus cumulative liquidity within ±X% of mid. An agent can separate it from get_mid_price (single mid) and get_volume (aggregate volume) 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 by 'order book depth' – depth/liquidity inspection – but the description never states when to prefer this over get_volume, get_pool_stats, or get_mid_price, nor any exclusions. Context ('read-only public data') is present but no routing 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 safety profile (readOnlyHint, idempotentHint, destructiveHint false), yet the description adds genuinely new behavior: it reads the live on-chain Pool object via Sui GraphQL and silently falls back to indexer pool-creation values if GraphQL is unavailable, plus a data-may-be-delayed-or-wrong caveat. That fallback path materially affects how the agent should trust the result, which the annotations do not convey.

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

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

The tool-specific content is front-loaded in the first two sentences with no wasted words. The trailing 'Education/information only; not financial advice' sentence is boilerplate legal hedging rather than operational guidance, though it is short enough not to seriously harm 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 one required parameter, no output schema, and annotations already declaring read-only behavior, the description fills the remaining gaps well by naming the returned field groups, the data source, the fallback source, and the staleness risk. An agent can decide whether to call it and how much to trust the result without further information.

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% and the single 'pool' parameter is already documented as BASE_QUOTE with case-insensitive '/'-or-'-' separators, so the description adds no format or constraint detail beyond it. Baseline 3 is appropriate when the schema fully carries parameter documentation.

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 enumerates the exact data returned (taker/maker fees, DEEP stake, tick/lot/min size, whitelist/stable flags, vault balances) for a DeepBook pool, which is far more specific than the title. It does not explicitly distinguish itself from the close sibling get_pool_stats, leaving the agent to infer the boundary between 'parameters' and 'stats'.

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 content list (call this when you need fee tiers or lot-size constraints), and the GraphQL-with-indexer-fallback note tells the agent what happens if the primary source fails. However, there is no explicit when-to-use/when-not guidance and no mention of an alternative sibling such as get_pool_stats or estimate_fees.

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 read-only, idempotent, non-destructive behavior, and the description adds genuinely new context: the data is public, may be delayed or wrong, and is educational only. It does not mention rate limits or whether history is bounded, which keeps it below 5.

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

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

Two compact sentences: the metric inventory is front-loaded, the disclaimer follows. The metric list is dense but every item earns its place by telling the agent what comes back.

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, enumerating returned fields is exactly the right compensating move, and the freshness caveat covers the main risk of acting on the data. Minor gap: no mention of pagination, limits, or what happens when hours exceeds the schema maximum.

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 documents 'pool' thoroughly (format, case-insensitivity, separators) but leaves 'hours' undescribed; the description partly compensates with 'over the last N hours', clarifying the window semantics. With 50% coverage this is the expected baseline level of added value.

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

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

States a specific verb and resource ('Scorecard-style stats for one pool') and enumerates the exact metrics returned, which distinguishes it as a composite metric tool rather than a single-metric one. It doesn't explicitly contrast with siblings like get_volume or get_ohlcv, so no sibling naming.

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 never says when to prefer this over get_volume, get_mid_price, get_ohlcv, or get_recent_trades, despite heavy overlap in returned data. Only an implied 'aggregated dashboard' use case is present; no exclusions or selection 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 establish read-only, idempotent, open-world, non-destructive behavior. The description adds useful context beyond that: results are newest-first, may be delayed or wrong, and are public read-only data.

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

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

The description is short and front-loaded, with the key purpose, return fields, optional range, and data caveat stated efficiently. Every sentence contributes useful 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?

Given full schema coverage and annotations, the definition is largely complete: it names the returned fields and warns about data freshness. The main remaining gap is lack of sibling differentiation for similar market-data tools.

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 parameters such as pool format, limit, and timestamp units are already documented. The description reinforces the optional time range and returned fields but does not add parameter-level detail beyond the schema.

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

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

States a specific resource and scope: "Most recent fills in a DeepBook pool (newest first)" and lists the returned fields. It is clear what the tool does, but it does not explicitly distinguish itself from nearby siblings such as get_bm_fills or get_ohlcv.

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

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

The description notes an optional time range, implying you can bound the query, but it gives no explicit when-to-use guidance or comparison against alternatives like get_bm_fills, get_order_book, or get_ohlcv.

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 openWorldHint, so the safety profile is covered. The description adds value beyond that by disclosing that the data is public, possibly delayed, and possibly wrong – a real caveat an agent needs before quoting numbers.

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 useful signal list, then the regime thresholds. The closing pair "Information only, not a trading instruction" and "Education/information only; not financial advice" is partially redundant and could be one clause.

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 usefully enumerates the return values (ranges, volatility, regime bands, rung count) and their numeric cutoffs. Missing only pooling of the response shape or units for volatility, which is a minor gap for a single-param read 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?

Only one parameter and schema coverage is 100%, with the pool format and case-insensitivity fully documented in the schema. The description adds no syntax or format detail beyond it, so 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 concrete verb and resource: high-low range and realized volatility from hourly candles, plus regime and ladder rung count. It is clearly distinguishable from get_ohlcv or get_volume because it names derived signals, though it never names a sibling directly.

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?

"Information only, not a trading instruction" is a usage constraint, but the description never says when to pick this tool over get_ohlcv, get_pool_stats, or get_volume. The agent must infer the selection rule from the field list 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?

This is a read-only public-data tool, and the description adds freshness and accuracy context that adds to the annotations ('may be delayed or wrong') plus an advice disclaimer. Together these note latency and data-quality caveats rather than repeating readOnlyHint.

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 shape and mode distinction are front-loaded in the first sentence, and the constraints follow. The disclaimer clause is arguably padding but occupies only a few words.

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

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

For a tool with no output schema, the description still enumerates what comes back (volume, high/low, last price, % change, top pools) and notes both modes and window constraints. Nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100%, so parameters are already documented, and the description adds little beyond noting window_hours is single-pool only. That constraint is also in the schema, so the description provides only incremental value.

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

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

The description pairs a specific verb and resource ('24h volume, high/low, last price and % change') with the resource ('DeepBook pool') and explicitly covers both operating modes: single pool versus top pools. This distinguishes the tool from get_mid_price, get_pool_stats, and get_ohlcv.

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

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

It clearly states the two modes and the condition that selects each ('if no pool is given', 'Set window_hours ... (single pool)'). It does not name competing siblings such as get_ohlcv or get_pool_stats, so the agent must infer which tool to choose for historical candles versus a snapshot.

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/idempotent/open-world safety, and the description adds genuinely new context: data is public, may be delayed or wrong, and is informational only. It stops short of describing pagination or output size behavior beyond the include_ids note.

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 fields, followed by the filter and a brief disclaimer. Efficient overall, though the 'education only / not financial advice' boilerplate is slightly expendable.

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

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

For a two-optional-param, no-output-schema read tool with rich annotations, the description conveys what is returned and the staleness caveat. Sufficient to invoke correctly, with only minor gaps around output shape.

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 parameters are already fully documented. The description adds a small clarification that trading params are reported 'in human units', but offers nothing further on the asset or include_ids 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?

States a specific verb and resource ('List Sui DeepBook v3 spot pools') plus the data returned (base/quote assets, tick, lot, min size). This clearly distinguishes it from siblings like get_pool_params and get_pool_stats, which concern a single pool's parameters/statistics.

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?

Mentions the optional asset-symbol filter and its intent, but gives no explicit guidance on when to choose this over siblings such as get_pool_params or get_pool_stats. Usage is implied (pool discovery) rather than stated.

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.