Chronary

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

In the absence of annotations, the description carries the full burden of behavioral disclosure. It reveals that the tool performs a write operation (re-accepting terms), requires specific authorization (org-level key), and is triggered by a specific HTTP header. However, it does not describe the response format or indicate whether the operation is reversible, leaving some behavioral gaps.

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 (4 sentences) and front-loaded with the core purpose. Every sentence contributes essential information: purpose, trigger, prerequisite data retrieval, and authorization constraints. There is no redundant or extraneous content.

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

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

Given that the tool has only one parameter, no output schema, and no annotations, the description provides sufficient context for an AI agent to select and invoke it correctly. It explains the business scenario, prerequisite steps, and authorization rules. A minor gap is the lack of detail on the expected response or error handling, but the core information 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?

The input schema describes the single parameter 'tos_version' with a minimal description ('must match the current version'). The description adds meaningful context by instructing the user to read the current version from 'GET /v1/auth/terms/current', which goes beyond the schema. With 100% schema coverage, the baseline is 3, and this added guidance justifies a 4.

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 re-accepts the Chronary terms of service on behalf of the calling org. It uses a specific verb ('re-accept') and identifies the resource ('terms of service'), leaving no ambiguity about its function. No sibling tools share this purpose, so differentiation is not required.

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 specifies when to use the tool ('when responses carry the Chronary-Terms-Upgrade-Required header'), explains why (MCP-only agents would otherwise be stuck), and provides step-by-step guidance ('Pass the current tos_version from GET /v1/auth/terms/current'). It also clarifies authorization requirements ('requires an org-level API key; agent-scoped keys cannot accept org-wide terms'), effectively distinguishing this from other 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?

With no annotations, description states it invalidates URL and does not disconnect completed connections. Missing details on authorization, reversibility, or side effects. Sufficient for simple tool but could be more thorough.

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 covering action and limitation. No redundant words, 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 single-parameter tool with no output schema, the description fully explains behavior and boundary conditions. No additional details are necessary.

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 'connection_link_id'. Description adds no further meaning; it relies on the schema's pattern and description.

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

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

Clearly states the action ('Cancel a pending human-calendar setup request') and distinguishes from disconnecting completed connections. The verb 'cancel' and resource 'setup request' are specific and 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?

Provides clear context: use for pending setup requests, not for completed connections. However, does not explicitly mention when to consider alternatives like 'create_connection_link' or 'delete_calendar'.

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

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

With no annotations, the description carries full burden. It discloses that the event is 'marked cancelled and excluded from future availability calculations' and explains the recurring series behavior thoroughly. This goes beyond basic functionality to inform the agent of side effects.

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 paragraph that front-loads the main purpose. Every sentence adds meaningful information: primary action, recurrence handling, optional parameter reasoning. No wasted words or redundancy.

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

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

Given no output schema, the description omits return values, but for a deletion tool this is acceptable. It covers all necessary contextual information: what the tool does, parameter semantics, and behavioral implications. Could mention that it returns the cancelled event or a success indicator, but not essential for 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 baseline is 3. The description adds value by explaining the purpose of `calendar_id` (optional, resolves from event, matches sibling asymmetry) and `occurrence_start` (for recurring events only, partial cancellation). This enriches the schema definitions without repeating them.

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

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

The description starts with a clear verb+resource ('Delete or cancel an event') and explains the core functionality. It distinguishes from siblings like confirm_event and release_event by mentioning that calendar_id asymmetry matches those tools. The scope (scheduled event/appointment) is explicit.

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

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

Explicitly states when to use ('remove, cancel, or delete any scheduled event') and provides detailed guidance for recurring events: pass `occurrence_start` to cancel one occurrence, omit to cancel the whole series. Also explains when to provide `calendar_id` (optional, but helpful for fast failure on typos). No need for alternatives because this is the delete operation.

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 the webhook side effect and authentication requirement, which are critical behavioral traits beyond basic cancellation. No annotations present, so description carries full burden.

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

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

Two concise sentences with front-loaded action. No extraneous text; 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?

Covers all key aspects: purpose, side effect (webhook), auth requirement, and plan restriction. Adequate for a simple mutation tool with one parameter.

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, and the description adds no additional semantic detail beyond what the schema already provides ('Proposal to cancel'). 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?

The description clearly identifies the action ('Cancel an open proposal') and the resource, distinguishing it from sibling tools like 'resolve_proposal' or '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?

Provides specific usage constraints: requires org-level API key and Pro plan. However, it lacks explicit guidance on when to use 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?

No annotations are provided, so the description carries the burden. It discloses that the tool reverts to default (no buffers, no working-hours mask), returns the deleted row or an error if none set. This is sufficient behavioral context for a simple tool.

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

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

Two sentences that are front-loaded with the action and result, followed by return value detail. 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's simplicity (one parameter, no output schema, no nested objects), the description covers the purpose, effect, return value, and error condition. It is fully adequate for an agent to select and invoke correctly.

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

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

Schema description coverage is 100% with a single parameter 'calendar_id' described as 'Calendar whose rules should be cleared'. The description adds no additional 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?

The description clearly states the verb 'Remove' and the resource 'availability rules from a calendar', and explains the effect of reverting to default. It distinguishes itself from sibling tools like set_availability_rules and get_availability_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 implies when to use (to clear rules) but does not explicitly state when not to use or provide comparison to alternatives. It lacks guidance on prerequisites or exclusion criteria.

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

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

With no annotations provided, the description carries the full burden. It discloses behavioral traits: the event's status requirement and that lifecycle webhooks fire after confirmation. It does not mention potential side effects like irreversibility or authorization needs.

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 with no wasted words. The first sentence immediately states the core purpose, and the second adds necessary preconditions and postconditions.

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 confirmation tool with one parameter and no output schema, the description covers preconditions and an important postcondition (webhooks). It could be slightly improved by noting error cases or that the event must belong to the user, but overall 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% with one parameter. The description adds no extra meaning beyond the schema's 'Event ID of the hold to confirm'.

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') with a specific verb and resource. It inherently distinguishes from sibling tools like 'cancel_event' or 'release_event' that handle different states.

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 preconditions: the event must have status 'hold' and hold_expires_at must not have passed. However, it does not state when not to use this tool (e.g., for non-held events) or suggest 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?

No annotations are provided, so the description carries full burden. It states agent registration enables ownership, but does not disclose any behavioral traits such as whether the operation is idempotent, requires authentication, or causes side effects beyond creation. For a create operation, some disclosure about what is returned (e.g., agent ID) is missing.

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

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

The description is a single front-loaded sentence with no unnecessary words. It efficiently communicates the core action and purpose. However, it could be slightly expanded to include the required parameters or return value without losing conciseness.

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

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

