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

With no annotations, the description carries the full burden and mostly delivers: it discloses the ordering, the returned fields (when, agent, tool, summary, undoable, undone), and that app-side edits are invisible to the log. It does not address pagination/limit behavior or any permission or retention constraints, which are the remaining behavioral gaps for a mutation-adjacent log.

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 dense but front-loaded: purpose and return shape first, then the undo handoff, then filter semantics, then the scope caveat. Every clause carries information, though the semi-colon-chained filtering sentence is slightly compacted and could be split for faster scanning.

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 read-only, four-optional-parameter query tool with an output schema and no annotations, the description covers purpose, ordering, fields, filters, the undo linkage, and the scope limit. Return-format detail is excused by the presence of an output schema; the only real omission is limit/pagination semantics.

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 largely does: 'Filter by agent name or tool' explains the agent and tool params, and 'only_undoable hides the rest' explains only_undoable. Only 'limit' goes unexplained (its default of 20 and interaction with the 'newest first' ordering are left implicit).

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 resource (an audit log of changes made through this server) with its ordering (newest first) and explicit scope exclusion (changes made directly in the Calendar/Reminders apps are not recorded). It also names the sibling it pairs with ('Use the id with the undo tool'), so an agent can distinguish it from the mutate-family tools at a glance.

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 gives concrete routing guidance ('Use the id with the undo tool') and a clear exclusion ('Changes made directly in the Calendar/Reminders apps are not recorded here'), plus how filters behave. It stops short of stating when to consult the log at all (e.g. before or after a mutation), so it is strong rather than complete.

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 does well: 'Add' makes the mutation explicit, the one-level nesting limit is non-obvious and disclosed, and the return value (new subtask with 'parent' set) is described. It omits permissions/preconditions (e.g., must the parent exist) and any error behavior, keeping it short of 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?

Three tight sentences, front-loaded with the action and the most important constraint. Every sentence adds distinct value (purpose, nesting limit, options reference, return shape) with zero 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?

