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

Annotations already declare readOnlyHint=false, openWorldHint=true, destructiveHint=false, so the write/safety profile is covered. The description goes well beyond that: it specifies the unified return object, Europe/Paris local-time semantics, all-day inclusion rules, the container default, RRULE prefix conventions, and the concrete consequence of tracked=true (occurrences behave as tasks and go overdue).

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?

The critical constraint is front-loaded before any format detail, which is exactly right. It is dense but nearly every clause carries operational meaning; only the explicit 'Renvoie l'objet résultant au format unifié' is weakly redundant given an output schema exists.

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 9-parameter mutation tool with an output schema and rich annotations, the description covers the non-obvious surface: timezone, all-day range semantics, recurrence format, and tracked behavior. Return values need no explanation since an output schema is present.

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 0%, so the description must carry the load, and it does for the hard parameters: start/end format, all_day boundary semantics, container default, recurrence RRULE shape with examples, and tracked behavior. title, notes, and location are left to inference, but they are self-evident, so this is a minor gap rather than a real one.

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 names a specific verb and resource ('Crée un événement') and adds scope-relevant detail that separates it from siblings like update_event or add_task. Nothing about the intent is ambiguous, and the leading French warning makes the tool's identity and gating unmistakable.

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 states when to use it and when not to: only on Denis's explicit request, never on the agent's own initiative, not even to 'help' or 'correct'. This is a rare case of a tool giving a hard behavioral gate with the exclusion condition spelled out.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds real behavioral context: it returns the resulting object in a unified format, and a nonexistent list_name is refused rather than created. It does not detail permission or rate-limit behavior, but for a non-destructive write this is solid.

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?

Dense but waste-free, and correctly front-loads the most decision-relevant constraint (write only on explicit request) before the mechanics. Every sentence carries information the agent needs.

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 4-parameter write tool with an output schema and safety annotations, the description covers the remaining gaps: usage constraints, parameter formats/defaults, and the refusal behavior. Nothing needed to invoke it correctly is missing.

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 0%, so the description must compensate, and it does for three of four parameters: due format ('AAAA-MM-JJ', optional), list_name default and refusal semantics, and a notes convention for estimated duration. Only the required title is left undocumented, which is self-evident.

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 ('Crée une tâche'), which an agent can distinguish from siblings like add_event (different resource) or update_task (different operation). The write framing further separates it from read tools such as tasks/agenda/overdue.

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 states when to use ('uniquement sur demande explicite de Denis') and when not to ('Ne jamais appeler de sa propre initiative, ni pour aider, ni pour corriger'). This is unusually precise routing guidance with named exclusions.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds real behavioral detail beyond that: a hard 31-day cap on the window, the default status filter, and an explicit output presentation instruction (markdown table). It does not mention authentication or how results are ordered beyond 'triés'.

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?

Dense and front-loaded: the scope and 31-day limit come first, then each parameter's semantics. Every sentence carries information, though the single run-on block with backtick references ('voir `containers`') is slightly harder to scan than a structured list.

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?

An output schema exists, so return-value explanation is not required, and the description instead supplies the window cap, defaults, and a presentation instruction. For a 4-parameter read query this is nearly complete; only pagination behavior across successive windows and the sort order for the 'triés' claim are missing.

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 0%, so the description must carry the load, and it largely does: it specifies the 'AAAA-MM-JJ HH:MM' format in Europe/Paris local time, that a date-only value means midnight, the default end (start + 1 day), the meaning of 'containers', and the status values/default. Only the exact ordering/sort key is left unstated.

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 resource and scope: dated events AND tasks merged and sorted over a bounded window. This distinguishes it from siblings like 'tasks', 'next', and 'overdue', though the leading phrasing is a noun phrase rather than an explicit verb, leaving the agent to infer it is a query/aggregation tool.

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?

Gives useful operating context — the 31-day maximum window, the default 'open' status, and the default end = start + 1 day — which implies when the tool applies. However, it never states when to choose this over 'tasks', 'overdue', or 'next', so the agent must infer the boundary from the sibling names.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that the listing surfaces read-only and primary flags, which is useful extra context, but says nothing about pagination, ordering, or freshness of the results.

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 compact sentences: what is listed first, then the practical reason to call it. No filler, no repetition of the tool name.

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?

An output schema exists, so return values need not be explained, and the description covers both what the tool returns and why it is called. With no parameters and annotations already carrying the safety hints, little is missing; only result-shape quirks or refresh expectations are unaddressed.

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?

There are zero parameters and schema coverage is 100%, so the baseline of 4 applies. The description adds no parameter detail because none exists to add.

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 names the concrete resources returned — Google Calendar calendars and Google Tasks lists — with their fields (nom, id, principal, lecture seule), so the verb+resource is unambiguous. It does not explicitly contrast itself with near-name siblings like 'tasks' or 'agenda', which keeps it short of a 5.

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 states the operative context: use it to file things correctly at write time via the `container` / `list_name` fields. That tells an agent when this lookup matters, though it names no alternative tool or exclusion condition.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely new behavioral facts: the deletion is permanent/irreversible, it is reserved for data-entry errors, and it returns the resulting object in the unified format. Only a permissions/auth requirement is left unstated.

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?

