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

With no annotations, the description carries the full behavioral burden, yet it only says 'start an activity'. It does not disclose side effects (launching UI on the device), permission/adb requirements, what happens on an unresolvable intent, or what the response looks like.

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?

One front-loaded sentence with the verb, mechanism, and key qualifier; no filler. It is efficient, though arguably too terse for a 6-param tool with a nested extras object.

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 tool with a nested `extras` object, no annotations, and no output schema, a single line is insufficient. An agent gets no return-value expectation, no failure semantics, and no note on how `extras` should be shaped beyond the one-word schema hint.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter (data, mime, action, extras, package, component) is already documented in the schema. The description adds nothing beyond the schema, so the baseline 3 applies.

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 ('Start an activity') and identifies the underlying mechanism (`am start`), plus the key qualifier 'arbitrary intent'. It stops short of distinguishing from the sibling `app_launch`, so an agent must infer which to choose.

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 explicit when-to-use guidance and no mention of alternatives like `app_launch` or `device_shell`. 'Arbitrary intent' weakly implies an advanced/low-level path but leaves the selection decision 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, the description carries the full behavioral burden. It does a good job explaining the returned state values (front, covered, other, unknown) and the covered case, but says nothing about permissions, failure modes when the package is not installed, or that restart force-stops (that lives only in the schema).

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 in one sentence, then the return semantics. Every sentence earns its place; only minor trimming would improve it.

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?

Since no output schema exists, the description usefully documents the return shape and state enum. However, for an app-launching action with no annotations, it omits failure behavior, permission requirements, and the effect of restart beyond the schema note, leaving meaningful 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 100%, including examples for package and the restart/activity semantics, so the schema already carries the parameter detail. The description adds no additional parameter meaning beyond it, making baseline 3 appropriate.

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: 'Bring an app to the foreground.' That is clearly distinguishable from mutating siblings like app_stop or app_intent, though the description never names those siblings or explains the difference 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?

There is no guidance on when to use this instead of app_intent, drive_open, calendar_open, or app_stop. The usage is only implied by the verb 'bring to foreground', leaving the agent to infer routing between launch-style siblings.

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. 'Force-stop' does convey abrupt termination rather than a graceful shutdown, which is meaningful behavioral signal. However, it does not say whether unsaved state is lost, what happens if the app is not running, or whether elevated permissions are required.

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 words, verb-first, zero filler — the essential action is front-loaded. It is sized appropriately for the tool's simplicity, though it is arguably too terse to be self-sufficient.

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 tool with a fully documented schema and no output schema, the core information is present. But with zero annotations the description should still cover side effects and failure modes, which it omits.

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 single parameter has 100% schema description coverage ('Android package name'), so the schema already does the work and the description adds nothing beyond it. This is the expected baseline when schema coverage is complete.

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 ('Force-stop') and resource ('an app'), and the word 'force' distinguishes it from the launch-oriented siblings app_launch and app_intent. It does not explicitly name those siblings, 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?

No indication of when to use this versus app_launch, app_intent, or a graceful close, and no prerequisites (device connected/unlocked) or failure conditions are given. The agent must infer usage entirely from the tool name.

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

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

With no annotations, the description carries the full disclosure burden. It usefully states that guests are not e-mailed and that the tool returns the Meet link once the provider has it. It does not cover permissions or failure behavior, but the schema supplies the editable-event constraint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two tightly focused sentences with the main action front-loaded. Every sentence adds useful information about behavior: provider limitation, guest notification, and return value.

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 and no output schema, the description covers the essential side effect (no guest e-mail) and the return value (Meet link). The fully documented schema handles parameters, though error behavior and existing-Meet-link conflicts 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?

Schema description coverage is 100%, so the schema already documents scope, start, timeout, and event_id. The description does not add parameter-specific syntax or format details beyond the schema, making the baseline 3 appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: "Add a Google Meet video conference to one of your events." It also adds the useful constraint that the provider cannot create one. It does not explicitly name sibling tools such as calendar_remove_meet or calendar_meet_link, so it is clear but not fully sibling-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?

Usage is implied by "to one of your events" and "the provider cannot create one," which suggests this is for events that need a Meet link added. However, it does not explicitly say when to use this versus calendar_remove_meet, calendar_meet_link, or calendar_create, and it gives no when-not 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 burden and does well: it discloses an outward-facing side effect (Google e-mails the invitees), states the return value, and warns that confirm=true is mandatory. It does not cover edge behavior such as what happens when an address is already an attendee or whether invites can be retracted, which keeps it off 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 sentences, zero filler, with the action and the observable side effect front-loaded and the precondition trailing. 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 4-parameter mutation with full schema coverage and no output schema, the description supplies the two things the schema cannot: the external e-mail side effect and the return value (attendee list). Remaining gaps are duplicate-invite semantics and permission requirements, which are minor.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents emails, event_id, optional and confirm. The description only reinforces the confirm requirement and never mentions the optional flag, adding essentially no meaning beyond structured fields — baseline 3.

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 + resource ('Invite people to an event') with the mechanism and the return value stated. It is trivially distinguishable from the sibling calendar_attendee_remove, and the parenthetical about Google e-mailing guests makes the effect 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?

Clear context for when to call it (adding guests to an existing event) and it flags the confirm=true gating condition inline. It doesn't explicitly contrast with calendar_create (which also takes attendees) or calendar_attendee_remove, so it stops short of full alternative 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 at all, the description does real work: it discloses the outward-facing consequence (Google may e-mail a cancellation), the mandatory confirm=true guard, and the return shape ('what is left'). It omits reversibility, whether non-attendee e-mails silently no-op or error, and any 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, zero filler. The destructive side-effect leads and the confirm requirement follows, both front-loaded where an agent will see them.

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 mutation with no annotations and no output schema, the description covers the essential danger (cancellation e-mails), the gate (confirm=true) and the return value. Missing only edge-case behavior for invalid or non-attending addresses.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so emails, event_id and confirm are already documented. The description only adds rationale for confirm ('outward-facing or destructive') and confirms that the response reflects remaining attendees; the emails parameter semantics (batch vs single, unknown addresses) get no extra clarity.

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 ('Remove guests from an event') that an agent can act on immediately. It does not name the obvious sibling calendar_attendee_add as the inverse operation, so differentiation is left implicit 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?

