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

Annotations already provide idempotent and non-destructive hints. Description adds that an org-level API key is required, which is a key behavioral constraint not in annotations. Does not detail side effects or error handling.

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, no filler. Front-loaded with action, condition, and key requirement. Ideal length and structure.

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 trigger, required auth, and parameter source. Lacks detail on return value or failure cases, but for a simple idempotent action, it is largely 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?

Only parameter tos_version is described in both schema and description. Description adds practical guidance on how to obtain the value (GET /v1/auth/terms/current), enhancing beyond schema's basic 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?

Clearly states the action: re-accept Chronary ToS on behalf of the calling org. Distinguishes from sibling tools which are unrelated CRUD operations. Includes trigger condition and required parameter.

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

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

Explicitly says when to use (when Chronary-Terms-Upgrade-Required header is present) and mentions that agent-scoped keys cannot be used. Provides clear context but does not name alternatives, though none exist in sibling list.

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 genuine value beyond that by specifying what is destroyed (the setup URL) and what is unaffected (a completed Google/Microsoft connection), clarifying the blast radius.

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 the primary action front-loaded and the disambiguation clause second. Every clause earns its place with zero filler.

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

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

For a single-parameter cancel tool whose annotations carry the safety/idempotency profile and with no output schema to describe, the definition covers action, scope, and side effects fully. Nothing an agent needs to call it correctly is missing.

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

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

There is a single parameter with 100% schema coverage, including a format/pattern constraint, so the schema does the heavy lifting. The description adds no additional meaning about the connection_link_id (e.g., source or lifecycle), 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 (cancel) and resource (pending human-calendar setup request / connection link), and explicitly contrasts with what it does not do. An agent can distinguish it from create_connection_link and get_connection_link 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?

Clearly scopes usage to *pending* setup requests and adds a useful exclusion ('does not disconnect an already completed Google or Microsoft connection'), which prevents misuse. It stops short of naming an explicit alternative tool for disconnecting an existing connection, so it is not a full 5.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, yet the description adds real behavioral substance beyond them: the event is marked cancelled (a soft cancel) and excluded from future availability calculations, and recurring-series cancellation is scoped by occurrence_start. It also explains the optional calendar_id as a fail-fast guard against cross-calendar typos, which is useful operational 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?

Four sentences, each carrying distinct information (purpose, post-condition, recurring scope, optional param rationale), and the core purpose is front-loaded. Slight redundancy in the 'remove, cancel, or delete' triple, but nothing is wasted.

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

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

With no output schema, the description adequately covers side effects (marked cancelled, removed from availability), the recurring variant, and the optional-parameter tradeoff. It does not address downstream effects such as attendee notifications or whether confirmed events can be cancelled, which is 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 100% so the baseline is 3, but the description adds the omit-case semantics for occurrence_start ('omit it to cancel the whole series') that the schema only implies, plus the resolution behavior and rationale for calendar_id. This meaningfully supplements rather than repeats 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 (delete/cancel) and resource (calendar event) and immediately gives alias terms so an agent can map varied user phrasing onto it. It does not explicitly differentiate itself from related lifecycle siblings like confirm_event or release_event, but no sibling overlaps the cancel/delete semantics, so the purpose 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?

Gives clear usage context ('remove, cancel, or delete any scheduled event or appointment') and an explicit decision rule for the recurring case: pass occurrence_start to cancel one occurrence, omit it to cancel the series. It stops short of when-not-to-use or naming alternatives, so it is strong but not exhaustive.

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 explicitly mentions the webhook firing, which adds value beyond the annotations (destructiveHint=true, idempotentHint=true). No contradiction with 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 concise sentences with front-loaded purpose, no 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?

Given a single parameter, no output schema, and annotations, the description adequately covers webhook behavior, auth requirements, and plan restrictions. Minor gap: no mention of error conditions or irreversible nature.

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% with a description for 'proposal_id'. The tool description adds no additional meaning beyond what the schema provides, justifying the baseline score of 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?

The description clearly states the verb 'cancel' and the resource 'open proposal', making it distinct from sibling tools like 'cancel_event', 'resolve_proposal', and 'respond_to_proposal'.

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 prerequisites (org-level API key, Pro plan) but does not specify when to use this tool versus alternatives, such as 'resolve_proposal' for rejecting a proposal.

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 provide destructiveHint=true and idempotentHint=true. The description adds value by specifying the default state after clearing ('no buffers, no working-hours mask') and the potential error condition. No contradiction with 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 sentences, no wasted words. First sentence states the action and effect, second sentence clarifies return behavior. Front-loaded and efficient.

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 tool with one parameter, no output schema, and adequate annotations, the description provides complete context: what it does, what the result is, and what happens to defaults.

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% for the single parameter calendar_id. The description does not add additional semantics beyond the schema. Baseline score of 3 is appropriate.

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

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

The description clearly states the action ('Remove the availability rules from a calendar'), the effect ('reverting to the default'), and the return value ('Returns the deleted row'). It distinguishes from sibling tool set_availability_rules by focusing on removal.

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 context (use when you want to clear rules) but does not explicitly state when to use this tool vs alternatives like set_availability_rules or get_availability_rules. No prerequisites or exclusions are mentioned.

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

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

The description adds behavioral context beyond annotations, such as the requirement for 'hold' status and the firing of lifecycle webhooks. Annotations already indicate idempotent and non-destructive, and description aligns without contradictions.

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 concise with two sentences, no extraneous words, and front-loads the primary action. Every sentence adds necessary value.

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

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

The description covers preconditions, the mutation effect, and webhook behavior. It is adequate for a simple tool with one parameter and no output schema. Missing error or success details, but acceptable.

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

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

The single parameter 'event_id' is fully described in the schema (100% coverage). The description does not add further semantics for the parameter itself, but the overall tool description provides context for its usage.

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

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

The description clearly states the action ('promote a held event to a confirmed booking') and the resource. It distinguishes from siblings like cancel_event or release_event by specifying the 'hold' status requirement.

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 explicit conditions for use: event must have status='hold' and hold_expires_at not passed. It does not explicitly state when not to use or mention alternative tools, but the conditions are clear enough for proper selection.

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

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

Annotations show readOnlyHint=false, so the tool modifies state. Description adds that the agent can own calendars, events, webhooks, but no additional behavioral details like permissions or conflict handling. Annotations already cover safety profile.

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?

Single sentence, no wasted words, front-loaded with the key verb and 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?

Given no output schema, description briefly explains purpose and ownership. Missing mention of return value or error cases, but adequate for a simple creation tool.

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

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

Schema covers 100% of parameters with descriptions. Description adds no extra meaning beyond the schema, so 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?

Description clearly states the tool registers an agent (AI/human/resource) to own calendars, events, and webhooks. The verb 'register' and resource 'agent' are specific, and it distinguishes from sibling tools like update_agent or list_agents.

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?

Description implies use when a new agent needs to be registered to own resources. It provides clear context but does not explicitly state when not to use or mention alternative 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?

Beyond the annotations (readOnlyHint=false, etc.), the description explains the booking flow: returns a booking_url, confirmed event creation on the calendar, webhook firing with booking_page_id, and that existing events always block slots. This adds significant behavioral context not covered by 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 three sentences, clearly front-loaded with the purpose. Every sentence adds essential information (what it creates, what it returns, how it works, a key constraint). No unnecessary 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?

