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

Annotations already provide readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description goes beyond these by adding critical behavioral context: 'Free advisory version check' (no cost), 'Does not install files, grant permissions, spend credits or require an update' (clarifies side-effects), and 'Report an available update ... once' (confirms idempotency in a specific way). It also clarifies that 'Unknown is not outdated' and never downgrades, which is safety-relevant. No contradictions 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?

The description is efficient and well-structured. It opens with the core purpose ('Free advisory version check'), then immediately gives usage instructions, followed by edge-case clarifications and a list of what it does not do. Every sentence adds value; there is no fluff or redundancy. The structure is front-loaded with the most important 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 the tool's simplicity (one optional parameter, no output schema), the description is complete. It covers when to call, how to construct the call, what to expect (report update once), constraints (no downgrade, unknown is not outdated), and side-effects (none). An agent has everything needed to invoke this tool correctly without further inference.

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 schema covers 100% of the parameter with a detailed description including pattern and usage guidance. The description repeats the 'omit when unknown' instruction but adds no new semantic information beyond what the schema already provides. With full schema coverage, baseline 3 is appropriate; the description does not need to compensate.

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 ('check') and resource ('SpriteShip skill updates'), and clearly indicates it is an advisory version check. It distinguishes itself from sibling tools like get_credits or get_project by focusing on update detection, and it specifies exactly what it does not do (install, grant permissions, spend credits). This is a clear, non-tautological purpose.

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 explicitly instructs when to call: 'Call once when starting SpriteShip work in a session' and how to handle the parameter: 'passing the version actually read from the installed skill; omit it when unknown.' It also clarifies edge cases: 'Unknown is not outdated; never downgrade a newer local copy' and states to report updates only once. This is explicit, actionable guidance with no ambiguity.

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