The description gives a precondition (confirm=true) and a side-effect warning, which implies when this tool is invoked. It never explicitly says when to use this versus calendar_attendee_add or calendar_update, nor when removal is inappropriate.

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 useful behavior: it is a read-only enumeration on the device, `primary` identifies the account's own calendar and is the implicit target of calendar.create, and hidden-but-synced calendars still appear. It stops short of stating ordering, completeness guarantees, or how many calendars are returned.

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 lines, front-loaded with what is listed and its fields, then the follow-on usage note. No filler and no repetition of schema content.

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 exists, so the description compensates by enumerating the returned fields (id, name, account, colour, access level, visible, sync). Combined with the follow-on guidance for the `calendar` parameter, an agent has everything needed to call it and use the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so visible_only and writable_only are already fully documented at the parameter level, setting the baseline at 3. The description adds conceptual context (visible vs sync, the meaning of `primary`) but never refers to the filter parameters by name.

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 calendars on the phone") and enumerates the fields returned, so an agent can distinguish it from calendar_events, calendar_get, or calendar_set_calendar immediately. The parenthetical field list makes the resource concrete rather than generic.

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 tells the agent how to use the output: feed `id` (or name) into the `calendar` parameter of other calendar ops, and notes `primary` is the default target of calendar.create. It does not, however, say when not to use it (e.g. vs calendar_get or calendar_set_calendar), so routing against siblings is only implied.

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, and it discloses only that the event syncs to Google Calendar and returns the new event. It omits that attendees trigger real e-mailed invitations requiring confirm=true, that recurrence/reminders have side effects, and whether the write is reversible.

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, and the core action is front-loaded ahead of the sync and return-value notes.

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 mutation tool with no annotations and no output schema, the description is thin: the external side effect of e-mailed invitations, which is the riskiest behavior here, is left entirely to the schema property text. It does at least cover the sync behavior and redirect to calendar.get for the response shape.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% across all 15 parameters, so defaults, formats, enum values, and the confirm requirement are already documented in the schema. The description adds no parameter-level meaning beyond referring to calendar.get for the return shape, so baseline 3 applies.

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 event', plus a scope note that it is synced to Google Calendar. That distinguishes it from calendar_update and calendar_task_create, though it never explicitly names those siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this versus calendar_update (edit an existing event), calendar_add_meet (attach a Meet link), or calendar_task_create. The only pointer, 'see calendar.get', is about the return value, not about tool selection.

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 so well: it discloses guest notifications, organizer-visible decline status, the series-versus-occurrence distinction, and the confirm=true requirement for this outward-facing/destructive action.

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 front-loaded with the core action, then uses compact bullets to cover the important side-effect cases and the confirm requirement. Every sentence provides decision-relevant information without repetition.

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 calendar tool with no annotations and no output schema, the description supplies the critical context an agent needs: side effects on guests, handling of received invitations, recurring-event granularity, and the mandatory confirmation requirement.

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 already 100%, so the schema documents all three parameters. The description adds useful meaning beyond the schema, especially that instance_start cancels only that occurrence while the series remains and guests are notified about the canceled occurrence.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Delete an event') and immediately clarifies recurring-event scope: whole series versus one occurrence. It also distinguishes its effect from calendar.respond by explaining that an invitation from someone else is only removed locally and recorded as declined.

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 when-to-use guidance: use this tool for deleting an organized event or removing an invitation, and use calendar.respond when the user wants to explicitly decline. It also explains the condition for using instance_start to cancel only one 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, the description carries the full burden and does well: it discloses the operation is destructive/outward-facing, requires confirm=true, and explains two non-obvious effects (weekly working-location setting is preserved; a multi-day Out of office is deleted in its entirety). It doesn't say whether the deletion is reversible or what happens if no matching entry 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?

Four tight sentences, each earning its place: scope first, then sibling differentiation, then the per-entry-type behaviors, then the confirm requirement. Front-loaded and free of 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 tool with no annotations and no output schema, the description covers scope, side effects, and the mandatory confirmation flag. It leaves out return/error behavior (e.g., no entry found for that day) but otherwise gives an agent enough to call it safely.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds real semantic meaning about the `date` parameter: for working locations only that day is affected, whereas for a multi-day Out of office the date selects an entry that is removed as a whole. That nuance is absent from the schema and materially affects how an agent should pick a date.

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 a precise resource scope (working location / Out of office / Focus time entries for one day in the Calendar app). It explicitly distinguishes itself from calendar_delete by noting those entries are not in the calendar provider and are therefore invisible to that tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Names the closest alternative (calendar.delete) and explains the condition under which this tool must be used instead, which is exactly the routing information an agent needs. It stops short of stating explicit exclusions or preconditions beyond the confirm flag.

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 so well: it discloses recurring-event expansion, hidden-calendar coverage, and the important side effect that `include_unsynced=true` temporarily enables sync, is slow (about a minute), and turns sync back off afterward. This is exactly the kind of behavioral context an agent needs before invoking the 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?

The description is front-loaded with purpose, followed by range rules, defaults, and important caveats. Every sentence adds useful information, and the structure makes it easy to scan without wasting space.

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 13-parameter tool with no annotations and no output schema, the description covers the critical context: purpose, default time range, calendar scope, hidden-calendar behavior, and the temporary-sync side effect. It does not describe the returned event shape, sorting, or timezone handling, which are minor but real gaps given the absence of an output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents each parameter and the baseline is 3. The description adds meaningful semantics beyond the schema by explaining the relationship between `period` and `start`/`end`/`days`, the default range, and the behavioral implications of `include_hidden` and `include_unsynced`.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'List event occurrences in a time range,' and adds that recurring events are expanded into instances. It is clear what the tool returns, but it does not explicitly distinguish itself from sibling tools such as calendar_search or calendar_next.

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 operational guidance for selecting a time range via `period` or `start` plus `end`/`days`, and states the default when nothing is provided. It also explains when `include_hidden` and `include_unsynced` matter, but it does not explicitly name alternatives or when not to use this 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?

With zero annotations the description carries the full burden and does so well: it discloses the outward-facing effect (colleagues see the block), the auto-decline side effect, the confirm requirement, and the important lifecycle quirk that the block is not visible in the calendar provider and must be read back from the app / removed via calendar.delete_special.

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 no filler; the core purpose leads and the lifecycle caveat follows. Efficient, though the parenthetical clauses could be tightened.

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 eight-parameter mutation with no annotations and no output schema, it covers the essential behaviors (outward-facing impact, confirm gate, non-provider lifecycle). It leaves minor gaps such as what the returned block looks like and how decline/message interact, but nothing critical to correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so all eight parameters including the decline enum are already documented in-schema. The description only obliquely reinforces auto_decline/decline via 'meetings can be auto-declined' and adds no syntax or default detail beyond the schema, so baseline 3 applies.

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 Focus time block in the Calendar app") and adds scope detail (colleagues see it, meetings can be auto-declined). The 'not in the calendar provider' line separates it from provider-level tools, though it never explicitly contrasts with calendar_create/calendar_update.

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?

Conveys the use case (blocking focus time) and a precondition (confirm=true), but never states when to prefer this over calendar_create or calendar_update for a normal event, nor when not to use it. Guidance is implied rather than explicit.

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 substantial work: it discloses which events are excluded (canceled, declined, all-day by default), how hidden and unsynced calendars are treated, and even surfaces the `unsynced_calendars` output field. It flags that include_unsynced is slow, which is exactly the kind of operational caveat an agent needs. It stops short of stating the return value shape (block granularity, timezone) or that the tool is read-only.

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 paragraphs, front-loaded with the return value, then behavioral rules. Each sentence carries a distinct rule (canceled, declined, all-day, hidden, unsynced). Minor deduction for opening with a noun phrase rather than a verb, which reads as a label rather than an instruction.

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 11-parameter tool with no output schema and no annotations, the description supplies the essential behavioral model: what counts as busy, what is skipped, and the calendar-inclusion matrix. The gaps are what happens with zero arguments (all params optional, no stated default range) and the format/granularity of the returned busy blocks.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline would be 3, but the description adds real meaning the schema lacks: the relationship between include_unsynced and the `unsynced_calendars` output, and the fact that sync-off calendars are excluded unless that flag is set. This cross-parameter interplay is not inferable from the individual field descriptions.

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 line states precisely what the tool returns: merged busy blocks plus the free gaps between them within a time range. That distinguishes it functionally from calendar_events or calendar_search, but it never names those siblings explicitly, so the differentiation must be inferred from the noun phrase alone.

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 through the filtering rules (canceled/declined skipped, tentative counted unless disabled), which tells an agent the result is a computed availability view rather than a raw event list. However, there is no explicit 'use this instead of X when…' guidance and no statement about what happens when no range is supplied — all 11 parameters are optional.

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 bears full behavioral burden. It adds useful context by disclosing that recurring events return the whole series and that attendees and reminders are included. However, it doesn't state read-only safety, permission requirements, or error behavior for missing event_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?

