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

With no annotations at all, the description carries the full burden, and it does disclose meaningful behavior: end auto-defaults to start + 1 hour (next day for all-day), timezone_name only applies to offset-less datetimes, and it returns the new event's uid. It stops short of side effects — no mention of invitations/notifications, whether duplicates are created, or what happens when calendar_name is omitted.

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 action, then dense format rules with concrete examples (2026-11-06, America/Sao_Paulo) and no filler sentences. Every clause conveys a rule an agent would otherwise get wrong.

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 an 8-parameter mutation with no annotations and no output schema, the description covers formats, defaulting, and the return value but leaves the calendar selection, alarm semantics, and side effects unexplained. An agent could call it, but could also silently create the event in the wrong calendar.

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 0%, so the description must carry parameter meaning, and it does well for start, end, and timezone_name. But four of eight parameters — calendar_name, alarm_minutes_before, location, description — are never mentioned, leaving the target calendar and alarm units/defaults entirely unspecified.

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 ('Create a calendar event'), which cleanly separates it from calendar_update_event and calendar_delete_event. It never explicitly routes to or away from those siblings, but the operation type alone is unambiguous.

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?

Usage is implied by the verb, and the format rules (ISO date vs datetime, IANA timezone) do tell the agent how to call it. However there is no guidance on when to prefer calendar_update_event versus a fresh create, nor any prerequisite such as which calendar is used by default or whether authentication/permissions are required.

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?

With no annotations provided, the description carries the behavioral burden and discloses the most important trait: deletion is permanent and cannot be undone. It does not mention permission requirements or other side effects, but the destructive irreversibility is clearly stated.

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 two short sentences with no wasted words. The core action and its irreversible nature are front-loaded, and the source of the uid is included compactly.

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 simple two-parameter delete tool with no output schema, the description covers purpose and irreversibility adequately. However, with no annotations and 0% schema description coverage, it should explain calendar_name and at least acknowledge permission or side-effect expectations.

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%, so the description must compensate for both parameters. It adds useful meaning for uid by noting it comes from calendar_list_events, but it says nothing about the optional calendar_name parameter, leaving half the parameters undocumented.

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 a specific verb and resource ('Permanently delete an event') and identifies the required identifier source ('uid from calendar_list_events'). This clearly distinguishes deletion from sibling tools such as calendar_update_event and calendar_create_event.

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 provides clear usage context by naming calendar_list_events as the source of the uid, which tells the agent how to obtain the required input. It does not explicitly describe when not to use the tool or name alternatives for modifying events, so it falls short of full routing guidance.

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?

No annotations are provided, so the description carries the full burden. It implies a safe read by saying 'List' and discloses the returned fields (name, supported component types), but says nothing about authentication needs, result ordering, or whether the list is paginated.

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?

A single sentence with zero waste, leading with the verb and resource and appending only the useful field list.

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 need no explanation, and a zero-parameter read is inherently simple. The description covers what an agent needs, though a note on scope (all calendars vs. selected) would fully close the 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline applies. The parenthetical describes output fields rather than parameters, which is harmless.

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 ('iCloud calendars') and names the returned fields. It is clearly distinct from siblings like calendar_list_events and reminders_list_lists by resource, though it doesn't explicitly contrast with them.

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?

There is no statement of when to use this tool versus alternatives such as calendar_list_events, nor any prerequisites or exclusions. Usage is only inferable from the verb and resource name.

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?

With no annotations, the description carries the full burden. It does add genuine behavioral context: recurrences are expanded (so recurring instances appear individually) and dates accept ISO dates or datetimes. It omits the read-only safety profile, the 200-event default cap and whether results are truncated or paginated, which matters for a listing tool.

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 short sentences, front-loaded with the core operation and its range constraint, with the recurrence and filter notes trailing. Nothing is redundant, though the parenthetical example is slightly bulky for the value it adds.

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 essential call contract (required range, optional filter, recurrence expansion) is covered. The missing pieces are the limit/pagination behavior and any statement of read-only semantics, which for a no-annotation tool leaves a real 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 description coverage is 0%, so the description must compensate, and it does for three of four parameters: start/end get accepted formats with concrete examples, and calendar_name is identified as an optional filter. The `limit` parameter (default 200) is never mentioned, leaving its truncation semantics undocumented in both places.

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 and resource ("List events") plus the bounding dimension ("between start and end"), which is enough to distinguish it from the sibling mutators calendar_create_event, calendar_update_event and calendar_delete_event. It stops short of explicitly naming those siblings, but the read-vs-write split is unambiguous.

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?

