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

With no annotations, the description itself discloses that this is a partial mutation ('Patch... Only include fields to change') and that passing an empty recurrence string stops repetition, which is useful non-obvious behavior. It does not disclose auth requirements, idempotency, or effects on related fields, but the core update semantics are clear.

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 sentences, action first, no filler; every sentence carries operational information. The partial-update guidance is front-loaded and the recurrence caveat 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 10 parameters, no annotations, 10% schema coverage, and no output schema, this short description leaves significant context implicit: what the tool returns, whether events/meetings are in scope, and how this relates to tasks_complete. It covers recurrence well but is incomplete for safe invocation at the stated complexity.

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?

The recurrence sentence adds real meaning beyond the enum by saying recurrence can be turned on, changed, or removed, and it reinforces the schema's empty-string instruction. Since schema description coverage is only 10%, the other nine parameters rely on self-explanatory names; the description does not clarify ambiguous ones such as kind meaning task/event/meeting.

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?

Description opens with a specific verb (Patch) and resource (a task), and clarifies partial-update semantics with 'Only include fields to change.' It does not, however, explain the tool's relationship to tasks_complete or that the schema also accepts event/meeting kinds, so it stops short of full sibling differentiation.

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 phrase 'Only include fields to change' and the recurrence note give basic how-to direction and tell the agent this is the endpoint for changing recurrence. It does not state when to prefer tasks_complete, tasks_delete, or tasks_create, so the when-to-use guidance is implied rather than explicit.

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