Given the complexity (10 parameters, no output schema, no nested objects), the description covers the core functionality, output, and critical constraint. The schema covers parameter details, so the description is complete for the tool's purpose.

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

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

Schema coverage is 100%, so baseline is 3. The description adds some context about availability_constraints and the overall behavior, but does not add meaning to individual parameters beyond what the schema already provides. The return value is explained, which helps, but for parameter-specific semantics it is adequate.

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 starts with a clear verb and resource: 'Create a public booking page... for a calendar.' It distinguishes itself from related tools like create_event (creates single event) and create_proposal (scheduling proposals) by specifying it creates a hosted scheduling link. The return value (booking_url) is also mentioned.

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 states when to use the tool: to create a booking page for a calendar. It also provides context about availability_constraints and how existing events block slots. However, it does not explicitly mention when not to use it or provide alternatives, though sibling context makes this clear enough.

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 indicate readOnlyHint=false and destructiveHint=false, meaning this is a mutating non-destructive operation. The description adds context about calendar ownership and sharing, but does not disclose specific behaviors like duplicate name handling or validation errors. It is adequate but not deeply transparent.

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

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

The description is two sentences long, each earning its place: first states purpose, second gives usage guidance, and the third adds important context about multiple calendars and org-level use. It is front-loaded, efficient, and contains no 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?

Given no output schema, the description does not mention return values, which is a minor gap. However, it covers prerequisites, usage scenarios, and parameter context, making it sufficiently complete for an agent to decide when and how to invoke the tool.

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

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

Schema coverage is 100%, so parameters are documented. The description adds meaning beyond schema by explaining the purpose of agent_id (omit for org-level) and the concept of multiple calendars. This helps the agent understand the parameter roles beyond their 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 clearly states 'Create a calendar to hold events and track availability.' It identifies the specific resource (calendar) and action (create), and distinguishes from sibling tools like update_calendar or delete_calendar by explaining that calendars are prerequisites for events.

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

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

The description provides explicit guidance: 'Calendars are required before creating events — call this first when setting up a new agent.' It also notes that agents can have multiple calendars and org-level calendars can be shared resources. It does not explicitly state when not to use it or mention alternatives, but the context is clear for correct invocation.

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, openWorldHint=true, idempotentHint=false, destructiveHint=false), the description discloses that OAuth credentials, provider calendar names, and event data never reach the agent, and that the secret URL is returned only on first creation. That is substantive behavioral context about an inherently stateful, non-idempotent handoff.

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

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

The purpose is front-loaded and each sentence carries load (handoff rule, credential boundary, reuse fallback). The final reuse sentence is dense and depends on output field names not defined in the schema, slightly hurting 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?

With no output schema, the description usefully covers the key return semantics (setup_url only on first creation) and the credential boundary, which is what an agent needs to act. It leaves the exact shape of the response and the meaning of reused less explicit than ideal.

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 calendar_id, capabilities, and publication_policy are already fully documented, making 3 the baseline. The description references reused and setup_url, which are response-side fields rather than input parameters, so it adds little meaning to the actual arguments.

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 and resource: requesting human OAuth setup of Google Calendar or Microsoft Outlook for a Chronary calendar, producing a setup link. An agent can distinguish it from get_connection_link and cancel_connection_link, which retrieve or destroy the same resource.

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

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

It clearly instructs the agent to give setup_url to a human and that the agent never receives credentials, and it specifies the reuse branch (reused=true with null setup_url → retain or cancel and recreate). It stops short of explicitly naming the sibling tools (get/cancel_connection_link) as alternatives.

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 write, non-idempotent, non-destructive. The description adds substantive behavior beyond that: the event blocks the agent's availability and surfaces in availability queries, and holds auto-release on their TTL. No auth or rate-limit detail, but the side-effect disclosure is the important part.

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

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

Three tight sentences, purpose front-loaded, followed by the sourcing constraint and then the hold pattern. Every sentence adds information with no filler.

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

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

For an 11-parameter mutation tool with no output schema, the description covers purpose, key side effects, the hold workflow, and the source of the required calendar_id while the schema handles all field-level detail. Nothing essential to invoking it correctly is missing.

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

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

Schema coverage is 100%, so the schema already documents all 11 parameters in depth (status, hold_priority, hold_expires_at, recurrence_rule, reminders). The description only reinforces the hold/TTL pairing and the calendar_id source, which the schema does not cover, so baseline 3 is right.

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 booking, appointment, meeting, hold, or any scheduled event on a calendar') and enumerates the concrete use cases it covers. An agent can immediately distinguish this from siblings like create_calendar, update_event, or create_proposal.

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

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

Gives clear context for the hold workflow ('Use status="hold" with hold_expires_at to tentatively reserve a slot') and tells the agent where calendar_id originates (create_calendar or list_events). It does not, however, state exclusions or when to prefer confirm_event/release_event/update_event over creating.

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 mark it as a non-read-only, non-idempotent, non-destructive write, but the description adds real behavioral value: the auto-resolution rule once all participants respond, the cancellation-on-full-decline path, and the org-level-API-key/Pro-plan requirements. These are the kind of side effects and auth constraints annotations don't 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?

Three tight sentences, front-loaded with the core action and followed by behavioral and requirement details. No filler, and each sentence carries distinct information.

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

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

For a write tool with a fully documented 7-parameter schema and no output schema, the description covers purpose, resolution behavior, and access requirements completely. 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 coverage is 100%, so every parameter including nested slot fields is fully documented in the schema and the baseline is 3. The description only echoes 'candidate time slots' and the scoring concept, adding no format or constraint detail 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 (Create) and resource (scheduling proposal), then defines the mechanism — sending candidate slots to participant agents for accept/decline/counter-propose. This clearly distinguishes it from siblings like respond_to_proposal, resolve_proposal, and cancel_proposal.

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?

Describes the full lifecycle (auto-resolves to highest-scoring slot, cancels if all decline) and the prerequisites (org-level API key, Pro plan), which tells an agent when this is the right entry point. It stops short of explicitly naming siblings to use for responding or resolving, so it loses the top score for lack of explicit alternatives.

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 (which show this is a non-read, non-destructive, non-idempotent mutation), the description adds critical behavior: the plaintext key is returned exactly once and cannot be retrieved later. This is essential for the agent to handle the response correctly. No contradiction with 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 three concise sentences with no wasted words. Each sentence adds value: purpose, usage context, and critical behavioral warning. Front-loaded with the key fact about the prefix and scoping.

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 covers all necessary context: what the tool does, when to use it, prerequisites, behavior of the return value (plaintext key once), and that it cannot be retrieved later. With no output schema, the description adequately explains the return behavior. The sibling tools provide additional context for lifecycle management.

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?

Both parameters (label and agent_id) are fully documented in the input schema with descriptions and constraints. The description does not add any additional semantic meaning beyond what the schema provides. Schema coverage is 100%, so 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 clearly states the tool creates an agent-scoped API key with a specific prefix (chr_ak_*). It highlights the key can only act on behalf of a single agent, which distinguishes it from other key-related tools like list_scoped_keys and revoke_scoped_key.

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 explicitly tells when to use this tool (self-provision or rotate per-agent credentials) and includes a crucial prerequisite (requires an org-level API key). It lacks explicit when-not-to-use guidance, but the sibling tools cover alternate operations like revocation and listing.

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

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