While the description covers the tool's purpose and the effect of registration, it lacks any information about return values (e.g., agent ID) or what happens upon success. Given no output schema and low complexity, the description should at least hint at what the agent gets upon creation.

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%, but the description adds meaning by clarifying that the agent types are 'AI assistant, human participant, or resource' and that the agent will 'own calendars, events, and webhooks'. This context helps infer the role of the 'type' parameter and the significance of the 'name' field.

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 'Register' and the resource 'your agent (AI assistant, human participant, or resource)'. It explains the purpose: so it can own calendars, events, and webhooks. This distinguishes it from siblings like update_agent or delete_agent, as it is uniquely the creation 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 this tool is used when you need an agent to own resources, but it provides no explicit guidance on when to use versus alternatives, prerequisites, or when not to use. The context from sibling tool names (e.g., update_agent) helps, but the description itself lacks usage heuristics.

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

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

No annotations are provided, so the description carries the full burden. It transparently states that a confirmed event is created on the calendar and an event.created webhook fires with a booking_page_id field. It also mentions the slot blocking behavior. This is comprehensive for a creation tool.

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

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

The description is two sentences with zero wasted words. The first sentence front-loads the purpose and return value, the second adds key behavioral constraints. Perfectly 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?

The description covers the main purpose, return value, webhook side effect, and slot-blocking behavior. Given the tool has 10 parameters but no output schema, the description provides enough context for an agent to understand usage, though some details about parameter interactions could be added but are 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 input schema has 100% description coverage, so baseline is 3. The description adds value by explaining the return value (booking_url), the effect of availability_constraints, and that existing events block slots, which goes beyond the schema's parameter descriptions.

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

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

The description clearly states the tool creates a public booking page, specifying the verb 'Create', the resource 'booking page', and the context 'for a calendar'. It distinguishes from siblings like 'create_event' by mentioning the return of a booking_url and the scheduling behavior.

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

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

The description provides usage context: 'Set availability_constraints to restrict to weekly working hours' and 'existing calendar events always block slots'. It implies when to use (to create a scheduling link) but does not explicitly exclude other scenarios, which is minor given clarity.

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

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

No annotations provided; the description adds context about org-level calendars as shared resources and the agent_id distinction. It does not fully disclose permissions or side effects but is helpful.

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

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

Three sentences, front-loaded with purpose, no wasted 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?

Given 4 parameters, no output schema, and missing annotations, the description covers prerequisites, parameter semantics, and organizational context comprehensively.

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% (baseline 3), but the description adds value by explaining default_reminders (inherit, system default, no reminders) and agent_id meaning (own vs org-level).

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 calendar to hold events and track availability. It distinguishes from siblings by noting that calendars are required before creating events, and it mentions org-level calendars for shared 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 says 'call this first when setting up a new agent,' providing clear context. It implies usage for creating calendars without explicit when-not 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?

With no annotations, the description fully discloses behavioral traits: the agent does not receive credentials, the secret URL is returned only on first creation, and conditional logic for reused=true. This covers security and lifecycle 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 four sentences, no fluff, and front-loaded purpose. Every sentence adds necessary detail, maintaining clarity without excessive length.

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

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

Given no annotations or output schema, the description covers key aspects: human involvement, credential security, URL lifecycle, and reuse behavior. However, it references parameters not in the input schema (reused, setup_url) and lacks explicit return value documentation, slightly reducing 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 description coverage is 100%, so baseline is 3. The description adds context about human setup and the setup URL but introduces terms like reused and setup_url not in the input schema, which may cause confusion. It does not significantly enhance parameter understanding 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 clearly states the tool requests human setup of Google Calendar or Microsoft Outlook for a Chronary calendar, specifying the verb 'request human setup' and resource 'connection link'. It distinguishes from siblings like cancel_connection_link and get_connection_link 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 that the agent never receives OAuth credentials and must give the setup URL to a human, providing clear usage context. However, it does not explicitly compare to sibling tools or state when not to use it, such as when an existing link should be retrieved or canceled.

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?

While no annotations exist, the description discloses key behaviors: the event blocks agent availability and appears in queries. It also explains the hold auto-release and recurrence limits. Missing details on error handling or idempotency, but sufficient for agent understanding.

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, front-loaded with main purpose, then key behavioral details. No redundancy, 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 11 parameters and no output schema, the description covers essential points: source of calendar_id, blocking behavior, hold semantics, and recurrence. Missing explicit return value description, but for a create tool, this is 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%, but the description adds value beyond the schema: it explains the hold_expires_at and status interplay, auto-release, and inheritance of reminders. It also clarifies recurrence rule constraints and limitations.

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 events (booking, appointment, meeting, hold) on a calendar, with specific verb and resource. It distinguishes from sibling tools like cancel_event, confirm_event, etc., by focusing on creation. The mention of calendar_id source further clarifies purpose.

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

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

The description provides context on when to use this tool, including dependency on calendar_id from other tools. It explains the hold mechanism and recurrence. However, it doesn't explicitly say when not to use it or compare to alternatives like update_event or confirm_event.

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

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

With no annotations, the description discloses key behaviors: proposal ownership, auto-resolution after all respond, selection of highest-scoring slot or cancellation if all decline, and auth/plan requirements. It does not mention rate limits but covers the core flow well.

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 primary action, then additional detail. No fluff—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 creation tool with 7 parameters and no output schema, the description provides sufficient context: the process, auth requirements, and plan restrictions. It could mention the return value (proposal ID) but is overall complete for an agent to decide and invoke.

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 each parameter's purpose. The description adds overall context (e.g., auto-resolution, scoring) but does not provide additional parameter-specific meaning beyond the schema.

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

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

The description clearly defines the tool's purpose: creating a scheduling proposal that sends candidate time slots to participants and auto-resolves. It distinguishes from sibling tools like resolve_proposal and respond_to_proposal by explaining the full lifecycle.

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 states the tool requires an org-level API key and Pro plan, and explains the organizer ownership and resolution process. It implies when to use but lacks explicit when-not-to-use or direct references to alternatives like create_event or find_meeting_time.

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

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

With no annotations, the description fully carries the burden and discloses critical behavioral traits: the key is returned once and cannot be retrieved later, it is agent-scoped, and requires an org-level API key. This provides essential security-aware guidance beyond basic functionality.

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 with no fluff. The first sentence clearly states the purpose, and subsequent sentences provide essential usage and behavioral details. 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?

The description covers the key behavioral aspects (one-time key retrieval, scoping) and prerequisites (org-level key). However, it lacks guidance on error handling or what happens with invalid agent IDs. Overall, it is sufficiently complete for a creation tool.

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

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

Both parameters have descriptions in the schema (100% coverage), so the description does not add additional meaning. It does not elaborate on parameter behavior or constraints 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 creates an agent-scoped API key, specifies the key prefix pattern, and distinguishes it from sibling tools like revoke_scoped_key and create_agent by emphasizing the 'scoped to a single agent' aspect.

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 recommends using this tool for self-provisioning or rotating per-agent credentials, providing clear context. However, it does not explicitly mention when not to use it or offer comparisons to 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?