A single front-loaded sentence with zero wasted words. Every element (single event, recurring series, attendees, reminders) 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 simple one-parameter read tool with no output schema, the description compensates by stating what is returned (attendees and reminders) and how recurring events are handled (whole series). Only minor gaps remain around error handling or authentication, which are less critical here.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the sole event_id parameter is well-documented in the schema, including its source (calendar.events / calendar.search). The description adds no further parameter semantics, which is the baseline expectation when schema coverage is complete.

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 ('Get') and resource ('one event'), and distinguishes from list tools by explicitly saying 'one event' and noting whole-series behavior for recurring events. It doesn't name a specific sibling alternative, but the scope is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied: an agent would naturally use this after finding an event_id. However, there is no explicit when-to-use guidance, no mention of alternatives like calendar_search or calendar_events, and no exclusions. Minimum viable 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 behavioral burden. It does disclose two useful traits — the value comes from the provider rather than the UI, and it only exists "if it has one" — but says nothing about failure behavior for events without a link, permissions, or what the response looks like.

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 key qualifier ("if it has one") placed early and no wasted words. It is efficient, though bordering on under-specified rather than maximally front-loaded.

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 exists, so the description should say what is actually returned — a URL string, null, or an error — when the event has no Meet link. The parenthetical hints at nullability but leaves the return contract ambiguous for an otherwise simple 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?

There is only one parameter and schema coverage is 100%, so the schema already documents event_id fully. The description adds no semantics beyond what the schema provides, which is the expected baseline for a single well-documented parameter.

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?

Identifies a specific resource — the Google Meet link belonging to a given event — which is distinct from siblings like calendar_add_meet and calendar_remove_meet that modify the meet link. It lacks an explicit verb (read/get), so the agent must infer that this is a retrieval operation from the noun phrase alone.

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?

"(provider only, no UI)" implies the agent should call this rather than opening the event and scraping the link from the calendar UI, which is a soft alternative. However, no sibling is named explicitly and there is no statement about when this is preferable to calendar_get or calendar_open_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?

No annotations are supplied, so the description carries the full burden. It discloses two useful behavioral facts, inclusion of currently-running events and soonest-first ordering, but says nothing about what a returned occurrence contains, whether defaults for hidden/declined calendars apply silently, or any performance caveat (the schema mentions a slow unsynced path that the description ignores).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence with no filler; the key qualifier (upcoming or currently running) and the ordering are both front-loaded. Nothing could be removed without losing signal.

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 7 optional parameters, full schema coverage, and no output schema, the definition is minimally adequate. However, because no output schema documents the return shape, the description should say what an occurrence looks like and how the count cap behaves when days and count interact.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter is already explained, which sets the baseline at 3. The description adds only indirect signal: 'currently running' bears on the days window and 'soonest first' on count, but no syntax or default behavior is contributed beyond 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?

The description names a specific resource ('event occurrences'), a scope ('next upcoming or currently running'), and an ordering ('soonest first'), so an agent understands what comes back. It does not differentiate itself from siblings like calendar_events or calendar_search, which overlap heavily with this concept.

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 next upcoming (or currently running) event occurrences' implies the use case of a quick look-ahead, but the description never says when to prefer this over calendar_events, calendar_get, or calendar_search. With dozens of calendar siblings, the absence of any explicit contrast leaves the agent to infer 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 at all, the description carries the full burden, and it does disclose the return shape (view, toolbar title, visible items, with per-day counts in month view) and that the view may be switched as a side effect. It omits whether the tool is read-only versus state-changing, whether it launches the app, and any latency or failure behavior, which matters for an unannotated UI-driving 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 tight sentences: what it does and returns first, the sibling alternative last. No filler, and the most important information is front-loaded.

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, but the description compensates by enumerating the return payload, including the month-view special case. For a 2-parameter, zero-required navigation tool this is nearly complete; only the app-state prerequisite 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 coverage is 100%, so both parameters (date formats, view enum and its 'keep current view' default) are already fully documented. The description only alludes to the view parameter ('optionally switching view') without adding format or edge-case detail beyond the schema, so the baseline 3 applies.

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 ('Show a date') plus the resource (Calendar app), and adds the read-back behavior ('read what is visible'). It explicitly distinguishes itself from the sibling calendar_view_screen, so an agent can pick between them without opening 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?

Gives an explicit routing rule: use this to open a date/view, use calendar_view_screen to read whole days in detail. That is a real when-to-use statement. It stops short of a full 5 because there is no guidance on prerequisites (must the Calendar app be running?) or when neither tool is appropriate.

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 does the heavy lifting well: it discloses that the tool navigates the UI ('read its screen'), enumerates the returned fields, and documents the RSVP state encoding including null. It omits the side effect of leaving the Calendar UI on the event screen (only implied by stay_open in the schema) and says nothing about failure behavior for unsynced events.

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 purpose sentence followed by a compact enumeration of the returned surface, which is warranted because no output schema exists. The parenthetical RSVP encoding is slightly dense but each clause carries 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 UI-navigation read tool with no annotations and no output schema, the description supplies both the precondition and a field-level summary of the return payload, which is exactly what an agent needs to decide and to interpret the result. Nothing critical 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 100%, so the baseline is 3; the description goes slightly beyond by pinning event_id to the provider-side id and tying validity to Google sync, which constrains which ids are legal. The recurrence-occurrence meaning of start 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?

The opening sentence gives a concrete verb pair (open + read screen) and a specific resource (an event, keyed by provider id), which is materially different from calendar_get or calendar_events. It stops short of naming the closest sibling (calendar_view_screen) explicitly, so differentiation is inferential 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?

A real usage precondition is stated — 'The event must be synced with Google' — which tells the agent when this call can succeed. However, there is no guidance on when to prefer this over calendar_get or calendar_view_screen, and no note on what to do when the event is not synced.

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 that this is outward-facing/destructive (hence confirm=true), that organizers receive 'message' and are notified on new_and_existing, that already-accepted meetings are only declined when explicitly requested, and that the block is not in the calendar provider and must be removed with calendar.delete_special. These are exactly the side effects an agent needs before invoking 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?

The purpose is front-loaded in the first sentence, and the second paragraph is dense with defaults and side effects rather than filler. It is on the long side, but each clause (default decline mode, notification behavior, removal path, confirm requirement) carries distinct information, so almost 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 an 8-parameter mutation with no annotations and no output schema, the description covers the essentials: side effects, defaults, prerequisites (confirm), and lifecycle (removal via calendar_delete_special). The only gap is what the call returns or how to verify the block was created, which is minor since there is no output schema to lean on.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents all 8 parameters and the baseline would be 3. The description adds genuine meaning on top: it clarifies that decline='new_and_existing' notifies organizers (a non-obvious side effect) and explains the confirm requirement's rationale ('outward-facing or destructive'), extending beyond the schema's terse default notes.

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 and resource ('Create an Out of office block in the Calendar app') and immediately states the visible effect ('colleagues see it; meetings can be auto-declined'), which distinguishes it from calendar_create, calendar_focus_time, and calendar_reminder_add. It also clarifies that this is not a provider-level event but an app-level construct, which is information an agent could not infer from the name alone.

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 operational context: default decline behavior is 'only_new', new_and_existing must be requested explicitly, and removal is done via calendar.delete_special rather than calendar_delete. It never explicitly contrasts with calendar_focus_time or calendar_create (the nearest-looking siblings), so an agent still infers which tool to prefer, but the behavioral framing is otherwise strong.

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 disclosure burden. It usefully states the tool returns the event's reminders (helpful given no output schema), but says nothing about whether the add appends or replaces existing reminders, permission requirements, or any cap on reminders per event — significant gaps 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?