Every sentence earns its place — write gating, return format, irreversibility, alternative routing, and the scope rule — and the most consequential constraint (explicit request only) is front-loaded. It is dense but not 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 two-parameter destructive mutation, the description covers usage gating, irreversibility, the alternative tool, and the one non-obvious parameter rule; an output schema exists so return values need no elaboration. What remains missing is only the authorization/permission context for permanent deletion.

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 0%, so the description carries the burden — and it does: it specifies that scope (this/series) is required for a recurring event, which is information the schema's nullable optional field does not convey. The id parameter is left implicit, which is a minor gap given its obviousness.

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 tool name is a bare generic verb, but the description supplies the operative meaning: 'Suppression définitive, réservée aux erreurs de saisie' and the recurring-event scope rule imply deletion of calendar records, and it explicitly contrasts itself with set_status(cancelled). The exact resource (event vs. task) is only implied via 'événement récurrent', so it stops short of a 5.

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 states when to call (only on explicit request from Denis), when not to call (never on own initiative, not to 'help', not to correct), and names the exact alternative for the adjacent case: set_status(cancelled). This is about as explicit as routing guidance gets.

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

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

Annotations already declare readOnlyHint and openWorldHint. The description adds meaningful context beyond annotations: searchable fields, all statuses, default time window, and local timezone. It omits result limits or pagination behavior, but otherwise adds solid behavioral detail.

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, dense sentences with no waste. The search scope, default window, and format guidance are front-loaded in a logical order.

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?

An output schema exists, so return values need not be explained. Annotations cover the safety profile. The description supplies search scope, default date range, and time format, making the tool callable; only minor details like result limits are absent.

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 0%, so the description must compensate. It defines the start/end format and default window, and clarifies that query searches titles and notes. Query syntax beyond that is unspecified, but the key parameter meanings are covered.

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: text search over events and tasks, all statuses. It is clear what the tool does, but it does not explicitly differentiate itself from siblings like agenda or tasks.

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 useful default behavior (90 days back and forward) and the start/end format, but gives no explicit when-to-use or when-not guidance relative to alternative search or listing tools.

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

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

Annotations only cover readOnlyHint/openWorldHint, so the description carries the behavioral load and does so well: it discloses that slots are computed from events exclusively, restricted to working days and working hours (9h-18h default), in Europe/Paris local time. It does not address holiday handling or whether bounds are inclusive, leaving a small gap.

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?

Purpose and the key constraint (events only) are front-loaded, and the run-on sentence packs several constraints without filler. It is dense but slightly hard to parse as a single block rather than separated clauses.

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?

With an output schema present, return-value explanation is correctly omitted, and annotations cover the safety profile. Combined behavior and parameter coverage make this sufficient to invoke correctly, with only edge-case semantics (boundaries, holidays) unstated.

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 0%, so the description must define all five parameters, and it does: start/end format and timezone, work_start/work_end as 'HH:MM' with the 9h-18h default, and min_minutes as the minimum slot duration. Minor gaps remain (inclusivity of bounds, min_minutes unit/default) but compensation is strong.

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/resource: free slots between `start` and `end`, and immediately delimits the computation source ('calculés à partir des événements uniquement'), which separates it from task-oriented siblings like `tasks` or `add_task`. An agent knows exactly what it produces without opening the schema.

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 'events only, tasks do not block time' clause is useful context for when this is the right tool versus task-related ones, but there is no explicit when-to-use/when-not statement and no sibling is named as an alternative (e.g. `agenda`). Usage is implied rather than directed.

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

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

Annotations only declare readOnlyHint and openWorldHint; the description goes well beyond by disclosing the default window behavior, the sort order of tasks (by due date then estimated duration), the required markdown/three-block presentation, the mandate to show an explicitly empty Overdue block, and the id-suppression rule. These are real behavioral traits not derivable from the annotations.

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?

The text is front-loaded with purpose then usage then rendering rules, so it reads in a sensible order and each clause carries information. It is somewhat long and includes presentation directives that border on agent prompting, but nothing is truly 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 a complex aggregator with an output schema present, the description still covers the scope, the trigger questions, the single parameter's default, the sort order, and the empty-result edge case. An agent has everything needed to call and render it correctly.

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 0% for the single `hours` parameter, so the description must compensate — and it does, defining it as a window in hours from now and pinning the default to end-of-workday (or midnight if already past). That fully specifies the only parameter's semantics and default.

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 precise verb+resource framing ('global state of the day in a single call') and then enumerates the four data categories it returns (overdue, window events, free slots, open tasks incl. undated). Because those categories map exactly onto the single-purpose siblings (overdue, agenda, free_slots, tasks), the composite scope makes selection unambiguous.

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 gives an explicit trigger: 'call for any question like what do I have today / to do', which is a clear usage context. However it names no alternatives or exclusions (e.g., 'use agenda/free_slots instead when you only need X'), so the routing versus its 12 siblings is left partly to inference.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely non-obvious behavior: recurring-event occurrences are excluded unless include_recurring=true, with a permanent exception for series titled '[suivi]'. It also documents sort order, but says nothing about return shape, pagination, or volume limits.

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?

