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

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

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

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

The first sentence is well front-loaded and specific. The remaining clauses ('Non-custodial... Spot only, no leverage. Education only, not financial advice') read as copy-pasted disclaimers that add little to correct invocation of a read-only guide, so not every sentence earns its place.

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

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

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

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. The schema is empty and fully described, confirming no hidden inputs.

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

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

States a specific verb (store) and resource (public trade receipt or strategy note) plus the mechanism (receipt schema + @mysten/walrus code). It implicitly contrasts with read_walrus_blob (read vs store) and build_walrus_register_tx (guide vs transaction), but never names those siblings explicitly.

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

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

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

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