SYNCDATE

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

Annotations only say readOnlyHint=false and destructiveHint=false; the description adds real behavioral context beyond that by disclosing the async nature of the flow, the two returned artifacts (authorize_url, poll_token), and the user-interaction step required. It omits any note on expiry, token lifetime, or failure handling, keeping it from a 5.

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

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

Three tight sentences with zero filler: the purpose comes first, then the return values, then the follow-up procedure. Every sentence carries information the agent needs to act.

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?

Although no output schema exists, the description names the returned fields and describes the multi-step completion path, which is the key missing piece for a flow-initiation tool. Combined with full schema coverage and annotations, nothing essential for correct invocation 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?

There is a single parameter with 100% schema description coverage and an enum, so the schema already fully documents 'provider'. The description mentions Google/Outlook but adds no syntax or constraint detail beyond the enum, which is the expected baseline when the schema does the heavy lifting.

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 ('Start an OAuth connect flow') and resource ('new Google or Outlook account'), and the provider scope implicitly separates it from connect_caldav_account, connect_ical_feed, and reauth_account. An agent can identify this as the tool for initiating a brand-new OAuth account connection 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?

Gives explicit workflow instructions: relay authorize_url to the user, then poll connect_account_status with poll_token until status leaves 'pending' — naming the sibling to use next. It doesn't explicitly state when NOT to use it (e.g., existing accounts → reauth_account, CalDAV → connect_caldav_account), so it falls just short of full when/when-not coverage.

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

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

Annotations already declare readOnlyHint=true, but the description adds real behavioral context beyond them: the pending/completed state machine, the need to poll repeatedly, and what is returned when finished. It stops short of disclosing failure/expired states or polling cadence/timeout limits, so not a 5.

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

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

Three short sentences, front-loaded with purpose then the polling rule then the completion outcome. No filler; every sentence carries operational 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?

With no output schema, the description correctly explains the return value (account_id on completion), covering the main gap. It omits what happens on failure/expiry statuses, which would matter for a polling loop, but is otherwise sufficient for correct invocation.

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

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

Only one parameter with 100% schema description coverage, so the schema already fully documents poll_token and its origin. The description repeats the token's provenance but adds no format or validity details beyond the schema. Baseline 3 is 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 (poll) and resource (status of an OAuth connect flow) and ties it directly to the sibling tools that create the flow (connect_account, reauth_account). An agent can distinguish this from other account tools 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 states when to call it (after connect_account/reauth_account), how to drive the polling loop ('keep polling while status is pending'), and the terminal condition that ends iteration. This is actionable routing guidance, not inference.

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

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

Annotations only declare readOnlyHint=false and destructiveHint=false; the description adds real value beyond them by disclosing the credential requirements per provider and the return values (new account_id, number of calendars discovered). It still omits failure modes, permission scope, or rate limits, so it is helpful but not exhaustive.

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

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

Three tight sentences with the core purpose and the two key provider caveats front-loaded; very little wasted text. A minor structural nit is that provider specifics are appended without clear labeling, but the size is appropriate.

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

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

With no output schema, the description correctly summarizes the return payload (account_id and calendar count), and all five parameters are fully schema-documented. Annotations cover the mutation safety profile; the only gap is the absence of error/reauth behavior, which is minor for a straightforward connect operation.

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

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

Schema description coverage is 100%, so the schema already documents every parameter, including server_url being required for Nextcloud and password meaning 'Password or App-Specific Password'. The description largely restates these, adding only the iCloud App-Specific Password hint, 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?

States a specific verb+resource (connect a CalDAV account) and enumerates the supported providers (iCloud, Fastmail, Nextcloud), making the tool's scope obvious. It does not explicitly contrast itself with connect_account or connect_ical_feed, so sibling differentiation is left implicit, keeping it just 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?

"Direct — no browser redirect needed" gives clear context for when this credential-based flow applies versus an OAuth/browser flow, and provider-specific prerequisites (App-Specific Password for iCloud, serverUrl for Nextcloud) guide correct invocation. No alternative tool is named and no explicit when-not condition is stated, so it lacks full routing guidance.

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

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses several real traits: it creates an account, validates reachability before creation, returns account_id, and is idempotent on repeated URLs. This is meaningful behavioral context; it does not cover auth-failure behavior or rate limits, but the mutation and safety profile are clear.

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 purpose, then behavior (direct), return value (account_id), validation and idempotency. Each sentence carries distinct information with no filler.

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

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

With no output schema, the description usefully states the return value (account_id), and annotations carry the safety profile. It is nearly complete; a note on failure modes when validation fails would close the remaining 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 url/name/password/username are already documented with their constraints (https/webcal, max 120 chars, Basic Auth pairing). The description adds only that the feed is read-only .ics; it does not clarify password/username pairing beyond the schema. 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 (Connect) and resource (read-only iCal feed / .ics URL), and the '.ics' plus 'read-only' detail clearly differentiates it from CalDAV (connect_caldav_account) and generic account connections. It does not name the alternative sibling explicitly, so an agent infers rather than is told the contrast.

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?

'Direct — no browser redirect needed' implies when this path is preferable to a redirected connect flow, and the idempotency note tells the agent re-connecting is safe. However there is no explicit statement of when to choose this versus connect_caldav_account or connect_account, nor any 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?

Annotations only declare readOnlyHint=false/destructiveHint=false; the description adds substantial behavioral context beyond that: provider capability limits (EVENT_TYPE_NOT_SUPPORTED on Outlook/CalDAV), the read-only iCal feed restriction, and the exact 400 error codes (DATETIME_AMBIGUOUS/DATETIME_INVALID) returned on invalid input. This is rich disclosure of preconditions and failure modes.

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 the constraints. The datetime paragraph is dense but each clause (four shapes, resolution semantics, rejection rule) is load-bearing. No filler sentences, though the density borders on exhaustive for a description field.

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 creation tool with no output schema, the description covers preconditions, provider limits, and the tricky datetime contract well. It does not mention what the call returns (e.g. created event ID), which would help an agent chain subsequent calls, leaving a minor gap.

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

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

Schema coverage is 67%, so the description must carry weight, and it does — enumerating the four accepted datetime shapes, the wall-clock resolution rule, and the 'never assumed UTC' contract. Much of this partly overlaps the start/end schema descriptions, but the end-time cross-field rule ('strictly after start') and error behavior add genuine meaning.

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 calendar event') that clearly distinguishes it from siblings update_event, delete_event, get_event, and list_events. An agent can route to it without ambiguity.

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

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

Provides a clear when-not exclusion ('Not supported for read-only iCal feeds') and provider-capability constraints. It does not explicitly contrast creation against update_event for the edit case, but the context is strong enough to imply correct usage.

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

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

Annotations only declare readOnlyHint=false and destructiveHint=false, so the description carries the real burden — and it delivers the FORBIDDEN failure mode for gated settings plus the exact default values applied when arguments are omitted. It omits whether creation triggers an immediate sync run and whether the operation is idempotent, which would round it out.

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, followed by argument format, return value, defaults, then plan gates — each sentence is actionable and none is redundant. The dense plan-gate block is information an agent must have to avoid a FORBIDDEN error, so it earns its length.

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

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

For a 10-parameter, deeply nested mutation tool with no output schema and no schema descriptions, the definition covers creation semantics, the calendar reference format, defaults, and plan gating well. It leaves gaps around deep settings structures and whether the new sync begins running immediately, but the essentials for a correct call 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 coverage is 0% and there are 10 parameters with deep nested objects, so the description must compensate. It does document the calendars {accountId, providerCalendarId} shape, several defaults, and names five nested settings keys, but the large fieldExpressions, exclusionRules, directionalSettings perPair and most copy* booleans remain unexplained in both schema and description.

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

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

States a specific verb (Create) and resource (sync process) plus the structural constraint of 'spanning two or more calendars'. An agent can distinguish it from get_sync, update_sync, trigger_sync, and delete_sync without opening any schema.

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

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