With no annotations, the description carries the full burden. It discloses critical behavior: the signing secret is returned once and must be stored for HMAC-SHA256 verification. It also notes authentication requirements. It does not mention idempotency, rate limits, or duplicates, but for a creation tool, the provided info is quite helpful.

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 core purpose, and every sentence adds essential information. No filler or redundancy.

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

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

Given the tool's simplicity (2 required params, no output schema), the description covers purpose, authentication, and a key behavioral nuance (signing secret). It is fully adequate for an agent to understand and invoke the tool correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value through event examples but does not deepen the explanation of the url or events parameters beyond what the schema already provides. The mention of the signing secret pertains to the response, not the input 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 tool creates a webhook subscription to receive HTTP POST notifications for events, with concrete examples like event.created and proposal.confirmed. It distinguishes itself from sibling webhook tools (e.g., delete_webhook, update_webhook) by its creation 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 includes a prerequisite: 'Requires an org-level API key.' While it doesn't explicitly state when not to use or compare with alternatives, the sibling tool names (get, update, delete, list) imply context. A clear usage directive is present, but exclusion guidance is missing.

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 behavioral effects: marks decommissioned and revokes scoped API keys. With no annotations, this is crucial context. Lacks details on reversibility or impact on associated resources, but sufficient for an agent deletion.

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 that front-load the action and effect, followed by an important constraint. 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?

Given the tool's simplicity (one param, no output schema), the description covers the essential purpose, side effects, and auth requirements. Adequate for correct invocation.

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

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