Usage is implied by the required date range and the optional calendar filter, so an agent can infer the intended call shape. However, there is no explicit statement of when to prefer this tool, when not to, or what to do when the range is large — no alternative is named despite four calendar siblings existing.

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?

With no annotations, the description carries the full burden. It does disclose two non-obvious behavioral traits: patch semantics ('Only the fields you pass change') and that recurring events with exceptions are updated as a whole series. But it says nothing about permissions, behavior on an unknown uid, timezone handling, or what the call returns.

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, no filler, and the core patch semantics are front-loaded ahead of the exclusion caveat. Every clause carries information an agent needs.

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 mutation tool with 8 parameters, zero schema descriptions, and no annotations or output schema, the description leaves too much undefined — most critically the date/time format and timezone semantics of the required data. The series caveat is valuable, but the parameter-level gap is large.

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 8 parameters, so the description must compensate and largely does not. Only uid gets any treatment (implicitly, via the list-events hint); start/end formats, timezone_name vs. start timezone interaction, and calendar_name scope are all left undefined.

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 ('Change fields of') and resource ('an existing event'), and identifies the lookup key (uid, sourced from calendar_list_events). This clearly separates it from calendar_create_event and calendar_delete_event by implying mutation of an existing entity, though it never names those siblings 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 a clear operational prerequisite (obtain uid from calendar_list_events) and an explicit when-not: 'Not for recurring events with exceptions.' That exclusion is genuinely selective guidance. It stops short of naming an alternative tool for the recurring-with-exceptions case, so it isn't a full 5.

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?

With no annotations, the description carries the full burden, and it does disclose meaningful behavior: substring matching across four fields and the empty-query-lists-all fallback capped at a limit. It stops short of stating that this is a read-only, side-effect-free operation or whether truncation at the limit is silently reported, leaving some behavioral questions open.

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?

A single sentence that front-loads the verb and resource and packs two useful behavioral details into a parenthetical with zero waste.

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?

Low-complexity two-parameter read tool with an output schema, so return values need no explanation. The description covers both parameters' semantics and the key edge case (empty query); only truncation signaling when results exceed the limit is unaddressed.

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%, so the description must compensate, and it largely does: 'query' is explained as a substring match over name/email/phone/org with empty meaning list-all, and 'limit' is referenced as the cap. Only the default value (50) and truncation semantics are left to the schema.

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 ('Search iCloud contacts') and enumerates the searchable fields (name/email/phone/org), so the agent knows exactly what this tool does. No contacts-domain siblings exist in the list to differentiate against, so the lack of explicit sibling routing is a minor gap rather than a real 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?

The parenthetical '(empty query lists all, up to limit)' tells the agent it can enumerate contacts by passing nothing, which is useful implied usage. However, there is no explicit when-to-use/when-not guidance, no mention of alternatives (there are none in the sibling set), and no indication of what happens when the result set exceeds the limit.

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?

With no annotations, the description carries the full burden. It usefully adds the due format, priority range, and return value (uid), but omits side effects, permissions, validation behavior, and what list_name/timezone_name do. Some behavioral context is present but incomplete for a mutation tool.

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, front-loaded with the action, then key parameter semantics, then return value. No filler or redundancy.

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 create tool with six parameters, no annotations, and no output schema, this is too sparse. It does not explain required title behavior, list placement, timezone handling, notes, or side effects, leaving significant gaps 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%, so the description must compensate for six parameters. It only explains due and priority; title, notes, list_name, and timezone_name remain undocumented beyond their bare schema titles.

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 reminder.' This clearly distinguishes it from reminders_list_*, reminders_update, and reminders_delete, though it does not explicitly name sibling alternatives.

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 no guidance on when to use this tool versus alternatives such as calendar_create_event, nor any prerequisites or exclusions. The agent must infer that this is the creation operation for reminders.

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?