The description reveals that the signing secret is returned only once and must be stored for HMAC-SHA256 verification, which is critical behavioral information beyond the annotations. It also implicitly confirms the tool is not read-only (readOnlyHint=false) and not idempotent. No contradiction with 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 three sentences: first states purpose, second adds crucial behavioral detail about the signing secret, third states a prerequisite. Every sentence is valuable and front-loaded, with no 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?

The description covers input behavior and prerequisites well, and mentions the signing secret in the response. However, without an output schema, it could further describe the full response structure (e.g., webhook ID, status) to fully inform the agent.

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

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

Schema description coverage is 100%, so the baseline is 3. The description repeats the schema's parameter descriptions almost verbatim for url and events, adding no new semantic meaning. The behavioral hint about the signing secret is valuable but not about 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?

The description clearly states it creates a webhook subscription for HTTP POST notifications, and specifies example events like event.created, proposal.confirmed. It effectively distinguishes from sibling tools like delete_webhook and list_webhooks by focusing on creation.

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

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

The description explains the purpose (receiving notifications) and includes a prerequisite ('Requires an org-level API key'). However, it does not explicitly state when not to use this tool or suggest alternatives, though the context of creation is clear among 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?

Description adds detail beyond annotations: explains that decommissioning revokes scoped API keys. No contradiction with annotations (destructiveHint=true, idempotentHint=true).

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 efficient sentences, no redundant information. Front-loaded with action and consequence.

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 single parameter, full schema coverage, and annotations, the description is complete. No output schema needed; behavioral effects are clear.

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 provides 100% coverage for parameter agent_id. Description does not add extra semantic meaning beyond what schema already states.

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?

Clearly states 'Decommission an agent' with specific verb and resource. Differentiates from sibling tools like create_agent and update_agent.

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 key requirement ('Requires an org-level API key') and a prohibition ('agent-scoped keys cannot delete agents'). Does not provide explicit alternatives, but 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 mark destructiveHint=true. Description adds that deactivation is not truly destructive to events, and URL stops resolving. No contradiction with 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 sentences with no wasted words. Action and effects stated upfront. Highly concise.

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 tool with one parameter and no output schema, description covers purpose and behavioral effects. Could optionally mention return value or confirmation, but not required.

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?

Single parameter 'booking_page_id' is fully described in schema (100% coverage). Description adds no additional semantic detail beyond what schema provides. Baseline score of 3 is appropriate.

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

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

Clear verb 'Delete (deactivate)' specifies action on 'booking page'. Includes effect on URL and unaffected events. Distinct from siblings like create_booking_page or get_booking_page.

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?

Describes the effect (URL stops resolving, existing events unaffected) but does not explicitly state when to use this vs alternatives (e.g., updating status) or any prerequisites.

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

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

Adds significant value beyond annotations: reveals soft delete nature, event unavailability, availability impact, and permission restriction. Annotations already indicate destructive and idempotent; description enriches with specific behavioral details.

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

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

Two sentences, no unnecessary words, front-loaded with key information. Highly efficient.

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 core delete behavior, consequences, and permission constraint. Lacks error scenarios or what happens if calendar doesn't exist, but for a simple tool with no output schema, this is mostly 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 coverage is 100% with a clear description for calendar_id. The tool description does not add extra semantics beyond what the schema provides, so 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 clearly states it deletes a calendar, specifies soft delete, explains consequences (events no longer returned, availability stops), and mentions permission nuance. Distinguishes from sibling delete tools by targeting calendar resource.

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

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

The description implies use when needing to remove a calendar, with soft delete behavior noted. Does not explicitly state when not to use or mention alternatives, but the context of a delete operation is clear enough.

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 indicate destructiveHint=true and idempotentHint=true. The description adds context that synced events are no longer refreshed, clarifying the side effect. However, it does not explicitly state that events themselves are not deleted, which may be inferred but is not fully transparent.

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 wasted words. The first sentence states the primary action, and the second adds important behavioral context. Perfectly front-loaded and concise.

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 delete operation with one parameter and no output schema, the description adequately explains the effect on synced events. Could mention that events remain but are static, but overall sufficient given the tool's simplicity.

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 description does not add information beyond what the schema provides for the subscription_id parameter. The baseline of 3 is appropriate as the schema already documents the parameter adequately.

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

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

Description clearly states the action 'Delete an external iCal feed subscription' and the consequence 'Events previously synced from the feed are no longer refreshed.' This distinguishes it from sibling tools like subscribe_ical or update_ical_subscription.

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 does not explicitly state when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. It implicitly suggests usage for removing subscriptions, but lacks guidance on not using it if events should be deleted 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 mark destructiveHint=true and readOnlyHint=false. The description adds behavioral context: the deletion is permanent, frees an endpoint slot, and requires an org-level API key. This goes beyond annotations, though it could detail cascading effects or irreversibility further.

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

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

The description is two sentences, efficiently front-loading the action and adding a contextual benefit. No unnecessary 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?

For a simple delete tool with one parameter and no output schema, the description covers purpose, permissions, and side effect. It could mention success/failure implications, but given the tool's simplicity, it is adequate.

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% for the single parameter webhook_id, which the schema describes as 'Webhook subscription to delete'. The description does not add additional meaning beyond what the schema provides.

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

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

The description clearly states the tool permanently deletes a webhook subscription, with the specific side effect of freeing an endpoint slot against the per-plan cap. Among siblings like create_webhook, update_webhook, list_webhooks, it is uniquely identified as the deletion action.

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 explicitly notes when to use (to delete a webhook and free a slot) and the prerequisite of an org-level API key. It does not explicitly state when not to use or mention alternatives, but the 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 cover the safety profile (readOnly, idempotent, non-destructive), so the description earns credit for the extra behavioral disclosure that it is fail-closed and that availability_state/warnings must be checked before trusting slots. This is genuinely useful and not redundant, though it stops short of explaining what fail-closed actually looks like 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?

Three short sentences, front-loaded with purpose, then the fail-closed caveat, then input aliases. Nothing is padded, though the trailing alias sentence is close to redundant with the schema and could be dropped.

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 of the return-value burden by naming availability_state and warnings, and 100% schema coverage handles the ten parameters. It is complete enough to invoke correctly, but a reader still has no picture of the actual slot payload returned.

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

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

