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

Annotations already declare a non-read-only, non-idempotent, open-world write; the description adds the crucial real-world consequence that actual calendar invites are sent and that user confirmation is required. It does not cover permission requirements, failure behavior on taken slots, or reschedule 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?

Two tightly written sentences with no filler; the core action comes first and the validity constraint and safety caution follow in priority order.

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?

Covers the action, the cross-tool prerequisite, and the side effect that matters most for a booking tool. Given annotations carry the safety profile and no output schema exists, the remaining gaps (conflict handling, returned event details) are minor.

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

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

Schema description coverage is 100%, so the baseline is 3; the description's constraint that start_at/end_at must exactly match a find_available_slots slot largely restates what the schema already says ('exactly as returned by find_available_slots'). No extra detail on time_zone, fields, or metadata beyond the schema.

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

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

States a specific verb and resource ('Book a meeting') plus the scope qualifier 'on a scheduling link for someone', which cleanly separates it from cancel_meeting and find_available_slots in the sibling list.

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

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

Explicitly names the prerequisite path — start_at/end_at must come from find_available_slots — and adds a caution to confirm details with the user first. It stops short of stating when not to use this tool or which alternative to pick if the slot is unavailable.

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 openWorldHint=true, so the safety profile is covered. The description adds real context beyond them: attendees are notified (an external side effect with open-world consequences) and the action cannot be undone, which reinforces but also concretizes the destructive hint.

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

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

Two short sentences with zero filler; the irreversibility and confirmation requirement are front-loaded where the agent will see them. Every clause earns its place.

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

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

For a two-parameter mutation with no output schema, the description covers the essential agent-facing facts: what happens to attendees, irreversibility, and the confirmation requirement. Minor gaps remain (permissions, recurring/series meetings), but nothing critical is missing.

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

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

Schema description coverage is 100%, with eventId pointing to list_events and cancel_reason documented as an optional attendee-visible reason. The description adds nothing about either parameter, so the schema does all the work and 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?

"Cancel a scheduled meeting" is a specific verb+resource that clearly distinguishes it from siblings like book_meeting, list_events, and get_event. It does not explicitly name an alternative, so it stops short of the 5 bar for sibling differentiation, but an agent can route to it unambiguously.

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

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

Gives an explicit precondition for invocation: "confirm with the user first" because the action is irreversible. It does not address alternatives (e.g., rescheduling vs. canceling, or handling recurring events), so it is clear context rather than full when/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 already declare this is a non-read-only, non-destructive, open-world operation, so the safety profile is covered. The description adds useful context about what the registered URL will receive, but omits behavior an agent would want: whether a signing secret is returned, whether re-registering the same URL is idempotent, and whether the endpoint is verified.

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, with zero filler. The parenthetical event examples earn their place by clarifying the trigger domain.

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

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

This is a simple one-parameter tool with annotations covering safety and no output schema to explain, so the description is nearly sufficient. The only meaningful gap is what happens after registration (secret, verification, duplicates), which an agent might reasonably expect for a webhook-creation tool.

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

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

There is a single parameter with 100% schema description coverage ('HTTPS endpoint URL'), so the schema already carries the parameter semantics. The description restates the URL's purpose but adds no format, constraint, or validation detail beyond what the schema provides, matching the baseline of 3 for high 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?

The description gives a specific verb ('Register') and resource ('a URL that receives SavvyCal event notifications') and even scopes the payload types (bookings, cancellations). It implicitly separates itself from list_webhooks and delete_webhook by describing creation, but 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?

Usage is only implied: an agent can infer you call this when you want outbound event notifications, and the examples ('bookings, cancellations') hint at triggering scenarios. There is no explicit when-to-use, no prerequisites (e.g. auth scope), and no mention of the sibling tools that read or remove webhooks.

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 without the description's help. The description adds only "by id" and says nothing about permanence, whether the webhook must exist, or failure behavior — extra context that would matter for a destructive operation.

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

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

A single short sentence with no filler and the operation front-loaded, which suits a one-parameter tool. It is arguably too terse rather than wasteful.

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

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

For a simple delete tool with annotations covering the destructive flag and no output schema, the definition is minimally sufficient. It still omits the one thing an agent would want for a destructive call: whether the deletion is permanent.

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 only supplies the weak hint "by id" for webhookId. It does not say where the id comes from (e.g., list_webhooks) or what form it takes.

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

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

