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

With no annotations, the description carries the full burden of behavioral disclosure. It does disclose that adding guests emails them invitations, that no guests means no notifications, and that addVideoMeeting attaches a Google Meet link. However, it doesn't mention side effects like creating an event in a default calendar when calendarId is omitted, or any authorization requirements. It adds some useful context beyond the schema but misses other important behavioral aspects.

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 description is four sentences, front-loaded with the core action ('Create an event') followed by the most critical usage details. It is efficient and avoids redundancy, though it could be slightly more structured. The information is dense and relevant, with no wasted words.

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?

Given the tool has 10 parameters, 60% schema coverage, no annotations, and no output schema, the description is incomplete. It fails to explain what happens without a calendarId (likely default calendar), doesn't mention return values, and ignores optional parameters like location and description. The agent may not know how to correctly invoke it in all cases, especially regarding default calendar behavior and expected response.

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 description adds meaningful context for key parameters: it clarifies the date format distinction between all-day and timed events (start/end), explains the invitation behavior for attendees, and describes the effect of addVideoMeeting. This goes beyond the schema's descriptions, which cover 60% of parameters. It doesn't address calendarId, location, or description, but those are self-explanatory from their names. The description compensates well for the parameters it touches.

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 states 'Create an event' which, combined with the tool name 'create_google_calendar_event', clearly identifies the action and resource. It distinguishes from sibling tools like create_google_calendar (which creates a calendar) and create_outlook_calendar_event, though it doesn't explicitly name those alternatives. The verb 'Create' and resource 'event' are specific, but the description alone could be slightly ambiguous without the title.

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 description provides usage details on date formats, guest invitations, and video meeting attachment, but it never explains when to use this tool versus its alternatives (e.g., create_outlook_calendar_event). It does not mention any conditions or exclusions for using this tool, leaving the agent to infer based on the title. This is a significant gap given the large sibling list with similar creation tools.

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