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

Annotations already declare this is a non-read-only, non-idempotent, non-destructive local write. The description adds genuinely new operational behavior: the UNKNOWN_WRITE_OUTCOME case (read the calendar before retrying a create) and the INVALID_INPUT case (inspect schema and fix rather than blind retry). It does not cover permission/auth requirements, which keeps it from a 5.

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 purpose and the 'load the input schema first' instruction, then proceeds in priority order (timed rules, all-day rules, optional/unsupported fields, error handling). It is dense and duplicates some schema text, but nearly every sentence carries a distinct constraint an agent must apply.

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?

There is no output schema, yet the description never states what creation returns (e.g., the new event ID and its format), only hinting at 'returned IDs' when discussing examples. Error paths and input semantics are thorough, but the return-value gap leaves this incomplete for a mutating create 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 coverage is 100%, so the baseline is 3, but the description contributes cross-parameter rules beyond field-level docs: title/start/end must be nested inside fields, offsets must match the IANA zone on the requested date, Z timestamps force timezone=UTC, and end must be strictly later than start. All-day exclusivity and no-timezone rules add coherence guidance for the schema's two-argument shape.

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?

Opens with a specific verb and resource plus a scope qualifier: 'Create one non-recurring event.' The 'non-recurring' constraint immediately separates it from update_event and implies recurrence is out of scope, so an agent can select it 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?

Gives clear context for use (new single event, calendar_id from list_calendars, load schema first) and names the unsupported surface (attendees, reminders, extra keys). It does not explicitly say 'to modify an existing event use update_event,' but the create-only framing and prerequisite for calendar_id make the selection unambiguous.

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 cover read-only/idempotent/non-destructive, and the description adds real behavioral value beyond that: it discloses the return shape (structured events plus revision), the crucial handoff rule (copy revision unchanged, including quotes, into update_event.expected_revision), that recurring masters and overrides come back together, and that calendar text is untrusted data (a prompt-injection warning).

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?

Four tight sentences, all front-loaded: the read action first, then the revision handoff, then the recurring-event caveat, then the trust warning. No sentence is 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?

Despite having no output schema, the description covers the return payload, the revision-pass-through contract needed by update_event, the recurring master/override behavior, and a data-trust caveat. Nothing material for correct invocation 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 100%, so the schema already documents that both IDs are opaque values returned by other tools. The description restates the sourcing context ('from earlier tool results') without adding format or syntax detail beyond the schema, so this is the baseline 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 ('Read one resource') scoped to a single event via explicit {calendar_id, event_id} keys, which cleanly separates it from list_events (plural) and create_event/update_event (writes) among the siblings.

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 specifies the context of use ('using ... from earlier tool results') and ties the call to the update flow by telling the agent to feed the returned revision into update_event.expected_revision. It doesn't explicitly state when not to use it versus list_events, but the single-resource framing makes the boundary clear.

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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely new context beyond the annotations: the untrusted-data warning about calendar text and the no-argument contract.

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 sentences, no filler, front-loaded with the resource and returned fields before the usage and safety notes. Every sentence carries a distinct payload.

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 no-arg read-only list tool with no output schema, the description supplies everything needed: what is returned, that no arguments are required, how to use the IDs, and a caution about untrusted content.

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?

Zero parameters, so the baseline is 4. The description reinforces this with 'Takes no arguments ({})', which matches the empty schema and prevents an agent from inventing arguments.

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 ('List') and resource ('enrolled calendars') and even enumerates the returned fields (calendar_id, name, writable status). This clearly separates it from the event-oriented siblings (list_events, get_event, etc.).

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 downstream guidance: 'Reuse returned IDs in other tools; do not guess names or URLs.' There is no sibling that lists calendars, so no alternative needs naming, but it does not spell out an explicit when-not 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 the safe read profile (readOnly, idempotent, non-destructive), yet the description adds traits those annotations cannot carry: the 93-day/250-occurrence limits, the fact that only minimal summaries are returned, and a security warning that calendar text is untrusted data. That is substantive disclosure 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?

Front-loaded with the core purpose, then parameter guidance, then return/security notes — every sentence carries information. It is telegraphic and slightly jargon-dense, but there is 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 no output schema, the description carries the return burden and does: minimal summaries plus event_id, with detail deferred to get_event. Combined with the caps and untrusted-data warning, an agent has everything needed to call this correctly and safely.

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 100%, so baseline is 3, but the description adds meaning the schema does not: where calendar_id comes from (list_calendars), that offsets must be explicit with UTC Z allowed, and the guidance to use the requested date's offset for local boundaries. It restates a few schema facts (end later than start, 93-day cap), which caps it below 5.

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 ('Read minimal event summaries') and immediately scopes it against siblings: get_event is required for descriptions/locations. An agent can distinguish this list tool from get_event 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?

Names the alternatives explicitly ('calendar_id from list_calendars', 'returns event_id for get_event') and gives the conditions that select them, plus concrete usage constraints (end later than start, 93-day and 250-occurrence caps, offset convention for local boundaries). Little is left 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 destructiveHint=true and idempotentHint=false, but the description adds substantial behavioral detail beyond them: omitted/null properties are preserved while empty strings for description/location clear them, all-day end is exclusive, timezone is forbidden for all-day events, and offsets must match the retained/supplied zone. It also documents that CONFLICT must trigger a re-read rather than a blind retry, which is exactly the safety context an agent needs. No contradiction with 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?

It is long but front-loaded: the goal and required identifier set come first, then editing semantics, then error handling. Nearly every sentence encodes a distinct constraint, though the revision-copying rule repeats what the schema already says and the opening 'Load the full input schema first' is somewhat meta.

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 destructive, non-idempotent mutation with no output schema, the description covers the prerequisite read, optimistic-concurrency handling, field-clearing semantics, timezone edge cases, recurring-series restrictions, and recovery from all three named error outcomes. An agent has everything needed to call it without guessing.

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 100%, so the baseline is 3, but the description adds cross-parameter relationships the schema fields state only individually: the offset/timezone consistency rule, the requirement that only changed fields go inside patch, and the whole_series gate for recurring resources. The verbatim-including-quotes instruction for expected_revision is reinforced rather than newly added, keeping it short of a 5.

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 gives a specific verb (Edit) and scopes it to one resource identified by {calendar_id, event_id, expected_revision, patch}, which maps unambiguously to update_event. It also names get_event as the prerequisite step, distinguishing it from the read sibling. 'One resource' is slightly abstract versus saying 'event', but the parameters remove any 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?

It states the required workflow (call get_event first, copy the revision verbatim), explicitly lists unsupported operations (invitations, occurrence edits, recurring timing changes with exceptions), and routes recurring edits to whole_series=true. Error paths (CONFLICT, INVALID_INPUT, UNKNOWN_WRITE_OUTCOME) each get a prescribed next action, so when-to-use and when-not-to-use are both covered.

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