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

The description explicitly claims the tool 'reaches no one outside the trip,' which directly contradicts the annotation openWorldHint=true (open world of external entities). Per the scoring rule, a description that contradicts annotations scores 1. This is notable because the definition otherwise carries strong behavioral detail (no confirmation prompt, cleanup via remove_place, API key requirement).

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?

Four sentences, front-loaded with the noun/verb and scope. It is efficient overall, though the 'it runs without asking, because it reaches no one outside the trip and is removed with remove_place' sentence bundles three distinct facts.

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?

No output schema exists, so the description must carry the load, and it does cover scope, auth requirement (Cotlet API key with app access), and cleanup. An agent has enough to invoke it correctly, aside from the annotation conflict.

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 coverage is 100%, so the schema already documents all three parameters including the day-omission behavior. The description's 'Adds a note to the day you name, or to the trip when no day is given' restates rather than augments the schema's day description, so baseline 3 applies.

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+resource: a free-text note on a day or the trip, with concrete examples (transit tips, opening hours, booking details). It is unambiguous what the tool creates. It does not, however, name or differentiate itself from siblings like add_expense, add_place, or add_checklist.

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 explains the branching behavior ('Adds a note to the day you name, or to the trip when no day is given'), which is useful context, but offers no guidance on when to prefer this tool over related Wanderlog tools or any exclusions. Usage is implied rather than routed.

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