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

The annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuine value beyond this by disclosing that the autonomy level is the user's, set out-of-band (Agents page or the MCP's own env) and never mutable by an agent — context about governance and modification authority that annotations cannot convey. It also enumerates the level values (ask / limits / instant), enriching the behavioral model.

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, zero waste. The first sentence front-loads the purpose with a concrete verb and enumerates exactly what's returned; the second sentence adds a critical behavioral constraint. Every clause earns its place, with no redundancy against the annotations.

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?

Although there is no output schema, the description covers the essential surface: the return contents (level enum values, ceilings, change instructions) and the read-only nature. For a simple 0-parameter read tool with strong annotations, this is nearly complete — it could marginally benefit from describing the exact response structure, but the description suffices for an agent to know what to expect.

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 0 parameters, the baseline is 4 per the rubric. The description does not discuss parameters (correctly, since there are none) but instead describes the semantic output: the autonomy level with its three possible values, USD ceilings, and how to change the level. This is the appropriate use of description space for a no-parameter configuration read.

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

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

The description uses a specific verb ('Read') with a clear resource (autonomy level, USD ceilings), and states exactly what information is returned (level values ask/limits/instant, ceilings, change instructions). It clearly distinguishes itself from all sibling tools, which deal with capabilities, status, execution, or market data — none of which cover the session autonomy configuration.

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 opening phrase 'Read how much this MCP may finish by itself' gives clear context for when to call this tool (when the agent needs to understand its autonomy ceiling and spending limits). The read-only caveat with 'never by an agent' effectively tells the agent this is a query-only operation, though it never names an explicit alternative tool for changing settings (since none exists — that's done out-of-band).

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 and destructiveHint=false, but the description adds behavioral details such as 'executable' order book and the aggregation of orders into one size per price level. This goes beyond the annotations, providing useful context about what the tool returns and implies.

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

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

The description is concise, consisting of two sentences that are front-loaded with the primary action and resource. Every sentence adds value: the first states what is read, the second defines top of book. No wasted 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 simple read-only tool with annotations covering safety, the description sufficiently explains the output (bids/asks, one size per level, top of book) without needing extensive detail. It lacks an explicit return format but that is not critical given the simplicity and the presence of annotations.

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 description adds minimal value beyond the schema: it calls the market ID 'opaque', but the schema already defines a pattern. The depth parameter is not mentioned in the description, though the schema provides its description. With 50% schema description coverage, the description does not compensate for the marketId lacking an explicit description, but it is adequate given the pattern and required nature.

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

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

The description clearly states the tool reads the executable order book for a specific market ID, specifying bids and asks with one size per price level and explaining top-of-book. It is distinct from sibling tools like strata_bbo, which likely provides only the best bid/ask, by describing a full 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?

The description implies usage for obtaining full order book depth but does not explicitly contrast it with alternatives like strata_bbo or strata_trades. It lacks explicit when-to-use or when-not-to-use guidance, though the context suggests it is for depth data as opposed to top-of-book.

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 'bounded' and 'time-bucketed' as useful behavioral context, but it does not disclose return format, pagination, or edge-case behavior.

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

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

The description is a single front-loaded sentence with no filler. Every phrase—'bounded', 'time-bucketed', 'one opaque Strata market ID'—adds meaningful context.

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

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

The schema and annotations are rich, and the description conveys the essential read-only, single-market, candle-aggregation behavior. Since there is no output schema, return format is left implicit, but 'candles' is a standard trading concept and the description covers the core operation well.

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 0% schema description coverage, the phrases 'bounded time-bucketed' and 'one opaque Strata market ID' add meaning: fromMs/toMs delimit the range and resolutionSeconds controls bucket width. However, the description never explicitly maps or explains individual parameters beyond these allusions.

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

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

The description names a specific verb ('Read'), a resource ('candles'), and a clear scope ('one opaque Strata market ID'). This distinguishes it from sibling market-data tools like strata_bbo, strata_trades, or strata_marks.

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

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

The description implies use when bounded, time-bucketed candle data for a single market is needed. It provides no explicit when-not-to-use guidance or named alternatives among the many strata_* data tools.

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

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

The description adds meaningful behavior beyond annotations: the Vault session verifies and signs, Strata pays the network fee, and under certain price conditions it prepares the packet without signing. The word 'permanently' makes the destructive annotation concrete. No contradiction with the annotations is present.

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

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

Three sentences with no filler. The core operation is front-loaded, followed by signing/fee behavior and then the conditional exception. Every sentence contributes essential 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?

For a mutation tool with destructive effects, six parameters, zero schema descriptions, and no output schema, the description is not complete enough. It omits parameter semantics, return behavior, and expected failure conditions. The ambiguous 'Under ask, or above a limits ceiling' clause needs parameter-level grounding to be actionable.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning, but it only clarifies the action enum (post/revoke) indirectly. It does not explain side, marketId, maxPriceAtoms, minPriceAtoms, or maxFillSizeAtoms. The phrase 'under ask, or above a limits ceiling' hints at price limits but does not map to specific 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 description uses a specific verb and resource: 'Post or permanently revoke an existing curated IntentBook seat', which makes the core operation clear. It does not explicitly name a sibling, but the one-call framing distinguishes it from prepare/submit flows. Slight jargon around 'curated IntentBook seat' and the conditional non-signing clause keep it from full clarity.

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

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

The description implies when to use it: when you want to post or revoke in a single call. It does not explicitly say when to prefer market_making_pare, submit_and_wait, or another sibling. The ask/limits-ceiling sentence gives behavioral context, not 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?

The description discloses that Strata resolves IDs, decimals, live mark, tick grid, expiry, safety bounds, and fixed on-chain arrays, and that the tool returns a transaction requiring external signing. This adds meaningful context beyond the annotations, especially the deferred submission via submit_and_wait. It does not contradict the destructiveHint annotation, and it clarifies that this tool itself does not submit. It could still mention side effects of 'stop' or error/failure behavior.

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

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

Three sentences, no fluff, with a clear front-loaded purpose followed by behavioral detail and the workflow instruction. Every sentence adds value and the structure guides the agent from what the tool does to what to do next.

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

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

This is a complex tool with 11 parameters, no output schema, and 0% schema description coverage. The description covers the general flow and a few key parameters, but leaves many fields (levels, levelStepBps, asyncOnly, side, action) to be inferred. An agent would likely need to inspect other tools or examples to invoke it correctly, especially for the 'stop' action or level structure.

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

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

Schema description coverage is 0%, so the description carries the burden of explaining parameters. It only maps 'market label', 'decimal base size', 'spread', and 'duration' to a few fields, leaving action, product, makerWallet, side, levels, levelStepBps, and asyncOnly unexplained. For 11 parameters, this is insufficient for an agent to confidently construct a correct request without guessing from names and enums.

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

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

The description clearly states a specific verb ('Prepare'), a specific resource ('Strand or Current'), and the main inputs (market label, decimal base size, spread, duration). It also explicitly distinguishes the tool from strata_market_making_submit_and_wait by prescribing the next step, making the tool's role in the workflow unambiguous. The minor mismatch between title 'simple' and description 'pro-level' does not undermine clarity.

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 an explicit workflow: prepare the transaction, sign it externally, then call submit_and_wait. This clearly situates the tool relative to its sibling submit_and_wait. However, it does not explicitly state when to choose this tool over alternatives like strata_trade or strata_quote, nor does it mention the 'stop' action or conditions for using start/stop.

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 read-only annotation, the description adds specific behavioral details: it is public by wallet address and requires no signature. It also enumerates the data returned (products, live exposure, health, kill state), which is not covered by annotations.

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

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

The description is concise, one sentence that efficiently conveys the tool's purpose and key behavioral traits without unnecessary detail. It is well-structured and easy to read.

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

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

Given the simplicity of the tool, the description covers essential context: what data is returned and that it is a public, read-only operation. It does not mention error cases, but that is not critical. The absence of an output schema is somewhat compensated by listing the output fields in the description.

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 description provides some semantic context for the parameters: it implies that 'walletAddress' identifies the maker and 'marketId' identifies the market. However, it does not explicitly map these names, and the schema itself lacks parameter descriptions, so the description only partially compensates.

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

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

The description clearly states the tool's function: it retrieves a maker's products, live exposure, health, and kill state in a specific market. It also indicates it is public and requires no signature, which precisely defines the operation.

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

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

The description does not explicitly state when to use this tool versus alternatives. It mentions that it is public and requires no signature, which gives some usage context, but it does not differentiate it from other maker-related tools like reputation or order queries.

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

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

The description adds useful behavior beyond annotations: it waits for chain-derived confirmation, the preparation token survives stateless HTTP requests and server restarts, and the control ID is the default idempotency key. These details are consistent with the annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=true, destructiveHint=true), with no contradiction.

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

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