Content is front-loaded (what it lists, then the ordering, then routing, then the recurrence rule) and no sentence is filler. The long parenthetical explaining the '[suivi]' convention makes the surface reading slightly heavy, but every clause earns its place.

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?

With an output schema present, return-value documentation is unnecessary, and the description covers filtering semantics, ordering, and sibling routing. Nothing an agent needs in order to call this correctly is missing.

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 0% for the single boolean, so the description must carry the burden — and it does, explaining exactly what include_recurring toggles, the default exclusion behavior, and the '[suivi]' series exception that overrides it. Without this text the parameter would be 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?

The description names a specific resource and its exact composition: past-and-still-open items (overdue tasks plus finished events not marked done), sorted oldest to newest. It explicitly separates itself from the sibling `next` by stating its content is otherwise already covered there, so an agent can route without opening either schema.

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 states the precise condition for using this tool alone ("qu'est-ce que je n'ai pas fait") and explicitly notes that otherwise the content is already in `next`, naming the alternative. This is a complete when/when-not/alternative statement.

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

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

Annotations declare write (readOnlyHint=false) and non-destructive, but the description goes further by disclosing idempotency, that recurring events affect only the occurrence, and that the result is returned in a unified format. These are non-obvious behaviors an agent cannot derive from the structured fields.

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?

The hard constraint ('uniquement sur demande explicite de Denis') is front-loaded before any mechanics, and every clause carries operational information. Dense but no filler.

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?

With an output schema present, return values need not be explained (though the unified format is mentioned), and the safety profile is covered by annotations. Guards, scope, idempotency and the delete alternative make this complete for a 2-param mutation tool.

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 0%, so the description is the only source of parameter meaning. It gives status values (which the enum already provides) and clarifies that `id` refers to an event or task, but says nothing about id format or resolution. Partial compensation only.

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+resource ('Change le statut d'un événement ou d'une tâche') and enumerates the target states (open, done, cancelled). It explicitly distinguishes itself from the sibling `delete` tool, so an agent can route without opening any schema.

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?

Unusually explicit: it says to call only on Denis's explicit request, never on its own initiative, and gives the alternative rule ('préférer cancelled à delete : on garde la trace'). When-to-use, when-not-to-use, and the competing tool are all named.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and scope are covered structurally. The description adds default behavior (list_name defaults to all lists, status defaults to open), which is genuinely useful behavioral context, but says nothing about pagination, result limits, or ordering.

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?

Compact and front-loaded: scope and sibling differentiation come first, then the two parameter notes. No filler, though the `next` cross-reference is slightly terse and assumes the reader knows what `next` does.

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?

With an output schema present, return values need not be described, and both input parameters are explained despite 0% schema coverage. The main residual gap is the absence of explicit routing guidance versus `overdue`/`agenda`, but for a two-param read-only task lister the definition is essentially complete.

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 0%, so the description carries the full burden — and it does cover both parameters: `list_name` (name of a list, default = all lists) and `status` (open/done/cancelled with open as default). The 'default = all lists' clarification adds meaning beyond the schema, since the schema only shows a null default.

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 names the resource (Google Tasks) and, more usefully, states the scope that sets it apart from siblings: it returns tasks with or without dates, and claims to be the only tool besides `next` that surfaces undated tasks. The retrieval verb is implicit rather than explicit, but an agent can still tell it apart from `agenda`, `overdue`, and `containers`.

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 hints at the selection criterion by contrasting with `next` for undated tasks, and states the defaults (all lists, status=open), which implies a broad listing use case. However, it never says explicitly when to prefer this over siblings like `overdue` or `agenda`, so the guidance is implied rather than stated.

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

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.

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

Annotations only declare readOnlyHint=false, destructiveHint=false and openWorldHint=true; the description adds the permission model (must be explicitly requested), the return shape ('objet résultant au format unifié'), and the clear_due removal semantics for the due field. That is real behavioral context beyond structured fields.

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?

The critical guardrail is front-loaded in caps before any mechanics, and every sentence carries information. Slightly dense with parenthetical parameter detail in the final sentence, but no filler.

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?

An output schema exists, so return values need not be explained (the 'format unifié' note is a bonus). For a 6-parameter mutation tool with zero schema descriptions, the description is nearly complete; the only missing piece is the null/undefined field semantics for partial updates.

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 0%, so the description carries the load and does so for most parameters: due format 'AAAA-MM-JJ', clear_due as the removal switch, list_name as the move target, plus title and notes. It omits what passing null/omitting a field does (leave unchanged vs overwrite) and does not describe id, which is the one real gap.

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 une tâche') and enumerates the mutable fields (titre, notes, échéance, liste), which clearly separates it from siblings like add_task, update_event and set_status. An agent can identify the tool without opening the schema.

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?

Explicit when-to-use ('uniquement sur demande explicite de Denis') and explicit when-not ('ne jamais appeler de sa propre initiative, ni pour « aider », ni pour corriger'). This is unusually strong routing guidance, though it does not name a sibling alternative for the same resource.

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