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

Adds real context beyond the annotations: it saves an exact request for review and does NOT create the event, locationId is optional only for authorized organization-wide events while manager site restrictions still apply, and provider record text is untrusted data. It does not contradict the readOnlyHint=false/destructiveHint=false annotations. It omits what happens on validation failure or how the staged request is later consumed.

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 is front-loaded and the 'does NOT create' and untrusted-data caveats earn their space. But the recurrenceEndDate computation sentence ('assistant_offset_date on the first date with days=21...') is dense, jargon-laden, and hard to act on, and the API/documentation tail adds little for tool selection.

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 needn't be described, and the safety profile is covered by annotations. However, for a 13-parameter mutation with zero schema description coverage, the description leaves several recurrence parameters (recurrenceMonthlyMode, recurrenceWeekOfMonth, recurrenceDayOfWeek) unexplained, which is a meaningful gap for correct invocation.

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% across 13 parameters, so the description must compensate, and it only partly does: it explains isRecurring, recurrencePattern, recurrenceDaysOfWeek, recurrenceEndDate, locationId, and the ISO offset requirement for timestamps. It says nothing about title, eventType, description, recurrenceDayOfWeek, recurrenceMonthlyMode, or recurrenceWeekOfMonth, leaving six parameters undocumented anywhere.

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: 'Prepare a NEW calendar event, including recurring events,' and immediately clarifies that it stages rather than creates. The scope (new events only, via the original event service) lets an agent distinguish it from execute_write or prepare_schedule_template, though it never names a sibling explicitly.

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 clear conditions for use: new events, recurring events via isRecurring=true plus the recurrence fields, and notes 'No spreadsheet needed' and that the result is for review rather than creation. It lacks an explicit 'use X instead when...' routing statement against prepare_write/prepare_schedule_template, keeping it short of a 5.

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