For a 7-parameter mutation tool with no annotations or output schema, the description covers the critical non-obvious facts: nesting limit, shared option set, and return value. Remaining gaps (due format, permission/precondition requirements) are minor given the cross-reference to create_reminder.

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 names the five optional parameters (due/notes/priority/flagged/notify) but defers their actual meaning to create_reminder rather than defining formats (e.g., due's expected format). parent_id and title are left to their obvious names, so compensation is partial.

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 ('Add a subtask under a reminder') and immediately clarifies the scope: it lives in the parent's list. The one-level nesting constraint cleanly distinguishes it from create_reminder without requiring the agent to open either 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?

Clearly establishes context and a key constraint: the app nests only one level, so a subtask cannot itself have subtasks. It also routes the agent to create_reminder for the shared option semantics. It stops short of explicitly comparing alternatives or stating exclusions, but the usage context is 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?

With no annotations, the description carries the full burden and does so well: it discloses the return shape (events sorted by start with their calendar), the overdue-reminder logic and its start-date dependency, the include_overdue escape hatch, and the exclusion of reminders with no due date. It stops short of declaring read-only/permission behavior or pagination.

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 punchy 'What's on' lead, then parameter semantics, then return behavior. Dense and mostly waste-free, though the returns sentence is a run-on that could be split for readability.

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 3-param, no-output-schema, no-annotation tool, the description covers parameters, return contents, and edge-case behavior adequately. Missing only peripheral details like auth/rate-limit expectations, which are minor for a read-oriented agenda call.

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%, yet the description fully documents all three params: start format ('YYYY-MM-DD') and default (today), days semantics (1 = just that day, 7 = a week), and include_overdue behavior. Complete compensation for the schema gap.

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 aggregation over two resources: events from ALL calendars plus due reminders in one call, which distinguishes it from the single-resource list_events and list_reminders siblings. It stops short of naming a specific sibling alternative (e.g. week_summary, find_free_time), so it's clear but not maximally differentiated.

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 'What's on' framing implies the daily-agenda use case, and the parameter explanations imply usage, but the description never explicitly says when to use this versus list_events, week_summary, or find_free_time, nor any when-not conditions.

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 exist, so the description carries the full burden and does well: it discloses the dry-run default, the batch cap, and the implicit skipping of completed reminders. It stops short of stating whether delete is reversible, whether any permission/auth constraint applies, or how partial failures are reported.

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-loads the most important fact (SAFE BY DEFAULT preview behavior) before the action list and filter syntax. It is dense but every clause carries operational information; a minor redundancy is the trailing 'set_priority needs set_priority', which reads as awkward phrasing rather than 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?

For a 15-parameter, no-annotation, no-output-schema mutation tool, the description covers selection, action-specific requirements, limits, and the commit/preview model. It omits what the preview response contains and whether ids can be combined with filters to narrow a set, which are the main remaining gaps.

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% and there are 15 parameters, so the description must compensate entirely — and it does: it documents the action enum values, priority enum values, date formats (YYYY-MM-DD inclusive), shift_days semantics ('keeps the time'), title_contains, include_completed, and the filter-vs-ids relationship.

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+resource ('Change many reminders at once') and enumerates all eight supported actions, which cleanly separates it from the single-reminder siblings (update_reminder, complete_reminder, delete_reminder) in the sibling list.

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?

Explicitly states the safe-by-default workflow (apply=False previews, apply=True commits), how to select targets (ids exact vs filters), and the guardrails: at least one selector required, max 50 per call, completed items skipped unless include_completed=True. Also names per-action prerequisites (move needs to_list, reschedule needs exactly one of shift_days/new_due).

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 does well: it discloses the end-defaulting rule (start + 1 hour), the whole-day input format, the calendar scope behavior, and the shape of the return (events each with their calendar, all_day flag). It stops short of stating permissions or whether the check is purely read-only, but the operational behavior is well disclosed.

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 core question then the input formats then the output. The rhetorical opening 'What overlaps a proposed time?' is slightly stylized but still earns its place as a purpose 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?

For a 3-parameter read tool with no output schema and no annotations, the description covers purpose, input formats, defaults, scope, and return shape — enough for an agent to call it correctly. Missing only secondary details such as timezone semantics and result ordering.

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, documenting start, end (including its default), and calendars ('or the named ones'). Only timezone handling for the ISO datetimes is left ambiguous.

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 operation (find what overlaps a proposed time interval) on a clear resource (calendar events), which an agent can readily separate from list_events or search_events. It never names a sibling to differentiate against, but the conflict-detection framing is distinctive enough on its own.

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 phrase 'a proposed time' implies the pre-creation check use case, but there is no explicit when-to-use or when-not-to-use guidance and no routing to close siblings like find_free_time or propose_event. Usage is inferred rather than stated.

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. It does disclose one meaningful trait beyond the schema - that the operation is reversible by passing completed=False - which tells the agent this is a non-destructive toggle, but it says nothing about permissions, failure modes, or whether other reminder fields are touched.

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 short sentence with the action front-loaded and the optional-mode detail parenthetically appended. No filler, no redundancy, and the most important information comes first.

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 mutation with no annotations and no output schema, the description covers the core action and its inverse but omits what 'id' refers to and what happens on an invalid or already-completed reminder. Adequate, but with recognizable gaps for a state-changing 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 nothing in the schema explains what the parameters mean. The description usefully clarifies the semantics of 'completed' (true = complete, false = incomplete), but the required 'id' parameter is left entirely undefined, so the compensation for the coverage gap is only partial.

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 ('Mark') and resource ('a reminder') plus the exact state transition it produces, so the operation is unambiguous. It does not, however, differentiate itself from the closely related update_reminder sibling, which could plausibly perform the same mutation.

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 name and the completed=False note, letting an agent infer this is the tool for toggling completion rather than general edits. There is no explicit statement of when to prefer this over update_reminder or delete_reminder, and no prerequisites or exclusions are given.

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 does well: it discloses the uniqueness constraint, the color format, that the result is the name, and explicitly that the operation 'Can be undone' (reversibility). It omits auth/permission requirements and error behavior, but covers the essentials for a non-annotated 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?

Four short sentences, purpose front-loaded, and every clause earns its place — constraint, format, return value, and reversibility each add distinct information with zero padding.

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?

No output schema and no annotations exist, yet the description still explains the return value (name) and its downstream use, plus key constraints. Complete enough for a two-parameter tool; only minor edge details like default color handling are absent.

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 compensate, and it does: it documents the uniqueness requirement for `name` and specifies the accepted format for `color` ('#RRGGBB'). Only a minor gap remains (default empty color behavior).

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 first sentence states a specific verb and resource ('Create a new event calendar'), which cleanly separates it from the many create_* siblings (create_event, create_list, create_reminder). An agent can identify the tool 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?

It gives useful workflow context ('use that as the `calendar` argument of the event tools') and a precondition ('Names must be unique'), but never states when to choose this over rename_calendar, set_calendar_color, or delete_calendar, nor any explicit alternatives. Adequate implied usage with clear gaps.

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 does surprisingly well: it discloses the end-time default (+1 hour), that repeats run forever unless repeat_count/repeat_until bounds them, that the two bounds are mutually exclusive, and exactly what warn_conflicts does ('a timed event is still created, but the result lists any events it overlaps under conflicts'). It omits permissions/auth requirements and what the call returns on success (e.g. an event id).

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?

Dense but front-loaded: the core create + start/end semantics come first, then repeat, alerts, conflicts, and metadata. Each clause covers a distinct parameter family with no filler, though the single unbroken paragraph makes lookup harder than a short structured list would.

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 17-parameter mutation tool with no annotations and no output schema, this covers parameter formats, defaults, and side-effects (conflict listing, unbounded recurrence) thoroughly. The remaining gaps — the required calendar identifier, permission requirements, and the success return value — are meaningful but narrow.

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 documents the non-obvious parameters in real depth: start/end ISO format, the all-day 'YYYY-MM-DD' convention and its midnight-based alerts rule, repeat/repeat_interval/repeat_days/repeat_count/repeat_until, alerts, status values, priority range, categories, url, and warn_conflicts. The required 'calendar' parameter is never explained (name or id?), and summary/location/description are left to their self-evident names.

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 opening sentence 'Create an event' states a specific verb and resource, which cleanly separates it from update_event, delete_event, and duplicate_event in the sibling list. An agent can identify the operation 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?

Usage is only implied – the description explains warn_conflicts behavior but never says when to prefer this tool over alternatives like propose_event, check_conflicts, or find_free_time, nor does it state prerequisites. For a straightforward create tool this is defensible, but there is no explicit when-to-use 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?

With no annotations, the description carries the full burden and does disclose several real traits: uniqueness constraint on names, the returned id/title, and the fact that color/icon are not configurable yet. It omits error behavior on duplicate names and any auth/permission notes, keeping it short of 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?

Three tight sentences: purpose first, then the uniqueness constraint, then return-value handling and the color/icon caveat. Every sentence carries information an agent would otherwise lack; nothing is padded.

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 one-parameter creation tool with no annotations and no output schema, the description covers the essentials: what it makes, the uniqueness rule, what it returns, and how the return value feeds other tools. Only duplicate-name failure behavior is left unstated.

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% and there is a single required `name` parameter, so the description must compensate. It adds the meaningful 'Names must be unique' constraint, but gives no format, length, or validation guidance beyond that.

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 Reminders list'), and the parenthetical clarifies the in-app location. The resource ('Reminders list') is clearly distinct from sibling creators like create_calendar, create_event, create_note, and create_reminder, so an agent can route without opening a 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?

It explains downstream usage ('use either as the `list` argument of the other tools'), which is helpful workflow context, but never states when to prefer create_list over alternatives or any precondition/exclusion. Usage is only implied by the verb.

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 behavioral burden and does real work: it discloses that the first line is rendered as the title, that the rest becomes body, and that only plain text is accepted. It omits failure/idempotency behavior and what the call returns, which keeps it short of 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?

Four short sentences, front-loaded with the action, no filler. Each sentence supplies distinct information (purpose, text semantics, folder semantics, format limit).

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 2-parameter creation tool with no output schema or annotations, the description covers purpose, parameter meaning, and format constraints adequately. It could note the return value or behavior on an unknown folder, but nothing essential 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 coverage is 0%, so the description must compensate, and it does for both parameters: 'folder' is explained as a name-or-id with empty meaning the default Notes folder, and 'text' is mapped to title/body structure. Only minor gaps (e.g., length/format limits) remain.

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 an Apple Note'), and the resource noun unambiguously separates it from the other create_* siblings (create_event, create_reminder, create_calendar). An agent knows immediately what this tool produces.

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 when to invoke it (to make a new note) but never says when not to use it or names alternatives such as move_note/delete_note. With no explicit routing guidance, this is only implied usage.

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 does well: it explains the notify default ('a reminder with a due TIME gets an alarm ... Set notify=False for a silent due time'), that user-supplied alarms override it, that the app holds only one early reminder, and that urgent/repeat require a due date. It omits failure modes, permissions, and what happens if the list is not found.

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 structured as one line per parameter group, front-loaded with purpose, and nearly every clause conveys non-obvious behavior (e.g. the '9 PM with a 15 minute heads-up' example). A few justifications are wordier than needed but none are 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?

For a 20-parameter creation tool with no annotations and no output schema, the description covers the risky/ambiguous inputs well enough to call it correctly. Missing: behavior on invalid list/title, and any indication of what the call returns.

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% across 20 parameters, so the description must compensate, and it largely does: formats for due, alarms, early_* semantics, priority values, repeat rules, and tag syntax are all spelled out. Gaps remain for notes and flagged, which carry no explanation 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+resource ('Create a real Apple Reminder in a list') and clarifies that the list can be a name or id. It does not, however, differentiate itself from siblings like bulk_reminders or create_event beyond a single aside routing nested items to add_subtask.

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 only explicit routing guidance is 'parent: ... prefer the add_subtask tool'. There is no guidance on when to use this versus bulk_reminders, or on required preconditions such as the target list existing. Usage is implied rather than stated.

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 does well: it discloses the refusal-on-non-empty rule, the cascading destructive behavior of delete_events, a 500-event limit, and — importantly — that the deletion is recoverable via undo. It omits permission/prerequisite requirements and whether an empty-calendar delete is likewise undoable.

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, front-loaded with the action, then the critical caveat and its consequences. The nested parenthetical about the 500 cap and undo is dense but each clause adds real information; nothing 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?

For a destructive two-parameter tool with no annotations and no output schema, the description covers the failure mode, the destructive flag's effect, a scale limit, and recovery. Missing only the identifier format for 'calendar' and any auth/prerequisite context.

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 explains delete_events thoroughly (what it enables, its cascade, the cap, reversibility), but the required 'calendar' parameter is left entirely undescribed — no hint whether it takes a name, ID, or path.

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+resource ('Delete an event calendar') that is unambiguous against siblings like delete_event, delete_list, and rename_calendar. The agent immediately knows this removes a whole calendar, not its contents or a list.

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 precise precondition for using it: a non-empty calendar is refused unless delete_events=True, so the agent knows when the default call will fail. It does not, however, name alternatives (e.g., delete_event for clearing contents) or state when deleting a calendar at all is preferred.

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 burden and does disclose meaningful traits: the whole-series deletion for repeating events, that the deletion is logged, and that it is reversible via the undo tool. It does not cover permission/auth requirements, but the destructive scope and reversibility are well conveyed.

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 tight sentences with the destructive scope front-loaded and no filler; every sentence adds actionable information.

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?

Output schema exists so return values need not be explained, and the series/undo behavior is covered. However, for a mutation tool with no annotations and an undocumented calendar parameter, the definition leaves key context gaps.

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 compensate. It explains that uid identifies the event but adds no format or qualifier details, and the calendar parameter is entirely unexplained in both schema and description.

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 (delete) and resource (event), plus the uid-based scope. It is clear what the tool does, though it does not explicitly differentiate itself from sibling deleters like delete_calendar or delete_reminder.

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 mention of the undo tool implies reversibility and the series note clarifies the outcome for repeating events, but there is no explicit when-to-use/when-not guidance versus alternatives such as update_event for adjustments or deleting a single occurrence.

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 full burden and does so well: it discloses the destructive cascade (reminders and their subtasks are removed), the guard that blocks deletion of a non-empty list, and the reversibility via the undo tool. These are exactly the traits an agent needs before invoking a destructive operation.

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 tight sentences, front-loaded with the action and scope, then the failure condition, then recovery. Every sentence adds information; nothing is redundant with the name or schema.

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 2-parameter, annotation-free, no-output-schema destructive tool, the description covers the essential decision points (guard, cascade, undo). It omits whether confirmation or special permissions are required and does not describe the response, though the absence of an output schema lowers that expectation.

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% and neither parameter has a meaningful description, yet the prose compensates: 'list' accepts a name or an id, and delete_reminders is explained both as the override for the refusal guard and as a cascading delete of reminders plus subtasks. Default-false behavior is implied rather than stated, keeping it just under 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?

States a specific verb+resource ('Delete a list') and clarifies the accepted identifier form ('name or id'). It is clearly distinguishable from sibling mutations like create_list and rename_list, and the cascade semantics further sharpen the meaning of 'delete'.

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 the concrete condition under which the call fails ('a list that still holds reminders is refused unless delete_reminders=True') and names the recovery path ('undone with the undo tool'). It stops short of explicitly directing the agent to delete_reminder for single-item removal or noting when to prefer rename/keep, so it is clear context rather than full when/when-not routing.

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 does well: it discloses that this is a soft delete (not erased), a 30-day retention window, and that undo restores it. It omits what happens after 30 days (permanent removal) and any permission/auth requirements, so it is strong but not exhaustive.

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 the core behavior front-loaded and the reversibility caveat immediately after. Every clause earns its place and nothing is redundant.

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 one-parameter tool with no output schema and no annotations, the description covers the essential semantics including reversibility and retention. It leaves only minor gaps: the fate of the note after 30 days and the id's expected format.

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 should compensate but does not mention the single 'id' parameter at all. The parameter name and type are self-evident, but there is no hint about its format or whether it is a note identifier versus a title, leaving a modest gap.

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 ('Move a note to Recently Deleted'), and the framing immediately distinguishes it from sibling note tools like move_note, read_note, and create_note. An agent knows exactly what operation this performs 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?

Usage is implied by 'Move a note to Recently Deleted' plus the retention note, so an agent can infer this is the delete path for notes. However, there is no explicit when-to-use/when-not guidance or comparison to alternatives (e.g., how it relates to move_note for relocating vs deleting), leaving selection 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?

No annotations are provided, so the description carries the full behavioral burden, yet it says nothing about permanence/reversibility, required permissions, or what happens to subtasks attached to the reminder. Only the implicit destructiveness of the verb 'Delete' conveys any behavioral information.

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 short sentence with the operation and key front-loaded; nothing is wasted. It is efficient, though the brevity borders on under-specification for a destructive operation.

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 not be explained, but for a destructive tool with zero annotations the definition should still cover irreversibility, permissions, or side effects. None of that is present, leaving the agent under-informed for a delete operation.

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% and the single 'id' parameter has no description, so the description must compensate. 'By id' at least clarifies that the identifier refers to a reminder (not a list or calendar), but it omits the id format, where the id comes from (e.g., list_reminders), and any error behavior for unknown ids.

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 ('Delete a reminder') plus the lookup key ('by id'), which cleanly distinguishes it from delete_event, delete_note, and delete_calendar in the sibling list. It does not, however, differentiate itself from complete_reminder or update_reminder as an alternative way to handle a reminder.

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?

No guidance on when to delete versus archive or complete a reminder, no prerequisites, and no mention of related siblings like complete_reminder or bulk_reminders. The agent must infer all usage context from the name alone.

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 present, the description carries the full burden and delivers two genuinely useful behavioral facts: a repeating event is copied as a whole series, and the operation 'Can be undone'. It omits permissions/auth requirements and any statement about the resulting copy's identity beyond the new uid.

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 core action is front-loaded, then each clause maps to a parameter or behavior with no filler. The sentence is long and slightly run-on, but every clause earns its place.

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 6-parameter mutation tool with no annotations, no output schema, and 0% schema coverage, the description covers the essential parameters and key behaviors (series copy, undoable). The main remaining gap is lack of explicit return-value and permission context.

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 compensate, and it does: it documents calendar, to_calendar, start, end, and title with their defaults, and even explains the interaction that a new start alone preserves the event's length. The formats are delegated to update_event rather than restated, but uid itself is only referenced obliquely.

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+resource, 'Copy an event under a new uid', which immediately distinguishes it from a plain create or move by emphasizing a new uid is generated. It stops short of explicitly naming the sibling alternatives (create_event, move_event) it could be confused with.

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 explains per-parameter defaults but gives no guidance on when to choose duplicate_event over create_event, move_event, or get_event. An agent must infer the selection criteria from the name alone.

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 exist, so the description carries the full burden, and it does well: it states the max-60-day horizon, the 'today starts from now' edge case, that all-day events don't block by default, and that buffer applies before and after each event. It stops short of confirming this is a pure read with no side effects, and says nothing about the return shape per stretch.

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 output, then a dense but well-ordered per-parameter glossary. Nearly every clause carries a default or format detail; the layout is telegraphic but 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?

For a 10-parameter tool with no annotations, no output schema, and 0% schema coverage, the description supplies inputs, defaults, edge cases, and an opening statement of what is returned. Remaining gaps are the undocumented 'limit' parameter and the concrete structure of each returned free stretch.

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 documents 9 of 10 parameters with formats and defaults ('YYYY-MM-DD', 'HH:MM', ['MO','TU','WE'], buffer semantics, calendars default all). Only 'limit' is left unexplained, which is a minor omission against an otherwise complete parameter glossary.

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 ('Find open time across your calendars') plus the output shape and ordering ('free stretches each at least duration_minutes long ... earliest first'). This cleanly separates it from siblings like check_conflicts, propose_event, and agenda without the agent needing to open 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?

Usage is implied by the purpose (find availability), and it explains what counts as busy vs free via all_day_blocks and buffer_minutes. However, it never names or contrasts the natural alternatives (check_conflicts, propose_event, agenda), so an agent must infer when this tool beats those.

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 discloses the return contents ('same fields as list_events plus its calendar, repeat rule and alerts'), which is helpful, and the cross-calendar fallback behavior. However, it doesn't state what happens on not-found, permission needs, or whether the calendar is required to disambiguate duplicate uids.

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 compact sentences, front-loaded with the core purpose followed by parameter behavior and return values. 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?

For a 2-param, no-output-schema read tool with no annotations, the description covers purpose, both parameters, and return shape. Missing edge-case behavior (not-found, duplicate uids across calendars) keeps it from a 5.

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 compensate. It meaningfully explains uid ('the id every event tool returns') and calendar (optional, omit to search all), adding semantics beyond the bare schema types. It could add format details (string id format) but covers both parameters adequately.

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 ('get one event's full details') and clarifies the key parameter's origin (the uid every event tool returns). Clear enough to distinguish from list_events, search_events, and read_note.

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?

Explains the calendar parameter's behavior: leave it out to search all calendars. It clarifies the retrieval context well, but doesn't explicitly contrast against list_events or search_events for when this is preferable (e.g., when you already have the uid).

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 does well: it declares the operation read-only and cheap, and discloses what each service reports (ok status, duration, and for an expired Reminders session the exact fix command). It stops short of covering auth prompts or network/permission prerequisites.

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, all load-bearing: what it checks, what it returns, and when to call it. The failure-triage cue is placed last as a callback, which is effective rather than wasteful.

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-param diagnostic with no output schema, the description covers purpose, cost, return shape, and remediation guidance adequately. It could be slightly more explicit about what a failing check looks like, but nothing essential for calling it correctly 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?

Zero parameters, so per the rubric the baseline is 4. The description correctly implies no input is needed, and there is nothing further for it to document.

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 precise verb+resource: checks reachability and sign-in state for Calendar (CalDAV) and Reminders/Notes (CloudKit). This is clearly distinguishable from every sibling, which are all functional CRUD/query tools on calendars, events, reminders, and notes.

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 an explicit trigger: 'Call this first when another tool fails oddly.' That is a clear when-to-use condition tied to the failure of the sibling tools. It does not name a when-not-to-use case, but for a cheap diagnostic probe that exclusion is largely implicit.

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 disclosure burden and does meaningful work: it states sizes are in GiB matching Settings, that a warning is emitted when nearly full, and that the plan name is inferred rather than reported by Apple. This is exactly the kind of caveat that prevents an agent from misreading the plan name as authoritative. It never explicitly says the operation is read-only, which keeps it short of 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?

Two tight sentences, front-loaded with the resource and its returned fields, followed by the two caveats an agent actually needs (units and inferred plan name). No filler, no restating of the tool name.

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, so the description must describe the return payload, and it does comprehensively: size, used, free, percent, warning, and category breakdown. The only gap is failure conditions such as not being signed into iCloud or storage data being unavailable, which are not addressed.

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 for 0 params applies. The description correctly spends no space on inputs and instead documents the shape of the result.

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 resource (iCloud storage and plan) and enumerates exactly what the summary contains: plan size, used/free space, percent used, near-full warning, and per-category usage. No sibling tool overlaps with storage reporting, so the agent can select it unambiguously.

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 resource rather than stated: an agent can infer you call it for a storage overview, but there is no explicit when-to-use, when-not-to-use, or alternative (e.g. per-category detail tools). A single clause like 'use when the user asks about iCloud space' would lift this to a 4.

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 real behavior: what each calendar entry carries and the non-obvious fact that over CalDAV iCloud may not expose subscriptions at all. It stops short of declaring this is a read-only operation or describing ordering/size of the result set, which for a no-annotation tool is a moderate gap.

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, front-loaded with the fields returned, followed by a targeted edge-case caveat. Every clause earns its place, though the field enumeration is slightly dense in list form.

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 read tool with an output schema, the description is complete enough: it explains what the entries contain (the output schema only names fields, it does not explain semantics like 'legacy reminders list') and adds the subscription-exposure caveat. It lacks any when-to-use routing against list_calendars, keeping it short of a 5.

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 to document and the baseline of 4 applies. The description correctly adds no parameter noise.

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 resource (calendars) and enumerates the detail fields returned (colour, contents type, write permission, subscription status), which distinguishes it from a thin 'list_calendars' by the richness of its payload. However, it never explicitly names or contrasts with the sibling list_calendars, so the differentiation is implied rather than stated.

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 list_calendars or the reminder-list siblings. The only contextual note is a CalDAV/iCloud caveat about subscriptions, which is behavioral rather than usage routing. An agent must infer the use case entirely.

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 burden, but 'List' strongly implies a non-mutating read and the tool takes no parameters. The description does disclose that only names are returned, which sets expectations about minimal output. It says nothing about ordering, empty results, or permissions, which leaves gaps for a no-annotation 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 filler. The key constraint (names only, event-capable calendars) is 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?

With an output schema present, the return shape needn't be described, and a zero-parameter read tool needs little more than this. The only omission is any pointer to list_calendar_details for richer per-calendar data, which would help an agent choose between the two.

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 has zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The phrase 'that can hold events' is effectively a filter semantic applied by the tool, which is mildly informative.

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), plus a meaningful scope qualifier: only calendars 'that can hold events'. This implicitly separates it from list_calendar_details, but it doesn't name that sibling or state the distinction explicitly, so it falls short of 5.

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 'can hold events' qualifier implies this is a discovery step before creating or moving an event, but there is no explicit when-to-use, when-not-to-use, or alternative named (e.g., list_calendar_details for richer metadata). Usage is only inferred.

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, so the description carries the full burden. It does disclose one genuinely useful behavioral fact — all-day events are included and flagged all_day=true — but says nothing about ordering, result limits, pagination, or calendar access/permissions. Partial coverage for a read tool whose output schema already exists.

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 tight sentences with zero filler; the scope constraint is front-loaded and the all-day behavior follows. Every clause earns its place.

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 not be restated. However, for a 3-param, 0%-coverage read tool with no annotations, the description leaves the 'calendar' argument, result ordering, and any limit/pagination behavior 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% and all 3 params are required, so the description must compensate. It clarifies that start and end accept ISO datetimes or dates (2 of 3 params), but leaves the required 'calendar' parameter entirely unexplained — nothing says whether it takes an id, name, or index.

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+resource ('List events in a calendar') with an explicit scope (between start and end). It implies a date-range read distinct from search_events or get_event, but never names those siblings, so the differentiation is inferential rather than explicit.

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 only implied by the date-range framing; the description never says when to prefer this over search_events, agenda, get_event, or find_free_time even though several siblings plausibly overlap. No prerequisites or exclusions are given.

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 a useful scope nuance: the special 'Recently Deleted' folder is included. It says nothing about ordering, account scoping, read-only nature, or auth, so the disclosure is thin but not absent.

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 action and resource, with zero filler. The scope caveat about Recently Deleted appears immediately after the core 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?

For a parameterless list tool with no output schema, mentioning the returned fields and the Recently Deleted inclusion covers most of what an agent needs. Ordering and whether the two fields are always populated remain unstated, 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?

The tool takes zero parameters, so the baseline is 4. No parameter meaning is needed, and the description correctly spends its words on returned fields instead.

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 ('List the Notes folders') and even names the returned fields (id, name). It is clearly distinguishable from list_notes, which lists notes rather than folders, though it never explicitly contrasts itself with that sibling.

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 only implied: an agent can infer this enumerates folders before calling move_note or list_notes with a folder id. There is no explicit when-to-use, no prerequisites, and no named alternative.

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 does disclose real behavior: ordering ('newest'), the returned columns (id, title, modified, locked), and that only titles come back. It does not explain the default limit of 20 or whether results are paginated, which keeps it short of a 5 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?

Two compact sentences with zero filler; the scope constraint and default are front-loaded, and the return-field list is dense but directly useful.

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 supplies the return fields and ordering itself, covers folder semantics, and routes to read_note. The only real gap is limit/pagination behavior, which matters for a list tool with a default cap of 20.

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 explains the folder parameter meaningfully ('name or id; empty is the default Notes folder') but says nothing about the limit parameter's effect, leaving one of two parameters undocumented on both sides.

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 ('List the newest notes in a folder') plus the exact fields returned, and explicitly distinguishes itself from read_note ('Titles only; use read_note for the text'). An agent can pick this apart from list_note_folders, read_note, and search_reminders 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?

Routes the agent to the alternative explicitly ('use read_note for the text') and clarifies the folder default ('empty is the default Notes folder'). It gives clear context for when this tool is right, though it offers no explicit exclusion beyond the read_note pointer.

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 burden, and it partially does so by naming the enumerated fields (id, title, item count). However, it discloses nothing about read-only semantics being guaranteed, ordering, or whether lists are paged/limited, so an agent gets only the bare minimum behavioral picture.

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 short sentence, front-loaded with verb and resource, followed by the return fields. No filler and nothing to trim.

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 the description is not obliged to explain return values, and for a zero-parameter read-only listing tool this is near-sufficient information. The only shortfall is the missing routing hint against sibling list tools.

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, and the schema is empty with full coverage, so there is nothing for the description to disambiguate. Baseline 4 applies for a parameterless tool.

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 ('List Apple Reminders lists') and even names the fields returned, so the agent knows this enumerates reminder lists rather than the reminders themselves. It does not explicitly contrast with the nearby sibling list_reminders, leaving the distinction to be inferred from the noun.

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?

No when-to-use guidance, no prerequisites, and no acknowledgement of alternatives such as list_reminders or list_notes. Usage is only implied by the verb 'List' and the 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?

No annotations are provided, so the description carries the burden. It usefully discloses that setting flagged/priority changes result ordering ('sorted most urgent first (priority, then due)') and the tri-state flag semantics, but says nothing about include_completed, defaults, or result limits.

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 front-loaded sentences with no filler; the main purpose leads and the smart-view details follow. Slightly dense but each sentence adds distinct information.

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 not be described, and the read-only nature is implied. Still, for a 4-param tool at 0% schema coverage, the total silence on include_completed leaves an agent without enough to call it confidently.

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 compensate. It documents list (name or id, empty = all), flagged (True/False/null), and priority enum values that the schema omits entirely, but leaves include_completed completely unexplained.

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 ('List reminders') plus scope ('in one list (name or id), or across all lists if empty'). An agent can distinguish it from siblings like search_reminders by the explicit filtering/listing semantics, though the contrast is implied rather than stated.

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?

Explains the default behavior (empty list = all lists) and that setting flagged/priority triggers urgency sorting, which is useful context for invoking it. However, it never names when to prefer this over search_reminders or list_reminder_lists, so routing 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?

With no annotations provided, the description carries the full behavioral burden and does a reasonable job: it discloses that identity/details are preserved, that repeating events move as an entire series, and that the action is reversible ('Can be undone'). It omits permission requirements and failure behavior (e.g., what happens if the target calendar does not exist), 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?

Three short sentences, front-loaded with the core action, then the optional-parameter rule, then the series and undo behaviors. Every sentence adds distinct information with 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?

For a mutation tool with no annotations, no output schema, and 0% schema coverage across 3 parameters, the description covers the key semantics (series behavior, reversibility, optional locating calendar) but leaves gaps on permissions, error cases, and what is returned. Adequate but noticeably incomplete.

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 the most confusing parameter: it explains that 'calendar' is an optional locating scope used to find the event in any calendar, distinguishing it from 'to_calendar' (the destination) and implying 'uid' identifies the event. The remaining two parameters are only inferable rather than explicitly defined, so it is not a full 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 states a specific verb+resource ('Move an event to another calendar') and clarifies scope with '(same uid, same details)', which implicitly separates it from update_event (which changes details) and duplicate_event. It does not name a sibling explicitly, so it stops short of a 5, but the operation 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?

It gives clear guidance for one parameter's usage ('calendar is optional: leave it out to find the event in any calendar'), which is genuinely useful context. However, there is no explicit when-to-use-this-vs-alternatives guidance for the sibling tools update_event, duplicate_event, or delete_event, so the routing burden is only partly addressed.

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 does disclose non-obvious behavior: deletion and restore are both achieved through this tool, and folder accepts a name or id. It omits permission requirements, error behavior for missing folders, and any return information.

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, zero filler, and the core action is front-loaded before the behavioral caveats. Every clause carries information about tool selection or side effects.

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 two-parameter mutation tool with no annotations and no output schema, the description covers the critical non-obvious semantics (destructive equivalence, restore behavior, folder identifier flexibility). Only parameter-level detail on 'id' and failure modes are 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 coverage is 0%, so the description must compensate. It adds real meaning for 'folder' (accepts name or id) but says nothing about 'id', the required note identifier, leaving half the parameters undocumented in both schema and description.

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 ('Move a note to another folder') with the target parameter format implied. It also differentiates behavior against delete_note, so an agent can tell it apart from that sibling, though it doesn't explicitly contrast with move_event or duplicate_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?

The description names the alternative operation ('Moving to "Recently Deleted" is the same as delete_note') and clarifies the inverse case (moving a trashed note back restores it), which routes the agent between delete, move, and restore. It stops short of an explicit 'use this when...' statement or any exclusions.

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 present, the description carries the full burden and does so well: it declares the tool writes nothing, enumerates what the response contains (draft, warnings for past/far-future/missing-end dates, overlapping events, likely duplicate), and explains that 'source' is persisted into the resulting event description plus a 'now' override for testing.

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 critical constraint is front-loaded in the first clause, and most sentences carry distinct actionable information. It is slightly rambling, with embedded parentheticals (the email example, the date-resolution aside) that interrupt the flow without adding much.

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, no-annotation, no-output-schema tool, the description covers the workflow, the return payload, and the handoff to create_event. It falls short only on the pass-through fields (calendar, location, description) that an agent must still guess about.

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 explains summary, start/end, source, and now meaningfully, but leaves calendar, location, and description undocumented — three of eight parameters with no semantic guidance 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 (check/propose) and resource (calendar event) and explicitly frames it as a dry-run preceding create_event — 'Check a calendar event BEFORE creating it... Writes nothing.' An agent can distinguish it from create_event, check_conflicts, and find_free_time without opening a 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 explicit when-to-use ('one an agent read out of an email'), the preprocessing condition (resolve 'the 18th' to a full date first), and the downstream rule 'only call create_event with create_event_args once the user agrees.' It names the alternative tool and the condition that selects it.

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 does disclose meaningful traits: locked notes are refused (error behavior) and formatting, checklists, and attachments are excluded from the result. It omits auth requirements and return shape details, keeping it out of the top band.

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, front-loaded sentences with zero filler — the core action comes first, followed by the key constraint and scope limits.

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 single-param read tool with no output schema, the description covers the essential constraints (locked refusal, plain-text-only scope). Only minor gaps remain around error detail and authentication.

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% for the single 'id' parameter, so the description must compensate; 'by id' is the only added meaning, which matches the already-named schema field. Adequate for a trivially-named single param but adds little.

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+resource ('Read the plain text of one note by id'), and the singular 'one note' implicitly separates it from list_notes. It does not explicitly name a sibling alternative, so it falls just short of the top band.

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 'by id' — an agent infers this is for retrieving a single known note versus listing — but there is no explicit when-to-use, when-not, or named alternative such as list_notes.

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 add two useful facts: names must be unique and the change is reversible ('Can be undone'). However, it omits what happens on a uniqueness collision, whether the calendar is addressed by name or ID, and any permission requirements for a 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?

Three short sentences, zero padding, with the action statement front-loaded and constraints following. Every sentence adds information.

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 no annotations, no output schema, and fully undocumented parameters, the description is only partially sufficient. It covers the uniqueness constraint and reversibility but leaves error behavior, target identification, and response expectations unstated.

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 both parameters are undocumented in the schema. The description implies new_name must be unique but never specifies the identifier format for 'calendar' (name vs. ID), so the agent is left to guess how to address the target.

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 ('Rename an event calendar'), which cleanly separates it from siblings like create_calendar, delete_calendar, set_calendar_color, and rename_list. It does not explicitly name or contrast with an alternative, but the resource specificity makes selection 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?

No guidance on when to choose this over alternatives. The natural sibling rename_list exists, and set_calendar_color is a different calendar mutation, yet the description says nothing about which to use or when this is appropriate. Only implicit context is provided.

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. It does disclose one genuine constraint beyond the schema — that list names must be unique — but says nothing about what happens on a duplicate (error vs. overwrite), whether a rename is reversible, or permission requirements.

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 action, with no filler. Slightly terse for a mutation tool whose uniqueness rule could use scoping detail, but nothing is wasted.

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 low-complexity two-parameter mutation with no output schema, the description covers the core action and the uniqueness constraint. However, with zero annotation and schema coverage it should at least state the failure mode on duplicate names or the required permissions.

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%, and the schema titles ('List', 'New Name') carry no meaning. The description partially compensates by explaining that the 'list' parameter accepts a name or an id, but adds nothing about 'new_name' beyond the obvious.

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+resource ('Rename a list') and clarifies the identifier form ('name or id'). It is clearly distinguishable from the sibling rename_calendar by resource, though it does not explicitly note that distinction.

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?

No when-to-use guidance, prerequisites, or alternatives are given, even though rename_calendar is a close sibling that an agent could confuse with this tool. The agent must infer the context entirely.

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 delivers: case-insensitive matching, default-all calendars, past-event hiding with include_past override, single vs per-occurrence treatment of repeating events, and the return contract (first `limit` by start time plus total count). This is unusually complete behavioral disclosure.

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 purpose is front-loaded and every clause carries information, but the second half is a dense run-on that mixes parameter semantics, default behavior, and return format into one paragraph. Slightly hard to scan but not wasteful.

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 annotations and no output schema, the description must explain both behavior and return values, and it does ('Returns the first `limit` matches by start time, and the total count'). An agent has everything needed to call this correctly.

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: it documents text (with example), calendar ('one name (default all)'), the required start/end format ('YYYY-MM-DD' or ISO datetime), include_past semantics, and limit's role. Only limit's default is 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 ('Find events by words in the title, notes or location'), plus the key differentiator 'without knowing the date' with a concrete example ('dentist'). This implicitly separates it from the date-oriented list_events, but it never names a sibling tool 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?

Clearly frames the primary use case (search when you don't know the date) and describes how the start/end presence changes what is returned. However it does not name an alternative tool or state when NOT to use it (e.g. vs list_events or get_event).

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 delivers real behavioral detail: match semantics ('every word must appear, in any order, any case') and result ordering ('title matches first, then by due date'). It omits the default exclusion of completed items and the limit behavior, but the search/ranking disclosure is well beyond what annotations would give.

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 tight sentences, zero waste, front-loaded with the core action and scope before the usage guidance. Every sentence earns its place.

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 explained; the description covers matching semantics, scope, ordering, and usage. It leaves the limit and completed-item defaults implicit, which is the one gap, but overall it is complete enough to call correctly.

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 compensate. It partially maps 'words in the title or notes' to text and 'across all lists (or one list)' to list, but says nothing about the limit or include_completed parameters and their defaults. Half the parameters remain 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?

Specific verb ('Find') plus resource ('reminders'), with scope stated: words in title or notes, across all lists or one. This clearly distinguishes it from sibling list_reminders (enumerate all) and search_events (different resource).

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?

Explicit when-to-use: 'before creating something to avoid duplicates, or to find that reminder about X.' This is concrete context. It doesn't name the competing sibling (list_reminders) as an alternative, so it falls just short of a 5, but the usage conditions are 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?

With no annotations, the description carries the full behavioral burden; it does disclose one genuinely useful trait, that the change 'Can be undone' (probably via the sibling undo tool). It omits permissions/auth requirements, whether the change is idempotent, and whether it affects shared or subscribed calendars.

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 clauses with zero filler; the operation is front-loaded and the format and reversibility notes are appended only after the core statement. Nothing extraneous.

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 mutation with no annotations and no output schema, the description covers the operation, the color format, and reversibility. It still leaves the calendar identifier and permission requirements unexplained, which matters given 0% schema description coverage.

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% - neither parameter has a description in the schema. The description compensates for 'color' by specifying the '#RRGGBB' format, but says nothing about 'calendar', leaving it unclear whether an ID, name, or path is expected.

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') and resource ('an event calendar's colour'), and the '#RRGGBB' hint narrows the operation to a color assignment. It doesn't explicitly contrast with the sibling rename_calendar, but the resource and format make the intent 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 when-to-use guidance, no prerequisites, and no mention of alternatives such as rename_calendar or delete_calendar. The agent must infer that this is the tool for recoloring a calendar purely from the 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 present, the description assumes the full behavioral burden and delivers: exact restoration for calendar changes, the specific reminder fields that are restored, the fields that are NOT restored (early-reminder and Urgent settings), and the conflict behavior (stops with a clear error, log entry stays undoable). This is unusual depth 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?

Front-loaded with the core action and the mode semantics before the fidelity details. The reminder restoration list is long and dense, though each field name conveys real information about undo scope, so little could be cut without losing meaning.

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 and no annotations, and the description covers modes, restoration fidelity and failure semantics thoroughly. It stops short of describing what a successful undo returns or any permission requirements, which is the only remaining gap for a mutation 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 carry all parameter meaning, and it does: entry_id is defined as an id from activity_log, batch is defined as undoing one bulk operation newest-first, and the default behavior when neither is supplied is stated. Nothing is left ambiguous.

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 opens with a specific verb+resource ("Undo a logged change") and immediately clarifies the relationship to activity_log, the sibling that produces entry_id. The three operating modes are enumerated, so an agent can distinguish this from any other sibling 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?

It explicitly routes the three possible call shapes: entry_id for a single logged change, batch to undo one bulk operation newest-first, and neither to undo the most recent undoable change by anyone. This is a complete when-to-use map for a zero-required-parameter tool.

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 present, so the description carries the full burden and does so well: it discloses merge semantics, the exact clearing conventions ('' / [] / 0 clears; [] removes all alerts), the series-wide blast radius on repeating events, and the all-day date convention. It stops short of permissions/error behavior and there is no output schema to cover 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?

Six dense lines, purpose first, then one clause per parameter group. Nothing is padded and the unusual semantics are front-loaded ahead of the routine clearing rules.

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 17-parameter mutation with no annotations, no output schema and no per-parameter schema docs, the description covers the behavioral essentials an agent needs to avoid destructive mistakes on merges and series. The missing pieces — return value, permissions, error cases — are secondary but real.

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 17 parameters, so the description must compensate — and it does for the parameters whose semantics are genuinely non-obvious: start/end date format and all-day meaning, repeat values plus 'none'/omit, alerts units and replace behavior, and clear-vs-omit for url/categories/status/priority. The remaining fields (summary, location, description, uid, calendar, repeat_*) are either self-evident by name or deferred to create_event, leaving a residual gap.

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+resource+identifier: 'Update fields of an existing event by uid.' An agent can immediately separate this from create_event, delete_event, move_event and duplicate_event. The partial-update scope ('Only provided fields change') further pins down what kind of update this is.

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?

Strong context for how to call it (partial update, omit-to-leave-alone, series-wide effect) and it routes the agent elsewhere for the repeat_* options ('see create_event'). It does not, however, address when to prefer this over move_event or duplicate_event, so the sibling boundaries are only partially drawn.

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 does so well: it discloses replace-vs-merge semantics for tags/links/alarms, clearing behavior, the alarm-follows-due side effect, notify=False silencing, and that location alarms are untouched. It omits auth/permission requirements and error behavior for invalid ids.

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?

Dense but well-organized one-line-per-parameter layout, front-loaded with the general update rule. Given 20 undocumented parameters, the length is largely earned, though it could be tightened slightly.

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 20-parameter tool with 0% schema description coverage and no annotations, the description is strong on the tricky fields but silent on notes, title, flagged, priority, and the non-obvious repeat_count/repeat_interval, leaving an agent to guess at several parameters.

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 compensate, and it explains roughly 13 of 20 parameters in detail (due, move_to, parent, all five early_* units, repeat, tags, links, alarms, notify). It leaves notes, title, flagged, priority, repeat_count, and repeat_interval completely unexplained.

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+resource ("Update a reminder by id") plus the crucial scope qualifier that only provided fields change, which separates it from create_reminder/delete_reminder. It does not explicitly name sibling alternatives, so it stops short of a 5.

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 partial-update semantics and the clear-value conventions ('' clears, [] removes, omit to keep) imply how to use it, but there is no explicit when-to-use/when-not guidance or routing to siblings like complete_reminder, add_subtask, or delete_reminder.

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 discloses key counting rules: overlaps counted once, all-day events excluded unless all_day_blocks, and crowded days defined as 75%+ of working hours booked. However, it does not clarify whether per-day hours booked are restricted to work_start–work_end or include events outside those hours.

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 compact sentences, front-loaded with the summary output then parameter details. No redundant text; every clause contributes.

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 5 params, no schema descriptions, no annotations, and no output schema, the description covers outputs and several parameters but leaves usage alternatives and work_start/work_end semantics unaddressed. It is adequate but incomplete for tool selection.

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% for 5 parameters. The description documents start format and default, days range 1-60, and the all_day_blocks effect. It only indirectly implies work_start/work_end define working hours and gives no format or default for them.

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 it summarizes booking per day with event count and hours, overlaps counted once, plus total, busiest, empty, and crowded days. It clearly defines the output metrics, though it does not name sibling tools like agenda or find_free_time to differentiate use cases.

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?

No explicit when-to-use guidance or alternatives. It only provides defaults and range for start/days. An agent must infer that this is for calendar load summaries rather than raw event listing.

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