With no annotations, the description carries the full behavioral burden, and it does disclose the single most important trait: deletion is permanent and cannot be undone. It says nothing about permissions, what happens if the uid does not exist, or whether deletion affects the containing list, leaving meaningful gaps for a destructive mutation.

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 short sentences with zero waste; the destructive consequence is stated immediately after the action, which is the correct front-loading for a delete tool.

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 simple two-parameter tool with no output schema or annotations, the description covers the action and its irreversibility adequately. It falls short on the undocumented list_name parameter and on error behavior for a nonexistent uid, both of which an agent would want before calling a destructive 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 description coverage is 0%, so the description must compensate and it only partially does: 'by uid' implicitly identifies uid as the reminder key. The optional list_name parameter is never mentioned, leaving an agent to guess whether it scopes or disambiguates the deletion.

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 a specific verb (delete) and resource (reminder) with the identifier (uid), which clearly separates it from siblings like reminders_update and reminders_create. It stops short of explicitly naming or contrasting those siblings, so it lands at a clear-but-undifferentiated 4.

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?

There is no guidance on when to delete versus when to use an alternative such as reminders_update or marking an item complete. The irreversible wording hints at caution but gives no conditional or alternative routing, which is exactly what an agent choosing among 10 siblings needs.

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?

No annotations are provided, so the description carries the full burden. It conveys only that results are filtered to incomplete items; nothing is said about read-only safety, Reminders/OS access permissions, ordering, or how the default limit of 200 truncates results.

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?

A single front-loaded sentence with no padding. It is efficient, though its brevity leaves the optional filter clause doing double duty as both parameter hint and scope statement.

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 shape needn't be explained, but for a 2-parameter, unannotated tool the definition omits limit behavior, list_name semantics, and any routing against the sibling reminders tools, leaving real gaps 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%, so the description must compensate. It gestures at list_name ('from one list') but never clarifies it is a list name string or whether matching is exact, and the limit parameter with its default of 200 is not mentioned at all.

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) plus resource (incomplete reminders/VTODOs) and adds the scoping dimension ('optionally from one list'). It implicitly separates itself from reminders_list_lists by dealing with reminders rather than lists, though it never names the 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?

'Optionally from one list' hints at when to pass list_name, but there is no explicit when-to-use guidance, no mention of reminders_list_lists as the way to discover valid list names, and no exclusion of alternatives such as a completed-reminders listing.

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?

With no annotations, the description carries the full burden. "List" implies a non-destructive read, and the VTODO clarification adds useful domain context, but nothing is said about permissions, whether all lists are returned, or any rate limits. Adequate but with clear gaps for an unannotated tool.

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?

A single front-loaded sentence with zero waste; the resource and its clarifying equivalence are stated immediately.

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 zero-parameter list tool with an output schema, the description needn't explain return values. It states what is listed and disambiguates the resource, though it could note scope (e.g., all lists vs. filtered) for full completeness.

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 tool takes zero parameters, so baseline is 4. There is nothing for the description to document beyond what the empty schema already conveys.

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 pairs a specific verb ("List") with a specific resource ("iCloud reminder lists") and clarifies with "calendars that support VTODO," which distinguishes it from calendar_list_calendars. It stops short of explicitly differentiating itself from reminders_list_incomplete, but the resource is unambiguous.

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?

There is no statement of when to use this tool versus siblings like reminders_list_incomplete or calendar_list_calendars. The listing purpose implies a discovery use case, but no prerequisites, exclusions, or alternatives are named.

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?

No annotations are provided, so the description carries the full behavioral burden for a mutation tool, and it discloses almost nothing: no permissions requirements, no statement that omitted/null fields are left unchanged, no confirmation of reversibility or of what the response returns. Only the completed=true effect is explained.

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 short sentences, front-loaded with the identifying action and the uid source, with no filler. Its brevity is a virtue stylistically even though the content is thin for this many parameters.

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 an 8-parameter mutation tool with no annotations, no output schema and zero schema descriptions, the definition leaves too much unspecified: how partial updates behave, what each field means, and what happens on success. An agent would have to guess at most parameters before calling it.

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?

With 0% schema description coverage and 8 parameters, the description should compensate but only addresses uid (source: reminders_list_incomplete) and completed (true = done). due, notes, title, priority, list_name and timezone_name are entirely undocumented, as is the null-default partial-update semantics.

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 ('Change a reminder') and names the sibling that supplies the required uid (reminders_list_incomplete), which separates it from reminders_create, reminders_delete and the calendar tools. It does not describe the update scope (full replace vs partial patch), but the core purpose is unmistakable.

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 implies a fetch-then-update workflow by pointing at reminders_list_incomplete as the source of the uid, and gives one concrete usage hint ('Pass completed=true to mark it done'). It does not state when to use this instead of reminders_create or what to do about fields that should not change.

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