The single parameter agent_id is fully described in the schema (100% coverage), and the description adds no new semantic information 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 action (decommission) and the resource (agent), distinguishing it from sibling tools like create_agent or update_agent. It also explains what the operation does (marks as decommissioned, revokes API 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?

Provides explicit auth requirement (org-level API key) and exclusion (agent-scoped keys cannot delete). Implicitly guides when to use, though no direct comparison to alternatives like deactivate is given.

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

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

No annotations are provided, so the description carries the full burden. It discloses two key behavioral traits: the URL stops resolving and already-booked events are unaffected. However, it does not clarify whether the deletion is reversible (permanent vs. deactivation), which leaves some ambiguity.

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 with no extraneous information. It front-loads the core action ('Delete (deactivate)') then adds the key behavioral details concisely. 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 delete tool with one parameter and no output schema, the description covers the main effect and side effects (URL resolution, unaffected events). It might be improved by noting if the deletion is permanent or reversible, but overall it 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?

The input schema has 100% description coverage for the single parameter 'booking_page_id', including the expected format (bkp_...). The tool description adds no additional meaning 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 tool name 'delete_booking_page' is clear, and the description reinforces this by stating 'Delete (deactivate) a booking page.' It also specifies that the hosted URL stops resolving, which adds clarity on the exact effect. The sibling tools include create, get, and list, so this tool is distinctly for 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?

Usage is straightforward: use when you need to remove a booking page. The description does not explicitly state when not to use it or provide alternatives, but given the simple one-parameter interface and clear sibling set, 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?

With no annotations, the description carries full burden. It discloses soft delete behavior and consequences (events no longer returned, availability stops), and a key authorization constraint. However, it omits whether the operation is reversible, error conditions, and return value 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, front-loaded with purpose, followed by consequences and constraints. 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?

For a simple 1-parameter tool with no output schema, the description explains key behavior and a restriction. It lacks error handling or return value info, but is largely adequate for basic usage.

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 'Calendar ID to delete', so baseline is 3. The main description adds no further parameter guidance (e.g., format, examples) 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 'Delete a calendar (soft delete)', specifying verb and resource. It distinguishes from siblings like delete_event or delete_agent by focusing on calendar. The nuance of soft delete and effects on events and availability adds specificity.

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

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

No guidance on when to use this tool versus alternatives (e.g., update_calendar to hide, or other delete tools). The only usage constraint is about agent-scoped keys, but no explicit when-to-use or when-not-to-use advice.

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

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

No annotations, so description carries burden. It notes that synced events are no longer refreshed, a useful behavioral trait. However, it doesn't mention permissions, reversibility, or what happens to existing events.

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

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

Two sentences, front-loaded with action, 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 one-parameter delete tool, description is adequate: covers action and behavioral effect. Missing error scenarios or success response, but acceptable given typical expectations.

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 description does not add extra meaning beyond the schema's parameter 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?

Description uses specific verb 'Delete' and resource 'external iCal feed subscription', clearly distinguishing it from siblings like subscribe_ical, list_ical_subscriptions, etc. Also notes effect on 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?

Clear context: this tool is for deleting subscriptions. No explicit when-not or alternatives mentioned, but the verb and resource make it unambiguous.

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

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

With no annotations, the description provides key behavioral insights: 'permanently delete' indicates irreversibility, and 'frees its endpoint slot against the per-plan cap' explains resource impact. Does not mention error conditions for non-existent webhooks, but still adds value.

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: first states the action, second adds critical context (frees slot, auth requirement). No wasted words, efficiently communicates essential 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 tool with a single required parameter and no output schema, the description covers purpose, behavioral effect (permanent, frees slot), and auth requirement. Fully adequate for agent decision-making.

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% (one parameter, fully described). The description does not add any meaning beyond what the schema provides for 'webhook_id'. 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?

Clearly states 'permanently delete a webhook subscription' with verb 'delete' and specific resource 'webhook subscription'. Distinguishes from siblings like create_webhook, update_webhook, and get_webhook by specifying the action is permanent and frees endpoint slots.

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

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

Explicitly notes 'Requires an org-level API key', setting a prerequisite and limiting scope. While it doesn't explicitly list when not to use or alternatives, the simple destructive nature makes this adequate.

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

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

With no annotations, the description carries the full burden. It mentions 'fail-closed' behavior and to inspect fields, but does not disclose whether the tool is read-only, what happens on errors, or how it handles missing calendars. The safety note adds some value but leaves significant behavioral gaps.

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 with no wasted words. It front-loads the core purpose and includes a key usage warning. 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 complexity (10 parameters, no output schema, no annotations), the description is too brief. It fails to explain output structure (availability_state, warnings), optional parameters like 'calendars' or 'include_busy', or how results are returned. This leaves the AI agent with inadequate context to use the tool correctly.

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

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

The input schema has 100% description coverage, so each parameter is documented. The description only briefly mentions parameter aliases, adding little beyond the schema. Baseline 3 is appropriate as the schema already provides sufficient 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?

The description clearly states the tool finds free time slots across multiple agents' calendars, using a specific verb ('Find slots') and resource ('when multiple agents are free'). It distinguishes from siblings like 'get_availability' (single agent) and 'create_event' (creates 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 includes a critical usage hint ('fail-closed: always inspect availability_state and warnings') but does not explicitly state when to use this tool versus alternatives like 'get_availability' or 'resolve_proposal'. No 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?

No annotations provided. Discloses agent-scoped key restriction, a behavioral constraint. Does not detail other traits like idempotency or read-only 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?

Three concise sentences with no filler. First states core action, second defines agent, third adds scoped key rule. 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?

Simple tool with one parameter and no output schema. Description covers purpose, agent concept, and scoped key behavior. Optionally could mention response format, 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?

Schema already fully describes the only parameter (agent_id) with coverage 100%. Description adds no additional parameter meaning beyond 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?

Description clearly states verb 'Fetch' and resource 'single agent by ID'. Contrasts with sibling tools like list_agents and create_agent. Adds context about agent semantics.

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?

Mentions agent-scoped API keys limitation, implying when not to use (other keys can fetch any agent). No explicit alternative tool stated.

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

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

The description discloses key behaviors: results are clamped to the plan's retention window, newest-first ordering, and the specific auth requirement. Since no annotations are provided, the description carries the full burden; it adds meaningful context beyond the schema, though it could mention pagination behavior (supported via cursor) for full transparency.

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 with zero waste. The first sentence immediately states purpose, scope, event types, and ordering; the second adds the critical auth requirement. 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 6 parameters, no output schema, and no annotations, the description covers purpose, ordering, clamping, and auth requirements. It lacks explicit mention of pagination (cursor-based) and default limit (50), but these are in the schema. Overall, it is mostly 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 coverage is 100% with descriptions for all 6 parameters, so the baseline is 3. The tool description adds value by explaining that results are clamped to the retention window (which applies to the 'from' parameter as noted in its schema description as 'silently clamped'), enhancing understanding beyond the schema alone.

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

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

The description clearly states the tool lists audit-log entries for the calling org, specifies the type of events (mutating operations and auth-lifecycle), and notes the ordering (newest first). It unambiguously identifies the resource and action, and since no sibling tool covers audit logs, it is well-distinguished.

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 requires an org-level API key (chr_sk_*) and notes agent-scoped keys cannot read the org-wide log, providing clear usage context. However, it does not explicitly contrast with alternative tools or state when not to use this tool, though the unique purpose makes this less critical.

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

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

With no annotations, the description carries full burden. It discloses fail-closed behavior, the need to check availability_state and warnings, and scope across Chronary and authorized human calendars. Absent are rate limits, permission requirements, or error handling details, but the key safety trait is covered.

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

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

Two sentences with zero waste: first sentence establishes purpose and scope, second delivers critical behavioral guidance and alias hint. Every word earns its place, and the structure is front-loaded with the most important usage caution.

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 8 parameters and no output schema, the description covers the critical behavioral point (fail-closed, inspect availability_state and warnings) but leaves out what the full output structure looks like (e.g., slots array, busy blocks when include_busy is true). It is adequate for basic use but incomplete for fully autonomous invocation without 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%, providing baseline 3. The description adds value by clarifying the alias relationship (start/end and start_time/end_time), deprecation of slot_duration in favor of duration, and the default for duration. This aids correct parameter selection beyond schema text.

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 'Check when a single agent is free', providing a specific verb and resource. It distinguishes from siblings like find_meeting_time (which checks multiple agents) by limiting scope to a single agent across its calendars.

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 'fail-closed' and advises inspecting availability_state and warnings, giving usage context. However, it does not explicitly contrast with alternatives like find_meeting_time for multi-agent scheduling or get_calendar for calendar-level views. Usage timing is implied but not fully guided.

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

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

With no annotations, the description carries the burden. It states the return value (rules row or error) and implies read-only behavior, but does not disclose permissions, rate limits, or potential side effects. Adequate but not comprehensive.

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

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

Two sentences, zero wasted words. Front-loaded with purpose and return value. Valuable content in minimal space.

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

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

Given the tool's simplicity (1 param, no output schema), the description is sufficiently complete. It covers purpose, input, and output. Minor gap: no mention of the specific format of the rules row, but 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?

Schema coverage is 100% with one parameter 'calendar_id' described as 'Calendar to read'. The description adds context about buffer times and working-hours rules but does not significantly enhance the schema's meaning. 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 verb 'Read' and the resource 'buffer times and working-hours rules' on a calendar. It distinguishes itself from sibling tools like set_availability_rules and clear_availability_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 implies usage when needing to view current rules, but lacks explicit guidance on when to use it over alternatives or when not to use it. No exclusions or context 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?

With no annotations, the description carries full burden but only states 'Fetch' implying a read operation. It does not disclose any side effects, authentication needs, rate limits, or behavior around not-found scenarios. It is adequate but minimal.

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 one sentence, 14 words, no fluff, and front-loaded with the action. 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 read tool with one parameter and no output schema, the description adequately states the action and return content (booking_url and settings). It could mention the response structure but is sufficient for an agent to understand 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?

The schema covers the single parameter booking_page_id with a description 'Booking page ID to fetch (bkp_...)'. The description adds no new information beyond 'by ID', so baseline 3 applies for 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 uses the specific verb 'Fetch' and clearly identifies the resource as 'a single booking page by ID'. It also lists what is included (public booking_url and settings), which distinguishes it from list_booking_pages (retrieves multiple) and other CRUD 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 provides no guidance on when to use this tool versus alternatives. It does not mention that this tool is for retrieving a single page by ID, while list_booking_pages is for listing, or any prerequisites or context.

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

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

No annotations are provided, so the description carries full burden. It correctly implies a read-only operation via 'fetch' and discloses the agent-scoped access constraint. It does not contradict any annotations. Minor lack of error handling 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: first states purpose and output, second adds a usage constraint. No extraneous words, front-loaded with action. Efficient and clear.

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 covers key return fields and a usage restriction. It is adequate for a simple get operation but lacks mention of error handling or authentication beyond the scope note.

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 parameter description 'Calendar ID to fetch'. The description adds value by enumerating returned fields (name, timezone, etc.) and explaining the agent-scoped key limitation, enriching parameter meaning beyond the schema.

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

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

The description clearly states the action ('Fetch a single calendar by ID') and specifies the included fields ('name, timezone, agent status, and default reminders'). It distinguishes from sibling tools like list_calendars (multiple) and get_calendar_context (contextual).

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 context by noting the agent-scoped key restriction, which helps determine when this tool is appropriate. However, it does not explicitly state when not to use it or mention alternatives for other scopes.

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

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

No annotations are provided, so the description must disclose behavioral traits. It describes the return fields but does not mention whether the operation is read-only, any side effects, rate limits, or the time window for 'recent past' and 'short upcoming window.' It assumes a read operation, which is reasonable but 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?

The description is two sentences: the first lists the comprehensive set of returned data, the second provides a use case. It is front-loaded, concise, and every sentence serves a purpose. 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 tool's complexity (1 parameter, no output schema, no nested objects), the description fully explains the return value and the intended use case. It is sufficient for an agent to understand what to expect and when to use it.

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 single parameter 'calendar_id' that has a description in the schema. The description adds no additional meaning beyond what the schema provides. 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 gets a calendar's temporal context, listing exactly what is returned (current event, next upcoming, recent past, upcoming window, agent status). It distinguishes from list_events by noting it's a single-call alternative for answering what the agent is doing right now.

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 'Use this to answer what is this agent doing right now? without issuing multiple list_events queries.' This guides when to use it and provides an alternative to avoid. It lacks explicit when-not-to-use conditions but is clear enough for typical 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?

With no annotations, the description fully carries behavioral disclosure. It clearly states what the tool does NOT do (never replays bearer URL, never exposes human calendar data), which is valuable for security-aware agents.

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 zero waste. Front-loaded with the action ('Poll a human-calendar setup request') followed by key constraints. 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 single-parameter tool with no output schema, the description covers purpose, constraints, and expected return fields (status, connection ID). Could optionally mention polling frequency or idempotency, but 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% but the description adds context by explaining the parameter's role in polling a setup request, going beyond the bare schema description ('Connection setup link ID').

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

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

The description uses a specific verb ('Poll') and resource ('human-calendar setup request'), and clarifies what it returns (status, connection ID). It distinguishes itself from siblings like create_connection_link and cancel_connection_link.

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

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

The implied usage is to check the status of a setup request, but no explicit guidance on when to use it versus alternatives (e.g., get_event for different data). Lacks when-not-to-use conditions.

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

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

No annotations provided; description discloses scope (works for internal and external events) but omits error handling, permissions, or side effects. Adequate but not exhaustive.

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

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

Three sentences, front-loaded with main action, no redundant text. 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?

No output schema, but description lists all expected return fields (title, times, status, location, reminders, metadata). With two simple params and no nested objects, 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?

Schema covers both parameters with descriptions. Description adds nuance: explains that calendar_id is optional and why to provide it, going beyond 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?

Description specifies exact action ('Retrieve a single event by ID') and lists included fields (title, times, status, etc.). Clearly distinguishes from siblings like list_events and update_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?

Provides explicit guidance on when to use calendar_id: optional but useful to fail fast on cross-calendar typos. Also clarifies that it works for both internal and externally synced events.

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

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

With no annotations, the description carries full burden. It discloses the return values (sync status, etc.) but does not explicitly state that the operation is read-only, has no side effects, or any authorization requirements. Adequate but not comprehensive.

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

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

One sentence clearly conveying the action and scope, with no unnecessary words. Efficient and well-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 tool has only one parameter and no output schema, the description sufficiently covers the purpose and return data. Small gaps like mentioning the subscription must exist or being read-only are minor.

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

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

Schema coverage is 100% (the parameter has its own description). The description adds no further meaning beyond 'by id'. Baseline of 3 is appropriate.

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

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

The description clearly states it retrieves a single iCal feed subscription by ID, specifying the returned fields (sync status, last sync time, last error). This distinguishes it from sibling tools like list_ical_subscriptions (list all) and subscribe_ical (create).

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

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

The description implies usage when needing details of a specific subscription but provides no explicit context on when to prefer this over alternatives (e.g., list_ical_subscriptions) 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?

With no annotations, the description carries full burden. It mentions the returned data (slots and responses), which is helpful, but lacks details on idempotency, error conditions, or side effects. For a simple GET tool, this is adequate but not exhaustive.

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

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

Two succinct sentences, front-loaded with purpose and key constraints. 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 one-parameter GET tool with no output schema, the description is nearly complete. It could mention that the proposal must exist, but that is implicit. Overall, it provides enough context for correct usage.

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 of proposal_id. The description adds only 'by id,' which is redundant. Baseline 3 is appropriate as the schema already 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 explicitly states 'Get a scheduling proposal by id, including its slots and per-participant responses.' This is a specific verb+resource pairing, clearly distinguishing from siblings like list_proposals or resolve_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?

It states 'Requires an org-level API key,' providing an important usage context. However, it does not explicitly contrast with alternatives like list_proposals or resolve_proposal, leaving some ambiguity.

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 explains what the tool returns (usage and plan limits for listed categories) and the auth requirement, but it does not explicitly state that the operation is read-only or non-destructive. Since no annotations are provided, the description carries the full burden, yet it omits explicit behavioral traits like idempotency or lack of side effects.

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

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

Two sentences with no filler: first sentence states the verb and resource with a list of included metrics; second sentence provides essential auth context. Every word contributes, making it highly efficient and easy to parse.

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

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

Given zero parameters and no output schema, the description adequately lists the categories returned (agents, calendars, etc.) and the auth constraint. It could be more complete by describing the output format or error scenarios, but for a simple get-all tool it is reasonably thorough.

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 no parameters (0 params, 100% schema coverage). The baseline for 0 params is 4 as per guidelines. The description adds no parameter-specific info (since there are none), but the auth requirement is a valuable contextual note. No deduction needed, so score 4.

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 tool name 'get_usage' and description clearly state it retrieves the calling org's current-period usage and plan limits, listing specific metrics (agents, calendars, events, etc.). This distinguishes it from sibling tools like 'get_agent' or 'get_calendar' which focus on individual entities, making the purpose unambiguous.

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

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

The description explicitly requires an org-level API key and warns that agent-scoped keys cannot access org-wide usage. This provides clear when-to-use and when-not-to-use guidance, though it does not name alternative tools for agent-scoped keys, which would have earned a 5.

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

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

With no annotations provided, the description fully discloses key behaviors: it returns event types and active state but never the signing secret. It also states the required authentication level (org-level API key). This covers the main behavioral aspects an agent needs to know.

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 minimal yet complete: two sentences that cover the main purpose, included/excluded details, and a prerequisite. Every sentence adds value, and it is appropriately front-loaded.

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

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

Given the tool's simplicity (single parameter, no output schema), the description adequately addresses what the tool does, what it returns, what it excludes, and the required auth context. An agent can confidently decide to invoke this tool based on this information.

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 the only parameter, so baseline is 3. The description adds no additional semantics beyond 'by id', which aligns with the schema description 'Webhook subscription to fetch'. No further enrichment provided.

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

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

The description clearly states the tool's purpose: 'Get a single webhook subscription by id'. It specifies what is included (event types, active state) and what is not (signing secret). This distinguishes it from the sibling tool list_webhooks, which retrieves multiple subscriptions.

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 the prerequisite 'Requires an org-level API key', which guides when the tool can be used. However, it does not explicitly mention when not to use it or alternatives, though the context of sibling tools implies that list_webhooks should be used for multiple webhooks.

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

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

The description does not disclose behavioral traits such as pagination (limit/offset), default limit of 50, or that filtering is available via parameters. Without annotations, the description carries full burden but provides only a bare statement.

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 of 6 words, which is concise but too terse to cover important details. It is front-loaded but lacks structure or elaboration.

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 complexity (4 optional parameters for filtering and pagination) and no output schema, the description is insufficient. It omits key context like default limit, enumeration values, and the fact that 'all' may be limited by pagination. A complete description would mention these details.

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?

Since schema coverage is 100% (all parameters have descriptions), the description adds no extra meaning beyond the schema. Baseline score of 3 is appropriate; the description does not mention any parameter details itself.

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 'List all agents in your organization' clearly identifies the verb (list) and resource (agents), distinguishing it from sibling tools like get_agent (single) or create_agent. However, it does not explicitly differentiate itself from similar list tools like list_booking_pages, but the context of agents vs booking pages is clear.

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

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

No guidance is provided on when to use this tool versus other agent-related tools (e.g., get_agent for a single agent, or list_agents with filters). The description lacks any context on prerequisites, typical use cases, or 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?

Without annotations, the description carries the behavioral burden. It discloses a key behavioral trait: agent-scoped keys only see pages on their own agent's calendars. However, it omits other important details like pagination behavior, return format, or sorting, which are typical for list operations.

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

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

The description is two sentences with no wasted words. The core action is front-loaded, and the scoping detail is relevant and concise. 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?

The tool is simple with two optional parameters and no output schema. The description covers the core action and scoping, but fails to mention return values or pagination behavior. For a list tool, providing return structure 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% and the parameters (limit, offset) are already well-documented in the input schema. The description adds no additional meaning or context for these parameters, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool lists booking pages in the org, which is a specific verb+resource. It distinguishes from sibling tools like get_booking_page (single) and create_booking_page. The additional scoping detail clarifies behavior for agent-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 provides context about scoping but does not explicitly guide when to use this tool versus alternatives like get_booking_page or other list tools. Usage is implied but not clarified with when-not-to-use or alternative recommendations.

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

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

No annotations are provided, so the description carries full burden. It discloses the scoping behavior (org vs agent keys) and the purpose of returning calendar IDs, which is sufficient for a read-only listing tool.

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

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

Two sentences that pack essential information: what the tool does, scope behavior, and usage guidance. No unnecessary words, front-loaded with the main action.

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 4 parameters are well-documented in the schema and no output schema, the description covers the key behavioral aspects and use case. It could mention pagination defaults but those are in the 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%, but the description adds context for 'include' and 'agent_id' beyond the schema descriptions, clarifying their scope restrictions. Limit and offset are standard and don't need extra explanation.

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

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

The description clearly states the verb 'list' and resource 'calendars', and distinguishes scope between org-level and agent-scoped keys. It also connects to the workflow of discovering calendar IDs.

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 'Use this to discover calendar IDs before creating or listing events,' providing a clear use case. It does not mention when not to use it, but the sibling tools are distinct.

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

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

No annotations are provided, so the description carries full burden. It reveals that events include both internal and external iCal-synced events, and details expand behavior (requires time window, max 366 days apart, returns recurringEventId and originalStartTime). This adds meaningful behavioral context beyond the schema.

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

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

The description is three sentences long, front-loaded with the core purpose, and uses clear, direct language. Every sentence adds value without redundancy.

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

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

With no output schema, the description covers the key aspects: listing both internal/external events, the two query modes, and available filters. Pagination (offset, limit) is documented in the schema. Missing details like default ordering are minor for a list 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 parameter descriptions, but the overall description adds semantic value by grouping filters (e.g., 'Narrow with ...') and explaining mutual exclusivity of calendar_id and agent_id. It also clarifies the expand parameter's dependency on start_after/start_before.

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 lists events on a calendar or across an agent's calendars, including both internal and externally synced events. It distinguishes from siblings like get_event (single event) by specifying the scope (multiple events) and the ability to filter by agent or 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 explicitly instructs to provide either calendar_id or agent_id, and lists filtering options (time window, status, source). While it doesn't mention when not to use it, the guidance is clear and sufficient for a list retrieval tool.

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

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

No annotations exist, so the description carries full burden. It discloses that the tool includes sync status and last sync time, but does not mention pagination behavior (though schema implies via limit/offset) or any side effects. Adequate but could be more explicit.

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, clear sentence (18 words) that is front-loaded with the verb 'List' and immediately states the resource. No superfluous 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 description includes the key data fields in the response (sync status, last sync time). Since there is no output schema, this is helpful. It does not mention that the response is an array or handling of empty results, but the schema covers pagination. Overall adequate for a straightforward list 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 clear descriptions for all parameters. The description adds no additional information about parameters beyond what the schema already provides. It reinforces agent_id context but that is minimal added value.

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

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

The description states the action ('list'), the resource ('agent's external iCal feed subscriptions'), and the data included ('sync status and last sync time'). It clearly distinguishes from sibling tools like get_ical_subscription (single) and subscribe_ical (create).

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

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

The description implies when to use it (to list subscriptions for an agent) but does not explicitly mention when not to use it or compare with alternatives like get_ical_subscription. However, the context and sibling tool names provide sufficient guidance.

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

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

With no annotations provided, the description carries the full burden. It discloses the auth requirement and implies pagination via schema params, but lacks details on ordering, default behavior, or response format. 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?

Two concise sentences: first states the core purpose, second adds filter details and auth requirement. No wasteful words, effectively front-loaded.

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

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

For a 4-parameter list operation with no output schema or annotations, the description covers purpose, filters, and auth. Missing details like output format or ordering, but sufficient for typical listing tasks.

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 repeats the filter options and auth requirement, adding minimal extra meaning beyond the schema definitions.

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 'List scheduling proposals for the org' with specific verb and resource, and mentions filtering by status and organizer_agent_id, distinguishing it from single-proposal tools like get_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 mentions the auth requirement ('Requires an org-level API key') and filters, but does not explicitly state when to use this tool over alternatives (e.g., get_proposal) or provide any exclusions or context on 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?

Discloses that only metadata is returned and never the plaintext secret. No annotations provided, so description carries full burden. Could add more about idempotency or rate limits but sufficient.

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 purpose, includes key constraints and return 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?

For a simple list operation without output schema, description adequately covers purpose, constraints, return fields, and auth requirement. No gaps.

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

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

No parameters to document. Schema coverage is 100% effectively. Baseline 4 for zero-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?

Clear verb 'list' and resource 'scoped keys' with qualifiers (live, non-revoked, for org). Distinguishes from siblings like create_scoped_key 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?

States prerequisite (org-level API key). Does not explicitly list when not to use, but purpose is clear enough to infer appropriate context.

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

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

Discloses that it returns counts per status and lists deliveries, but lacks details on pagination, rate limits, or error behavior. Without annotations, more behavioral context would be helpful.

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: first defines purpose, second provides usage and authorization. No unnecessary 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?

Given no output schema, the description mentions per-status counts but does not indicate the overall response structure (e.g., list of objects with metadata). Pagination and error handling are also omitted.

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?

All 5 parameters are described in the schema (100% coverage), so the description adds no extra meaning 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 that it lists delivery attempts for a webhook subscription, with per-status counts, distinguishing it from sibling tools like list_webhooks which list subscriptions.

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 suggests using this to debug failing deliveries and mentions the requirement for an org-level API key, providing good context for when to use.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that signing secrets are never returned (important privacy note) and that an org-level API key is required. However, it does not explicitly state that the operation is read-only or describe pagination behavior beyond schema.

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

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

The description is extremely concise: two sentences with zero wasted words. The key information (what is listed, what is not returned, auth requirement) 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 absence of an output schema, the description gives a reasonable overview (list of subscriptions, event types, active state, no signing secrets). However, it does not mention whether the response includes IDs, URLs, or other fields, and does not clarify ordering or result structure. Middle-of-the-road 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?

The input schema has 100% coverage for both parameters (limit, offset) with descriptions, so the description does not need to add more. It adds no additional meaning beyond the schema, thus baseline score 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 'List' and the resource 'the org's webhook subscriptions', and specifies what is included (subscribed event types and active state) and excluded (signing secrets). It differentiates from siblings like get_webhook (single) 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 includes an important prerequisite ('Requires an org-level API key'), but does not explicitly guide when to use this tool versus alternatives like get_webhook or for filtering. Usage context is implied but not directly stated.

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

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

No annotations are provided, so the description must convey behavioral traits. It discloses that the tool mutates state and frees a slot, but does not specify the resulting event status, whether the action is reversible, or the permissions required. The description is partially transparent but missing key 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?

The description consists of two concise sentences that front-load the purpose and key conditions. Every word adds value, with no redundancy 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 tool has no output schema, the description should explain the expected return value or side effects. It mentions freeing the slot but does not describe what the caller receives (e.g., success message, updated event object) or possible error cases. The single parameter and precondition are well-covered, but the missing return information leaves the description incomplete.

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

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

The input schema covers the single parameter with a description ('Event ID of the hold to release'), achieving 100% coverage. The tool description does not add substantial meaning beyond what the schema already provides, so baseline score of 3 applies.

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

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

The description clearly identifies the tool's action: manually releasing a held event. It specifies the required precondition (status='hold') and the timing condition ('before hold_expires_at'), which distinguishes it from sibling tools like cancel_event or confirm_event.

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

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

The description states when to use the tool (to release a held event before expiry) and the prerequisite status. It does not explicitly mention alternatives or when not to use it, but the conditions imply that it is only applicable to events currently in 'hold' status.

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

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

No annotations provided, so description carries full burden. It explains the decision logic (highest-scoring slot accepted by most participants), creation of calendar event or cancellation, and authorization requirements. Does not detail side effects like notifications, but sufficient for a mutate tool.

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

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

Three concise sentences: action, outcome, usage guidance. Front-loaded with verb and resource, no fluff. Every sentence is valuable.

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?

Single parameter, no output schema, but description fully explains what happens with the input, the decision process, and the resulting action. Includes prerequisites (org-level API key, Pro plan). Completeness is high given low 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?

Single parameter proposal_id with schema description 'Proposal to resolve'. Description adds context that it must be an open proposal with collected responses, but schema coverage is 100% so baseline is 3. Minimal added value beyond 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 clearly states it force-resolves an open proposal using collected responses, picks the highest-scoring slot accepted by most participants, creates a confirmed calendar event, or cancels if all declined. This distinguishes it from siblings like cancel_proposal or 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?

Explicitly says 'Use when you want to close out a proposal without waiting for every participant.' Provides context of required API key and plan. Could mention alternatives like cancel_proposal, but the use case 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?

No annotations are provided, so the description carries full responsibility for behavioral disclosure. It states the auto-resolution behavior, the requirement for selected_slot_id when accepting, and that counter_slots are for counter responses. However, it does not mention failure conditions (e.g., duplicate responses, expired proposals) or rate limits.

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

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

The description is 4 sentences long, each providing distinct information: purpose, response logic, auto-resolution, and prerequisites. It is front-loaded with the core action and efficiently conveys all necessary information without 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 the tool has 6 parameters (3 required) and no output schema, the description adequately covers the workflow: how to respond, auto-resolution, and requirements. It could benefit from mentioning the return value or error handling, but the core interaction is well explained.

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 with descriptions for all parameters. The description adds value by explaining the semantic relationship between response type and parameters: 'accept' requires selected_slot_id, 'counter' uses counter_slots. This goes beyond the schema's individual parameter descriptions.

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

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

The description clearly states the verb 'Submit a response' and resource 'open proposal', and specifies the three response types (accept/decline/counter). It distinguishes from sibling tools by noting auto-resolution when all participants respond, and from cancel_proposal and resolve_proposal by focusing on the response 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 explains when to use the tool ('to an open proposal') and notes that after all participants respond, the proposal auto-resolves, so no separate resolve call is needed. It also lists prerequisites (org-level API key, Pro plan). However, it does not explicitly mention scenarios where the tool should not be used (e.g., if the proposal is already closed).

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?

Describes irreversible nature and timing of effect. No annotations provided, so description fully carries burden; it is transparent and accurate.

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 action, second provides critical details (permanence, timing, auth). No wasted words, front-loaded.

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

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

For a simple revocation tool with one parameter and no output schema, description covers all necessary context: purpose, effect, timing, and auth requirement.

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

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

Schema coverage is 100% and parameter description is already in schema. Description adds no additional semantic value beyond what 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?

Clearly states action (revoke) and resource (agent-scoped API key). Distinct from siblings 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?

Explicitly states permanence, propagation delay (about a minute), and auth requirement (org-level API key). No alternative actions needed.

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?

Without annotations, the description discloses key behaviors: the tool overwrites existing rules ('Upsert'), and set rules automatically affect availability queries ('every availability query on this calendar automatically applies them'). It also notes that passing null to working_hours removes those constraints. Missing details like permissions or rate limits, but overall sufficient for safe use.

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-loading the core purpose in the first sentence. Every word adds value; there is no fluff or repetition. It is efficiently structured to quickly inform the agent.

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 tool with five parameters (one required) and no output schema, the description explains the effect of setting rules on availability queries and the upsert behavior. It is complete enough for an agent to understand the tool's role, though it could mention the return value (e.g., success confirmation) for full 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 the schema fully documents all five parameters. The description adds meaning by summarizing the overall function (buffer times and working hours) and clarifying that buffer minutes are before/after events. While helpful, it does not provide significant additional detail beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Set or replace the availability rules on a calendar — buffer times before/after events and optional per-day working hours.' It uses specific verb 'Set' and resource 'availability rules on a calendar', distinguishing it from siblings like clear_availability_rules or get_availability_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 explains that the rules are automatically applied to availability queries and that the operation is an upsert (overwrites existing rules). However, it does not explicitly mention when not to use this tool (e.g., when to use clear_availability_rules instead), leaving the agent to infer from sibling names.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals important constraints (calendar ownership, incompatibility with org-level calendars) and the effect (external events appear in availability calculations). It does not detail rate limits or immediate fetch behavior, but the disclosed constraints are valuable.

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 paragraph with two sentences. It front-loads the purpose and then provides critical usage guidelines. Every sentence adds value, and there is no redundancy 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 tool's complexity (4 parameters, no output schema), the description adequately covers purpose, usage constraints, and key prerequisites. It could mention what happens after subscription (e.g., immediate sync) or return behavior, but the provided info is sufficient for an agent to use the tool correctly.

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

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

Schema description coverage is 100% (all four parameters have descriptions). The description adds meaning beyond the schema by explaining the ownership constraint for agent_id and calendar_id, and confirming that url is an HTTPS iCal feed. The optional label parameter is not elaborated, but the description compensates well overall.

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 purpose: 'Link an external iCal feed... to an agent's calendar so external events appear in availability calculations.' It uses a specific verb ('link') and specifies the resource (external iCal feed) and the target (agent's calendar). This distinguishes it from sibling tools like sync_ical_subscription or delete_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 provides explicit guidance: 'The target calendar must be owned by the specified agent — create the calendar with that agent_id first...' It also explains when not to use ('org-level calendars without an agent_id cannot host external iCal subscriptions') and suggests an alternative ('create a dedicated per-agent calendar for sync targets').

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool returns once the sync is queued, but lacks details on authentication requirements, rate limits, or potential errors. Adequate but not comprehensive.

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 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 trigger tool with one parameter and no output schema, the description is mostly complete. It explains the action and return behavior. However, it could clarify what 'queued' entails or how to verify sync completion.

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 parameter schema already describes 'subscription_id'. The description adds no extra meaning beyond the schema, meeting the baseline for high coverage.

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

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

The description clearly states the verb 'sync' and the resource 'iCal subscription', and differentiates from waiting for the next scheduled poll. It is specific and distinguishes from sibling tools like subscribe_ical or 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 explicitly says to use this for triggering an immediate sync instead of waiting for the scheduled poll, providing clear usage context. However, it does not mention when not to use or provide 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?

No annotations are provided, so the description carries the full burden. It clearly identifies the tool as a mutation (updating fields) and includes an authorization constraint. However, it does not disclose potential side effects, error conditions, or the return format. With no annotations, additional behavioral detail (e.g., whether partial updates are atomic, what happens to unmentioned fields) would improve transparency.

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 very concise: two sentences that state the function and a key requirement. Every sentence adds value, with no redundancy or filler. The structure is front-loaded with the primary 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 the tool's complexity (5 parameters, no output schema, no annotations), the description covers the core purpose and a critical authorization detail. However, it lacks information about return values, error handling, or success indicators. For a mutation tool, an agent would benefit from knowing what the response looks like or common failure modes.

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 descriptions for all parameters. The description adds meaning by listing the updateable categories (name, description, metadata, or status) and notes that description can be null to clear. This provides context beyond the schema, though the schema already describes each 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?

The description clearly states the verb 'Update' and the resource 'agent' along with the specific attributes that can be modified (name, description, metadata, or status). This distinguishes it from sibling tools like create_agent, delete_agent, and get_agent, making its purpose unambiguous.

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

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

The description explicitly states a key requirement: 'Requires an org-level API key — agent-scoped keys cannot mutate agents.' This provides important context for when the tool can be used. However, it does not discuss alternatives or when not to use this tool relative to other update tools (e.g., update_calendar), so it falls short of a perfect score.

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

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

With no annotations, the description carries full burden; it lists updatable fields but omits critical behavioral details such as side effects (e.g., timezone change on events), idempotency, error states, or resource limits.

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

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

The description is two concise sentences, front-loading the key action and fields, followed by an important authorization note—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 6 parameters, nested objects, and no output schema, the description covers the primary fields and a constraint, but lacks details on return values, error handling, or post-update effects.

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 merely reiterates field names without adding meaning beyond the schema, failing to explain nuances like metadata size limits or default_reminders behavior.

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

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

The description clearly states the verb 'update' and lists the specific calendar attributes that can be modified (name, timezone, agent status, default reminders, metadata), distinguishing it from sibling tools like create_calendar, delete_calendar, or update_event.

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

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

The description provides a crucial authorization constraint ('Agent-scoped keys may only update calendars owned by their agent') but does not guide when to use this tool over other update tools (e.g., update_event, update_ical_subscription) or specify any prerequisites.

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

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

No annotations exist, so description carries full burden. It discloses partial-update behavior ('Provide only the fields you want to change') and constraints (holds not editable, external iCal read-only). Could add more on success/failure behavior or idempotency.

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?

Concise two core sentences plus additional context for constraints and optional parameters. Front-loaded with purpose, 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?

Given 11 parameters, nested objects, and no output schema, the description covers all essential aspects: editable fields, partial update, constraints, optional parameter behavior. Complete for agent usage.

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 (baseline 3). The description adds value by summarizing editable fields, explaining calendar_id optionality, and clarifying reminder mechanics (omit/null/[]).

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 reschedules or edits events, listing specific fields (title, description, times, etc.). It distinguishes from siblings by noting that holds require confirm_event/release_event and 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?

Explicit when-to-use: rescheduling/editing events. When-not-to: for holds (use confirm_event/release_event) and external iCal events. Also explains optional calendar_id resolution.

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

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

No annotations provided, so description must carry full burden. It discloses that changing the URL forces a full re-sync on next poll, which is a key behavioral trait. However, it does not mention idempotency, authorization requirements, or whether other changes are immediate or have side effects.

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 purpose. No redundant information. Efficiently communicates key information without waste.

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

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

Covers core functionality and the re-sync side effect. However, with no output schema, the description does not indicate what the tool returns (e.g., the updated subscription object). For a simple update, this is adequate but not fully 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 all parameters described. The description adds value beyond the schema by linking the URL parameter to the re-sync behavior and clarifying that the tool changes label or URL. This provides context not present in the schema descriptions.

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

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

The description clearly specifies the verb 'update' and the resource 'external iCal feed subscription', with explicit fields that can be changed (label or URL). It distinguishes from siblings like subscribe_ical (create), delete_ical_subscription (remove), and sync_ical_subscription (trigger sync).

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

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

No explicit guidance on when to use this tool versus alternatives. The description implies usage for updating label or URL, but does not mention cases where other tools (e.g., sync_ical_subscription) might be more appropriate. Usage context is only implied by the nature of the tool.

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

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

With no annotations, the description carries full burden. It communicates that the tool mutates webhook settings and requires an org-level API key. However, it does not disclose additional behavioral traits like immediacy, side effects, or irreversibility.

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 with no wasted words. It front-loads the tool's purpose and efficiently lists what can be changed.

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 update tool with no output schema and no annotations, the description covers the essential aspects: action, changeable fields, constraint, and auth requirement. It could be more complete by mentioning error scenarios or 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 coverage for parameters is 100%, so each parameter already has a description. The description adds value by summarizing the overall purpose and introducing the constraint that at least one field must be supplied, which is not in the schema.

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

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

The description clearly states the tool updates a webhook subscription and lists the changeable attributes: delivery URL, event types, and active status. It distinguishes itself 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 clear context for when to use this tool (to update an existing webhook) and mentions the prerequisite (org-level API key). However, it does not explicitly state when not to use it or list alternatives.

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