States a specific verb and resource ("Delete a webhook") that cleanly separates it from create_webhook and list_webhooks in the sibling set. It does not explicitly name an alternative or describe the scope of the deletion, so it stops short of 5.

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

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

There is no guidance on when to call this versus list_webhooks or create_webhook, no prerequisites, and no warning about irreversible removal. The agent must infer usage entirely from the tool name.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered; the description adds useful behavior beyond that: results are grouped by day, rendered in readable local times, and the search window is capped at 31 days. It still doesn't mention pagination, rate limits, or what happens when no slots exist.

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

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

Two tight sentences with zero filler. The core purpose and output grouping are front-loaded, and the constraints and follow-up action come second.

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

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

For a read-only slot-lookup tool with a fully documented schema and no output schema, the description covers purpose, defaults, limits, and the downstream book_meeting handoff. The main remaining gap is return behavior in edge cases such as an empty slot 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?

Schema description coverage is 100%, so all six parameters are already documented in the schema, including the raw flag, ISO date formats, duration filter, and Olson time zone. The description largely restates the default window and local-time rendering already present in the schema, adding only the cross-tool note about reusing exact start_at/end_at.

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

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

States a specific verb and resource ('Find bookable time slots on a scheduling link') plus the output shape ('grouped by day with readable local times'). This is clearly distinguishable from siblings like list_events, get_scheduling_link, and book_meeting 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 the default window (next 7 days, max 31) so the agent knows behavior when no range is supplied, and explicitly routes the agent forward: 'Use the exact start_at/end_at of a slot when calling book_meeting.' It lacks an explicit when-not-to-use or a named alternative for listing events directly, but the workflow context is clear.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful context by naming the returned payload (name, email, time zone), which matters because no output schema exists; it stops short of noting auth-token requirements or the 'etc' fields.

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

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

A single front-loaded sentence with no filler. It says what it fetches and what comes back, then stops.

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 identity lookup with no output schema, the description gives enough to call it correctly and set expectations about the response. The trailing 'etc' leaves the full field set slightly under-specified, but nothing essential is missing.

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

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

The tool takes zero parameters, which is the baseline-4 case per the rubric. The description correctly implies a no-argument call and instead spends its words on the response shape, which is the only open question the schema cannot answer.

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 the authenticated SavvyCal user') and even enumerates the returned fields. No sibling tool retrieves the current user, so it is unambiguously distinguishable from list_events, get_event, and the rest.

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

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

Usage is implied by the name and the phrase 'authenticated user' — an agent knows this is for resolving the caller's own identity — but the description names no alternatives or conditions and never says when this is preferable to, say, get_event for identity 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 readOnlyHint and openWorldHint, so the safety profile is covered. The description adds real value by disclosing what the response contains (attendees, conferencing details, form answers), which matters since there is no output schema. It does not mention error behavior for an unknown eventId.

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 verb and resource, with the return contents appended for efficiency. Nothing redundant or 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 single-resource read with full schema coverage and read-only annotations, this covers what the agent needs; and with no output schema, naming the returned fields is a genuine addition. Only missing detail is failure behavior on a missing/invalid ID.

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

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

Schema description coverage is 100% and the single eventId parameter is documented as "Event ID or UUID (from list_events)". The description adds no format or sourcing detail beyond that, so the schema does all the work — the baseline 3 applies.

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

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

States a specific verb and resource ("Get one meeting") and enumerates the payload (attendees, conferencing details, form answers). The singular "one meeting" implicitly separates it from the list_events sibling, though that sibling is never named.

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

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

Usage is only implied: an agent can infer this is the by-ID lookup for a single meeting, and the schema's "from list_events" hints at the workflow. No explicit when-to-use, prerequisites, or alternatives (list_events, find_available_slots) are 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 and openWorldHint=true, so the safety profile is covered. The description adds the useful detail that the response includes settings and booking form fields, which matters because there is no output schema, but says nothing about failure modes (missing/invalid linkId) or permissions.

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; everything in it is informative given the absence of an output schema.

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

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

For a simple read-only single-record getter with complete schema coverage and annotations carrying the safety hints, the description is nearly sufficient, and its summary of the returned fields compensates for the missing output schema. Only error/boundary behavior is left unstated.

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

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

Schema coverage is 100% and the single linkId parameter is fully documented with a format example and a pointer to list_scheduling_links as the source. The description adds no parameter meaning beyond the schema, 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?

Specific verb (get) plus resource (scheduling link) and a note on what the payload contains (settings and booking form fields). The singular 'one' implicitly separates it from list_scheduling_links, but no sibling is named, so it stops short of a 5.

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

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

