update_event

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

Adds substantial behavior beyond annotations: it is a write operation requiring explicit human request, it returns the resulting object in the unified format, and it discloses that recurring events require scope or the server refuses, plus start/end coupling and Europe/Paris local time format. These details are not present in the annotations and materially affect safe invocation.

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?

Front-loads the critical write restriction before explaining the action, then moves to return format and key parameter constraints. Every sentence is purposeful and none are redundant.

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 an 8-parameter mutation tool with zero schema descriptions and only basic annotations, the description supplies the essential operational context: authorization, recurrence handling, date format, and field updates. The output schema exists, so return details need not be fully expanded, and the omission of all_day is minor.

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?

With schema description coverage at 0%, the description must carry parameter meaning and it does so for scope values, start/end dependency, date format, timezone, and several field names. It leaves all_day and id semantics unmentioned, which prevents a full score.

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 and resource: "Modifie un événement" and enumerates the editable fields (titre, horaire, notes, lieu). This distinguishes it from add_event, delete, and update_task because it is plainly an update of an existing event rather than a creation or deletion.

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?

Provides explicit when and when-not guidance: only on Denis's explicit request, never on the agent's own initiative, and not even to "help" or correct. Although it does not name an alternative update tool, that is not relevant here; the constraint is unusually precise and actionable.

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