Gives a concrete prerequisite pointer ('use list_available_calendars to discover them') and extensive plan-tier gating rules that condition when certain settings can be used. It does not, however, state when to prefer create_sync over update_sync or explain behavior for repeated creation attempts, so it stops short of full when/when-not coverage.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds value beyond that by making the irreversibility concrete ('Permanently... cannot be undone'), clarifying there is no trash/recovery path — something the hint alone does not convey. It still omits side effects (e.g. impact on existing syncs of the calendar) and 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, with the core action front-loaded and the warning immediately after. Nothing needs trimming and nothing is 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 three-parameter destructive tool with full schema coverage and annotations that already carry the safety signal, the description covers the essentials (what it deletes, that it is irreversible). It is slightly thin on interaction effects with the many sync-management siblings in the toolset, which an agent managing mirrored events might need.

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 all three required parameters (accountId, providerCalendarId, eventId) are documented in the schema itself. The description adds no parameter-level meaning beyond what structured data already provides, so the baseline 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?

States a specific verb (delete) and resource (an event from a calendar), with scope narrowed by 'from a calendar'. An agent can trivially distinguish this from siblings like update_event, get_event, or list_events without opening any schema.

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

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

The description gives no when-to-use context, no prerequisites (e.g. that the account must be connected or the calendar listed first), and does not point to update_event as the alternative when the goal is modification rather than removal. Usage is only inferable from the verb.

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

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

Annotations already flag destructiveHint=true, but the description adds the specifics annotations cannot: the status transitions to 'deleting' immediately, cleanup is enqueued asynchronously, the immediate return shape is { status: 'scheduled' }, and deletion may take minutes for large calendars. This is exactly the destructive-op context an agent needs before calling.

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 sentences, zero filler, and the async/scheduling behavior is front-loaded before the optional-parameter caveat and the polling guidance. Every sentence changes how the agent would call or follow up on the 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?

There is no output schema, and the description compensates by stating the immediate return value ({ status: 'scheduled' }) and prescribing the polling tool for completion. For a two-parameter destructive async tool, nothing needed to invoke 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 description coverage is 0%, so the description must carry the load, and it does for the non-obvious parameter: deleteEvents is explained as 'synced copies on all target calendars are also deleted', including the latency caveat. syncId is left unexplained, but as a required UUID identifier its meaning is self-evident from the 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?

The description opens with a specific verb+resource ('Delete a sync process') and immediately qualifies the operation as asynchronous, so an agent knows this is not a simple synchronous delete. It does not, however, explicitly distinguish itself from the related sibling finish_sync_delete, leaving that differentiation to inference.

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 post-call context: returns immediately and the agent should poll with get_sync until the sync disappears. It also explains the conditional effect of deleteEvents (deletes synced copies on target calendars, may take minutes), which guides the agent on how much to promise the user. No explicit when-not or named alternative such as finish_sync_delete.

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

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

Annotations already flag destructiveHint=true, and the description goes well beyond them: it discloses the ownership constraint (cannot disconnect the SYNCDATE sign-in account), the dependency constraint (active syncs must be removed first), the specific error code returned (FORBIDDEN), and the permanence of the operation. This is exactly the extra behavioral context annotations cannot convey.

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 with no filler, and the core action plus its permanence are front-loaded before the conditional failure detail. Every clause carries information the agent needs.

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

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

For a mutation tool with no output schema, the description covers the critical preconditions and the error behavior. It does not state what happens to the account's calendars and events after disconnection, which is a meaningful gap for a destructive operation, but the essentials for a correct call 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?

There is a single parameter and schema description coverage is 100%, with account_id already documented as 'Account UUID to disconnect'. The description adds no format, constraint, or lookup guidance 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 (disconnect) and resource (calendar account) with the irreversibility modifier 'permanently'. It does not explicitly distinguish itself from nearby siblings such as request_account_deletion, reauth_account, or revoke_mcp_connection, so an agent still has to infer the boundary.

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 clear usage context by naming the failure conditions (sign-in account, dependent active syncs) and the required ordering ('delete those syncs first'), which effectively tells the agent when the call will be rejected and what to do first. It stops short of stating when to prefer this over sibling account-management 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?

Annotations already declare readOnlyHint=false and destructiveHint=false, so the write-nature of the tool is covered structurally; the description adds only the account scoping phrase. It says nothing about the idempotencyKey's role in retry safety, rate limits, or whether submission notifies support, which is the value an agent would need beyond the annotations.

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

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

A single front-loaded sentence with no filler, so structure and brevity are good. It is under-specified rather than padded, which keeps this dimension clean.

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 four required parameters, no output schema, and 0% schema coverage, the description is too thin — it omits what a valid submission looks like and what the agent gets back. The missing idempotency behavior in particular is something only this description could have supplied.

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

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

Schema description coverage is 0% across four required parameters, and the description supplies no semantics for any of them — not the subject/body length constraints, the requestType enum values, nor the purpose of the format:uuid idempotencyKey. With four required parameters and zero compensating text, the description leaves the agent to guess at call syntax.

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

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

The description gives a specific verb+resource ('Create a support request') and scopes it to 'your SYNCDATE account', so an agent can distinguish it from get_support_case and list_support_cases. However, it does not differentiate from reply_to_support_case, which also creates content on a support case, leaving one ambiguity among 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?

There is no when-to-use guidance, no exclusion for cases where an existing case should be replied to instead (reply_to_support_case), and no note about prerequisites or account scoping rules. The description states what the tool does but never tells the agent when to pick it over its neighbors.

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

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

Annotations already cover the safety profile (readOnlyHint=true), and the description adds genuinely useful behavioral detail beyond it: recurring series are expanded, Google OOO events count as busy (opaque), and workingLocation events do not. It does not describe the return shape, but the busy-detection semantics are a substantial addition.

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 sentences, purpose front-loaded, then progressively finer behavioral detail about busy detection. Every sentence 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 query tool with no output schema, the description conveys what is returned (free time slots) but not their structure or granularity (e.g., whether adjacent slots are merged, per-calendar vs aggregated). It is nearly complete but leaves a small gap on return semantics.

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

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