No statement of when to use this over get_event, list_scheduling_links, or find_available_slots, and no prerequisites called out. The only usage signal is the implied 'you need an ID to fetch one record,' which the agent must infer from the singular phrasing.

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 openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that: it does not mention pagination behavior (despite after/before cursors), default state/period behavior, or result ordering semantics, leaving the schema to carry the full behavioral burden.

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 before the filter list. Efficient, though the filter enumeration is a light restatement of the schema rather than new 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 10-parameter list tool with no output schema, the description covers the primary filtering concept but omits pagination flow and what a result contains. It is adequate but leaves meaningful gaps for an agent driving multi-page listing.

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 80%, so the baseline is 3. The description does add real meaning by clarifying that period takes upcoming/past/fixed and that a fixed period implies a date range, but it ignores attendance, limit, and the cursor parameters entirely.

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 scheduled meetings') and immediately names the filter axes, which separates it from single-event siblings like get_event. It does not explicitly distinguish itself from find_available_slots or list_scheduling_links, but the resource is unambiguous.

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

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

The description enumerates capabilities but gives no when-to-use guidance, no exclusions, and never names an alternative tool. An agent must infer from the name alone whether to reach for list_events versus find_available_slots or get_event.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds the user-scoping constraint ('the user's') and the shape of the returned records (id, name, slug, url, durations, state), which partially substitutes for the missing output schema, but says nothing about pagination or filtering 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 front-loaded sentence with the core purpose up front and the field enumeration in a compact parenthetical. No wasted prose, though the parenthetical is arguably filler given the schema already exposes the filterable state.

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 listing tool, the description covers scope and returned fields, which compensates for the absent output schema, and annotations cover the safety profile. It could still note that results are paginated and filterable via the state parameter to be fully self-contained.

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% (after/limit/before documented in-schema; state has only an enum), so the schema does most of the work. The description lists 'state' as a returned field but does not explain that the state parameter filters by active/disabled, nor does it add meaning to the cursor or limit parameters.

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

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

States a specific verb and resource ('List the user's scheduling links') and even enumerates the returned fields. It is distinguishable from get_scheduling_link (singular) only implicitly via the plural name, so it stops short of explicit sibling differentiation.

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

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

There is no when-to-use, when-not-to-use, or alternative guidance. Nothing tells the agent to prefer get_scheduling_link for a single link, or that this tool should be used for browsing/auditing the user's links; only the plural name implies listing semantics.

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 openWorldHint=true, so the safety and open-world profile is known. The description adds nothing beyond that: no pagination behavior, no scoping (user vs workspace), no volume or rate context.

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 waste. It is front-loaded, though its brevity borders on under-specification rather than true concision.

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-argument read-only list tool with annotations covering safety, the minimum is met, but with no output schema the description should say something about what is returned (e.g. all webhooks, scope, pagination). It leaves useful context on the table.

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 no parameter semantics burden; the baseline for 0 params is 4. The description does not mislead about inputs.

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 the verb (list) and resource (webhooks) plainly, so an agent knows it retrieves configured webhooks. However, it is essentially a restatement of the name/title and does not distinguish it beyond the obvious from create_webhook/delete_webhook siblings, nor does it describe 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 guidance on when to use this versus siblings, and no stated prerequisites or scope. The agent must infer that this is the read counterpart to create_webhook/delete_webhook purely from the name.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false. The description usefully signals flip semantics ('between active and disabled'), which matters since toggling twice reverts state and no target-state parameter exists — but it omits permission requirements and confirmation of the resulting state.

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

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

One short sentence, front-loaded with the action and resource, no filler or redundancy.

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

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

For a state-flipping mutation with no output schema and no way to specify a desired end state, the description should clarify that the caller must know the current state (or that the response reports the new state). Annotations cover safety, but this operational detail is missing.

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

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

Schema coverage is 100% and the single linkId parameter is fully documented in the schema, including its source (list_scheduling_links). The description adds nothing about the parameter, so the schema does all the work — baseline 3.

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

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

States a specific verb (toggle) and resource (scheduling link) plus the two resulting states (active/disabled). It's clearly distinguishable from siblings like get_scheduling_link or list_scheduling_links, though it doesn't explicitly name them.

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

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

No when-to-use guidance, no preconditions, and no mention of alternatives such as get_scheduling_link for checking current state before toggling. The agent must infer that this is the write counterpart to the read siblings.

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