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

Annotations already declare readOnlyHint=true, idempotent and non-destructive, and the description reinforces this with the strong, useful statement that it 'opens nothing by itself' — important for an agent that might otherwise assume a side effect. The note that Pirate Ship has no official API is valuable behavioral context that prevents wasted API exploration. It stops short of describing exactly what the returned guidance contains or how long it is.

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 facts are front-loaded: it returns instructions, it performs nothing, and the browser tools do the work. It is a single dense sentence chain with little waste, though the trailing API note with a suspicious future check date ('11 Oct 2026') reads as an aside that could be trimmed or corrected.

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 zero parameters, no output schema, and rich annotations, this is a simple informational tool and the description covers what an agent needs: what it returns, that it has no side effects, and which tools to use next. Only the shape of the returned guidance (length, format, whether it is per-screen instructions) is left unspecified, which is minor here.

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 and there is nothing for the description to disambiguate. The schema's additionalProperties:false correctly conveys that no arguments are accepted, and the description does not falsely imply any configuration input.

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 specific resource (orders in the user's own Pirate Ship account) and explicitly re-frames the verb: it returns step-by-step instructions rather than performing the import, which corrects the potentially misleading tool name. It distinguishes itself from the cotlet_browser_* siblings by handing the actual execution to them. Slightly reduced because the opening 'Import orders' phrasing still reads as an action before the clarification arrives.

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 gives a clear use condition (get the walkthrough with screens, buttons and fields first) and names the alternative tool family to use afterward (cotlet_browser_* in the Pirate Ship Cloud Browser). It does not state when this tool is unnecessary, e.g. if the agent already knows the flow or if a sibling like pirate_ship_buy_labels_in_bulk covers the task.

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