Two tight sentences with zero waste; the action is front-loaded and the return-value note follows. Every sentence earns its place, especially since the second sentence substitutes for a missing output 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 3-parameter mutation tool with no annotations and no output schema, the description covers the action and the return shape, but omits permission requirements, append-vs-replace semantics, and any indication of what happens on invalid event_id. Adequate but with clear 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 100%, with all three parameters documented including the enum and the 0-40320 minute range. The description adds no parameter-level meaning beyond the schema, so the baseline 3 applies.

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 ("Add a reminder to an event"), which is unambiguous and lets an agent distinguish it from calendar_reminder_remove by the verb alone. It stops short of any explicit sibling comparison, so it lands at 4 rather than 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?

There is no when-to-use guidance, no prerequisites (event must exist, permission needed), and no mention of the natural alternative calendar_reminder_remove or how many reminders an event can hold. The agent must infer all usage context.

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 does add one genuinely useful fact — 'Returns what is left' — which covers the absent output schema. But it omits mutation-relevant traits: whether removal is reversible, whether minutes-matching deletes all matching reminders, and what happens if nothing matches.

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, with the selection modes front-loaded and the return behavior trailing. Nothing could be cut without losing 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 4-parameter mutation with full schema coverage and no output schema, the description plus schema is nearly sufficient — the return note fills the output-schema gap. The only shortfall is missing guidance on parameter interaction and non-matching-reminder behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and each parameter is already documented, including the useful hint that reminder_id comes from calendar.get. The description's mode list restates the schema rather than adding new meaning, so baseline 3 applies; it gives no guidance on mutual exclusion among all/minutes/reminder_id.

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 (remove) plus resource (reminders from an event) and the three selection modes, which cleanly separates it from the sibling calendar_reminder_add. It never names the sibling explicitly, but the add/remove pairing 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?

The parenthetical lists the three removal modes, implying when each applies, but the description never states when the agent should reach for this tool versus calendar_update (which may also alter reminder state) or when removal is inappropriate. Usage is inferable 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 usefully discloses that the link stops working and that the action is outward-facing/destructive requiring confirm=true, but it does not cover permissions, reversibility, or the asynchronous timeout behavior documented in the schema.

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 definition is two short sentences, front-loaded with the action and effect, and the confirm requirement is stated clearly with no wasted text.

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 but simple removal operation with full schema coverage and no output schema, the description provides enough context to call it correctly. It could be slightly richer about reversibility or permissions, but the essential effect and safety requirement are present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents event_id, scope, start, confirm, and timeout. The description only restates the confirm requirement and adds no extra parameter semantics beyond 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?

The description states a specific verb and resource: remove the Google Meet conference from one of the user's events. The effect, that the link stops working, further distinguishes it from sibling operations like calendar_add_meet or calendar_meet_link.

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 implies when to use the tool by describing removal of a Meet conference and notes the confirm requirement. However, it does not explicitly name alternatives or when-not conditions, such as using another calendar update tool instead.

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 the key external side effect (the organizer is notified by Google) and the confirm gate. It stops short of stating whether the status can be changed again later, what permissions are required, or whether the action is idempotent for a recurring series.

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: the action first, then the hard prerequisite. Nothing is redundant and every clause carries information the caller needs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple four-parameter mutation with a fully documented schema and no output schema, the description covers purpose, side effect, and the confirm gate adequately. The only material omission is routing guidance against the near-duplicate calendar_rsvp sibling.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%: status enum, event_id series semantics, instance_start, and confirm are all documented in the schema. The description only restates the confirm requirement and adds no parameter detail beyond the structured fields, so the baseline 3 applies.

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 ('Answer an invitation: set your own attendee status'), which is concrete and actionable. However it does not distinguish itself from the sibling calendar_rsvp, which appears to cover the same ground, so an agent cannot tell the two apart from the description alone.

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 confirm=true prerequisite is stated, which is useful gating guidance, and the parenthetical explains the outward effect. But it gives no when-not guidance and never mentions calendar_rsvp or calendar_attendee_add as alternatives for RSVP-like actions, leaving the agent to infer which tool to pick.

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 does the heavy lifting well: it discloses that the organizer is notified (outward-facing side effect), that the effect lands on Google's servers immediately while the local provider catches up after sync, and that confirm=true is mandatory. It does not cover failure modes (invalid event_id, declined confirm) or whether an answer can be revised later, 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?

