Add a rental car

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

With no annotations at all, the description carries the entire burden and does well: it discloses that locations are geocoded against Google Places near the trip, that a "Rental cars" section is auto-created if absent, and that the response returns the resolved pick-up and drop-off. It does not cover what happens when place matching fails, whether duplicate rentals are allowed, or whether the call is idempotent, which keeps it out of the top band.

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 short sentences, front-loaded with the action, then the location-resolution rule, then the section side effect, then the return value. Each sentence carries information; the phrasing is slightly chatty ("whatever you pick as the location") but nothing is padded.

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?

For a nine-parameter mutation tool with no annotations and no output schema, the description supplies the important missing pieces: geocoding behavior, the side effect of creating a section, and what the call returns. Only failure modes and error behavior are absent, which is a modest gap given everything else it covers.

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 baseline is 3, but the description adds real meaning beyond the schema by clarifying the semantics of pickup_location — the company name is folded into the location string, and there is deliberately no separate firm parameter. The returned "resolved" locations also warn the agent that the input string may be normalized.

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 opens with a specific verb and resource: "Adds a rental car to a Wanderlog trip, covering a pick-up and drop-off window." That is concrete enough to separate it from wanderlog_add_place, wanderlog_add_hotel and wanderlog_add_transit, but none of those siblings are named, so the differentiation is by noun alone.

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?

Usage is implied rather than stated: an agent can infer this is the tool for car rentals, and the note that "the rental firm is whatever you pick as the location — there is no separate company field" is a genuinely useful pre-call instruction. There is still no explicit when-to-use/when-not guidance, no mention of prerequisites such as an existing trip_key, and no routing to alternatives.

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