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

The description discloses key behaviors beyond the annotations: it is non-custodial, the user pays gas, and creators earn 80% of trade fees. It also clarifies that the tool does not actually perform the publish (the user does), which is valuable context given the annotations only indicate it is not read-only.

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 zero waste. It front-loads the core purpose (renders package and commands), then adds the non-custodial detail and fee structure. 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?

The description explains what the tool produces (Move package and sui-client commands) and the non-custodial execution model. It does not detail the output format, but since there is no output schema, this is a minor gap. The required parameters are covered by the schema, so the description is sufficiently complete for an agent to call it correctly.

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

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

Schema description coverage is 100%, so all parameters are documented in the schema. The description does not add extra meaning to the parameters; it only implies the tool's overall purpose. This meets the baseline for full schema coverage but adds no additional semantic 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 the tool's function: it renders a Move package and sui-client commands for launching a token. It distinguishes itself from siblings by emphasizing the non-custodial, prepare-only nature ('you publish from your own Sui wallet'), so an agent can tell it apart from launchpad_launch_token even without opening schemas.

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

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

The description gives clear context that this tool prepares the launch while the user executes the publish themselves, implying this is a preparatory step. However, it does not explicitly name the alternative (e.g., launchpad_launch_token) or state when not to use it, so some inference is still required.

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