The description is only two sentences, and both earn their place: the first defines the action and completion condition, the second adds critical idempotency and token-lifecycle behavior. It is compact, front-loaded, and free of filler.

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

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

The core workflow is described well enough for a likely happy path, but the tool has 5 parameters, no output schema, and no parameter descriptions, so important gaps remain. In particular, confirmationTimeoutMs semantics, timeout/non-confirmation behavior, and the expected response/return shape are not addressed.

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 0% schema description coverage, the description must compensate for the schema's missing parameter explanations. It clarifies preparationToken ('unchanged', persistent), signedTransactionBase64 ('exact externally signed quickstart transaction'), and makerControlId via 'control ID' as the default idempotency key. It only indirectly implies idempotencyKey and leaves confirmationTimeoutMs entirely unexplained.

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 action ('Submit') and outcome ('wait until Strata's chain-derived maker state confirms the product started or stopped'). It is clear enough to distinguish from prepare and status tools, though it does not explicitly name or contrast sibling tools.

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

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

The description implies sequencing by requiring an 'exact externally signed quickstart transaction' and the 'unchanged preparation token', telling the agent this is meant to follow market_making_prepare. However, it never says when not to use the tool or names alternatives such as market_making_status for checking state, so the guidance remains 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds the context that availability is 'current', implying live data, but does not disclose response format or any edge cases.

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

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

The description is a single, clear sentence with no wasted words. It is front-loaded and easy to parse.

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

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

The tool is simple with one optional parameter and no output schema, but the description does not clarify the return structure or what 'Sonar quote availability' entails. Given the lack of an output schema, a bit more detail about response data would improve completeness.

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 only parameter (includePaused) is fully documented in the schema with a clear description, and schema coverage is 100%. The tool description does not add any additional meaning beyond what the schema already provides, so baseline 3 is appropriate.

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

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

The description uses a specific verb ('List') and identifies the resource ('Strata markets') plus a distinguishing aspect ('current Sonar quote availability'). It clearly differentiates from sibling tools like strata_quote and strata_capabilities.

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 guidance is provided on when to use this tool versus the sibling tools (strata_capabilities, strata_quote). It does not mention use cases, prerequisites, or alternatives, leaving the agent to infer context.

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

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

Annotations already declare the tool read-only, idempotent, and non-destructive, so the description does not need to repeat safety. It adds context by specifying the price is 'customer-facing' and 'current,' which informs expected semantics. However, it does not disclose behavior on invalid inputs, rate limits, or any additional side effects beyond what annotations state. Given the rich annotations, the description provides adequate additional context without contradiction.

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

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

The description is a single, direct sentence with no extraneous words. It front-loads the purpose and delivers the core information efficiently. Every word contributes value, and there is no fluff or repetition.

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

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

For a simple read tool with strong annotations and a single parameter, the description is complete enough. It clearly states what is read, the scope, and the nature of the price. It does not describe the output format, but given no output schema, this is a minor gap. It adequately covers the essential context for an agent to invoke the tool correctly and interpret the returned price as the reference price for the specified market.

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 compensate. It adds the meaning 'opaque' to marketId, clarifying it is a system-generated identifier rather than a human-readable name. It also implies a single market ID via 'one opaque market ID,' matching the schema's required field. However, beyond that, it does not elaborate on format, constraints, or units, though the schema already defines the pattern. The addition is minimal but sufficient for a simple one-parameter tool.

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

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

The description clearly states the action (read), the resource (current customer-facing reference price), and the scope (one opaque market ID). It distinguishes from siblings like strata_bbo or strata_quote by specifying 'reference price' rather than bid/offer or quoted price. The verb+resource combination is specific and 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 provides no guidance on when to use this tool versus alternatives. It does not mention when it is appropriate or not, nor does it reference any sibling tools for comparison. The context is implied (e.g., if you need a reference price, use this), but there is no explicit directive or exclusion.

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

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

Annotations already convey destructive and read/write behavior; the description adds valuable context: Strata resolves balance, market, mark, decimals and tick grid internally, and autonomous placements fail-closed if the dead-man guard is not established. This is a meaningful behavioral disclosure beyond the flags and is consistent with the annotations.

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

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

Three dense sentences with an example front-loaded and no filler or restatement of the title. The security-related final sentence earns its place, though the phrasing 'warm dead-man guard' is somewhat jargon-heavy and could be clearer.

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

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

For a 15-parameter, multi-action execution tool with no output schema, the description is too thin: it leaves the operations array composition, per-action required parameters, defaults, and error/return behavior unspecified. An agent can get the high-level intent but must rely heavily on enum names and property names to invoke 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?

With only 40% schema description coverage, the description partially compensates by linking the friendly-order inputs ('availablePercent' + 'markOffsetBps') to a concrete example and mentioning exact-atom controls. But it does not clarify many parameters such as operations structure, idempotencyKey, orderType, clientOrderId, or which fields apply to which action, so the coverage gap remains.

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

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

The description clearly identifies the operation family: placing human limit orders and using exact-atom cancel/replace/batch controls, with a concrete example ('sell 10% of available SOL at mark +3%'). It adds specificity through the internal-resolution note. It does not explicitly contrast with sibling tools such as strata_trade or strata_market_making_intent_execute, so it falls short of full sibling differentiation.

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

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

It states primary use cases—friendly human limit orders in one call and exact-atom control operations—and implies an autonomous use case via the dead-man guard note. However, it gives no exclusions or explicit alternatives, so an agent must infer when to prefer this over related execution or market-making tools.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior, so the description adds useful behavioral context beyond that: current-week activity is provisional until finalization time, owner balance is immutable, and standings are bounded. This temporal nuance is valuable for interpreting results and is not present 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 two sentences with high information density and no filler. It front-loads the primary action and resource, then packs the key outputs and behavioral caveats into a compact, readable format. Every clause adds 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?

For a read-only aggregate tool, the description covers the output semantics well: timing, budget, weights, balances, standings, and provisional activity. However, the two optional parameters are entirely undocumented, and there is no output schema to compensate, leaving an agent uncertain about how walletAddress and limit affect 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?

Schema description coverage is 0% and neither parameter (limit, walletAddress) is explained in the description. The description mentions a 'complete' fleet-wide read, but does not clarify whether walletAddress filters the response or what limit controls. The description provides no meaning beyond the raw schema constraints.

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

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

The description opens with a clear verb ('Read') and a specific resource: the complete fleet-wide Points program. It enumerates the exact contents (season/epoch timing, weekly budget, allocation weights, standings), which makes its purpose obvious and differentiates it from sibling tools focused on markets, trades, or quotes.

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 scope is implied: 'complete fleet-wide Points program in one request' and 'All live markets participate' suggest this is the aggregate points overview tool rather than a per-market or per-wallet detail tool. However, it does not explicitly state when to use this tool versus alternatives, nor does it name any sibling tools or exclusion cases.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds behavioral value by explicitly stating 'No signature, no session key' and 'public read', which are auth-related details not covered by annotations. It also clarifies the scope ('across every live market') and data format ('exact USD'), enhancing transparency beyond annotations.

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

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

The description is two sentences, front-loaded with the core purpose ('The whole account in one public read, by wallet address') followed by a clear list of contents. It is concise, with zero filler, and every clause contributes to understanding the tool's scope and constraints.

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

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

Given the tool returns a comprehensive portfolio snapshot without an output schema, the description lists the types of data returned (balances, positions, orders, fills) and specifies 'exact USD' for balances. It also sets expectations by mentioning 'across every live market'. It could optionally clarify data freshness or size limits, but for a read-only portfolio endpoint, it is sufficiently complete.

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

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

There is only one parameter, walletAddress, with a schema pattern but no description coverage (0%). The description references 'by wallet address' but adds little semantic meaning beyond what the parameter name and pattern already convey. It does not explain the address format or requirements, but the pattern is self-explanatory for those familiar with crypto addresses. Given the simplicity, the description is adequate but not value-adding.

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

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

The description clearly states the tool's purpose: 'The whole account in one public read, by wallet address' and enumerates the specific contents (balances, positions, open orders, recent fills) across all live markets. It distinguishes itself from siblings by emphasizing 'one public read' and 'no market selection', which differentiates it from market-specific tools like strata_bbo or strata_order_status.

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

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

The description provides clear context on when to use this tool: when you need a complete snapshot of an account without filtering by market. It does not explicitly name alternatives or state when not to use, but the phrase 'no market selection' implies it's not for granular per-market queries. The sibling tools like strata_order_status or strata_execution_status suggest alternatives exists, but the guidance is implicit 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?

Annotations already cover read-only and non-destructive behavior, so the bar is lower. The description adds meaningful context by noting the quote is short-lived, returns an expiry, and includes fees and price impact. No contradiction with annotations.

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

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

Two tight sentences: the first states purpose and lifespan, the second covers how to specify inputs and what the response contains. No filler or redundant restatement of schema details.

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 correctly enumerates the key return fields: expected output, fees, price impact, and expiry. Combined with the well-described input schema and annotations, this is sufficient for an agent to invoke the tool correctly, though it never explicitly says the quote does not execute a trade.

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 baseline is 3. The description's examples for amount and market mirror the schema rather than adding new meaning, and it adds little beyond pointing at advanced atom inputs. maximumToleranceBps and side are left to the schema.

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

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

The description uses a specific verb and resource ('Request a short-lived Sonar quote') and states the tool's output. It is clearly a quoting tool, but it does not explicitly distinguish itself from the execution sibling strata_trade or other market tools.

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

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

The description gives usage instructions for inputs ('Use a market label and a human amount') and notes advanced atom inputs, but it never says when to prefer this tool over alternatives such as strata_trade. Usage context 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?

Annotations already flag destructiveHint=true and openWorldHint=true, so the description's job is to refine those. It does: submission only happens with a session, it respects user autonomy limits, and without a connection it degrades to a harmless read-only quote. This conditionality is exactly the nuance annotations cannot express, and it does not contradict the annotations.

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

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

Three short sentences, each with a distinct job: purpose, parameter semantics, and conditional behavior. The purpose is front-loaded. Minor deductions for the filler word "obvious" and for the human-amounts sentence partially duplicating the schema description.

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

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

The description covers the no-session return path (quote plus setup link) but not the session path's return behavior, which matters for an agent deciding whether to proceed. With no output schema and six parameters, it also leaves the meaning of "autonomy limits" and the relationship to siblings like strata_quote and strata_autonomy unstated.

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 schema coverage at 50%, the description should compensate for undocumented parameters, but it only reinforces what the schema already says about amount ("Human amounts such as 0.1 SOL and $20 are supported" mirrors the schema example). It adds nothing about idempotencyKey or maximumToleranceBps, both of which lack schema descriptions — a genuine gap for a potentially destructive trading tool.

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 phrase "Quote and trade in one obvious tool" names specific actions (quote, trade) and a resource (Strata markets), making the tool's dual role immediately clear. It implicitly distinguishes itself from strata_quote by covering both quote and trade, though it never names that sibling 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?

The two-state behavior (no trading connection → read-only quote + setup link; with a session → follows autonomy limits and may submit) tells the agent how the tool behaves in different contexts, which implies when it is safe to call. However, it never explicitly names alternatives like strata_quote for quote-only needs, nor states exclusions, so the agent must infer routing from sibling names.

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, and non-destructive. The description adds 'anonymized' prints and specifies the data fields (price, size, side, time), providing behavioral details beyond the annotations about the nature of the returned 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?

A single, front-loaded sentence that conveys the verb (read), the resource (recent anonymized prints), the qualifier (for one opaque market ID), and the output contents (price, size, side, time). No redundant or extraneous 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?

The description sufficiently conveys what the tool does and what returns, but omits details like default limit, pagination, or potential error cases. However, given the lack of an output schema and the simple nature of the operation, it covers the essential aspects adequately.

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 covers `limit` with a description, but `marketId` has no description beyond the pattern. The tool description adds 'one opaque market ID', clarifying that marketId is a hash-like identifier, but doesn't explain how to obtain or interpret it. With 50% schema coverage, the description provides minimal extra 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 clearly states it reads recent anonymized prints, identifies the target resource (a market ID), and lists the return fields (price, size, side, time). This distinguishes it from sibling tools like strata_candles or strata_bbo by its specific focus on trade prints.

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

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

The description implies usage for retrieving recent anonymous trades for a specific market, but does not explicitly contrast with alternatives or state when not to use it. It provides no direct comparison to sibling tools, leaving the agent to infer the scope from the name and context.

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