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

Annotations only declare readOnlyHint=false/destructiveHint=false; the description adds substantial behavioral context beyond that: provider capability limits (EVENT_TYPE_NOT_SUPPORTED on Outlook/CalDAV), the read-only iCal feed restriction, and the exact 400 error codes (DATETIME_AMBIGUOUS/DATETIME_INVALID) returned on invalid input. This is rich disclosure of preconditions and failure modes.

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-loaded with the core action, then the constraints. The datetime paragraph is dense but each clause (four shapes, resolution semantics, rejection rule) is load-bearing. No filler sentences, though the density borders on exhaustive for a description field.

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 creation tool with no output schema, the description covers preconditions, provider limits, and the tricky datetime contract well. It does not mention what the call returns (e.g. created event ID), which would help an agent chain subsequent calls, leaving a minor 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 coverage is 67%, so the description must carry weight, and it does — enumerating the four accepted datetime shapes, the wall-clock resolution rule, and the 'never assumed UTC' contract. Much of this partly overlaps the start/end schema descriptions, but the end-time cross-field rule ('strictly after start') and error behavior add genuine meaning.

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 ('Create a new calendar event') that clearly distinguishes it from siblings update_event, delete_event, get_event, and list_events. An agent can route to it without ambiguity.

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 a clear when-not exclusion ('Not supported for read-only iCal feeds') and provider-capability constraints. It does not explicitly contrast creation against update_event for the edit case, but the context is strong enough to imply correct usage.

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