Front-loaded with the purpose, then the sibling contrast, then the prerequisite, then the confirm requirement — a sensible order with no filler. Minor deduction for referring to siblings as 'calendar.respond' / 'calendar.open_event' (dot notation) while the actual tool names use underscores, which is a small avoidable ambiguity.

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 and no output schema, the description covers the essentials: side effect, sync/asynchrony behavior, precondition, and the confirm guard, which explains the confirm and timeout parameters implicitly. Missing only edge-case behavior such as what a failed or timed-out answer looks like.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the enum/default documentation for scope, start, confirm, and timeout is already complete, so the baseline is 3. The description's only added parameter meaning is the scope='this' recurring-occurrence case, which largely restates the schema's own scope 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 ('Answer an invitation with the Calendar app's Yes / No / Maybe buttons') and immediately adds the consequence ('organizer is notified'). It is clearly distinguished from the sibling calendar_respond by transport path and by the single-occurrence capability.

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 contrasts with calendar.respond (provider path) and explains why you would pick this one: it goes through Google's servers at once and can answer a single occurrence with scope 'this'. It also gives an ordering prerequisite — read the current answer first with calendar.open_event — and the confirm=true gate.

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 discloses several non-obvious traits: all calendars including hidden ones are searched, results are newest first, and recurring events use the first occurrence's start/end. It does not describe return structure, permissions, or rate limits, but the key search semantics are covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short paragraphs, front-loads the core purpose, and every sentence adds useful scope or behavioral context. There is no repetition or 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 six-parameter search tool with no output schema, it covers the critical invocation semantics: series versus occurrences, all-calendar scope, result ordering, and recurrence handling. It does not explain the shape of returned results, but enough is present to call the tool 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 100%, so the baseline is 3, but the description adds meaning beyond the schema by clarifying that the query searches title, description, and location, and by explaining how start/end behave for recurring event series. It reinforces that the calendar parameter can cover hidden calendars too.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: search event series by text in title, description, or location. It immediately distinguishes series from occurrences and names calendar.events for concrete occurrences, so an agent can tell it apart from calendar_events without inspecting 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?

It explicitly says to use calendar.events with `query` when the agent needs concrete occurrences in a range, which is a clear alternative-selection rule. It also specifies that the search covers all calendars including hidden ones, giving enough context to choose this tool over calendar-specific listing tools.

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 — and it does disclose the key side effects: hiding does not stop syncing, disabling sync removes events from the device, enabling sync downloads them via a separate tool. It doesn't mention permission requirements or error behavior when the calendar id is unknown.

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 operation and followed by the two most important semantic distinctions. No filler or repetition.

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-annotation, no-output-schema settings mutation, the description covers what changes, what the states mean, and the required follow-up call. Minor gap: no statement about failure modes for an invalid calendar id.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already defines 'visible', 'sync', and 'calendar'. The description adds genuine meaning by explaining that the two booleans are independent settings with different consequences (hidden vs. synced), which an agent could not infer from the schema alone.

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 (show/hide, toggle sync) and resource (a calendar in the phone's calendar list), and explicitly separates it from event-level operations ('not changes to the events'), which distinguishes it from calendar_update and calendar_events.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear context: use it for phone-level settings, and run calendar.sync_background after enabling sync to actually fetch events. It also excludes event editing. It stops short of fully routing the agent to a sibling for event-level changes by name, hence a 4 rather than a 5.

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

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

With no annotations, the description carries the full disclosure burden and does well: it reveals outward visibility (colleagues see it in Calendar/Gmail/Chat), that the change is scoped to the listed days while weekly settings persist, the undo path, and the confirm=true gate with its rationale. It stops short of covering permission/account scope or error behavior, 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?

Four tight sentences with the action front-loaded, followed by consequences, undo and the confirm requirement. The trailing confirm=true sentence partially duplicates the schema's own confirm description, which is the only real redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 4-parameter mutation tool with no annotations and no output schema, the description covers effect, visibility, scope persistence, reversal and the confirm gate. Only peripheral context such as account/timezone handling is 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 description coverage is 100%, so the baseline is 3. The description's 'Home, Office or any place' and 'one day or a range of days' largely restate what the schema already documents for place, date and end_date, adding only modest framing value.

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 ('Set your working location') plus the accepted values (Home, Office, any place) and the temporal scope (one day or a range of days). It also disambiguates from the read path by naming calendar.working_location, so an agent can tell it apart from calendar_set_calendar and the read sibling 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?

Explicitly routes the agent: read with calendar.working_location, undo by re-setting the previous place or by calendar.delete_special, and use this tool for per-day overrides that should not disturb weekly settings. Both alternatives and their selecting conditions are named.

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

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

With no annotations, the description carries the full burden and does disclose the key behavior: it forces a sync, waits for completion, fetches new server events, uploads local changes, and verifies the sync start on Android's sync manager. It does not describe failure behavior, timeout outcomes, or what the response contains.

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 core action and effect in the first two sentences, then details the method modes. Dense but each sentence adds operational information; the nested parenthetical about the fallback path is slightly hard to parse.

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 three-parameter sync tool with no annotations and no output schema, the description covers the action, side effects, method trade-offs, and verification. It falls short of fully complete because return values and failure/timeout handling are left unexplained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline would be 3, but the description adds real meaning to the 'method' enum by explaining what auto, background, and ui actually do, beyond the schema's terse 'auto, background or ui.' The 'wait' and 'timeout' parameters are already explained in 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 ('Force a Calendar sync with Google') plus the waiting side effect. It explicitly distinguishes itself from the sibling calendar_sync_background by noting that background mode is 'same as calendar.sync_background', so an agent can tell the two apart without opening 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?

Explains the three method modes with when each is appropriate: auto tries the fast no-screen sync manager first and falls back to the app's Refresh, background is sync-manager only, and ui uses the drawer Refresh. It routes to the sibling for background mode but does not state when not to use this tool or any prerequisites.

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, and it delivers real operational detail: it pushes local create/update/delete/respond changes and pulls server changes, and runs headless with the screen off. It omits failure behavior, network requirements, and whether partial failures roll back, so it is strong but not complete.

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 key scope and mechanism are front-loaded and the total is three sentences with no filler. The closing sentence about calendar_sync falling back to the app is slightly compressed and takes a moment to parse, which keeps it from a 5.

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-optional-parameter sync tool with no annotations and no output schema, the description covers what is synced, in which direction, and under what device conditions. Return values and error semantics are absent, but the essentials for a correct invocation are there.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and both parameters (wait, timeout) have their own descriptions, so the schema does the semantic work. The description adds no parameter-level detail, making the baseline 3 correct.

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 ("Sync the calendar with Google") plus the mechanism (Android sync manager, requestsync) and scope (without the screen). It explicitly distinguishes itself from the closest sibling calendar_sync, so an agent can pick between them 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 a concrete usage condition (works with phone locked and screen off) and names the alternative (calendar_sync) with its distinguishing fallback behavior. It never states an explicit when-not-to-use case, which keeps it short of a 5, but the context needed to choose is present.

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 discloses that undo=true marks a completed task as not completed, which is useful, but it does not describe permission requirements, side effects, missing-task behavior, or what confirmation is returned.

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 a single front-loaded sentence with no wasted words. It communicates the primary action first and the undo variant second.

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?

The schema is fully described and there is no output schema, so much of the calling detail is covered. Still, as a mutation tool with no annotations, the description does not address permissions, result behavior, or what happens when no matching task title exists.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all four parameters are already documented. The description adds the semantic of undo=true, but that is also present in the schema. Baseline 3 is appropriate because the schema does most of the parameter explanation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: mark a Google Task as completed. It also clarifies the inverse operation with undo=true, making the core action clear. However, it does not explicitly distinguish this tool from sibling calendar_task_update, which likely handles other task edits.

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 use the tool by naming the completion and undo scenarios. It does not state when to prefer calendar_task_update for other changes, nor does it mention prerequisites or exclusions. Usage is inferable but not fully guided.

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 only that the task appears in Calendar on its date; it says nothing about whether the task is created immediately, what happens if the target list does not exist, or any permissions/side effects. For a write tool with zero annotation coverage, this is thin.

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?

One short sentence, front-loaded with the action and resource, with zero wasted words. Its terseness is more a completeness gap than a conciseness problem, but it is arguably too minimal to stand alone.

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?

The input schema is fully described and simple (6 params, one required), which covers most of what an agent needs to call it. However, with no annotations and no output schema, the description should do more to explain mutation behavior and success semantics; the single-sentence description leaves that gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter (date, list, time, notes, title, starred) is already documented in the schema with defaults and formats. The description adds no parameter-level information beyond what is structured, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb and resource: 'Create a Google Task', and adds where it surfaces ('shown in Calendar on its date'). That is enough to distinguish it from event creation (calendar_create) and the other task siblings by name, though it never explicitly contrasts itself with calendar_task_update or calendar_create.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this versus calendar_task_update or calendar_create, and no prerequisites or exclusions. The only signal is the verb 'Create', which leaves the agent to infer usage from the tool 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 are provided, so the description carries the full behavioral burden. It usefully discloses that the action is "outward-facing or destructive" and requires confirm=true, but it does not explain irreversibility, permission requirements, side effects, or what happens when multiple matching tasks exist.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short sentences with zero waste. The core action is front-loaded and the confirmation requirement follows 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?

The schema fully documents the parameters, and the description adds the critical confirm requirement. But for a destructive tool with no annotations and no output schema, it is still missing important context about reversibility, matching behavior, and how it differs from related task 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?

Schema description coverage is 100%, so all five parameters are already documented. The description mentions confirm=true, but this is already stated in the schema and does not add meaning beyond it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: "Delete a Google Task." It is clear what the tool does, but it does not differentiate from closely related siblings such as calendar_task_complete, calendar_task_update, or calendar_task_list_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?

The usage is implied by "Delete a Google Task" and the required confirm=true prerequisite. However, there is no explicit guidance on when to delete versus complete, update, or otherwise modify a task, and no alternatives are named.

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

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

With no annotations, the description carries the behavioral burden. It usefully discloses a state side-effect ("it becomes the list shown"), which tells the agent creation changes the active list. However, it omits permissions, duplicate-name behavior, and what the call returns for this 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?

One short sentence that is fully front-loaded with the core action and the side-effect clause. Nothing wasted, nothing buried.

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 creation tool with a fully covered schema and no output schema, the description is largely sufficient. The only minor gap is that it doesn't state what is returned or whether the new list's identity/name is confirmed.

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 single `list` parameter is fully documented in the schema (100% coverage) as "List name." The description adds no syntax, naming constraints, or format details beyond the schema, so the baseline 3 applies.

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 new Google Tasks list"), which clearly separates it from sibling list operations like calendar_task_lists (read) and calendar_task_list_delete (delete). It stops short of naming those siblings explicitly, so it is 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?

There is no explicit when-to-use, when-not-to-use, or named alternative. An agent must infer that this is the right tool when a new task list is needed rather than creating tasks within an existing list via calendar_task_create.

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 well: it discloses that the operation is destructive and cascading (all tasks in the list go with it), that the default list is protected, and that confirm=true is required. It stops short of stating irreversibility 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 sentences, no filler, with the destructive scope front-loaded and the constraint and confirmation requirement following. Nothing to cut.

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 destructive tool with no annotations and no output schema, the description covers the essentials: cascade effect, protected target, and the confirm gate. It omits failure behavior and whether 'list' is matched by name or ID, which are minor residual 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 100%, so the schema already documents both parameters; the description mainly restates the confirm=true requirement. It does add genuine semantics for 'list' by declaring which list values are invalid (the default list), which the schema's bare 'List name.' does not convey.

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 Google Tasks *list*, plus the cascade scope ('and all its tasks'). That scope distinguishes it from the sibling calendar_task_delete (which deletes a task), though the sibling is never named 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?

The parenthetical '(the default list cannot be deleted)' gives one concrete when-not condition, which is real guidance. But there is no routing to alternatives (calendar_task_delete for single tasks, calendar_task_lists to inspect lists first), so the agent must infer the rest.

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 does not state that this is a read-only operation, whether it requires auth, whether pagination applies, or what the response shape is beyond 'names'. The one genuinely useful disclosure — that the values feed the `list` argument elsewhere — is the only behavioral detail present.

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 text is short but ends in a dangling 'Args:' fragment, which is noise from an incomplete template and misleads the agent into looking for arguments that do not exist. The remaining sentence is not front-loaded as a verb+object action 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?

There is no output schema, so the description is responsible for conveying return values; it only hints that names are returned. For a tool whose whole purpose is producing identifiers for other calls, the agent is left unsure whether it gets a list of strings, objects with ids, or counts.

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 per the baseline this scores 4. However the trailing dangling 'Args:' indicates a truncated or omitted documentation block, which is a defect even though there are no parameters 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?

The fragment 'The Google Tasks lists' identifies the resource and implies a read of task lists, and the parenthetical tells the agent the returned names can be used as `list` elsewhere. But it is a noun phrase with no verb, no statement of what is returned (names only? ids? ordering?), and it does not distinguish itself from calendar_tasks or calendar_task_list_create/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?

There is no explicit when-to-use or when-not-to-use guidance. The nested hint that names are usable as `list` in other task ops weakly implies 'call this before task ops', but the agent must infer that; nearby siblings like calendar_task_list_create and calendar_task_list_delete are not mentioned.

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 usefully discloses that tasks are not in the provider, how due dates are shown, which task fields are returned, the parent-then-subtask ordering, and the title-plus-occurrence addressing convention used by other task operations.

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 front-loaded with the core purpose in the first sentence and then adds useful return-value details. It is mostly efficient, though the output-field enumeration is dense and the final addressing note is more about the task ecosystem than this specific call.

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 appropriately enumerates the task fields returned and explains subtask ordering. It is nearly complete for a read-only list tool, though it leaves read-only/non-destructive behavior implicit rather than stated explicitly and does not discuss pagination or result limits.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents both parameters fully, including the default list behavior and include_completed. The description adds little parameter-specific meaning beyond reinforcing that the operation is scoped to one list.

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 names a specific verb and resource: listing Google Tasks for one list, and clarifies the Calendar-app view. It also distinguishes this list operation from the other task ops that address tasks by title, so an agent can identify what the tool does 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 'List Google Tasks of one list' and the note that other task ops address tasks by title, but the description does not explicitly say when to use this versus alternatives such as calendar_task_lists or calendar_task_update. The schema references calendar.task_lists for discovering list names, but the description itself provides no when-to-use/when-not 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. It does usefully disclose the return payload and the non-obvious identity semantics (renaming changes the task's identity, so new_title + occurrence must be reused). It says nothing about permissions, failure behavior when the title isn't found, or whether clear_date/notes clearing is reversible.

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 paragraphs: the operation and its editable surface first, then the return/identity contract. Every sentence carries information an agent needs to sequence follow-up calls.

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 12-parameter mutation tool with no annotations, the description covers the operation list, the return shape, and task-identity reuse — enough to invoke correctly. The remaining gap is error/ambiguity handling when the title matches no task or multiple, which the `occurrence` hint only partly addresses.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description goes beyond the schema by explaining why `occurrence` matters in follow-up calls and pairing it with `new_title` as the new identity — semantics the per-parameter text alone doesn't connect.

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 ('Edit a Google Task') and enumerates exactly which fields are editable (title, date/time, notes, subtasks, star, list). The scope is unambiguous, though it never distinguishes itself from the sibling calendar_task_complete, which also mutates a task.

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 field list — an agent infers it should edit an existing task rather than create one. There is no explicit when-not guidance, and notably no routing to calendar_task_complete for marking a task done, despite the overlapping `completed` parameter that only acts as a lookup filter here.

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 and does: guest e-mail side effects requiring confirm=true, permission limits on foreign invitations, and a concurrency hazard (rapid successive edits can be overwritten by the server; check pending_sync). It also discloses that instance_start produces a new occurrence object with recurrence_exception_of set.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action, then grouped into labelled paragraphs (recurrence, clearing, guests, sync hazard) that an agent can scan selectively. Dense but essentially waste-free; the parenthetical examples ('e.g. move tomorrow's stand-up') earn their space by anchoring the semantics.

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 14-parameter mutation tool with no annotations and no output schema, the description covers mutation scope, confirmation auth, permission boundaries, recurrence edge cases, and even the shape of the returned occurrence. Nothing an agent needs to call 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?

Schema coverage is 100%, so the baseline is 3, but the description adds genuine cross-parameter meaning the schema cannot express: start-only keeps duration, end/duration_minutes keeps start, empty string clears location/description, rrule='none' demotes a series to a single event at its first occurrence. Only timezone/all_day/color semantics are left entirely 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?

Opens with a specific verb+resource: 'Change fields of an event', and immediately narrows scope ('whole series for recurring events, or one occurrence'). It also names the sibling it competes with ('answer them with calendar.respond / calendar.rsvp'), so an agent can distinguish it from calendar_create and the RSVP tools without reading schemas.

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 inclusions and exclusions: use instance_start to move one occurrence, use calendar.respond/calendar.rsvp for invitations you don't organise. It even states the narrow legal subset of edits on third-party invitations (availability/colour, calendar.reminder_*), which is exactly the routing decision an agent must make.

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 well: it discloses a real side effect (if provider events are missing from the app, 'the app is refreshed and read again') and what happens to ones still absent ('listed in not_shown_event_ids'). It also explains the semantics of the response field (absent when you accepted or organise). It stops short of stating permissions or performance/rate implications.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core purpose, then the value-add, then the row shape — a sensible order with no filler sentences. The dense parenthetical field list ('response (Not responded / No / Maybe..., absent when you accepted...)') is efficient but borders on a run-on.

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 exists, and the description effectively supplies one by enumerating row kinds and fields, plus the not_shown_event_ids fallback. What's missing is any statement of result size limits, date-range errors, or failure behavior for malformed dates — minor for a read 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 100%, so date, days, include and match_ids are already documented in the schema. The description adds only indirect meaning ('one or more days', id matching tied to event_id/instance_id) rather than extra format or edge-case rules, so the baseline 3 applies.

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 with scope: 'Read what the Calendar app shows for one or more days, as structured rows (schedule view)'. The phrase 'Shows things the provider lacks' draws the key distinction from provider-backed siblings like calendar_events and calendar_get, so an agent can route without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear context for use (app-rendered schedule incl. working locations, tasks, RSVP) and an explicit follow-on path: use event_id/instance_id with calendar.open_event / calendar.rsvp. It never explicitly says when to prefer calendar_events or calendar_get instead, so exclusions are 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, the description carries the full behavioral burden. It usefully discloses that working locations are not in the provider and that missing days are reported with place null, but it does not state read-only status, permissions, or the full output shape.

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 resource and followed by useful caveats about provider absence and null place values. No filler or repetition.

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?

The tool is low-complexity and the schema is fully described, but no output schema exists. The description mentions the null edge case yet does not fully describe the return structure or confirm read-only behavior, leaving modest gaps for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so date and days are already documented in the schema. The description reinforces the per-day nature but adds no parameter-specific format or behavior beyond what the schema provides.

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 clearly identifies the resource: daily working locations from the Calendar app, with example values (Office, Home). It does not explicitly name the read/list action or distinguish itself from the sibling calendar_set_working_location, but the intended data is clear.

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 implies the tool is for viewing working locations, but gives no explicit when-to-use guidance, prerequisites, or exclusions. Critically, it does not tell the agent to use calendar_set_working_location when changing a location instead.

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; it does disclose the returned shape (name and type), which is useful. However it says nothing about whether an unlocked device or GET_ACCOUNTS-style permission is required, whether results include all account types, or what happens when no accounts exist.

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, front-loaded sentence with no waste. It is arguably terse to the point of under-specification, but nothing in it 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 zero-parameter tool with no output schema, the description should explain what comes back, and it only minimally does so (name and type). It omits account type semantics (e.g. Google vs Exchange) and any indication of result ordering or volume, leaving the agent to discover return details at call time.

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 and the baseline of 4 applies. The schema is empty and consistent with a simple read of phone state.

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?

Names the specific resource (accounts registered on the phone) and the fields exposed (name and type), which distinguishes it from file-listing siblings like device_ls and state siblings like device_status. The verb is implicit rather than stated (it presumably lists/returns accounts), which keeps it 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?

There is no guidance on when to call this versus device_status, device_ls, or any other device-inspection tool, and no stated preconditions such as the device being unlocked or the required account permissions. The agent must infer usage entirely 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, the description must carry the behavioral burden; it does disclose that the action is 'outward-facing or destructive' and requires confirm=true, plus the environment restriction on APK installs. It omits the concrete side effects an agent would want — whether the IME is enabled/switched, whether root or reboot is involved, and how to revert — so disclosure is partial.

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 caveat front-loaded before the mechanics. The compressed parenthetical is dense but every clause carries decision-relevant information; 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 two-parameter mutation with no output schema and no annotations, the description covers when to skip it and the confirm gate, but says nothing about post-install effects or verification. Adequate to decide whether to call, thin on what happens once you do.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and both parameters are documented in-schema (apk_path's local path and source repo, confirm's required-true semantics). The description adds no parameter detail beyond restating the confirm requirement, so the baseline 3 applies.

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: 'Install ADBKeyboard' is concrete and distinct from the device_* siblings like device_push or device_shell. The parenthetical adds scope-limiting context (it's usually redundant), which further sharpens the purpose.

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 says when NOT to use it ('not needed: the on-phone server types any Unicode') and flags a policy blocker ('the office phone forbids APK installs'), which is exactly the kind of exclusion that prevents wasted calls. It stops short of naming the preferred sibling (e.g. ui_type) to use instead.

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 implies a read-only listing operation but says nothing about permissions, hidden files, recursion depth, metadata returned, or error behavior.

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 a single front-loaded sentence with no filler. It is appropriately sized for a simple one-parameter listing tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple optional-parameter listing tool with no output schema, the description is minimally adequate. However, it leaves out usage context and return behavior, which an agent might need 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 100%, and the single remote_dir parameter is already fully documented with a default. The description adds only the phrase 'phone directory,' which does not meaningfully extend the parameter semantics beyond 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?

The description states a specific verb and resource: 'List files in a phone directory.' This is clear enough to distinguish it from most siblings, especially device_pull/device_push/device_rm, but it does not explicitly contrast with drive_list or other listing tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use device_ls versus alternatives such as drive_list, nor any prerequisites or exclusions. The agent must infer usage entirely from the tool name and schema.

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 says 'Copy' rather than move, which usefully implies the source remains, but it does not disclose overwrite behavior for local_path, permission needs, or what happens if the destination directory is missing.

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 a single front-loaded sentence with no wasted text. It puts the core action and direction first and appends the useful default destination.

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 file-transfer tool with no output schema and no annotations, the description covers the source, destination, and default destination adequately. It could be more complete on overwrite and error behavior, but the remaining gaps are modest for this complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline would be 3. The description adds meaningful information beyond the schema by specifying the default local destination when local_path is omitted, which is not stated in 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?

The description states a specific verb and resource (copy a file) and makes the direction explicit: from the phone to this computer. This distinguishes it from the sibling device_push by direction, though it does not name 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 implied by the transfer direction and the default download directory, but there is no explicit guidance on when to choose device_pull versus device_push or other device file tools. It also omits prerequisites such as whether the remote file must already exist.

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. It gives the default destination folder but says nothing about overwrite behavior when the file already exists, whether missing directories are created, permission/root requirements, or what errors look like — critical gaps for a file-writing 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?

One short sentence with the direction front-loaded and the destination default in parentheses. Efficient, though the parenthetical duplicates the schema default rather than earning 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?

A two-parameter, one-required tool with no output schema and no annotations. The description covers the direction and destination adequately, but with no annotations the missing failure/overwrite semantics leave the agent without enough to predict outcomes.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and both parameters are already documented, including the trailing-slash rule and the /sdcard/Download/ default, which the description merely restates. Baseline 3 applies since the description adds no meaning beyond 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 (copy) plus both endpoints (this computer to the phone), which implicitly distinguishes it from the reverse-direction sibling device_pull. It never names device_pull explicitly, so differentiation is inferred 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?

The phrase 'from this computer to the phone' implies when to use it over device_pull, but there are no explicit exclusions, no prerequisites, and no named alternative. Usage is implied rather than guided.

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 at all, the description carries the full behavioral burden. It usefully discloses that this is destructive and gated behind confirm=true, plus a path restriction, but says nothing about irreversibility (no trash/undo), permission requirements, whether directories are rejected, or what happens on failure.

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: the operation and scope come first, the confirm precondition second. Every clause earns its place and 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 simple two-parameter destructive tool with no output schema, the description covers the essentials: resource, location restriction, and the safety gate. The main omission is an explicit statement that deletion is permanent/not recoverable, which matters for a destructive operation with zero annotation 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 description coverage is 100%, so both parameters are already documented in the schema, including the confirm=true requirement and the /sdcard restriction on remote_path. The description only restates the confirm rule, adding no format examples or edge-case guidance beyond structured fields; baseline 3 is appropriate.

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), resource (a file), and location (phone's shared storage, /sdcard only), which clearly separates it from sibling device_* tools like device_pull/device_push and from drive_delete_forever. It does not explicitly name a sibling alternative, but the scope constraint does most of the disambiguating work.

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 '/sdcard only' scoping and the 'Requires confirm=true' prerequisite give implicit guidance on when this tool applies. However, there is no explicit statement of when NOT to use it, nor a pointer to sibling alternatives (e.g. drive_delete_forever for cloud files, device_shell for paths outside /sdcard).

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 says 'raw adb shell' and 'escape hatch,' which hints at arbitrary device execution, but it does not disclose privilege level, destructive potential, side effects, or output behavior.

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 a single front-loaded sentence with no wasted wording. The parenthetical 'escape hatch for anything not covered' adds useful routing context without bloating the definition.

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 unannotated arbitrary shell executor, the description is too thin on safety and execution context. It does not explain privileges, whether commands can modify or destroy device state, or how output is returned, and there is no output schema to compensate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and both `command` and `timeout` are documented in the schema. The description adds no parameter-level meaning beyond what the schema already provides, so the baseline score of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: run a raw `adb shell` command on the phone. The phrase 'escape hatch for anything not covered' clearly distinguishes it from the many dedicated sibling tools such as `ui_tap`, `device_pull`, and `device_status`.

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 a clear fallback condition: use this when no dedicated tool covers the task. It does not explicitly warn against bypassing dedicated tools or list representative alternatives, but the selection rule is 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 burden. It usefully discloses the screen-off effect, the re-lock side effect, and the CPU-saving rationale, but it omits whether the device must already be unlocked, what happens if it is already locked, and whether any confirmation is returned.

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, zero wasted words, and the core effect is front-loaded before the usage guidance.

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-optional-parameter device action with no output schema, the description covers purpose, side effect, and timing. The schema handles the parameter detail; only minor behavioral edge cases remain 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 100%, and the single home parameter is fully described in the schema. The description does not add any parameter meaning beyond the schema, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and effect: turning the screen off and re-locking the phone. This clearly distinguishes it from the sibling device_unlock action and tells an agent exactly what the tool does.

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 usage context: use when done, to save CPU on the host. It does not name alternatives or exclusions, but the timing guidance is explicit.

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 does disclose the returned signal set, which implies a passive read, but it says nothing about latency, whether it requires a live adb connection, or what happens if the device is offline or locked.

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 colon-list with zero filler; every item earns its place as a reported field. It is slightly telegraphic, 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?

With no annotations and no output schema, the description partially compensates by listing the fields it reports, but it omits the response format (flat text vs structured object) and the failure modes for a disconnected or locked device. Adequate but with a clear gap for a diagnostic 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?

The tool takes zero parameters and the schema is an empty object, so there is nothing for the description to disambiguate. Baseline 4 applies.

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 names the resource ('Phone status') and then enumerates the exact facets reported: adb state, Android version, screen on/locked, foreground app, app versions. That is specific enough to separate it from siblings like ui_dump (hierarchy) or device_ls (files), though the verb 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 guidance on when to call this versus alternatives such as ui_dump, ui_find, device_accounts or ui_screenshot, and no preconditions (e.g., whether adb must be connected) are mentioned. The agent must infer usage from the field list 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, the description still discloses the core behavior: it wakes the screen, unlocks with the configured PIN, and is automatically performed by UI operations. It does not cover failure modes such as a missing PIN or whether it is safe to call when already unlocked, but the core behavior is clear for a zero-parameter 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?

The description is a single front-loaded sentence with no wasted words. The automatic UI behavior note is compactly placed in parentheses.

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 zero-parameter device action with no output schema, the description provides enough context to select and invoke it correctly. Minor gaps remain around return values and edge cases such as no configured PIN, but these are not central to invoking the 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?

The tool has zero parameters, so the baseline is 4. The description correctly indicates that the PIN is configured rather than passed as an input.

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 names a specific action and resource: waking the screen and unlocking it with the configured PIN. It also distinguishes this tool from the ui_* siblings by stating that every UI operation performs this automatically.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The parenthetical '(every UI op does this automatically)' gives useful context that this tool is usually unnecessary before UI interactions, implicitly reserving it for explicit unlock scenarios. However, it does not explicitly state when the tool must be used instead of relying on automatic behavior.

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 implies stateful navigation by saying "Enter a folder" and mentions returning the folder's items, but it does not disclose whether the current location persists, error conditions, permission requirements, or how the limit parameter affects returned items beyond what the schema already states.

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 a single, front-loaded sentence with no wasted wording. The parenthetical path rules are dense but each clause contributes useful navigation semantics.

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-optional-parameter navigation tool with no annotations and no output schema, the description covers the core path/index modes and says it returns the folder's items. However, "items" is vague without an output schema, and the stateful effect on the current location is only implied rather than explicitly stated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds meaningful semantics beyond the schema by explaining path resolution: relative to current location, ".." means parent, and leading "/" means from My Drive; it also clarifies that index refers to the last list.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: "Enter a folder" via path or index and returns the folder's items. It is clear what the tool does, but it does not explicitly name sibling alternatives such as drive_up or drive_list to sharpen differentiation.

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 how to specify a path, including relative paths, ".." for parent, leading "/" for My Drive, and index from the last list. However, it does not explicitly say when to use this tool versus drive_up, drive_list, drive_open, or drive_location, nor does it provide 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, the description must carry the full load. It does disclose two genuine behavioral traits — the automatic naming ("Copy of <name>") and the resulting navigation state ("Drive is left in the destination folder, where the copy is checked") — but omits whether sharing/permissions are inherited by the copy, whether folders can be copied recursively, and what happens on name collisions.

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 short and front-loads the action, which is good. However, the quoted UI label "Make a copy" is redundant noise and the second sentence ("Drive is left in the destination folder, where the copy is checked") is grammatically garbled, forcing the agent to guess at its 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?

This is a mutating tool with zero annotations and no output schema, so the description should state prerequisites, permission/sharing inheritance, and collision behavior — none of which appear. Post-operation state is mentioned, but an agent still cannot predict side effects on the duplicated item's sharing or size limits.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all five parameters (name, path, index, occurrence, destination) are already documented, including destination defaults. The description adds nothing parameter-specific beyond the naming outcome, so the baseline 3 applies.

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 ("Make a copy of a file") and adds the resulting name convention ("Copy of <name>"), so the agent knows exactly what operation this performs. It never contrasts itself with nearby siblings such as drive_move, drive_rename, or drive_upload, though none of those overlap enough to cause real confusion.

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: nothing says to locate the item first via drive.list/drive.search (only the schema's 'index' description implies it), nothing says copies of folders are or aren't supported, and nothing excludes alternatives. The only contextual hint is the post-operation sentence, which describes state rather than selection criteria.

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 it delivers a genuinely non-obvious behavioral fact: creation is delegated to the Docs/Sheets/Slides app, and on a device lacking that app it redirects to the Play Store and fails with `app_missing` while creating nothing. That failure-without-side-effect detail is exactly what an agent needs. It stops short of stating permissions, whether the new file opens, or what is returned, so it is 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?

Purpose is front-loaded in the first clause, and the second sentence is long but earns its space by explaining a real failure mode. The '(Create new > Google Docs...)' UI-menu aside is marginal padding but small.

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, so the description must fully cover behavior; it explains the failure path well but says nothing about the success path — whether the new file opens, what identifier is returned, or which folder it inherits by default. Those are material gaps for a creation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and both parameters are self-documenting, so the schema does the heavy lifting; the description only echoes the docs/sheets/slides enum already in `kind`. It adds no clarification about `path` defaulting or whether the parent folder must already exist.

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 Google Docs/Sheets/Slides file') and names the exact UI action it mirrors. This is clearly distinct from sibling mutations like drive_mkdir (folder), drive_upload, or drive_copy, which an agent can rule out from the description alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the verb and by the enumerated kinds, but the description never states when to prefer this over drive_upload, drive_copy, or drive_mkdir, nor any prerequisites. It spends its second sentence on a failure mode rather than on routing guidance.

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

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

With no annotations at all, the description carries the full burden and does disclose the two traits that matter most: the action is irreversible ('cannot be undone') and it is gated behind confirm=true as an outward-facing/destructive action. It does not describe failure modes (missing name, stale index) or what the caller sees afterwards.

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, irreversibility and the safety gate front-loaded, zero filler. Nothing could be cut without losing a required warning.

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 4-param destructive tool with no annotations and no output schema, the description supplies the essentials: it is permanent, it only applies to Trash contents, and confirm is mandatory. Minor gaps remain around error behavior and item identification ambiguity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents name, index, and occurrence. The description only reinforces the confirm parameter's role ('Requires confirm=true'), adding no guidance on how name/index/occurrence combine to identify one item; baseline 3 applies.

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 ('Permanently delete an item') and qualifies the scope ('that is in the Trash'), which separates it from drive_trash (move to trash) and drive_empty_trash (bulk). It never names those siblings explicitly, so the differentiation is inferred 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?

The precondition 'item that is in the Trash' plus the mandatory 'confirm=true' gate give clear context for when this tool applies. No alternative or exclusion is spelled out (e.g. use drive_trash to delete a non-trashed item, drive_restore to recover), so the agent has to infer the routing.

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