Schema description coverage is 100%, so every parameter including the aliases and the deprecated slot_duration is already documented in the schema; the baseline is 3. The description adds only a light signal that agents/start/end are the core inputs, and its alias sentence largely repeats what the schema already says.

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 ('Find slots when multiple agents are free') and scopes the data sources (Chronary calendars plus each agent's authorized human calendars). The multi-agent scope implicitly separates it from the single-target get_availability sibling, but no sibling is named, so the 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?

It gives clear operating context: use it to find common free time across several agents, and 'always inspect availability_state and warnings before using slots'. It never states when NOT to use it or which sibling (e.g. get_availability, create_proposal) to prefer instead, 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 readOnlyHint=true and idempotentHint=true, so the description adds value by noting that agent-scoped API keys may only read their own agent. This is useful behavioral context beyond what annotations provide. No contradiction.

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 efficient sentences. The first states the core action, the second provides additional context. No wasted words, front-loaded with the main purpose.

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 low complexity (1 param, no output schema) and the presence of annotations, the description is mostly complete. It covers the action, parameter, and a security nuance. However, it doesn't describe the return format, which could be inferred from context but is a minor gap.

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

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

The input schema has 100% coverage with a description for the single parameter ('Agent ID to fetch'). The tool description does not add extra meaning beyond 'by ID' and what the schema already says, so a baseline score of 3 is appropriate.

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

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

The description explicitly says 'Fetch a single agent by ID', a specific verb+resource. It also clarifies what an agent represents (AI assistant, human, shared resource), distinguishing it from list_agents and create_agent. This is clear and precise.

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 usage for fetching a single agent by ID and adds a constraint about scoped API keys. However, it does not explicitly state when to avoid this tool (e.g., for multiple agents use list_agents). That said, the context is adequate for an agent to decide.

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, so the bar is lower, yet the description adds real value: results are clamped to the plan's retention window, event ordering, and an auth constraint that isn't derivable from annotations. It stops short of describing pagination or return shape.

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

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

Two sentences, no filler, with the resource/scope front-loaded and the auth constraint placed last as a gating condition. 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 read-only list tool with no output schema, it covers scope, ordering, retention clamping, and auth requirements. It could say more about the response shape or pagination, but nothing an agent needs 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 100%, so from/to/limit/action/cursor/actor_key_prefix are already documented. The description only reinforces the retention-clamping behavior already noted in the 'from' param description, adding no new parameter 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 (List) and resource (audit-log entries), scoped to 'the calling org', and enumerates the content (mutating operations and auth-lifecycle events) plus ordering (newest first). No sibling covers audit logging, so the agent can distinguish this immediately.

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 concrete usage precondition: it requires an org-level API key (chr_sk_*) and explicitly excludes agent-scoped keys. That is strong when/when-not guidance, though it names no alternative tool for the agent-scoped case.

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/closed-world, so the safety profile is covered. The description adds genuinely new behavior: the tool is fail-closed and callers must check availability_state and warnings before trusting slots — meaningful context about partial/uncertain results that annotations cannot express.

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

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

Three tight sentences, front-loaded with the purpose and scope, then the fail-closed warning, then the alias note. The alias sentence duplicates schema content slightly, but 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?

With no output schema, the description usefully names the two fields an agent must inspect (availability_state, warnings), partially compensating for the missing return spec. It does not explain include_busy's effect on the response or result-size/pagination behavior, which are the remaining gaps for an 8-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 100%, so all 8 parameters are already documented in the schema, including the start/end vs start_time/end_time aliases and the duration vs deprecated slot_duration preference. The description restates the alias fact but adds no format, constraint, or default detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb ('Check when ... is free') plus resource scope ('a single agent', across 'its Chronary calendars and any human calendars authorized for that agent'). This distinguishes it from get_availability_rules (configuration) and find_meeting_time (multi-party search), though it never names those siblings explicitly.

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

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

Gives a consumption rule ('fail-closed: always inspect availability_state and warnings before using slots') but no when-to-use/when-not guidance relative to get_availability_rules or find_meeting_time. Usage is implied by the purpose rather than routed.

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, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds that it 'Returns the rules row, or an error if none are set', providing useful behavioral detail about the error case. No contradictions.

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 concise with two sentences that front-load the primary action. It is efficient and avoids unnecessary words, though it could be slightly more structured.

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 low complexity (one parameter, no output schema), the description is adequate. It explains the purpose and a possible outcome (error). While it doesn't detail the return format, the lack of an output schema makes that acceptable.

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% with one parameter 'calendar_id' described as 'Calendar to read'. The description does not add additional meaning beyond the schema, so a baseline score of 3 is appropriate.

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

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

The description clearly states the verb 'Read' and the specific resource 'buffer times and working-hours rules configured on a calendar'. It distinguishes from sibling tools like 'set_availability_rules' and 'clear_availability_rules' by indicating it is a read operation.

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 that this tool should be used to retrieve availability rules, providing clear context. However, it does not explicitly state when not to use it or mention alternatives like 'get_calendar', but the purpose is sufficiently 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 idempotentHint=true, so the description adds the context that it returns public booking_url and settings. This is useful but minimal additional behavioral disclosure beyond 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?

Description is a single concise sentence that front-loads the key information. 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?

For a simple read-only fetch tool with one parameter and clear annotations, the description is sufficient. Not having an output schema is acceptable given the simplicity; the description mentions what is included in the result.

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

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

Schema description coverage is 100% for the single parameter, and the schema description is clear. The tool description adds no additional detail about the parameter beyond what the schema provides.

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

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

Description clearly states verb 'Fetch' and resource 'single booking page', and specifies what is included ('public booking_url and settings'). It distinguishes from sibling tools like list_booking_pages (list vs single) and create_booking_page (create vs 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?

The description does not explicitly state when to use this tool vs alternatives. While the purpose is clear, there is no guidance on when not to use or comparison with similar tools like list_booking_pages.

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, and destructiveHint=false, indicating a safe read operation. The description adds the important behavioral context of agent-scoped key restrictions, which is beyond what annotations provide.

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

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

The description is two sentences long, front-loads the primary purpose, and includes a necessary constraint without any wasted words. 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 simple fetch-by-ID tool with one parameter, strong annotations, and no output schema, the description provides sufficient context. It mentions the fields returned and the key restriction. A minor gap is the lack of error behavior if the calendar is not found, but this is not 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?

The schema has 100% coverage for the single parameter calendar_id, with a description that simply states 'Calendar ID to fetch'. The tool description does not add any additional meaning or format details beyond the schema, so it meets the baseline but does not exceed it.

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

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

The description uses a specific verb 'Fetch' and clearly identifies the resource as a single calendar by ID. It distinguishes from sibling tools like list_calendars and get_calendar_context by specifying it fetches one calendar with details like name, timezone, agent status, and default reminders.

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 a clear constraint: agent-scoped keys can only read calendars owned by their agent. While it does not explicitly list alternatives or when not to use, the context is clear enough for an agent to differentiate 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, idempotentHint=true, destructiveHint=false. The description adds detailed behavioral context about what exactly is returned (current event, next, past, upcoming, agent status), which goes beyond 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 efficient sentences: first lists what the tool returns, second provides the use case. No superfluous text, front-loaded with purpose.

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 context tool with one parameter and no output schema, the description fully explains the returned data and use case. No gaps remain.

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% for the single parameter calendar_id with a basic description. The tool description does not add further parameter semantics, but baseline is 3 as schema already covers it adequately.

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

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

The description clearly states the tool retrieves a calendar's temporal context including current event, next event, past events, upcoming window, and agent status. It uses a specific verb 'Get' and resource 'calendar's temporal context', and distinguishes from siblings by noting it avoids multiple list_events queries.

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

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

Explicitly tells when to use the tool: 'to answer what is this agent doing right now?' and mentions the alternative (multiple list_events queries) indicating when not to use 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 cover the safety profile (readOnly, idempotent, non-destructive, closed world), so the description is freed to add non-obvious behavior. It does: it discloses that the bearer setup URL is never replayed and human calendar data is never exposed, which is a meaningful security constraint an agent could not infer. It doesn't state what status values look like or terminal vs pending states.

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

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

A single dense sentence, front-loaded with the action, followed by the return/behavior caveats. No filler and nothing 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?

With no output schema present, the description correctly carries the return-value burden, describing status plus resulting connection ID and ruling out the setup URL and calendar data. It could go further by enumerating possible status values, but combined with the annotations it is largely 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 coverage is 100%, with connection_link_id fully documented including its prefix pattern, so the schema carries the parameter burden and baseline is 3. The description notes the ID relates to a 'connection' but adds no format or sourcing detail 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: 'Poll a human-calendar setup request.' The polling verb cleanly distinguishes it from create_connection_link and cancel_connection_link, which are the lifecycle siblings. It stops short of naming those siblings explicitly, so it lands at 4 rather than 5.

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

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

'Poll' implies the tool is for repeatedly checking an in-flight setup, which is useful implied usage. However, there is no explicit when-to-use versus create_connection_link/cancel_connection_link guidance and no stated precondition that a connection_link_id must already exist from create_connection_link.

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 indicate read-only and non-destructive. Description adds context: works for both internal and externally synced iCal events, calendar resolution behavior, which goes beyond 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 sentences, no fluff, well-structured with purpose first then auxiliary info about calendar_id. Every sentence adds value.

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

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

Given no output schema, description adequately explains what fields are returned, supports both event types, and addresses calendar_id optionality. Complete for a read-only retrieval tool.

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

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

Schema coverage is 100% with descriptions. Description adds meaning: event_id is the identifier to retrieve, calendar_id optional with behavioral note on fast failure for cross-calendar typos.

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?

Description clearly states 'Retrieve a single event by ID' and lists included fields (title, times, status, location, reminders, metadata). Differentiates from sibling tools like list_events (which retrieves multiple) and other get_* tools.

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

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

Provides guidance on calendar_id: optional with fallback resolution, use to fail fast on typos. Does not explicitly compare to list_events for filtering, but context is clear for single-event retrieval.

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 idempotentHint=true. The description adds value by specifying the returned fields (sync status, last sync time, last error), beyond what annotations provide. However, it does not disclose any additional behavioral traits like defaults or caching.

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 sentence that efficiently conveys all necessary information without waste. Every word adds value.

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

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

For a simple get tool with one parameter and comprehensive annotations, the description is complete. It specifies what the tool does and what it returns, leaving no gaps for the agent.

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

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

The input schema covers 100% of parameters with a description for subscription_id. The description does not add meaning beyond what the schema already provides, so baseline score of 3 is appropriate.

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

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

Description clearly states the action (Get), the resource (single external iCal feed subscription), and what is included (sync status, last sync time, last error). This distinguishes it from sibling tool list_ical_subscriptions, which returns all subscriptions without detailed sync info.

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 usage when needing details of a specific subscription, but does not explicitly state when not to use it or mention alternative tools. The context is clear but lacks exclusionary 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 indicate read-only and idempotent behavior. Description adds useful context: requires org-level API key and details response content (slots, responses). No contradictions.

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 concise sentences, front-loaded with core purpose, followed by a necessary prerequisite. No fluff.

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 get tool with a single parameter and no output schema, the description adequately explains purpose, auth, and return content. Could mention potential errors or pagination for slots, but not essential.

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% for one parameter. Description adds no additional meaning to the parameter beyond what the schema provides, so baseline score of 3 is appropriate.

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

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

Description clearly states 'Get a scheduling proposal by id' with specific verb and resource, and adds what is included (slots, responses). Distinguishes from sibling list_proposals and other get tools.

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

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

Description mentions auth requirement but provides no explicit guidance on when to use this tool vs alternatives like list_proposals or get_event. Usage context is 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 declare readOnlyHint, idempotentHint, and destructiveHint. The description adds authentication requirements and mentions the return type (usage and plan limits), providing additional behavioral context without contradicting 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 sentence that efficiently conveys the tool's purpose, scope, and authentication requirements. Every piece of information is relevant, with 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 tool has no output schema, but the description sufficiently indicates it returns usage and plan limits. For a read-only tool with no parameters, the description is fairly complete, though lacking detail on output 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?

The input schema has zero parameters with 100% schema description coverage. The description doesn't need to add parameter info, meeting the baseline for no-parameter tools.

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 explicitly states 'Get the calling org's current-period usage and plan limits' and lists specific metrics, clearly defining the tool's purpose. It distinguishes itself from siblings that operate on individual resources.

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 clear context: it retrieves org-wide usage and requires an org-level API key. It warns that agent-scoped keys cannot use this tool, offering usage guidance, though it does not explicitly name alternative 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, destructiveHint, idempotentHint. The description adds valuable behavioral context beyond annotations: 'The signing secret is never returned' and auth requirement. No contradiction with 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 concise sentences. The first sentence front-loads the core functionality, and the second adds critical behavioral info. 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?

Given the tool's simplicity (1 param, no output schema), the description covers the return content, hidden behavior (signing secret), and auth requirement. Could be slightly more explicit about the return format, but overall 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?

The single parameter 'webhook_id' is fully described in the schema with a description. The tool description adds no additional parameter semantics beyond what the schema provides. Baseline score of 3 is appropriate given 100% schema 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 clearly specifies the verb 'get', resource 'webhook subscription', and includes what is returned ('subscribed event types and active state'). This distinguishes it from sibling tools like 'list_webhooks' and 'create_webhook'.

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 a prerequisite ('Requires an org-level API key') but does not explicitly state when to use this tool versus alternatives (e.g., 'list_webhooks') or when not to use it. The usage context is implied by the tool's 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 provide readOnlyHint=true and idempotentHint=true, so description's burden is lower. It adds the scope 'in your organization', which is helpful context beyond the annotations. No contradictions.

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?

Single sentence of 6 words with no unnecessary information. Every word contributes meaning.

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

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

For a simple read-only list tool with full parameter descriptions in schema and safety annotations provided, the description is sufficient. No output schema needed; return value is implied. Complete for the 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%, with descriptions for all 4 parameters. The tool description adds no additional meaning beyond what the schema already provides. 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?

Description uses specific verb 'List' and resource 'agents' with scope 'in your organization', clearly distinguishing it from sibling tools like get_agent (single) and create/delete/update agents.

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

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

No explicit guidance on when to use this tool versus alternatives. However, the name and sibling list imply it's for listing multiple agents, while get_agent is for a single agent. Adequate but lacks exclusions or alternative suggestions.

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 mark the tool as read-only and non-destructive. The description adds valuable behavioral context: agent-scoped keys see only pages on their own agent's calendars. This goes beyond annotations and clarifies scope constraints.

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: first states the core purpose, second adds a crucial nuance. No wasted words, front-loaded with key 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?

The tool is simple with pagination parameters fully described by the schema. However, since there is no output schema, the description could mention the return format (e.g., list of booking page objects). Still, given the minimal complexity, it is fairly 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?

The input schema has 100% description coverage for both limit and offset. The description does not add any additional meaning beyond what the schema already provides, so baseline score of 3 is appropriate.

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

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

Description clearly states the tool lists booking pages in the org, using a specific verb and resource. It also adds nuance about agent-scoped key behavior, which distinguishes it from siblings like get_booking_page (single) and create_booking_page.

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 clear context about agent-scoped key visibility but does not explicitly state when not to use the tool or mention alternatives like get_booking_page for a single page. Usage is implied but lacks explicit exclusions.

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

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

Annotations already indicate readOnlyHint, idempotentHint, and no destructiveness. The description adds valuable context about key scoping behavior (org-level vs agent-scoped), which is beyond the annotations and helps the agent understand 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?

Two sentences, front-loaded with the core purpose, no unnecessary words. Every sentence adds value.

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

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

For a simple read-only listing tool, the description covers the essential behavioral context (key scoping) and usage purpose. No output schema exists, but the tool's return is likely a list of calendars, which is straightforward.

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% with adequate descriptions. The description does not add significant new meaning beyond the schema, meeting the baseline. It mentions the 'include' parameter implicitly but not in detail.

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

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

The description clearly states it lists calendars in the org, distinguishes between org-level and agent-scoped API keys, and explicitly says to use it for discovering calendar IDs, which differentiates it from sibling tools like list_events or list_agents.

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 advises using it 'before creating or listing events' to discover calendar IDs, providing clear when-to-use context. It also explains scope differences but does not explicitly state when not to use it, though the guidance is strong.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds useful substance by disclosing that results span internal and externally synced events, but says nothing about pagination behavior, ordering, or result limits beyond what the schema states, leaving it at a modest add.

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

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

Three tight sentences: purpose and scope first, then the required identifier constraint, then the optional filters. No filler and no redundancy with the schema; each clause carries distinct information.

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

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

For a read-only list tool with 100% schema coverage and no required parameters, the description covers what the tool returns conceptually and how to scope the query. The only shortfall is that with no output schema present, it could have said more about the returned event shape or pagination envelope, though for a list operation this is 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 description coverage is 100%, so every one of the 9 parameters is already documented, including the mutual-exclusivity note on calendar_id/agent_id and the enum values for source and status. The description reinforces which parameters matter but adds no syntax, format, or constraint detail 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?

States a specific verb (List) and resource (events), and goes further by scoping it to a calendar or across an agent's calendars while explicitly including both internally created and externally synced iCal events. This lets an agent distinguish it from single-event siblings like get_event and from list_calendars 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 clear usage rule: 'Provide calendar_id OR agent_id', and enumerates the narrowing filters (start_after/start_before, status, source). It supplies positive context but never names an alternative tool or a when-not-to-use condition (e.g. get_event for a single event), 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?

The description adds value beyond annotations by specifying that results include 'sync status and last sync time'. It does not contradict annotations (readOnlyHint, idempotentHint, destructiveHint) and aligns with the read-only, idempotent nature.

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, well-structured sentence that front-loads the verb and resource, includes examples, and provides specific details. No unnecessary 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?

Given no output schema, the description usefully indicates return fields (sync status, last sync time). It does not describe the overall structure (array of subscriptions) or pagination details, but the schema covers limit/offset defaults.

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 all parameters. The description does not add any meaning beyond what the schema provides, meeting the baseline of 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?

The description clearly states the action 'List', the resource 'agent's external iCal feed subscriptions', and includes examples and return fields (sync status, last sync time). It effectively distinguishes from sibling tools like `list_calendars` and `get_ical_subscription`.

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 usage for listing subscriptions for a given agent, but does not explicitly state when to use it versus alternatives like `get_ical_subscription` for single items or `delete_ical_subscription`. No direct exclusions or when-not-to-use guidance is provided.

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

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

Annotations already declare the tool read-only and idempotent. The description adds the crucial authentication requirement and implies pagination via limit/offset parameters, providing valuable behavioral context beyond 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 concise sentences with no wasted words. The primary purpose is front-loaded, and every sentence adds necessary context.

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

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

The tool lacks an output schema, and the description does not explain the return structure (e.g., array of proposals, fields). It covers filtering and auth, but omits sorting, default behavior, and response 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 100%, and the description does not add significant meaning beyond the schema's parameter descriptions. It lists filter options but without extra detail on usage or format.

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

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

The description clearly states the verb 'List', the resource 'scheduling proposals', and the scope 'for the org'. It also specifies acceptable filter values, distinguishing it from sibling tools like 'get_proposal' for a single item.

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 explicitly states when to use the tool and the required authentication context ('org-level API key'), but does not provide exclusions or alternative tools for different use cases.

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 adds value beyond the annotations by stating that it lists only live keys, returns metadata but never the plaintext secret, and requires an org-level API key. This goes beyond the readOnlyHint and idempotentHint 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 two sentences, front-loaded with the main action and scope, and contains no redundant 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 listing tool with no parameters and no output schema, the description covers purpose, scope, output details, and requirements, making it fully informative.

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 no parameters (schema coverage 100%). The description appropriately provides context about the tool's function without needing to explain 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?

The description clearly states the verb 'List', the resource 'live (non-revoked) agent-scoped API keys', and the scope 'for this org'. It distinguishes from sibling tools like create_scoped_key and revoke_scoped_key by focusing on listing non-revoked keys.

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 specifies a prerequisite ('Requires an org-level API key') and explains what is returned. It does not explicitly state when not to use this tool, but the context makes it clear that it is for listing, not creating or revoking.

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 annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not repeat safety info. It adds value by specifying the need for an org-level API key, which is a behavioral constraint not in 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 sentences with no wasted words. First sentence states action and output (per-status counts), second adds use case and auth requirement. Front-loaded and efficient.

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

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

The tool has no output schema, but the description mentions per-status counts, giving a hint of return format. It covers purpose, use case, and auth. For a read-only list tool with 5 parameters, this is fairly complete, though more detail on sorting or pagination could help.

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 input schema has 100% description coverage for its 5 parameters, so the schema already documents parameter meanings. The description does not add much beyond mentioning 'per-status counts,' which loosely relates to the status parameter. 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 clearly states that the tool lists delivery attempts for a webhook, with per-status counts. The verb 'List' and resource 'delivery attempts' are specific, and the mention of per-status counts distinguishes it from other list tools.

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

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

The description explicitly says to use this to debug failing deliveries, providing a clear use case. It also notes the requirement for an org-level API key, but does not explicitly state when not to use it or mention alternatives.

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 and idempotent. Description adds that signing secrets are never returned and requires org-level API key, providing extra context beyond 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 sentences, no wasted words. First sentence states purpose, second adds critical security and auth context.

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 listing action, return fields (event types, active state), what is not returned (secrets), and auth requirement. Lacks output format details but sufficient given common list pattern and no output schema.

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

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

Schema coverage is 100% with clear parameter descriptions; tool description does not add any additional parameter information, so 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?

Clearly states it lists org's webhook subscriptions with event types and active state. Distinguishes from sibling tools like get_webhook (single) and create/delete/update by specifying listing action.

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?

Implies usage for enumeration of webhooks, and mentions prerequisite (org-level API key), but does not explicitly compare to alternatives like get_webhook or list_webhook_deliveries.

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 indicate destructive and idempotent behavior. Description adds that it frees a slot for other agents, beyond annotation details. No contradiction.

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

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

Two sentences, no superfluous words, front-loaded with action and condition.

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 mutation with one parameter and no output schema, the description covers all essential context: action, precondition, effect, and idempotency.

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 has 100% description coverage for the single parameter. Description adds the requirement that event must be held, which is implied but clarifies the parameter's context.

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?

Description clearly states the action (release held event), the condition (status='hold'), and the effect (frees slot). Distinguishes from siblings like confirm_event or cancel_event.

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

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

States explicit condition (status='hold') and timing (before hold_expires_at). Does not explicitly mention when not to use or compare to alternatives, but condition serves as clear usage guide.

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?

Discloses key behavior beyond annotations: picks highest-scoring slot accepted by most participants, creates confirmed event, and cancels if all responses are 'decline'. No contradiction with annotations (idempotentHint=true, destructiveHint=false).

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, each adding value. Front-loaded with core purpose. No unnecessary words or fluff.

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 single required parameter and no output schema, the description covers behavioral outcomes, constraints, and prerequisites fully. The tool is simple but the description is 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?

Only one parameter (proposal_id) with 100% schema coverage; description does not add additional semantics beyond the schema's 'Proposal to resolve'. 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 explicitly states the verb 'Force-resolve' and the resource 'open proposal', and it distinguishes from siblings like 'respond_to_proposal' by specifying it uses collected responses without waiting for all participants.

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 clear context: 'Use when you want to close out a proposal without waiting for every participant.' Also mentions requirements: 'Requires an org-level API key. Pro plan only.' Lacks explicit when-not-to-use or alternative tools, but the context is sufficient.

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 establish the safety profile (writes, non-destructive, non-idempotent), and the description adds information the annotations cannot convey: org-level API key requirement, Pro-plan gating, and the auto-resolution lifecycle behavior. It also flags the per-response conditional obligation (accept needs a slot id), so no hidden mutation semantics are left undisclosed.

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

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

Four short sentences, front-loaded with the action, followed by per-response requirements, lifecycle behavior, and prerequisites in descending order of importance. No filler or restated field names.

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 prerequisites, response-dependent inputs, and the post-call lifecycle outcome (auto-resolve), which is the key thing an agent must anticipate. It stops short of describing what the call itself returns, which would be the only 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?

With 100% schema description coverage, the schema already documents all six parameters including the conditional requirements for selected_slot_id and counter_slots. The description restates the accept/counter conditions but adds nothing about slot weighting, limits (maxItems 20), or time formats, 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?

Specific verb (submit a response) + resource (an open proposal) + actor scope (on behalf of one participant agent), with the three allowed responses enumerated inline. This clearly separates it from resolve_proposal, cancel_proposal, and create_proposal 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 tells the agent that a resolve call is unnecessary because the proposal auto-resolves once all participants respond — that is a real routing decision against the sibling resolve_proposal. It also states prerequisites (org API key, Pro plan), though it never states when responding would be inappropriate (e.g., after resolution or cancellation).

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 adds valuable behavioral details beyond annotations: revocation is permanent, cannot be undone, and takes effect within about a minute. This complements the destructiveHint and idempotentHint 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 consists of two efficient sentences with no extraneous text. The first sentence states the primary action, and the second provides crucial caveats and prerequisites.

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 single parameter, no output schema, and clear annotations, the description is complete. It covers the action, effect, timing, and authentication requirement.

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

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

The input schema covers the single parameter key_id with a description ('ID of the scoped key to revoke'). The description does not add additional semantic information beyond what the schema provides, so a baseline score of 3 is appropriate.

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

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

The description clearly states the action 'Revoke', the resource 'agent-scoped API key', and the method 'by ID'. It effectively distinguishes this tool from related tools like create_scoped_key and list_scoped_keys.

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 mentions a prerequisite ('Requires an org-level API key') and the permanent nature of revocation, providing clear context for when to use. While it doesn't explicitly state when not to use, the irreversibility is strongly 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 indicate idempotentHint=true and destructiveHint=false, so the description's mention of 'Upsert: overwrites any existing rules' and the effect on availability queries adds some context but does not significantly extend beyond the annotations. No side effects beyond overwriting are disclosed, and the impact on existing events is not clarified.

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 three sentences long, front-loaded with the core purpose, followed by the effect on queries and the overwrite behavior. No extraneous information; 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?

Given the tool has 5 parameters and no output schema, the description covers the main behavior: setting buffers and working hours, their automatic application, and the upsert nature. It could mention that working hours are optional or that timezone defaults to UTC, but the schema handles that. Overall, it is sufficiently complete for a setter tool.

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

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

Schema coverage is 100%, so the baseline is 3. The description mentions 'buffer times before/after events and optional per-day working hours', which aligns with parameters but does not add detailed semantics beyond what the schema already provides. The parameter descriptions in the schema are already comprehensive.

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

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

The description clearly states the tool's verb ('Set or replace'), the resource ('availability rules on a calendar'), and the specific behaviors ('buffer times before/after events and optional per-day working hours'). It distinguishes itself from sibling tools like 'clear_availability_rules' and 'get_availability_rules' by focusing on setting/replacing rules.

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 context on when the rules take effect ('every availability query on this calendar automatically applies them') and notes the upsert behavior ('overwrites any existing rules'). However, it does not explicitly state when to use this tool versus alternatives, such as when to use 'clear_availability_rules' for removal.

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 indicate a mutation (readOnlyHint=false) and non-destructive. The description adds context that the calendar must be agent-owned and that org-level calendars won't work. However, it does not disclose behavior on duplicate URLs, error handling, or whether existing subscriptions are overwritten. Adequate but not rich.

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

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

The description is two sentences: the first states purpose and benefit, the second provides a critical constraint. No unnecessary words; it is front-loaded and efficient.

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 complexity of 4 parameters and no output schema, the description covers purpose and prerequisite but does not indicate what the tool returns on success or what error scenarios exist. Adequate but could be more complete, especially since there is no output schema.

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

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

Schema coverage is 100%, so parameters are already described. The description reinforces the role of agent_id and calendar_id but adds no new details about url or label beyond the schema. Baseline score of 3 is appropriate.

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

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

The description clearly states the tool links an external iCal feed to an agent's calendar for availability calculations. The verb 'link' and resource 'iCal feed to agent calendar' are specific, and it is distinct from sibling tools like delete_ical_subscription or sync_ical_subscription.

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 includes when to use (to include external events in availability) and a critical prerequisite: the target calendar must be owned by the agent. It warns against using org-level calendars, providing clear guidance. It does not explicitly name sibling alternatives but the context is sufficient.

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 provide idempotentHint=true, destructiveHint=false. The description adds that the tool returns once the sync is queued, indicating asynchronous behavior and immediate return, which is useful context beyond annotations. No contradictions.

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

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

The description is two sentences, very concise, and front-loaded with the key action. Every word is useful with no filler or repetition.

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

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

The tool is simple with one parameter and no output schema. The description explains the queuing behavior but does not address potential error cases (e.g., invalid subscription ID) or confirm if the sync actually completes. Given the low complexity, it is mostly complete but could briefly mention what happens if the subscription is invalid.

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?

Input schema has one required parameter (subscription_id) with a clear description. Schema coverage is 100%, so the baseline is 3. The description adds no additional parameter semantics beyond what the schema already provides.

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

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

The description clearly states the tool triggers an immediate sync of an iCal feed subscription instead of waiting for the next poll. It specifies the action (trigger sync) and resource (iCal feed subscription), and contrasts with the scheduled alternative, effectively distinguishing it from siblings like subscribe_ical and update_ical_subscription.

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 explicitly tells when to use this tool: when you need immediate sync instead of waiting for the next scheduled poll. It does not explicitly list when not to use it or provide alternative tool names, but the context is clear enough for an AI agent to understand the use case.

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 mutation/idempotency profile is covered. The description adds a genuinely non-derivable constraint — the call requires an org-level key and agent-scoped keys cannot mutate agents — which prevents a whole class of failed calls. It does not say whether omitted fields are preserved or how partial updates behave.

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

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

Two sentences, no filler, with the action and its target front-loaded before the operational constraint. The field enumeration partly duplicates the schema but reads quickly and aids scanning.

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

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

For a partial-update mutation with full annotation coverage and no output schema, the description covers purpose and the key auth gate. It leaves minor but real gaps: whether unspecified fields are preserved, and what happens on validation/permission failure.

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 every parameter (name, status enum, agent_id, metadata 16KB limit, description-null-clears) is already documented in the schema, so the baseline of 3 applies. The description restates the field set but adds no format, null-semantics, or update-mode detail beyond the schema.

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

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

The description gives a specific verb (Update) plus the resource (an agent) and enumerates the mutable fields (name, description, metadata, status), which separates it from read-only siblings like get_agent and from create_agent/delete_agent. It stops short of explicitly naming those siblings or stating what it is not, so it is clear but not fully differentiated.

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

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

Usage is implied by the auth prerequisite: 'Requires an org-level API key — agent-scoped keys cannot mutate agents.' That tells the caller when the call will succeed, but there is no explicit when-to-use-vs-alternative guidance (e.g., use create_agent first, use delete_agent to remove, or that this is a partial update).

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 indicate mutation (readOnlyHint=false), idempotency (idempotentHint=true), and non-destructiveness (destructiveHint=false). The description adds context about agent-scoped key restrictions, which is valuable beyond the annotations. No contradictions.

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

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

The description is two sentences long. The first sentence immediately communicates the tool's purpose, and the second adds a key restriction. No unnecessary words – 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?

The tool has 6 parameters (one required) and a nested metadata object. The description covers the main updatable fields and the agent-scoped restriction but does not mention return values or error states. Given no output schema, more detail on the response would improve completeness.

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

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

Schema coverage is 100%, so each parameter has a description in the schema. The tool description only lists the updatable fields broadly, adding minimal extra meaning. Baseline of 3 is appropriate given high schema 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 clearly states 'Update a calendar's name, timezone, agent status, default reminders, or metadata.' It uses a specific verb ('Update') and lists the resources/attributes affected, distinguishing it from sibling tools like create_calendar, delete_calendar, or get_calendar.

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 includes a usage guideline: 'Agent-scoped keys may only update calendars owned by their agent,' which provides important context about authorization. However, it does not explicitly mention when to use this tool versus alternatives like update_event, though the purpose is clear.

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

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

With annotations covering safety (readOnlyHint=false, idempotentHint=true, destructiveHint=false), the description adds meaningful behavioral context: partial update semantics ('Provide only the fields you want to change'), a restriction on holds, and read-only behavior for external iCal events. It does not describe the return value or any notification side effects, so it is strong but not exhaustive.

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

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

The description is front-loaded with the core purpose, followed by usage guidance and key constraints. Every sentence earns its place: purpose, when to use, partial-update instruction, and two important exclusions. No filler or repetition.

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

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

Given 11 parameters, full schema coverage, and annotations covering safety, the description is nearly complete: it covers purpose, usage, partial-update behavior, and key restrictions. It could still mention what a successful update returns or that the operation is idempotent, but the annotations already convey idempotency, making the remaining gap minor.

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

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

Schema description coverage is 100%, so the schema already documents all 11 parameters thoroughly. The description only adds the general partial-update instruction and notes that calendar_id is optional and resolved from the event, which largely duplicates the schema's own description for calendar_id. Baseline 3 is appropriate 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?

The description states a specific verb and resource: 'Reschedule or edit an event — change its title, description, start/end times, location, status, reminders, or metadata.' It also distinguishes from siblings by noting that holds cannot be edited here and must use confirm_event or release_event, and that external iCal events are read-only.

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 context ('Use this to move an appointment to a new time or update its details') and explicit exclusions for holds and external iCal events. However, it does not address when to use this tool versus cancel_event or delete_event, nor does it clarify whether setting status to 'cancelled' is preferred over the cancel_event sibling.

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=false, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavior: a URL change forces a full re-sync on the next poll. It does not say whether omitted fields are left untouched or require permissions, but the added side-effect disclosure is meaningful.

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, and the core action is front-loaded before the re-sync caveat. 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 mutation tool with full annotation coverage, no output schema, and 100% schema coverage, the description supplies the key behavioral consequence of a URL change. Minor gaps remain: partial-update semantics for omitted fields and any auth/permission requirements are unaddressed.

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

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

Schema description coverage is 100%, so all three parameters are already documented in the schema; the description's mention of label and feed URL largely restates those properties. Baseline 3 applies since the schema does the heavy lifting, though the URL/re-sync linkage adds a little 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 ('Update an external iCal feed subscription') and enumerates the two mutable fields (label, feed URL), which is far more than a tautology. The re-sync note implicitly separates it from sync_ical_subscription, but no sibling is named outright, so it stops short of full 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?

'Change its label or its feed URL' implies the context in which the tool is used, but there are no explicit when/when-not statements, no prerequisites, and no routing to alternatives — notably it never says to use sync_ical_subscription if you want an immediate re-sync rather than waiting for the next poll.

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 adds value beyond annotations by specifying the required authentication scope ('org-level API key') and the constraint that at least one field must be supplied. Annotations already indicate a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). No contradictions.

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 concise sentences with no redundant information. The purpose and key constraints are front-loaded in the first sentence, and the second adds important usage notes. 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 mutation tool with no output schema, the description covers the action, parameters, and auth requirement. It does not mention the return value (likely the updated webhook object), but that is somewhat inferred from the sibling get_webhook. Overall, fairly complete for the complexity.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds meaning by summarizing what the parameters control (delivery URL, event types, active status) but does not detail each parameter beyond the schema's own descriptions. Adequate but not exceptional.

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

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

The description clearly states the action ('Update'), the resource ('a webhook subscription'), and the specific fields that can be modified ('delivery URL', 'event types', 'pause/resume via active'). This distinguishes it from siblings like create_webhook, delete_webhook, and get_webhook.

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 key usage constraints: 'At least one field must be supplied' and 'Requires an org-level API key.' It does not explicitly compare to alternatives, but the sibling list makes the context clear. Slight room for improvement by stating when to use over create/delete.

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