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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuine context beyond that: the route is stable for the whole day for a given visitor_name, and completing it yields a 'tour-<personality>' badge. It stops short of saying how many stops a route has or whether starting a tour registers any progress.

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, front-loaded with what the tool returns, followed by the determinism guarantee and the badge reward. No filler, though the badge sentence slightly mixes outcome motivation with tool behavior.

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 must convey the return shape, and "a route through today's open rooms" leaves the structure (ordered list of rooms? pieces? with IDs?) unclear. The badge and determinism details are helpful, but an agent still cannot predict what it will receive or how large a tour is.

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?

visitor_name is fully documented in the schema, but personality (with its six-value enum) has no schema description, and the description only says the route is "made for your personality" without explaining how scientist vs. speedrunner vs. wanderer change the result. With 50% coverage, the description partially compensates but leaves the key enum semantics opaque.

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?

"Get a route through today's open rooms" gives a specific verb (get) and a concrete resource (a personalized route), and the personality/visitor_name determinism further pins down what the tool produces. It is distinguishable from list_tours or get_room, though the word "pieces" is site jargon that isn't defined here.

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 (to get a curated tour for a visitor) and hints at a follow-up workflow ("Visit all its pieces to earn a badge"), which suggests pairing with get_piece. But it never states when to prefer this over list_tours, todays_hunt, or recommend_piece, and gives no prerequisites or exclusions.

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