Schema description coverage is 75%, so the nested window object, calendars pairs, busyTimezone, and minDurationMinutes are largely documented in the schema itself. The description adds no additional parameter meaning (no format or default elaboration beyond 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 ('Find') and resource ('free (unbooked) time slots'), plus the scope ('within a window across one or more calendars'). This clearly differentiates it from siblings like list_events or get_event, which return events rather than computed free slots.

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 window/calendars framing but there are no explicit when-to-use statements, no exclusions, and no named alternatives (e.g., list_events when the agent wants raw events). The agent must infer the 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?

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds genuinely new behavioral context: this is a partial destruction that preserves 'the remaining event copies,' which is exactly what an agent would worry about with a destructive tool. It stops short of explaining what 'held' means or what permissions are needed.

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 compact sentence, front-loaded with the action and scoped by a subordinate clause. No filler. It is slightly ambiguous enough to require a re-read, keeping it out of the top score.

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 mutation with no output schema and only annotation-level safety hints, the description omits key context: what a 'held' deletion is, which tool created that state, and how it relates to delete_sync. Adequate to call the tool, but incomplete for confident selection among many sync-related siblings.

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

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

Schema description coverage is 0%, so the schema contributes nothing about syncId. The description gives no explicit semantics for the parameter either, relying entirely on the self-evident name 'syncId'. For a single obvious identifier, 3 is a fair minimum-viable score rather than a larger penalty.

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: 'Finish a held sync deletion.' It implies a two-phase deletion workflow, which is more informative than the name alone. However, it never names or differentiates itself from the sibling delete_sync, so an agent cannot tell which entrypoint to pick 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?

The word 'held' implies this is a follow-up step to an already-initiated deletion, and 'keeping the remaining event copies' hints at the outcome. But there is no explicit when-to-use, no mention of the prerequisite tool that held the deletion, and no comparison to delete_sync. Usage is only inferred.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds genuinely useful context beyond them: the returned link is 'same-origin' and the actual billing mutations occur elsewhere on the website, telling the agent this call does not itself change anything.

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

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

Two short sentences, front-loaded with the core action and followed by the one constraint that matters. Nothing is padded or repeated.

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 read-only link getter with annotations covering safety and no output schema, the description is close to adequate, but it leaves three enum parameters and the return value's form unexplained. It should do more given the 0% schema 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 0%, so the description must carry parameter meaning, but it never mentions intent, plan, or interval. The enum values are self-describing to a degree, yet the required 'intent' and its interaction with plan/interval are left entirely to inference.

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

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

States a specific verb and resource ('Get a same-origin link to the billing page or plan selection'), so an agent immediately knows this returns a link rather than performing billing. It does not reference any sibling, but unlike get_plan_usage its domain (billing/plan link) 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?

'Billing actions happen in the website' implies the intended flow: use this to obtain a redirect target, then let the user act on the site. It does not state when to prefer this over other paths or which intent values map to which scenario, leaving usage largely inferred.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description's only added signal is the word 'optional', hinting preferences may be unset or empty, but it says nothing about the shape of the response or auth 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?

A single short sentence with the resource front-loaded and no filler. It is appropriately sized for a trivial zero-parameter read, though it borders on being too terse to be informative.

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

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

With no output schema, the description carries some burden to describe the returned preference fields, and it does not. For a zero-parameter read whose annotations already cover safety, this is adequate but leaves the return shape and the meaning of 'optional' 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline of 4 applies; no compensating detail is required.

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 (Read) and resource (your optional email preferences), which is clearer than a bare name restatement. It does not, however, explicitly distinguish itself from the sibling set_email_preferences or explain what the preferences contain, so an agent must infer the read/write split from names 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 description gives no when-to-use guidance, no mention of the complementary set_email_preferences tool, and no indication of prerequisites. Usage is only implied by the verb 'Read'.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered by structured data. The description adds only the fact that this is a single-item lookup keyed by three identifiers; it says nothing about error behavior for a missing event, permissions, or rate limits, so it is minimum viable given annotations.

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

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

A single front-loaded sentence that names the action, the resource, and the lookup keys with zero filler. Nothing could be removed 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 simple read-only getter with three fully documented required parameters and no nested objects, the description plus schema covers what an agent needs to invoke it. The absence of an output schema means the return shape of a 'calendar event' is unspecified, but that is a minor gap for a straightforward lookup.

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%: each parameter is documented in the schema, including the hint that accountId and providerCalendarId come from list_accounts and list_calendars. The description restates the three keys but adds no format or constraint 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 and resource ('Get a single calendar event') and names the three lookup keys, which cleanly separates it from list_events and get_sync. It does not explicitly name the sibling alternative, but the singular/plural distinction makes the purpose 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 requirement that the caller already possess account, calendar, and event IDs implicitly signals this is a direct lookup rather than a search, but there is no explicit statement of when to use this over list_events or what to do if the IDs are unknown. Usage is implied rather than stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered without the description. The description adds only that it returns limits and current usage, which is modest added value; return format/pagination remain unspecified and there is no output 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?

One short sentence, front-loaded with the resource and no filler. Nothing can be trimmed.

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-parameter, read-only tool with complete annotations, the description is sufficient to call it. With no output schema, adding a hint about what the response contains would have made it fully complete, so it falls just short of 5.

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

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

Zero parameters, so the schema carries no parameter semantics to explain. Baseline for a parameterless tool is 4; nothing is missing.

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 ('Read') plus resource ('plan limits and current usage'), so the agent knows exactly what it returns. It doesn't explicitly distinguish itself from near-neighbors like get_billing_link, but the resource 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?

No statement of when to call this versus alternatives (e.g. get_billing_link for payment info) and no prerequisites or exclusions. Usage is only implied by the word 'your'.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered by structured data. The description adds that the response includes the request's messages (not just the case metadata), which is useful value beyond the annotation, but it omits pagination behavior for the message thread and any filtering semantics.

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 the verb and resource leading; nothing is wasted. It is appropriately sized for a simple read tool, though it is so terse that it leaves gaps that a slightly longer sentence could have closed.

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 singular read with safety already covered by annotations and no output schema, the description is nearly sufficient. However, the optional cursor suggests the message thread can be paginated, and neither that behavior nor what the returned messages contain is disclosed, leaving an agent guessing about 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 0% across two parameters, so the description must compensate and does not: neither caseId nor cursor is mentioned. Only a faint hint that an identifier is needed can be drawn from 'one of your support requests', and the cursor's pagination role is entirely unexplained.

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

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

States a concrete verb (Read) and resource (one of your support requests and its messages), which is more specific than a bare 'get'. It implicitly distinguishes itself from list_support_cases by the singular scope, but never explicitly names sibling tools or contrasts the retrieval behavior.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as list_support_cases (to find a case) or mark_support_case_read. The need for a caseId is only inferable from 'one of your support requests'.

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

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

Annotations declare readOnlyHint=true, so safety is covered, but the description adds genuinely useful behavior: the exact payload shape (last 5 run summaries plus any recent error), which is the only place this is documented since no output schema exists. It still omits what happens when the syncId does not exist or is not accessible.

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 sentence, front-loaded with the core action, and every clause (run summaries, recent error) earns its place by telling the agent what it will receive. No filler or restatement of the tool name.

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

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

For a one-parameter read-only getter with no output schema, the description adequately covers the return contents. The remaining gap is not telling the agent where syncIds come from (list_syncs) or what a missing ID returns, which is minor but real.

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

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

Schema description coverage is 0%, but the single parameter is the self-explanatory syncId and the schema enforces a strict UUID format and pattern, so callers cannot easily misuse it. The description adds no meaning beyond the schema, so this sits at the baseline rather than above 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?

States a specific verb (get) and resource (a single sync), and goes further by naming what the response contains: last 5 run summaries and any recent error. It is clearly distinguishable from list_syncs and get_sync_run, though it never explicitly contrasts itself with get_sync_health, which also targets one sync.

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

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

No when-to-use guidance, no prerequisites, and no named alternatives. The agent must infer from the name alone that this is the by-ID lookup versus list_syncs for enumeration or get_sync_health for status. There is no help routing between these near-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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds genuine behavioral context beyond that: it discloses what the snapshot contains and notes that OOO events from Google are counted as busy time by the sync engine, a non-obvious engine behavior an agent should know. It stops short of stating auth/permission requirements or rate limits.

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

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

Three sentences, each doing distinct work: purpose plus return fields, sibling routing, and one behavioral caveat. Front-loaded with the core action and free of 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?

There is no output schema, so the description must describe the return value, and it does list the snapshot fields. Usage and one behavioral caveat are covered. Minor residual gaps only (how to obtain syncId, permission requirements), which are low-risk for a read-only single-parameter tool.

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

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

Schema description coverage is 0%, but the single parameter still carries type, UUID format and pattern, so the agent knows the expected input shape. The description only implies the parameter via 'for a sync process' and adds no naming, sourcing, or format guidance beyond that; it does not compensate for the missing description coverage.

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 a specific verb and resource ('Get a consolidated health snapshot for a sync process') and enumerates the returned content (healthy flag, last run status, 24-hour error rate, active alerts, suggested fixes). It explicitly positions itself against the sibling get_sync, so an agent can distinguish the two 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?

Contains an explicit routing rule: 'Use this instead of get_sync when you want to quickly answer is this sync working?' Names the alternative and the condition that selects this tool over it.

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

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

Annotations already declare readOnlyHint=true, so the safe-read profile is covered. The description usefully adds that the response contains per-event-type counts (created, updated, deleted, skipped, reconciled) and error codes, which partially compensates for the absent output schema, but says nothing about auth needs, pagination, 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?

A single well-formed sentence that front-loads the verb and resource. No filler or redundancy, though it is lean enough that it omits needed detail rather than being 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?

With no output schema the description does convey the shape of the returned data, which is the right focus. However, for a 2-parameter tool at 0% schema coverage it omits any parameter explanation and any sibling differentiation, leaving real gaps.

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

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

Schema description coverage is 0% for both required parameters (syncId, runId), and the description does not explain either one. It only implies that a run is identified, leaving the description unable to compensate for the schema gap.

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

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

States a specific verb ('Get') plus resource ('a single sync run') and enumerates the returned content (per-event-type counts, error codes). The 'single' wording implicitly distinguishes it from list_sync_runs, though no sibling is 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?

There is no statement of when to use this tool versus list_sync_runs, get_sync, or get_sync_health, and no prerequisites or exclusions. The only hint of usage is that a single run is addressed, which an agent must infer from the existence of a runId parameter.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds genuinely useful context beyond that: the operation is owner-only (an auth/permission constraint) and scoped to a settings page rather than arbitrary team data.

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

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

A single front-loaded sentence with no filler; the verb comes first and the content enumeration is compact and informative.

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

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

With no output schema, the description usefully enumerates the returned sections (members, invitations, billing summary, onboarding link), which is exactly what an agent needs to decide whether to call it. Combined with the owner-only constraint, nothing material is missing for a zero-param 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?

The tool takes zero parameters, so per the baseline there is nothing for the description to document or compensate for. No parameter-level ambiguity exists.

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 ('Read') plus resource ('Team settings page') and enumerates exactly what the page contains: members, invitations, billing summary, onboarding link. This is clearly distinguishable from siblings like get_team_sync_policy, get_billing_link or update_team without opening any schema.

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

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

The 'owner-only' qualifier gives a clear access condition that tells the agent when this tool is callable and by whom. It stops short of naming alternatives or an explicit when-not-to-use case, so it lands at clear context without full routing guidance.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description's contribution beyond that is the ownership requirement, which is genuine but thin — nothing about behavior when no policy exists or what the application status represents.

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 waste, with the resource and scope front-loaded before the permission qualifier. Nothing could be removed 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 read-only tool whose safety profile is carried by annotations and which returns the policy plus its status, this is minimally sufficient. It omits edge cases (no policy configured, insufficient permissions beyond 'owners only') and the shape of the returned status, though the absence of an output schema makes that less critical.

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

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

Schema description coverage is 0% and the single parameter (organizationId, a UUID) is never mentioned in the description, so the description does not compensate for the coverage gap. The parameter is near self-explanatory from its name and format, but the description adds nothing.

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 ('Read') and resource ('Team sync policy') plus the extra dimension of 'application status', which cleanly separates it from the sibling reads like get_team. However it does not explicitly distinguish itself from preview_team_sync_policy or publish_team_sync_policy, so the sibling differentiation is left to inference.

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?

Adds a real usage constraint ('Team owners only'), which tells the agent who may call it, but gives no guidance on when to prefer this over preview_team_sync_policy or publish_team_sync_policy, nor any preconditions such as requiring an existing policy.

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?

Beyond the annotations (readOnlyHint=false, idempotentHint=false, openWorldHint=true), the description discloses the 1–20 batch limit, a concurrency cap of four simultaneous invite requests, and that accepted invitations are queued for delivery through SYNCDATE Mailer. That is substantive operational context an agent could not infer from the annotations. It still says nothing about partial failure 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?

Three short, front-loaded sentences with no filler; the action and batch constraint lead, with concurrency and delivery details trailing. Every sentence adds information.

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

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

For a mutation with no output schema and only partial annotation coverage, the description covers batch size, concurrency, and delivery path but omits what happens with duplicate or already-invited addresses, whether failures are partial, and what privileges are required. 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 0%, so the description must carry the load. It clarifies that emails are email addresses and states the 1–20 bound (already encoded as minItems/maxItems in the schema), but organizationId is never explained — no indication that it is the target team's UUID. One of two parameters remains semantically undocumented.

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

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

The description opens with a specific verb+resource: "Invite 1–20 email addresses to the Team per call." An agent immediately knows this adds people to a team, and the per-call batch bound is stated. It does not differentiate itself from close siblings like update_team_invite or update_team_member, which keeps it out of 5 territory.

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 and no named alternative among the many team-related siblings (update_team_invite, request_team_auto_join_domain, update_team_member). The batch and concurrency limits are invocation constraints, not routing advice, so the agent gets no help deciding between this tool and its neighbors.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful behavioral context by noting that only active accounts are returned and by explaining the provider and CalDAV server-type fields in the response.

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 no wasted words. The key scope (active accounts) is front-loaded, and the field details follow efficiently.

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

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

There is no output schema, and the description supplies the important response fields, including provider and caldavServerType enum values. It does not mention pagination or ordering, but those are minor for a no-parameter read-only list.

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 are zero parameters, so the baseline is 4. The description instead documents meaningful response-field semantics, which is helpful even though parameters themselves need no 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?

States a specific verb and resource: list active calendar accounts connected to the SYNCDATE user. It is clear enough to distinguish from list_calendars/list_events, though it does not explicitly name the sibling alternative.

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 the obvious use case of retrieving connected accounts, but gives no explicit when-to-use guidance, prerequisites, or mention of alternatives such as list_calendars or connect_account.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered elsewhere. The description adds only the word "home," hinting at personal vs. team scoping, but discloses nothing about filtering behavior, pagination via cursor, or default result windows despite the range param defaulting to 7d.

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 clean, front-loaded sentence with zero wasted words. But for a tool with nine filter parameters, this level of terseness is under-specification rather than effective conciseness.

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 nine parameters, no output schema, and 0% schema coverage, the description should carry much more weight. It leaves filtering semantics, the today/7d/30d/custom range behavior, and pagination entirely undocumented, which is inadequate for this tool's 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 0% across 9 parameters, yet the description mentions none of them. Filters like q, types, range, syncIds, calendarIds, and the cursor pagination token are completely unexplained anywhere, so the description fails to compensate for the coverage gap.

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

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

"Read your home activity feed" states a verb (read) and a resource (home activity feed), so it is not a tautology. However, "activity" is never defined (sync runs? file changes? calendar changes?), and it does not distinguish itself from siblings like list_events or list_sync_runs. An agent gets the general idea but not the scope.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of any alternative tool. The description never says when this feed should be consulted instead of list_events, list_syncs, or list_sync_runs. The agent must infer usage entirely.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds value beyond that by disclosing what the response contains ('sync partner info and entitlement caps'), which is important since there is no output schema. It does not mention pagination or whether disconnected accounts are excluded.

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. Scope is front-loaded in the first sentence and the usage cue in the second, which is exactly the right ordering.

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

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

With no output schema, the description partially compensates by naming the return payload (partner info, entitlement caps) and the follow-up action. The one material gap is the unresolved overlap with the sibling 'list_calendars', which is not addressed.

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

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

The tool takes zero parameters, so there is nothing for the description to document; the baseline for a no-param tool is 4. The description correctly avoids inventing filtering options that the schema does not support.

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 all calendars') and adds meaningful scope ('across all connected accounts'), so the agent knows this is a cross-account enumeration. However, it never distinguishes itself from the sibling 'list_calendars', which an agent could easily confuse it with given the near-identical names.

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

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

Explicitly states the usage context: 'Use this before create_sync to discover which calendars are available.' That is a clear when-to-use cue tied to a named sibling tool. It stops short of an exclusion rule (e.g. how it differs from list_calendars).

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

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

Annotations already declare readOnlyHint=true and a title, so the safety profile is covered. The description usefully adds that results span all connected accounts for the SYNCDATE user, but says nothing about whether disconnected/read-only calendars are included, ordering, or result size.

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

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

A single, front-loaded sentence with no filler. Every word carries scope or resource meaning, and nothing is wasted.

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

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

For a simple zero-parameter read tool the description is serviceable, but with no output schema the agent gets no sense of what the returned calendars look like or how they relate to list_available_calendars. A brief return-shape note would close the gap.

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

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

The tool takes zero parameters, so there is nothing for the description to clarify and the baseline of 4 applies. No parameter-level ambiguity exists.

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

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

States a specific verb (List) and resource (calendars) with scope ('across all connected accounts for this SYNCDATE user'). However, it does not address how it differs from the sibling list_available_calendars, which an agent could easily confuse with this 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?

There is no guidance on when to call this versus list_available_calendars, list_accounts, or list_events. With a near-identical sibling present, the agent is left to infer the selection criterion entirely.

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

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

readOnlyHint=true already covers the safety profile, so the bar is lower, yet the description adds a genuinely useful behavioral fact: recurring series are expanded into per-occurrence events. That materially affects how an agent interprets the result set (expanded occurrences rather than series masters) and is not present in the annotations.

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

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

Two short sentences, zero filler. The core action and scope lead, and the recurring-expansion caveat follows as the one non-obvious detail worth including.

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 read-only list tool with full schema coverage and an existing readOnlyHint, the description covers the essentials plus the recurrence-expansion behavior. With no output schema it could say a bit more about what a returned event looks like, 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 description coverage is 100%, so start, end, accountId, and providerCalendarId are all documented in the schema, including their ISO 8601 formats and defaults. The description only echoes the time-range and single-calendar concepts, adding no format or default detail beyond the schema; 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?

The description gives a specific verb ('List'), resource ('events'), and scope ('from a single calendar in a time range'), which clearly separates it from get_event (single event) and list_calendars (calendars, not events). It stops short of explicitly naming any sibling, so it is clear but not sibling-differentiating by name.

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 scoping phrase 'from a single calendar in a time range' implies when this tool applies, but there is no explicit guidance on when to prefer it over get_event, list_available_calendars, or find_free_time, and no stated prerequisites. 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so safety is fully covered by structured data. The description's only added behavioral value is the 'active' scope, which implies inactive/disconnected connections are excluded, but it does not say whether results are paginated or how many 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?

A single short sentence with the resource and the scoping qualifier front-loaded, and no filler. Every word 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 zero-param, read-only listing with no output schema and complete annotation coverage, the description supplies what an agent needs to decide to call it. It could be tightened by stating that only currently connected MCP integrations are returned and in what form.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a 0-param tool is 4. The description adds no spurious parameter claims.

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

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

States a specific verb (list) and resource (active connected agents/MCP connections), and the annotations' title aligns the term 'agents' with 'MCP connections'. It is distinguishable from neighbours like list_accounts and list_calendars, but the description never explicitly contrasts with them or with revoke_mcp_connection.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as connect_account_status when the agent wants connection state. The only hint is the word 'active', which implies a filter but is not explained.

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?

readOnlyHint=true is already annotated, and the description adds that the response includes an unread count, which is useful return context. However, it omits pagination behavior despite the cursor parameter, and does not discuss rate limits or case visibility.

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

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

A single, front-loaded sentence with no wasted words. It is appropriately sized for the little it conveys, though it could be slightly richer without losing conciseness.

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 list tool with annotations covering read-only safety, the description covers purpose and one return detail. It leaves the cursor parameter unexplained and does not clarify pagination or the distinction from get_support_case, leaving gaps for correct invocation.

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

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

The single optional cursor parameter has 0% schema description coverage and the description never mentions it. The agent receives no explanation of what cursor does (pagination) or how to use 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?

States a specific verb (List) and resource (support requests) and adds the unread count. It distinguishes from get_support_case (singular get) and file_support_case (create) by implying a collection, but does not explicitly name alternatives or scope.

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

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

No when-to-use guidance, no mention of alternatives like get_support_case for a single case or mark_support_case_read. The agent must infer usage from the name alone.

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

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

The readOnlyHint annotation already establishes that this is a safe read operation, lowering the burden on the description. The description adds useful behavioral context by saying it returns 'summaries' in reverse chronological order, but it omits pagination behavior and anything about how recent runs are selected.

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 sentences, front-loaded with the core purpose, followed by concrete usage examples and the return ordering. Every sentence contributes information without 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?

The description tells an agent what the tool lists and in what order, which is useful for a read-only list endpoint. However, with no output schema and 0% schema description coverage, it leaves pagination and summary contents underspecified for fully confident invocation.

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

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

Schema description coverage is 0%, so the description must carry the burden for three parameters. It only implicitly covers syncId through 'for a sync process' and gives a vague sense of 'recent' and ordering, while the limit and before/pagination parameters are never explained.

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 recent sync run summaries for a sync process.' The word 'summaries' distinguishes it from sibling get_sync_run, which presumably returns one detailed run, and 'sync process' scopes it away from list_syncs. An agent can identify the correct operation without opening the schema.

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

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

The description provides concrete example questions it is meant to answer, making the intended usage context clear. It does not mention when not to use it or explicitly point to alternatives like get_sync_run for detailed data, but the positive use case is well specified.

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?

readOnlyHint=true already tells the agent this is a safe read, so the description's main contribution is naming the returned fields (status, participating calendars), which is useful since no output schema exists. It stops short of pagination behavior, result limits, or ordering, which would matter for a potentially unbounded list.

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 sentence, front-loaded with the action and resource, with the scope and return content packed in without redundancy. Nothing to trim.

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

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

For a no-param read-only list tool with no output schema, the description covers what is listed and what each entry contains, which is most of what an agent needs. Minor gaps around result size/pagination prevent a 5.

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

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

The tool takes zero parameters and schema description coverage is 100%, so there is nothing for the description to compensate for. Baseline 4 applies for a parameterless tool.

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

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

States a specific verb and resource ('List all sync processes') and adds scope ('owned by this SYNCDATE user') plus returned content ('current status and participating calendars'). It does not explicitly distinguish itself from siblings like list_sync_runs or get_sync, which is the only thing keeping it from 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?

Usage is implied by 'list all sync processes' — an agent can infer this is the enumerating counterpart to get_sync and list_sync_runs. However, no when-to-use condition, prerequisite, or named alternative is given, so the agent must infer routing on its own.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond restating the action: it does not explain what 'read' changes, whether it affects unread counts or notifications, or whether the case must be yours.

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 compact sentence with no filler, and the action is front-loaded. It is under-specified rather than padded, so conciseness itself is fine.

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, non-destructive mutation whose annotations already convey idempotency and safety, the description is close to sufficient. It falls short on the sole parameter's semantics and the absence of any usage routing, but nothing critical is misleading.

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

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

Schema coverage is 0% for the single required caseId parameter, and the description offers no format or source detail beyond the vague 'one of your support requests'. It does not clarify the `^[A-Za-z0-9_-]{1,200}$` pattern or where to obtain the 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?

States a specific verb ('Mark ... as read') and resource ('support requests'), which is clear and distinct from siblings like get_support_case or reply_to_support_case. It does not explicitly contrast itself with those siblings, keeping it below 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 guidance on when to use this versus get_support_case, list_support_cases, or reply_to_support_case, and no prerequisite noted (e.g., that caseId must come from an existing case). Usage is only implied by the verb 'Mark ... as read'.

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?

The description goes far beyond basic read/write flags provided by annotations. It details crucial operational constraints: 'Existing events are untouched; no new propagation occurs until resumed,' which informs the agent about the scope of the pause.

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 extremely concise. It front-loads the core purpose and uses the remaining sentences efficiently to explain the operational guarantees (untouched events, idempotency).

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

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

Given the simple schema, the description is comprehensive. It addresses the primary behavioral concerns (mutability, state preservation, idempotency) necessary for an AI agent to execute the tool safely and 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?

With 0% schema coverage, the description must compensate for the lack of detail regarding the 'syncId' parameter. However, the description focuses entirely on the *action* and not on the meaning or constraints of the input parameter, resulting in a baseline adequate score.

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

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

The description uses a precise verb and resource ('Pause a sync'), which clearly distinguishes it from related tools like 'get_sync' (read) or 'resume_sync' (opposite action). The purpose is immediately 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 explicitly defines the tool's behavior relative to its state by stating, 'Idempotent — pausing an already-paused sync is a no-op.' This provides strong guidance on when calling the tool repeatedly is safe.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered structurally, and the description's 'before applying an edit' corroborates the non-mutating intent. However, it adds nothing about what the preview produces (a diff, conflict list, warnings) or how large an input it can handle, which matters for a tool whose entire value is its output.

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

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

A single, front-loaded sentence with no filler: the verb and object lead, and the temporal qualifier comes second. It is efficient, though arguably too terse given the six-parameter surface it has to cover.

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

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

With no output schema, the description carries the burden of explaining what a preview returns, and it says nothing about the response shape or how to interpret it. Combined with 0% parameter coverage and nested objects, an agent cannot confidently construct or parse a call from this definition alone.

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

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

Schema description coverage is 0% across 6 parameters, including a nested 'settings' object and five untyped/undocumented fields such as 'calendars', 'proposedDirection', and the one-way source calendar IDs. The description only gestures at 'proposed sync settings' in aggregate and gives no meaning, format, or relationship between these parameters, leaving the agent to guess.

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 uses a specific verb ('Preview') and resource ('impact of proposed sync settings'), and the phrase 'before applying an edit' frames it as a dry-run rather than a mutation. It does not name the sibling that performs the actual edit (update_sync), so the distinction is implied rather than explicit.

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

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

It clearly states the context of use: run this prior to applying an edit, implying it is a pre-flight validation step. There is no explicit when-not or named alternative (e.g., 'to actually persist changes, call update_sync'), so it stops short of full routing guidance.

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

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

Annotations already declare the read-only, idempotent, non-destructive profile. Beyond that, the description adds a real behavioral constraint the annotations do not carry: the caller must be a Team owner, and the call is anchored to an expected revision (implying optimistic-concurrency failure if stale).

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

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

Two tight sentences, front-loaded with the verb and resource, with the permission constraint appended. 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?

There is no output schema, so the description should explain what a 'preview of the impact' actually returns, and it does not. Combined with an undocumented nested policy object and an unexplained expectedRevision contract, an agent is left guessing at the result and payload format.

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

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

Schema coverage is 0% and the nested 'policy' object is entirely undocumented. The description alludes to the policy and to 'expected revision' but says nothing about the shape of the policy payload or the role of organizationId, so it only partially compensates for the coverage gap.

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

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

Specific verb ('Preview') plus resource ('Team sync policy') and a scope qualifier ('at its expected revision'). It implicitly separates itself from publish_team_sync_policy and get_team_sync_policy, though it never names those siblings explicitly.

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

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

'Team owners only' gives an authorization precondition, and 'preview' implies it should be used before publishing. But there is no explicit statement of when to choose this over publish_team_sync_policy or get_team_sync_policy, so usage 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?

Annotations already declare this is a non-read-only, non-idempotent write with destructiveHint=false, so the safety profile is covered. The description contributes beyond that by disclosing the authorization requirement ('Team owners only') and the optimistic-concurrency precondition ('at its expected revision'), though it omits what happens on a revision mismatch or whether the operation 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 short sentences, no filler, with the core action and the revision precondition front-loaded. Every clause carries information; nothing is repeated from the schema or annotations.

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 a nested policy object, 0% schema coverage, no output schema, and no annotations describing failure behavior, the definition is too thin. It leaves the shape of the policy payload and the consequence of a stale revision unexplained, which an agent needs before invoking a publish operation.

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

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

Schema description coverage is 0%, so the description must carry the load, and it only clarifies one of three parameters — 'at its expected revision' gives meaning to expectedRevision. organizationId and especially the nested 'policy' object are completely unspecified anywhere, which is a meaningful gap for a write tool.

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

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

The description states a specific verb and resource ('Publish a Team sync policy'), which clearly separates it from read-oriented siblings like get_team_sync_policy. However, it never mentions the closely related preview_team_sync_policy or clarifies the relationship between previewing and publishing, so sibling differentiation is only implied by the verb.

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 adds one useful precondition ('Team owners only'), which tells the agent this is not for general members. It does not say when to publish versus when to preview via preview_team_sync_policy, nor whether a preview should precede the publish, so usage guidance is only partially 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?

Beyond the annotations, the description explains OAuth behavior for Google/Outlook (authorize_url + poll_token), direct credential updates for CalDAV/iCal, and the iCloud App-Specific Password constraint. These are important behavioral details an agent needs to invoke the tool correctly.

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, then organized by provider case. Each sentence contributes specific, actionable detail with no obvious 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?

There is no output schema, but the description explains the key return shapes for OAuth and direct-update flows. Combined with the schema and annotations, it gives enough context to call the tool correctly across providers.

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 most parameter requirements. The description adds meaningful provider-specific semantics, especially that iCloud requires a newly generated App-Specific Password and that OAuth accounts should omit the password.

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, "Re-authorize a stale account," and ties it to provider-specific status/flow conditions. It clearly distinguishes reauthorization from the sibling connect_* tools by focusing on stale accounts and existing credentials.

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 clearly identifies when this tool applies, especially for Google/Outlook accounts with status needs_reauth, and gives provider-specific usage instructions. It does not explicitly compare against alternatives like connect_account or connect_caldav_account, so it stops short of 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?

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered. The description adds only the 'verified' qualifier, implying the domain must already be verified, but says nothing about irreversibility, required permissions, or side effects on team members joined via that domain.

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

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

A single, front-loaded sentence with no filler. Nothing could be trimmed without losing the verb or resource.

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, non-nested tool with no output schema, a one-line description could be adequate, but the complete absence of schema descriptions and any auth/usage context leaves real gaps. It is minimally viable rather than complete.

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

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

Schema description coverage is 0%, so the description must carry the burden for the two parameters (organizationId, domain) and it does not. It only echoes the word 'domain' and the Team context implicitly tied to organizationId, adding essentially no meaning beyond the bare parameter names.

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

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

The description states a specific verb ('Remove') and resource ('verified auto-join domain from a Team'), which is unambiguous. It does not, however, distinguish itself from the sibling `request_team_auto_join_domain` or explain how 'remove' differs from that request flow.

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, no prerequisites (e.g., admin role), and no mention of the related `request_team_auto_join_domain` tool. Usage is only weakly implied by the verb.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the safety profile is covered. The description adds only the null-clearing behavior, which the schema also states, and says nothing about permissions required, whether the change propagates to synced events, or reversibility.

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

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

Two short sentences, front-loaded with the action and immediately followed by the one non-obvious behavior. The second sentence largely duplicates the schema's nickname description, which is the only slight waste.

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

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

For a simple two-parameter mutation with full schema coverage and annotations covering safety, the description is sufficient to invoke correctly. Missing details (prerequisites, side effects on sync) are minor for this tool's 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%: both account_id (UUID) and nickname (max 50 chars, null to clear) are fully documented in the schema. The description merely restates the null-to-clear semantics without adding format, constraint, or edge-case detail 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?

States a specific verb and resource: set or clear the nickname for a connected calendar account. It is unambiguous and distinct from the other account-level siblings (list_accounts, reauth_account, disconnect_account), though it does not explicitly name a contrast case.

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

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

Usage is implied by the purpose (rename an account after connecting it), but there is no explicit when-to-use/when-not guidance, no note that the account must already be connected, and no mention of alternatives for editing other account attributes.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the agent knows this is a non-destructive mutation. The description adds important behavioral context by indicating that the reply must use the version last read, implying an optimistic-concurrency requirement, but it does not explain conflict behavior, notification effects, or idempotency semantics.

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 states the action and the key version condition without unnecessary 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 non-destructive mutation tool with four required, undocumented parameters and no output schema, the description is too thin. It omits idempotencyKey semantics, body constraints, caseId sourcing, and expected conflict handling, leaving the agent with gaps it cannot resolve from the schema alone.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It clarifies expectedVersion as 'the version you last read,' which is valuable, but it says nothing about the required idempotencyKey, the caseId pattern/source, or the body length limits and purpose.

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 uses a specific verb ('Reply') and resource ('support requests'), making clear it adds a message to an existing case rather than reading, listing, filing, or marking one. It is readily distinguishable from the sibling support-case tools such as get_support_case, list_support_cases, and mark_support_case_read.

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 action itself: this is the tool for replying to an existing support case. The phrase 'using the version you last read' hints at a prerequisite prior read, but the description does not explicitly state when to use this versus alternatives or what to do if no last-read version exists.

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?

Adds real context beyond annotations: the tool sends an email link, requires the owner to sign in, type their email, and confirm, so no immediate destruction occurs. This reconciles the destructiveHint=true with actual behavior. It doesn't mention rate limits or what happens if the owner doesn't act.

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

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

Two tight sentences, front-loaded with the action and followed by the critical safety clarification. No wasted words.

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

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

The two-step flow and safety profile are well covered, and no output schema exists to explain. However, the meaning of the required delete_events parameter is left unaddressed, which is a real gap for a tool the agent must call correctly.

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

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

Schema coverage is 0% and the required delete_events boolean is never explained — the agent cannot tell whether it means 'delete events along with the account.' Only the vague phrase 'with your choices preselected' gestures at how reason/delete_events are used.

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?

Precise verb+resource: it emails a link that opens the deletion dialog, and explicitly states it does not delete anything. This clearly distinguishes it from actual delete operations among siblings (delete_event, delete_sync).

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 makes clear this is the initiation step for account deletion rather than the deletion itself, which tells the agent when to reach for it. It doesn't name alternatives or exclusions, but no sibling competes for this exact purpose.

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

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

Annotations already declare a non-read-only, non-idempotent, non-destructive write, so the bar is lower; the description adds genuinely useful behavior by disclosing the two-step verification flow and that the domain is only added after verification. It omits whether repeated requests re-send emails and what 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?

Two sentences, front-loaded with the action and followed by the consequence. No filler or redundancy.

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

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

With no output schema, the description carries the burden of explaining the outcome, and it does so via the verification-email flow. It is nearly complete for a 2-parameter write tool whose safety profile is already covered by annotations, missing only permission prerequisites.

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 only 50% (organizationId is undocumented), and the description only reinforces the email parameter's meaning ('work email address at that domain'), which the schema already states. It does not compensate for the missing organizationId semantics.

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

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

States a specific verb and resource ('Request adding an auto-join domain') and clarifies the mechanism (work email at that domain). It is readily distinguishable from the sibling remove_team_auto_join_domain, though it never names siblings explicitly.

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

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

It describes how to invoke the tool (supply a work email at the target domain) and what follows, but gives no explicit when-to-use guidance, no prerequisites such as admin rights, and no comparison against alternatives like invite_team_member.

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

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

Annotations cover only the mutation/safety profile (readOnlyHint=false, destructiveHint=false), so the description carries the rest. It adds a genuinely useful behavioral trait not present in annotations — idempotency — which prevents redundant-call concerns. It does not disclose required permissions or the effect on sync state beyond resumption.

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, with the action and its precondition front-loaded before the idempotency caveat. Nothing is wasted or repeated from the 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 one-parameter mutation with no output schema, the essentials are covered, but it omits what resumption actually does to the sync (continue from pause point vs. restart), whether an invalid or completed syncId errors, and any permission requirement. 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 0% and the description never mentions syncId, its format, or where to find one. Because the single parameter's name and uuid format make its intent largely self-evident, this lands at the baseline rather than below it, but the description adds zero parameter meaning.

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 ('Resume') plus resource ('sync') and adds the precondition that distinguishes it from its siblings: the sync must be 'previously paused', separating it from pause_sync, trigger_sync, and create_sync.

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 trigger condition is explicit (use after a sync has been paused), and the idempotency clause tells the agent what happens if it calls the tool on a non-paused sync. It stops short of naming the complementary alternative (pause_sync) or stating error behavior for unknown/invalid syncIds.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered structurally. The description adds nothing beyond that — it does not say whether revocation is reversible, what happens to associated syncs or mirrored events, or whether reconnection is possible, all of which matter for a destructive operation in this family.

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, front-loaded sentence with no filler, which is structurally clean. But it is terse to the point of under-specification rather than efficient conciseness, so it does not fully earn its brevity.

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

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

For a destructive, non-read-only mutation with no output schema and an undocumented identifier parameter, the description should disclose side effects and where the ID comes from. It says nothing about consequences, reversibility, or downstream effects on syncs, leaving the agent under-informed before an irreversible call.

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

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

Schema description coverage is 0% and the single connectionId parameter has no prose explanation anywhere. The description gives no hint that the identifier comes from list_mcp_connections or what format it takes, so it fails to compensate for the schema gap.

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

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

The verb 'Revoke' is specific and the object ('connected agents') loosely identifies the MCP connection resource, so an agent can roughly infer the operation. However, it never names MCP connections explicitly, and the sibling set contains both list_mcp_connections and disconnect_account, so the boundary between this tool and those is not made clear 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as disconnect_account or how this differs from deleting or pausing a related sync. The agent is left to infer the trigger condition 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond them: it never explains what counts as a "mirrored" event, whether it reads across accounts (relevant given accountId/providerCalendarId inputs), or what the scan returns.

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

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

A single front-loaded sentence with no filler, which is structurally clean. The problem is under-specification rather than verbosity: the one sentence leaves the core concept and scope unexplained.

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, yet the description never describes what the scan produces or how results are surfaced. For a cross-calendar comparison tool that requires 2+ calendars, the omission of both input constraints and return shape leaves the agent under-informed.

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

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

Schema description coverage is 0% for the single `calendars` parameter, so the description carries the full burden and largely fails. It says "calendars" but never mentions the 2-20 item bounds, the required accountId/providerCalendarId pair, or that multiple calendars must be compared against each other.

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 verb ("Check") and resource ("calendars", "events"), so the basic action is recoverable. However, the defining concept "events that appear to mirror each other" is unexplained jargon, and nothing distinguishes this scan from siblings like list_events, get_event, or find_free_time.

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

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

There is no statement of when to use this tool, no prerequisites, and no mention of alternatives such as list_events or find_free_time. The agent must infer the use case 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?

Annotations already declare openWorldHint=true, idempotentHint=false, and destructiveHint=false, so the safety/behavior profile is partly covered. The description adds nothing beyond that: no mention of auth requirements, rate limits, or what happens to the submitted feedback. With annotations doing the heavy lifting the bar is lower, but zero added context still warrants a low score.

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 single sentence is front-loaded and free of padding, which is structurally sound. But it is under-specified rather than concise, cutting information the agent actually needs instead of trimming 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?

With no output schema, 0% schema coverage, and three undocumented parameters, the description is too thin for a tool that writes data to an external system. It omits parameter meaning, usage routing, and any behavioral context not already in annotations.

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

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

Schema description coverage is 0% across all three parameters, so the description carries the full burden and fails it. The 'type' enum values (bug/feature/help/general) and the purpose of pageUrl are never explained, leaving the agent to guess how these fields shape the submission.

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?

"Send feedback to SYNCDATE support" states a specific verb (send) and resource (feedback to support), so the basic action is clear. However, it does nothing to distinguish this tool from the many support-related siblings such as file_support_case, reply_to_support_case, and get_support_case, leaving the agent to guess which support entry point applies.

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 tool versus file_support_case or reply_to_support_case, nor any stated preconditions. The agent must infer usage purely from the name, which is exactly the ambiguity the description should resolve.

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

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

Annotations already establish that this is a non-read-only, idempotent, non-destructive, closed-world operation. The description adds almost no behavioral context beyond that — it does not mention batch size limits, account requirements, what happens when hiding, or any side effects. It does not contradict the annotations.

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

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

The description is a single, front-loaded sentence with no wasted words. It is efficient, though its extreme brevity leaves important details unsaid.

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

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

Given a batch mutation with a nested object array, no output schema, and zero property descriptions in the schema, the description is not complete enough. It omits key operational details such as how accountId and providerCalendarId identify a calendar, the batch constraints, and what the visibility change affects.

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

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

Schema description coverage is 0%, and the description only loosely maps the hidden boolean to 'show or hide calendars'. It never explains the entries array, accountId, providerCalendarId, the 500-item maximum, or the 1-item minimum, leaving the nested parameter structure largely undocumented.

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

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

The description states a specific action pair (show/hide) and resource (calendars), making the tool's purpose clear at a glance. It does not explicitly contrast with any sibling tool, but the visibility-setting purpose is distinct enough from list_calendars and update_sync to avoid 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?

The description gives no guidance on when to use this tool versus alternatives, nor does it state prerequisites such as needing an existing account or provider calendar. Usage is only implied by the basic purpose statement.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety and repeatability profile is covered. The description adds only the partial-update notion ('one or more optional'), without stating whether omitted preferences are left unchanged, whether auth is required, or how the four preferences behave (subscribe vs. unsubscribe semantics).

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 no padding, and the key operation is front-loaded. It is efficient, though its brevity borders on under-specification rather than tight communication.

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 four-parameter mutation tool with zero parameter documentation and no output schema, the description omits the meaning of each preference and the partial-update contract. Annotations cover safety, but an agent still lacks enough to invoke this confidently beyond passing arbitrary booleans.

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

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

Schema description coverage is 0% for all four parameters (unsubscribed, monthlyDigest, productUpdates, lifecycleEmails), so the description carries the full burden and does not meet it. It never names any parameter or clarifies the boolean semantics (does true mean opt-in or opt-out?), leaving the agent to guess at meaning.

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 (Update) and resource (email preferences), and the word 'optional' plus 'one or more' signals a partial-update operation. It contrasts implicitly with the sibling get_email_preferences (read counterpart), but never names or explicitly differentiates from it.

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

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

No when-to-use guidance, no prerequisites, and no mention of the sibling get_email_preferences as the read alternative or of what happens when a preference is omitted. The only implied guidance is that at least one preference must be supplied, which the schema already enforces via minProperties: 1.

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

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

Annotations only declare readOnlyHint=false and destructiveHint=false; the description adds genuinely new behavioral facts: it returns immediately, returns a job ID, can be gated with structured reasons (backoff, coalescing, rate limit), and does not block for completion. This is exactly the async/gating context an agent needs and cannot get from annotations.

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

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

Three short sentences, zero filler, front-loaded with the core action followed by return semantics and the non-blocking caveat. Every sentence earns its place.

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

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

For a one-parameter mutation with no output schema, the description covers async semantics and gating reasons well. It stops short of stating how to follow up (e.g., poll via get_sync_run) or any permission prerequisites, so it is strong but not exhaustive.

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

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

Schema description coverage is 0%, so the description carries the burden, and it says nothing about syncId. The parameter is largely self-evident from its name and the schema supplies uuid format/pattern, so the gap is mild rather than severe, but no added semantics are provided.

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: 'Manually trigger a sync run.' This distinguishes it from config-oriented siblings like create_sync and state-control siblings like pause_sync/resume_sync. However, it never explicitly names an alternative, so an agent must infer the boundary itself.

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 word 'manually' implies usage in contrast to a scheduled/automatic run, giving implied context. But there is no explicit when-to-use, when-not, or named alternative (e.g., use list_sync_runs or get_sync_run to observe results), leaving routing 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?

Goes well beyond the destructiveHint=true annotation: documents provider-specific limits (eventType Google-only), specific error codes (EVENT_TYPE_NOT_SUPPORTED, DATETIME_ALLDAY_REQUIRED, DATETIME_TIMEZONE_WITHOUT_START), and the silent-drop failure mode it guards against. This is exactly the behavioral context an agent needs before 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?

Purpose is front-loaded, then the datetime contract, then the numbered patch rules — a logical order with no filler. The rule sentences are dense and pack multiple clauses each, which costs some readability.

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

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

For a mutation tool with no output schema, it covers the risky parts (datetime patching, provider divergence, rejection modes) thoroughly. It doesn't describe the success response or confirm whether unspecified fields are always preserved, but nothing critical for correct invocation is missing.

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

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

Schema coverage is 75%, and the description adds real meaning on top: the interplay of start/end/isAllDay, what happens when both are omitted, and why timezone fields without their datetime are rejected. Enum fields like visibility and reminders get no prose, so it's not fully exhaustive.

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 ('Update an existing event in place') and immediately clarifies the patch semantics ('Provide only the fields to change'). It also anchors the datetime contract to create_event, letting an agent place it against the create/update/delete family 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 clear use-case framing (partial patch on an existing event) and rules for edge cases, including the explicit rejection behaviors. It does not explicitly say when to prefer create_event or get_event instead, but the update-only framing makes the boundary reasonably clear.

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

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

Annotations only say readOnlyHint=false and destructiveHint=true; the description goes well beyond by disclosing the entitlement gate, the `wouldDelete`/`confirmDestructive:true` retry contract, the `ONE_WAY_SOURCE_SET_INVALID` mutual-exclusion error, and the 'omitting both preserves sources' default. These are exactly the behavioral traits annotations cannot convey.

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 tool's scope, and the parenthetical asides (back-compat note, error codes, 'N sources fanning into M targets') each add real signal. The opening sentence is dense with clauses and the block runs long, keeping it below 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 10-parameter, deeply nested mutation with no output schema, the description covers the risky and confusing parts an agent would otherwise get wrong. It is only incomplete on the unexplained `impactToken` and the unenumerated `settings.*` propagation fields.

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

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

With 0% schema description coverage the description must carry the load, and it does for the hard parameters: `enabled` maps to pause/resume, `calendars` is an end-state field, `direction`, `confirmDestructive`, and the array-vs-singular `oneWaySourceCalendarIds`/`oneWaySourceCalendarId` distinction with their rejection rule. It leaves `impactToken` and most `settings.*` fields unexplained, so it compensates well but not fully.

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 (update) and resource (sync) and then enumerates the exact editable surface: rename, pause/resume via `enabled`, propagation settings, `direction`, and the `calendars` end-state field. An agent can tell this apart from pause_sync/resume_sync/delete_sync 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?

Gives clear operational context: the dashboard-editor mental model, the entitlement prerequisite for `settings.directionalSettings`, and the two-call confirmation flow for destructive calendar removal. It stops short of explicitly naming alternatives (preview_sync_edit, pause_sync) or stating when not to use it, so it lands at 4 rather than 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?

Annotations already disclose that this is a non-destructive, idempotent, closed-world write, so the description doesn't need to restate safety. It adds that the operation is strictly a rename (not broader team settings), but says nothing about required permissions, whether omitted fields are preserved, or effects on members.

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

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

Two short sentences with the core action front-loaded and the alternative routing immediately after; 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, the description covers the action and the sibling boundary but leaves parameter roles and side effects unexplained. Annotations carry the safety profile, so the remaining gap is modest rather than severe.

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

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

Schema description coverage is 0%, so both 'name' and 'organizationId' are undocumented in structured data. 'Rename a Team' implies 'name' is the new team name, but the description never explains that 'organizationId' is the sole required parameter or what happens if 'name' is omitted.

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

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

States a specific verb and resource ('Rename a Team'), so the agent knows exactly what the tool mutates. It also implicitly narrows scope away from team domain management, which several sibling tools (request_team_auto_join_domain, remove_team_auto_join_domain) handle instead.

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 adjacent task ('add or remove auto-join domains') to the Team domain proof tools, giving a clear when-not-this-tool signal. It doesn't discuss siblings like update_team_member or update_team_invite, but the rename scope is unambiguous.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered. The description adds one genuine behavioral note (resend queues Mailer delivery, i.e. async), but does not disclose whether revoke is irreversible, what permissions are required, or that get_link is a read operation inside an otherwise destructive tool.

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

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

Two compact sentences with the operation set front-loaded and zero filler. No restatement of the title and no redundant prose.

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 moderate-complexity mutation tool with no output schema, the description identifies all three modes but omits prerequisites, permission needs, and reversibility of revoke. Annotations cover the destructive/safety profile, so the gaps are survivable but not complete.

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

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

Schema description coverage is 0%, so the description must carry the load. It only restates the action enum values (resend/revoke/get_link) and clarifies marginally what resend and get_link do, but says nothing about inviteId or organizationId, leaving two of three parameters undocumented in both schema and description.

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

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

The description states specific verbs and a specific resource: resend, revoke, or get the live acceptance link for a Team invitation. An agent can distinguish this from update_team and update_team_member by the 'invitation' resource. It does not explicitly name the sibling alternatives, keeping it just below a 5.

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

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

The three action values are enumerated, which implicitly tells the agent this tool has three operating modes, but there is no explicit guidance on when to choose each mode or when to prefer this tool over a sibling like invite_team_member. Usage is left to inference from the self-describing action names.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false and readOnlyHint=false, so the safety profile is covered. The description adds the precondition that the target must be an active member, which is useful, but it does not state permission requirements or whether admin promotion/removal 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?

A single efficient sentence with the key action front-loaded and no filler. Nothing is wasted, though the sentence is terse enough to leave meaning implicit.

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 3-parameter mutation with no output schema, the description covers the action space but omits prerequisites, permissions, and irreversibility. Annotations carry the safety signal, so the remaining gap is moderate rather than severe.

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

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

Schema description coverage is 0%, so the description carries the full burden. It maps the two enum values to intent ('make an admin' / 'remove'), which is marginally helpful since the enum names are already self-documenting, but it says nothing about organizationId or userId beyond their self-evident names.

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

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

States a specific verb+resource ('Make an active Team member an admin or remove a member from the Team'), covering both enum actions clearly. It is distinguishable from invite_team_member and update_team_invite by scoping to existing members, but it never names or contrasts those siblings explicitly.

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

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

The description implies a precondition ('active Team member') but gives no explicit when-to-use guidance, no alternatives, and no exclusions. An agent cannot tell from this text alone when to choose update_team_member over invite_team_member or update_team.

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