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

Annotations already declare non-readOnly, idempotent, non-destructive, openWorld, so the safety profile is covered. The description reinforces that this is a partial edit rather than a full replacement, but adds no context on auth requirements, side effects, or what happens to fields not supplied (that detail lives in the schema, not the description).

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?

Two tight sentences: the capability first, the triggering condition second, with a natural-language example. No filler and nothing buried.

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 partial-update tool with full schema coverage, an explicit annotation set, and no output schema, the description covers the essentials an agent needs to select and invoke it. It stops short of richer behavioral detail (permissions, conflict handling), which is the only gap.

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 description coverage is 100%, so every parameter including the nested location object is already documented. The description's field list (time, price, location, booking link, notes) loosely maps to start/end, totalCost, location, link, notes but adds no syntax, format, or precedence guidance beyond the schema.

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?

States a specific verb (Edit) and resource (existing event) and enumerates the concrete fields that can be changed: time, price, location, booking link, notes. This clearly separates it from add_event, which creates rather than edits.

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?

Explicitly says when to use it — 'when the user has new information about an activity that is already on the plan' — and gives a concrete utterance example. It implies the boundary with add_event ('already on the plan') but does not name sibling alternatives like toggle_event or delete_trip_item for other operations on an event.

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