booking_chest

by dsddet

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
The tools are mostly well-disambiguated, with distinct prefixes for teams, event types, webhooks, etc. However, there is some potential confusion between user-level and event-type webhooks (e.g., list_webhooks vs list_event_type_webhooks) and between private links and general event type operations.
Naming Consistency4/5
Tool names consistently follow a verb_noun pattern (e.g., list_event_types, create_booking), which aids predictability. A minor inconsistency is that some names use 'get' while others use 'list' for retrieval, but this distinction is appropriate for single vs. collection resources.
Tool Count3/5
With 68 tools, the count is high but somewhat justified by the broad scope (bookings, calendars, teams, webhooks, etc.). However, it feels heavy for a typical MCP server, and some tools (like refresh_api_key, check_ics_feed) could be considered extraneous or better merged.
Completeness4/5
The server provides comprehensive CRUD operations for core entities like bookings, event types, schedules, teams, and webhooks. Notable gaps include the absence of a tool to update a booking (only cancel, reschedule, mark no-show) and no tool to get or list team invites (only create).
Average 3.3/5 across 67 of 68 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It merely states 'Create a booking' without disclosing side effects (e.g., notifications sent, slot consumed), permissions needed, or whether the action is reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence, but it sacrifices informativeness for brevity. It earns its place but fails to justify itself with needed details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters, 4 required, and an output schema, the description provides no contextual hooks—no explanation of parameter interplay, no output hints, and no business logic. Critically incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is already documented. The tool description adds no extra semantic context beyond the schema, making it neutral at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'create' and resource 'booking' are clear, with parenthetical 'schedule a meeting' adding context. However, it does not differentiate from sibling booking tools like cancel_booking or reschedule_booking, missing an opportunity to clarify scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as reserve_slot or get_available_slots. Prerequisites like having an event_type_id or checking availability are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It does not indicate whether subscribing requires special permissions, whether it mutates state (e.g., creates a stored subscription), what happens on failure (e.g., invalid URL), or if there are rate limits. 'Subscribe' implies a persistent change, but this is left implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At 5 words, the description is extremely concise. However, it is too terse for a tool with 2 parameters and a persistent effect; additional context would be justified. The front-loading of the purpose is good, but the brevity comes at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is an output schema (not shown but confirmed present), the description need not explain return values. However, the tool handles external URL subscriptions, which implies error handling (invalid URLs, network issues) and side effects (data persistence). The description omits all of this, making it incomplete for practical usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds no further meaning beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Subscribe to external ICS calendar feeds,' which clearly identifies the verb (subscribe) and resource (ICS feeds). However, it does not distinguish this tool from the sibling tool `check_ics_feed`, which also deals with ICS feeds, so the differentiation is missing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like `check_ics_feed`. There is no mention of prerequisites (e.g., needing a feed URL format), when not to use it, or what the subscription entails in terms of ongoing behavior (e.g., polling).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only says 'Update' which implies mutation but does not specify required permissions (e.g., admin or owner), whether changes are immediately active, what happens to existing triggers if 'active' is toggled, or if partial updates are allowed. The response format or side effects are not mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but under-specified. It does not front-load critical details; it provides the bare minimum without earning its place by adding value beyond the tool name. A bit more context would improve utility without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description need not explain return values. However, the tool has a nested 'fields' object (flagged by context) and is a mutation without annotations or behavioral guidance. Competitors like 'update_webhook' exist, and no cross-reference is provided. The description is incomplete for an agent to safely select and invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description itself adds no parameter information beyond the schema. The 'fields' parameter is a nested object with a helpful example in its schema description, but the tool description does not reinforce or clarify the permissible keys (e.g., 'subscriberUrl', 'active') or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Update an event type webhook' which is a clear verb+resource pair. However, it does not distinguish this from its siblings like 'update_webhook', 'update_team_event_type_webhook', or 'delete_event_type_webhook' which operate on similar resources. The purpose is minimally clear but lacks differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives such as 'update_webhook' (general webhook) or 'update_team_event_type_webhook' (team-scoped). The description does not mention prerequisites, context, or when not to use it, leaving the agent to infer based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description alone must disclose side effects. It fails to mention irreversibility, attendee notifications, or cancellation policies, leaving the agent blind to important behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence is efficient but lacks detail. Conciseness is achieved at the cost of valuable context, earning a mediocre score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema and well-documented parameters, the description omits critical context such as whether cancellation is reversible, prerequisite booking state, or how it interacts with other booking lifecycle tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; both parameters have clear descriptions in the schema. The description adds no additional meaning, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'Cancel' and resource 'booking' clearly convey the action. It distinguishes from siblings like reschedule_booking or mark_booking_no_show, but lacks additional context such as the effect on the booking's status or related notifications.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to cancel vs reschedule or mark no-show. Sibling tools exist for other modification actions, but the description provides no selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states the action without mentioning side effects (e.g., whether deletion is permanent, if it triggers downstream events, or if it requires certain permissions). This is insufficient for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at three words, with no wasted content. It is front-loaded and clear, but some would argue it is under-specified given the missing context for a destructive tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a destructive operation with no annotations, and the output schema exists but is not referenced, the description should provide more context about return values, error states, or prerequisites. It is incomplete for safe agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'webhook_id', which is well-documented as 'Webhook ID' in the schema. The description adds no extra meaning beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Delete a webhook' which is a clear verb+resource combination. However, among siblings like 'delete_event_type_webhook' and 'delete_team_event_type_webhook', it does not differentiate itself, leaving ambiguity about what kind of webhook this applies to (e.g., general webhooks vs. event-type-specific webhooks).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'delete_event_type_webhook' or 'delete_team_event_type_webhook'. It does not specify prerequisites, idempotency, or consequences of deletion, leaving the agent without decision-making support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It does not clarify whether the tool performs a read-only check, what happens if the subscription is invalid, or any side effects. The description is too brief to convey essential behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it omits necessary context. It earns its place but fails to convey enough information for an effective tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown), the description need not detail return values, but it should clarify what 'subscription status' means, what possible statuses exist, and how this differs from other calendar checks. The description is incomplete for a tool with no parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema description coverage is 100%, so the schema adds no constraints. The description correctly implies that no further input is needed. A baseline of 4 is appropriate given no parameters require elaboration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Check ICS calendar feed subscription status', which communicates a specific action (check status) on a resource (ICS feed subscription). However, it does not differentiate from the sibling tool 'save_ics_feed' or other calendar tools like 'check_calendar_connection'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as 'save_ics_feed' or 'check_calendar_connection'. The description lacks context about prerequisites or situations where checking the ICS feed status is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It fails to mention idempotency, duplicate behavior, URL validation, authentication requirements, or side effects. The only behavioral clue is implicit in 'create', but critical details are missing 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is efficient but omits necessary information. It is under-specified rather than truly concise. A better structure would front-load the purpose and then clarify usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of sibling webhook tools and a detailed input schema, the description is incomplete. It does not explain how this tool differs from 'create_webhook' or what the 'event type' concept entails. The output schema exists, so return values are covered, but usage context is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents each parameter's purpose. The description adds no additional semantics or usage guidance beyond what the schema provides. A baseline score of 3 is appropriate given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and resource 'webhook for a specific event type'. However, it does not distinguish this tool from sibling 'create_webhook', which may serve a similar but more generic purpose. The purpose is clear on its own but lacks differentiation within the broader toolset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool versus alternatives like 'create_webhook' or 'create_team_event_type_webhook'. It also lacks context on prerequisites, appropriate scenarios, or 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It merely states 'Create an availability schedule' with no mention of side effects, permissions, idempotency, or any operational constraints. The input schema hints at behavior (e.g., 400 error without is_default) but the description itself adds zero behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but lacks structure. While it earns its place by stating the purpose, it does not front-load additional context or use any formatting. For a tool with 4 parameters and an output schema, a more structured description would be beneficial.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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, output schema, many siblings), the description is insufficient. It fails to mention key aspects like the purpose of the schedule, time zone handling, the significance of is_default, or any constraints. The output schema exists but the description does not reference it or explain what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond what the input schema already provides for each parameter. It does not explain parameter relationships, formats, or constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create an availability schedule' uses a specific verb 'Create' and resource 'availability schedule', clearly distinguishing it from sibling tools like list_schedules, get_schedule, update_schedule, and delete_schedule. The purpose is immediately clear and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, no prerequisites, no context for when not to use it, and no mention of the required 'is_default' field's significance. The user must infer usage solely from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. Only states 'create', with no disclosure of side effects, idempotency, authentication needs, rate limits, or response behavior. Output schema exists but is not referenced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise but lacks structure. It is front-loaded but fails to provide essential information, making it under-specified rather than efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, many siblings, and no annotations, the description is far from complete. It does not explain return values, error conditions, or how this tool differs from similar webhook creation tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds no additional meaning beyond the schema; it does not explain parameter semantics like valid triggers or URL format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create a webhook for a team event type' which is a clear verb+resource. It distinguishes from generic webhook and event type webhook by specifying 'team event type', but does not explain what a webhook is or its purpose beyond creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like create_event_type_webhook or create_webhook. No prerequisites, context, or when-not-to-use provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only states 'Cancel' which implies a destructive/mutating action, but does not explain side effects (e.g., freeing the slot), authentication requirements, or reversibility. This is insufficient for an agent to understand the full impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise at one sentence, but it is under-specified. It earns its place but lacks depth. The structure is front-loaded, but the brevity sacrifices completeness. It is not a tautology, but it is not well-calibrated for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 annotations, output schema exists but is not shown), the description is too sparse. It does not explain the outcome of cancellation, how it differs from 'cancel_booking', or any constraints. The context signals include many sibling tools, but the description fails to provide enough information for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter 'uid' described as 'Reservation UID (from reserve_slot response)'. The description adds no additional meaning beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Cancel a slot reservation' clearly states the action (cancel) and the resource (slot reservation). It is specific and avoids tautology. However, it does not explicitly differentiate from the sibling 'cancel_booking' tool, relying on the agent to infer the distinction between a slot reservation and a booking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives such as 'cancel_booking' or 'reserve_slot'. No prerequisites, context, or exclusions are mentioned. The schema's parameter description hints at the source of the UID, but this is not part of the tool description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states 'Update,' implying mutation, but does not explain whether the update is partial or full, whether it requires specific authorization, or whether the operation is reversible. The description adds no details beyond the verb itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, but it is too brief to be fully helpful given the tool's complexity (3 required params, no annotations). It earns its place but could include a bit more context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having a 100% schema coverage and an output schema (unknown richness), the description does not explain the behavior of the 'fields' parameter (e.g., whether it merges or replaces), nor does it clarify enterprise-specific constraints. Sibling tools provide context, but the description alone is insufficient for an agent to confidently invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all three parameters have descriptions in the schema). The tool description does not add any additional meaning beyond what the schema provides. Baseline of 3 is appropriate because the schema already explains each parameter's role.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and the resource ('private booking link') with an enterprise qualifier. It distinguishes the tool from siblings like create_private_link, delete_private_link, and list_private_links. However, it does not elaborate on the scope of updates, e.g., which fields beyond the schema example are modifiable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No instructions are provided on when to use this tool versus alternatives, such as when a partial update is needed vs. using create_private_link anew. There is no mention of prerequisites (e.g., user must have enterprise permissions) or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 disclosing behavioral traits. It does not mention that this is a mutation (creating a new resource), any required permissions, rate limits, or side effects. The description is too brief given the lack of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at one sentence. It is front-loaded with the core action and resource. However, the brevity sacrifices necessary detail for a mutable tool with many parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (12 parameters, no annotations, and an output schema), the description is incomplete. It fails to explain the return value, error scenarios, or how this tool relates to siblings like 'create_team_event_type'. The tool is a mutation with many parameters, requiring more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond what the schema already provides. For a tool with 12 parameters, the description could add value by summarizing key parameter groups or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('event type'), and provides helpful synonyms in parentheses ('meeting type / booking page'). This distinguishes it from siblings like 'list_event_types' or 'update_event_type'. However, it could be slightly more precise about what an event type represents in this domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. For example, it doesn't mention that 'create_team_event_type' is the sibling for team-level event types, or that users should first list existing event types to avoid duplicates. No prerequisites or context about team vs. personal event types are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It does not mention whether this requires special permissions, if an existing invite is revoked when a new one is generated, or any expiration behavior. The description only states what it returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the main purpose. The second sentence adds value by stating the return values. However, it could be slightly more compact by merging the two sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description need not explain return values, but given the tool's simplicity (1 param) and the lack of annotations, the description is complete enough for a basic understanding but fails to provide important context like permissions and behavior of replacing existing invites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the single parameter (team_id) with a clear description. The description adds no extra meaning beyond what the schema provides, warranting a baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Generate a team join invite) and the resource (team invite link). It returns a token and inviteLink, distinguishing itself from sibling tools like create_team, create_team_membership, or list_team_members, but does not explicitly differentiate from them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool vs alternatives like create_team_membership or list_team_members. It does not mention prerequisites (e.g., user must be a team admin), nor does it instruct on sharing the inviteLink.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. The description 'Add a user to a team' implies a simple direct addition, but the schema reveals an 'accepted' parameter with default false, suggesting the tool actually creates a pending invitation. This contradiction is not clarified. The description also omits permission requirements, mutability, side effects (e.g., notifications), and whether the operation is reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—one sentence of five words. It earns its place by stating the core action without fluff. However, it could be slightly expanded to include key behavioral context without losing conciseness (e.g., 'or send an invitation' for the accepted parameter).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, an output schema, and several sibling tools (create_team_invite, update_team_membership, etc.), the description is severely incomplete. It does not address the invitation versus direct addition distinction, the role options, the meaning of the 'accepted' parameter, or any return value details. The presence of an output schema reduces the need to describe return values, but the description still fails to provide essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with each parameter already documented (role, team_id, user_id, accepted). The tool description adds no additional meaning or context beyond what the schema provides. Baseline of 3 is appropriate since the schema carries the entire burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add a user to a team' uses a clear verb+resource structure, making the tool's purpose immediately understandable. However, it does not differentiate from sibling tools like create_team_invite, which may have a similar intention but different behavior (invitation vs direct addition). The purpose is clear but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives such as create_team_invite, update_team_membership, or list_team_members. There are no prerequisites, context hints, or exclusions stated, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It merely states the action 'Delete an event type.' without revealing any side effects, required permissions, irreversibility, impact on associated data (e.g., webhooks, bookings), or other behavioral traits. This is a critical gap for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. However, its brevity sacrifices necessary behavioral information, so while it is structurally efficient, it does not fully earn its place by compensating with missing details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations and a single required parameter, the description is insufficiently complete. It omits any context about prerequisites, irreversibility, or how this fits among sibling tools like update_event_type or get_event_type. The presence of an output schema slightly reduces the need to describe return values, but overall the description lacks the depth needed for an agent to use it safely and correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the parameter 'event_type_id' has a description 'Event type ID'). The tool description adds no additional meaning beyond what the schema already provides, so it meets the baseline without adding value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete an event type.' clearly specifies the verb (Delete) and the resource (event type). Among sibling tools, there are other delete operations like delete_event_type_webhook and delete_schedule, so this description uniquely identifies the action on event types without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 over alternatives (e.g., update_event_type or get_event_type). No prerequisites, preconditions, or exclusions are mentioned, leaving the agent without context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must bear the full burden of behavioral disclosure. It states the action (delete) and hints at mutability but provides no details on side effects (e.g., whether webhook configuration is permanently removed, if dependent processes fail, or if authentication is required). This is a critical gap for a destructive action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that conveys the core action without extraneous words. It is appropriately sized for a straightforward deletion operation, though it could benefit from a slight front-loading of context (e.g., 'Deletes an existing webhook for a specific event type').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 parameters, no nested objects) and the presence of an output schema (which likely documents return values), the description is moderately complete. However, the lack of behavioral transparency and usage guidance leaves gaps for an agent deciding when to invoke this versus sibling deletion tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters (event_type_id and webhook_id) with descriptions. The tool description adds no additional parameter meaning beyond what the schema provides, placing it at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair ('Delete an event type webhook'), making it clear what the tool does. It distinguishes itself from sibling tools like 'delete_webhook' (which likely deletes a general webhook) and 'delete_team_event_type_webhook' (team-specific) by scoping to event type webhooks, though it could explicitly differentiate these sibling relationships.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided—no when or when-not to use, no prerequisites (e.g., permissions required), and no mention of alternatives among siblings. For instance, it doesn't clarify when to use this versus 'delete_webhook' or 'delete_team_event_type_webhook', leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states 'Delete a schedule' without indicating irreversibility, cascade effects, required permissions, or whether the action is safe to undo. This is insufficient for an agent to understand consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (three words), which is concise but at the cost of necessary detail. It fails to earn its place because it adds nothing beyond the tool name, making it essentially a tautology.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description omits crucial context for a destructive operation: irreversibility, effects on associated data, or permission requirements. It is incomplete and does not adequately inform the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with a single parameter 'schedule_id' described as 'Schedule ID'. The tool description adds no further meaning, so baseline 3 applies per the rule that high schema coverage limits the need for additional param info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The tool name and description 'Delete a schedule' clearly state the verb and resource. Among sibling tools like create_schedule, update_schedule, list_schedules, and get_schedule, this description distinguishes itself by specifying the destructive action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as verifying that the schedule exists or checking impacts on linked resources, leaving the agent with no context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist to describe behavior. The description only states 'Delete a team' but fails to disclose key behavioral traits like irreversibility, cascading deletion of associated resources (e.g., members, event types, webhooks), required permissions, or error conditions. For a destructive mutation operation, this lacks essential transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence of only 3 words. It is front-loaded and efficient, with no unnecessary text. However, it may be too terse given the need for behavioral transparency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a 'delete' operation with potential irreversibility and cascading effects, the description is incomplete. Although there is an output schema, the description should clarify what happens when a team is deleted (e.g., deleted team members, event types, webhooks). It lacks sufficient context for an agent to safely use this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single 'team_id' parameter described as 'Team ID' in the schema. The description adds no additional semantic context beyond that. Baseline score 3 is appropriate since the schema already provides adequate parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a team' clearly states the action (delete) and the resource (team). It is specific and distinct from sibling tools like 'create_team', 'update_team', 'get_team', and 'list_teams', 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.
Usage Guidelines2/5
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 prerequisites (e.g., permissions needed, whether the team must be empty), potential side effects (e.g., what else gets deleted), or when to avoid using it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden to disclose behavior. It only states 'Delete a team event type' which implies a destructive mutation, but it doesn't confirm irreversibility, cascade effects (e.g., cancel associated bookings), authentication requirements, or rate limits. The output schema exists but isn't leveraged in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence and no redundant information. However, given the low behavioral transparency, the brevity undermines completeness. It could be restructured to front-load key behavioral context (e.g., 'Permanently delete a team event type. This action cannot be undone.') without adding length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 params, no enums, output schema exists) but the description lacks completeness. It fails to explain return value (output schema exists), scope (team-specific), or side effects. Sibling tools like 'get_team_event_type' and 'update_team_event_type' suggest a CRUD lifecycle, but the delete step is underspecified. Annotations could compensate but are absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema; it merely restates the parameter fields indirectly. The agent must rely solely on the JSON schema for parameter semantics (e.g., team_id and event_type_id are integers with simple labels). No explanations of their relationship or validation rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the resource ('a team event type'), which is a specific verb+resource pair. However, it does not differentiate from sibling tools like 'delete_event_type' (which likely operates on individual event types) or 'delete_team_event_type_webhook', leaving the agent uncertain about scope without context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives like 'delete_event_type' or 'update_team_event_type'. For example, it doesn't specify whether this tool is for deleting team-scoped event types (requiring team_id) versus user-level ones. The description lacks context on prerequisites or consequences (e.g., affects future bookings).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It fails to mention that deletion is irreversible, whether it requires special team permissions, or if cascading effects (e.g., losing webhook data) occur. The description is too minimal for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that conveys the core action and resource with no fluff. It is well-structured and front-loaded. However, it could be slightly more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a delete operation (destructive, requires correct IDs, team context, possibly irreversible), and the lack of annotations or output schema (though one is present but not used), the description is under-specified. It does not clarify return values, error conditions, or prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents each parameter's type and name. The description adds no extra meaning (e.g., how to obtain these IDs or valid ranges). Baseline 3 is appropriate since the schema handles the burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the resource ('team event type webhook'), which distinguishes it from webhook-related siblings like 'delete_webhook' (team-agnostic webhook) and 'delete_event_type_webhook' (non-team event type webhook). The verb-resource combination is 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.
Usage Guidelines2/5
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 alternatives (e.g., 'delete_webhook' or 'delete_event_type_webhook'). It does not mention prerequisites, such as needing the webhook ID from a list operation, nor does it indicate that this affects only this specific event type's webhook.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral transparency. It only says 'list bookings with optional filters' and does not disclose authentication needs, data scope (e.g., current user only), pagination behavior, or read-only nature. This is insufficient for safe and effective agent usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—one sentence with no superfluous words. It is front-loaded. However, it may be too brief given the tool's complexity and multiple parameters; a bit more structure could improve clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the presence of an output schema, the description lacks critical context. It does not clarify the scope of the list (e.g., personal vs. all bookings), pagination details, or how this tool relates to similar ones. A more complete description would include such context to aid proper usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no meaning beyond the schema; it merely states 'optional filters' without elaborating on what filters exist or how they work. The schema already describes each parameter adequately, so the description provides negligible added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists bookings and supports optional filters, which is a specific verb-resource combination. However, it does not differentiate from sibling tools like list_team_bookings or get_booking, which could cause confusion about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. For example, it doesn't indicate that get_booking is for a single booking or that list_team_bookings is for team bookings. No exclusions or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits fully. However, it only states the core action without mentioning whether this is a read-only or destructive operation, whether it requires specific permissions, what the response format looks like, or whether there are any side effects. The description does not contradict any annotations (as none exist), but it leaves significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of nine words, which is concise and front-loaded. Every word earns its place, but it could be slightly more informative without sacrificing brevity – for example, noting the team scope to differentiate from 'list_bookings'. The structure is clear and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is relatively simple (1 parameter, no enums, has output schema), a 3-sentence description might be sufficient. The description covers the basic purpose, but it lacks differentiation from siblings (especially 'list_bookings') and does not leverage the existence of an output schema to describe what is returned. An agent may not understand the team-centric scope without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description adds value by clarifying that the team_id parameter refers to the team whose event type bookings are being listed. However, it does not explain what 'bookings for a team's event types' means – e.g., whether these are bookings made by team members or bookings on team event types. Still, it adds enough context beyond the terse schema description ('Team ID') to warrant a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all bookings for a team's event types' uses a specific verb ('list') and identifies the resource ('bookings for a team's event types'). It clearly states what the tool does, but it does not distinguish itself from sibling tools like 'list_bookings' (which likely lists individual bookings) or 'list_team_event_types' (which lists event types, not bookings). The differentiation from 'list_bookings' is implied by the 'team' qualifier but not explicitly addressed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. Given the sibling tool 'list_bookings' exists, an agent would benefit from knowing whether to use 'list_team_bookings' for team-scoped bookings and 'list_bookings' for personal/organization-level bookings. There are no when-to-use, when-not-to-use, or prerequisite instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must convey all behavioral traits. It only states 'Update', implying mutation, but does not disclose potential side effects, authorization requirements, idempotency, error handling, or what happens if the webhook does not exist. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 6 words, which is very concise and front-loaded. While it efficiently conveys the core action, it may be too terse given the complexity of the tool. One could argue a slightly longer description would be more helpful, but brevity alone is not a flaw.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 required parameters, a nested 'fields' object, an output schema, and many closely related sibling tools. The description does not explain the relationship between team, event type, and webhook, nor does it state prerequisites or the expected effect of updating a webhook. This is inadequate for an agent to understand the full context and correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents each parameter. The description adds no additional meaning to the parameters, such as clarifying the structure of the 'fields' object beyond the example in the schema. Baseline of 3 is appropriate as the description does not degrade or enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a team event type webhook' clearly states the action (update) and the specific resource (team event type webhook). It distinguishes from sibling tools like 'update_event_type_webhook' (non-team) and 'create_team_event_type_webhook'. However, it lacks detail about what aspects of the webhook can be updated, which would improve clarity further.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not help the agent decide when to use this tool versus similar alternatives like 'update_event_type_webhook', 'update_webhook', or 'create_team_event_type_webhook'. There is no mention of prerequisites or context for team-level updates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states the action and scope, omitting traits like read-only nature, authentication needs, pagination, output format, or whether it returns schedules for all members. The output schema exists but the description adds no behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4 words) but under-informative. It is front-loaded and efficient, but does not earn its place fully because it lacks context that would help the agent use the tool correctly. Conciseness without completeness is not sufficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, an output schema, and no annotations, the description is too minimal. It does not explain what 'availability schedules' are, how they relate to sibling tools like 'list_schedules' or 'get_schedule', or what the output contains. The context of team-specific schedules is implied but not elaborated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (team_id has a description 'Team ID'), so the baseline is 3. The description does not add any extra meaning beyond the schema, such as clarifying what the team_id represents or how to obtain it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List availability schedules for team members' uses a specific verb ('list') and resource ('availability schedules for team members'), clearly distinguishing it from siblings like 'list_schedules' (general) and 'get_schedule' (single schedule). The team scope is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as 'list_schedules', 'get_schedule', or team-specific tools like 'list_team_bookings'. It does not specify prerequisites, team membership requirements, or 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It only states 'reschedule a booking' without disclosing side effects (e.g., freeing the old slot, conflict checks, permission requirements, or what happens to the existing booking). This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (8 words) and front-loaded, but it sacrifices completeness for brevity. While concise, it could incorporate key usage hints without becoming verbose. It is acceptably structured but borderline under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and full schema coverage, the description omits crucial context: what triggers success, error scenarios, and whether the new time slot must be pre-validated. For a tool that mutates resources, this is incomplete and leaves the agent guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema's parameter descriptions; it does not elaborate on formats, constraints, or relationships between parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (reschedule) and the resource (a booking) with a specific target (new time slot). It effectively distinguishes from sibling tools like cancel_booking, create_booking, and mark_booking_no_show by naming the unique operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 prerequisites (e.g., checking slot availability, booking existence) or when not to use it. With many booking-related siblings, explicit usage context is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. The description states 'Remove' implying a destructive action, but it does not mention side effects such as whether this affects future bookings, schedules, or other team data. It also does not specify the return value or error conditions. The tool is likely destructive, but no such hint is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, no fluff. Every word is needed and clear. It is appropriately front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no enums, output schema exists), the description is minimally adequate. The output schema is not shown, but context indicates it exists, so return values are not required in description. However, the lack of behavioral detail on side effects and usage context is a gap for a destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing 'Team ID' and 'Membership ID' in the schema. The description adds no further meaning about these parameters, e.g., how to obtain the membership_id or whether membership_id is unique only within a team. Baseline 3 is appropriate given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is clear and direct: 'Remove a member from a team.' The verb 'Remove' combined with 'member' and 'team' leaves little doubt. It differentiates from siblings like 'create_team_membership', 'update_team_membership', and 'get_team_membership', though it does not explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives (e.g., 'delete_team' which removes the entire team, or 'update_team_membership' which might change role instead of removal). There are no prerequisites, no conditions on membership status, and no warning about consequences of removal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only says 'Get OAuth authorization URL' without explaining behavioral traits: the URL is temporary, requires user authorization, and may expire. It also does not disclose side effects (e.g., a pending connection state). The description is too minimal to inform an agent about the tool's behavior beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the key action. It is concise and avoids unnecessary words. However, it could briefly mention the OAuth flow context without becoming verbose. Still, it earns its place with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's role in an OAuth flow (two parameters, output schema exists), the description lacks critical context: it does not explain that the URL is used to redirect a user for authorization, that it is part of a multi-step process, or that the redirect_url parameter is critical for the callback. The schema and output schema help, but the tool description is insufficient for an agent to understand the full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both parameters have detailed descriptions in the schema (redirect_url: 'Where to redirect after OAuth authorization'; calendar_type: provider with correct values). The tool description adds no additional meaning beyond the schema. Per guidelines, baseline is 3, and no extra value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 OAuth authorization URL to connect a calendar.' It uses a specific verb ('Get') and resource ('OAuth authorization URL'), and it distinguishes itself from sibling tools like list_calendars (which lists calendars) or check_calendar_connection (which checks connection status). No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. For example, it does not mention that this URL is needed before calling check_calendar_connection, or that it requires user interaction. Sibling tools like add_selected_calendar or set_destination_calendar also exist, but no context is given about the OAuth flow sequence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral transparency. It does not disclose whether the tool is read-only, requires authentication, handles errors, or what happens if the ID does not exist. Since there is no contradiction with annotations (none exist), no flag is raised, but the description is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and to the point. Every word is functional and there is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and only one parameter fully described in the schema, the description is minimally adequate but lacks context on behavior and usage boundaries. For a simple get-by-ID operation this is borderline sufficient, but additional context about error handling or permissions would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage with a clear description for event_type_id ('Event type ID'), so the baseline is 3. The tool description does not add any new information beyond the schema, which is acceptable because the schema already adequately defines the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get an event type by ID' clearly states the action (get) and resource (event type) along with the lookup method (by ID). It distinguishes this read operation from siblings like list_event_types and create_event_type, though it could be slightly more specific about the uniqueness of the lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like list_event_types, and no mention of prerequisites or typical use cases. The agent must infer from context that this is for retrieving a single event type rather than listing all or creating one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states it is a read operation ('List'), but omits important details such as existence of pagination, sorting, rate limits, or whether the response includes full schedule objects or summaries. Given the simplicity (zero parameters), the minimal disclosure is insufficient for robust agent reasoning.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently communicates the primary action and resource. Given the tool's simplicity (no parameters, no annotations), this level of conciseness is appropriate and does not omit critical information that would fit in a similarly short statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (not shown) and no parameters, the description does not mention what the output represents (e.g., user's schedules, organization-wide). It fails to clarify scope in the context of sibling tools like list_team_schedules. For a simple read tool, it is minimally adequate but leaves room for agent uncertainty.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and schema coverage is 100% (trivially). The description 'List all availability schedules' adds a scope qualifier ('all') but does not add meaningful parameter semantics beyond what the empty schema already conveys. Per guidelines, baseline is 3 when coverage is high, and the description does not exceed that baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all availability schedules' clearly identifies the verb (list) and resource (availability schedules). It distinguishes from singular fetch tools like get_schedule and mutation tools like create_schedule. However, it does not clarify whether this returns schedules for the current user or across teams, which is important given the sibling list_team_schedules. The agent might need to infer scope from context or name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 over alternatives such as list_team_schedules or get_schedule. The description does not mention prerequisites, allowed contexts, or typical use cases. An agent would need to rely solely on the tool name to differentiate, which is risky when multiple list-like tools exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full safety disclosure burden. While "List" conventionally implies read-only, the description does not explicitly state that the tool is non-destructive, has no side effects, or requires specific permissions. The absence of any behavioral cues makes the tool's transparency inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of six words, front-loaded with the verb and resource. There is zero fluff; every word is essential to communicate the core purpose. This is an exemplary use of conciseness given the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one well-documented parameter and an output schema (exists but not described), the description is minimally viable. It tells what the tool does but omits details like whether it returns all event types for the team, pagination behavior, or any relationship to the output schema. In a larger context of many sibling tools, this lacks the depth to fully prevent misuse.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (team_id described as "Team ID"), so the baseline is 3. The description adds no additional meaning to the parameter beyond what the schema already provides. This is acceptable but does not exceed the minimum expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description "List event types for a team." uses a specific verb (List) and resource (event types) with a clear scope (for a team), effectively distinguishing it from sibling tools like list_event_types. However, it simply restates the tool name without adding deeper context about what qualifies as a "team event type."
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 over similar ones (e.g., list_event_types) or any prerequisites (e.g., requiring an existing team). The sibling tools list includes a related tool list_event_types, but the description does not help an agent decide which one to call based on intent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description warns about the validation error if scheduling_type is missing, which is helpful. But it does not disclose that this is a write operation (mutation), whether it requires special permissions, what side effects may occur (e.g., notifications, conflicts with existing event types), or the nature of the response. For a creation tool with no annotation safety net, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: one line defining purpose and one line highlighting the critical scheduling_type requirement. No fluff. It accomplishes the goal efficiently. Loses a point because it could integrate the requirement hint more naturally into the purpose line for better front-loading.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is moderately complex (6 parameters, 5 required) and has an output schema (which reduces need to explain return values), the description is minimally adequate. It covers the essential purpose and a key gotcha. However, it doesn't explain how team event types differ from individual ones, what scheduling_type values mean concretely (beyond schema), or the significance of slug/team_id. A team event type creation tool could use a bit more contextual richness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already describes each parameter (slug, title, team_id, description, scheduling_type, length_in_minutes) well. The description adds one useful detail: that scheduling_type (despite being required in the schema) is specifically needed for team event types to avoid validation errors. This is a minor addition beyond the schema. Baseline 3 is appropriate since schema does most of the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a team event type.' This is a specific verb ('Create') and resource ('team event type') that distinguishes it from siblings like 'create_event_type' (individual), 'create_team', or 'create_team_invite'. It lacks nuance about team event types vs. individual ones, but it's still clear enough for a 4.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description emphasizes that 'scheduling_type is REQUIRED for team event types (API returns validation error without it).' This provides a critical usage hint about mandatory parameters. However, it does not guide when to prefer this tool over 'create_event_type' (individual) or 'update_team_event_type' (modify existing). No when-not-to-use or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must convey behavioral traits. 'Delete' implies irreversibility and potential cascade effects, but the description does not elaborate on what happens upon deletion (e.g., whether bookings referencing the link are affected). This partial disclosure is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and resource. Every word serves a purpose. Could optionally add more details without bloat, but current length is effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only two parameters, 100% schema coverage, and no nested objects, the description is mostly adequate. However, since there is no behavioral context beyond 'Delete' and the enterprise note, completeness is moderate. The output schema exists but is not described, which is acceptable per rules.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both link_id and event_type_id are documented with their types and descriptions. The description does not add further semantic detail beyond what the schema provides (e.g., how to obtain link_id or event_type_id). Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete'), the resource ('private booking link'), and notes it's enterprise-only with parentheses. It distinguishes from sibling tools like create_private_link, update_private_link, and list_private_links by conveying the destructive operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_private_link) or when not to use it. The enterprise mention implies constraints but doesn't list prerequisites or required permissions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description correctly implies a read operation (Get), but does not mention what the response contains, whether it requires specific permissions, or what happens if the webhook does not exist. An output schema exists which may mitigate some of this gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It could be slightly more informative without losing conciseness, but it is appropriately front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three required parameters and an output schema, the description is minimally complete. However, it lacks context about the relationship between the three IDs, the expected behavior upon success or failure, and any distinctions from similar read tools. The output schema likely provides return structure, so the description is adequate but could be richer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully documented in the schema with descriptions like 'Team ID', 'Webhook ID', and 'Event type ID'. The description adds no additional semantic context 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a webhook for a team event type' uses a clear verb (Get) and identifies the specific resource (webhook) scoped to a team event type. However, it does not differentiate itself from the sibling tools 'get_webhook' or 'list_team_event_type_webhooks', which could cause confusion about whether this retrieves a single webhook by ID or lists many.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. With siblings like 'get_webhook', 'list_team_event_type_webhooks', and 'delete_team_event_type_webhook', the description should clarify that this is for retrieving a single webhook by explicit IDs, not for listing or modifying.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. The description correctly identifies the operation as a list (read-like), but it does not disclose whether pagination, filtering, or authentication is required. Since it is a list operation, the lack of destructive hint is acceptable, but more detail on return format would help.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 8 words, which is very concise and front-loaded with the key action and resource. However, it could include a bit more context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description does not need to explain return values. The description is minimal but adequate for a simple list operation with one parameter. However, it lacks any mention of the Enterprise scope or potential filtering, which would be useful for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the single parameter 'event_type_id' is described as 'Event type ID' in the schema). 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool will 'List private booking links for an event type', which is a specific verb ('List') and resource ('private booking links' for an event type). The parenthetical '(Enterprise)' disambiguates the scope, but it does not distinguish from siblings like 'create_private_link' or 'update_private_link', though those are clearly different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as 'create_private_link', 'update_private_link', or 'delete_private_link'. It does not mention prerequisites (e.g., Enterprise plan required) or any context indicating when listing is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states roles are included, which is a behavioral trait. However, no annotations are provided, so the description carries the full burden. It does not disclose whether the tool is read-only (likely but unconfirmed), whether pagination is used, or what happens if the team_id is invalid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that is well-front-loaded with the key action. It wastes no words but could benefit from a brief note about team membership types or scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the description need not explain return values. However, the tool is one of many team-related tools, and the description provides no context on how it differs from related membership tools like 'list_team_membership' or 'get_team_membership', leaving some ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% but the parameter description 'Team ID' is minimal. The tool description adds no extra meaning beyond what the schema already provides. For a single integer parameter, the schema alone is sufficient for correct invocation, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 'all members of a team with their roles', which matches the tool name. However, it does not differentiate from sibling tools like 'list_team_bookings' or 'list_team_schedules', though the resource is distinct enough that confusion is unlikely.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as 'get_team_membership' (for a specific member) or 'list_team_invites'. It also does not mention prerequisites like requiring a valid team_id or the context of needing team admin permissions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. 'Get' implies a non-destructive read operation, but it does not disclose what is returned (though output schema exists), any error conditions (e.g., what happens with an invalid ID), or whether it requires authentication. Baseline is 3 as it doesn't mislead but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It is front-loaded with the key action and resource. For a tool with one parameter and an output schema, this level of brevity is ideal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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, output schema present), the description is minimally complete for a basic lookup. However, it could mention that the output contains booking details, though the output schema technically covers that. It lacks any error context or ID validation hints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage with a single required param (booking_id). The description 'Get a booking by ID' merely echoes the schema's 'Booking ID' description, adding no new semantics like expected format or constraints (e.g., integer range). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (get) and the resource (booking by ID). It distinguishes itself from sibling tools like list_bookings (which lists multiple bookings) and cancel_booking (which modifies a booking). The 'by ID' qualifier adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 vs alternatives. For example, it doesn't mention that list_bookings would be appropriate for fetching multiple bookings or filtering, nor does it state any prerequisites like needing the booking ID beforehand.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The description says 'Get team details by ID,' which implies a read-only operation, but it does not disclose what 'details' means (e.g., which fields are returned), whether the tool might fail for invalid IDs, or any side effects. Since there is an output schema (not shown in description but noted in signals), the lack of explicit detail is partially mitigated, but the description itself is minimal for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that directly states the purpose. It is front-loaded and contains no extraneous words. While it is concise, it could add a tiny bit more context (e.g., 'including name, timezone, and members') without becoming verbose, but as-is it earns a high score for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (1 required parameter, output schema present) and the signals, the description is adequate but minimal. The output schema may provide the return structure, so the description doesn't need to list fields, but it could mention common use cases or error scenarios. The sibling tools suggest a rich API, and for a simple 'get by ID' tool, this is just barely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage: team_id is described as 'Team ID' and is the only required parameter. The description adds that the tool retrieves 'team details' using this ID, which reinforces the parameter's role but does not add much beyond what the schema already provides. Since coverage is high, the baseline is 3, and the description's clarity on the parameter's use nudges it to 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Get' with a clear resource ('team details') and the required parameter 'Team ID' is explicitly mentioned, making the purpose clear. However, it does not differentiate 'team' from the many other tools that operate on teams (e.g., list_teams, update_team, delete_team), which would help the agent select among siblings. The description is otherwise unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives like list_teams (which retrieves all teams) or get_team_event_type (which retrieves event types for a team). The description gives no prerequisites, context for typical use, or warnings. The agent must infer usage solely from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. The description only states the tool retrieves a membership by ID, but it does not disclose whether this is a read-only operation, what happens on failure, or any authentication requirements. This leaves the agent guessing about safety and 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with zero wasted words. It is front-loaded with the verb and resource, making the purpose immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is an output schema (not shown), the description does not need to explain return values. The tool is simple with only 2 required parameters. However, with no annotations and sparse description, the agent lacks guidance on error conditions or prerequisites, which holds it back from a higher score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add any additional semantics to the parameters beyond what the schema already provides. Both parameters are simple integer IDs with basic descriptions, and the description offers no further context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'Get' and resource 'team membership' clearly indicate a retrieval operation. The description is straightforward and distinguishes from siblings like create_team_membership, update_team_membership, delete_team_membership, and list_team_members by specifying lookup by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that the tool requires both team_id and membership_id to retrieve a specific membership. However, it does not explicitly state when to use this tool over alternatives like list_team_members (for listing) or when the tool might fail (e.g., if the membership does not exist).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states 'Get a webhook by ID,' which implies a safe read operation, but it does not confirm idempotency, error handling (e.g., behavior if webhook_id doesn't exist), authentication requirements, or rate limits. There is no annotation contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at one sentence with no wasted words. It is front-loaded with the key action and resource. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one required parameter (high simplicity), full schema coverage, and an output schema exists (so return values are documented). The description sufficiently covers the basic purpose for retrieving a single webhook, though it lacks error or security context. Given the low complexity and supporting structure, it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the single parameter (webhook_id: string). The description adds no extra meaning beyond the schema. Baseline score of 3 is appropriate, but the parameter is self-explanatory and the schema is clear, so no deduction is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets a webhook by its ID, with a specific verb ('Get') and resource ('webhook'). It distinguishes itself from siblings like delete_webhook, update_webhook, and create_webhook by its read-only nature. However, it does not differentiate from get_team_event_type_webhook as both retrieve a webhook by ID, though the context of the webhook (team vs. event type) is implied by the schema name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. Among siblings are list_webhooks, get_team_event_type_webhook, and check_ics_feed, but the description offers no criteria for selection, such as needing to retrieve a specific webhook for auditing or debugging. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only mentions the PATCH method, implying partial updates, but fails to disclose any behavioral traits such as authorization needs, rate limits, side effects on existing bookings, or what happens if no fields are provided. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, front-loading the action (Update) and the method (PATCH). It is very concise, though it could be slightly more structured with additional context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, one required, and an output schema, the description is too brief. It does not explain the return value, the effect of setting is_default, or how the schedule array is structured. The schema provides some details, but the description should compensate for missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for each parameter. The description adds the 'send only fields to change' hint, which reinforces PATCH semantics but does not add meaningful 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update a schedule' with the PATCH method hint, which is a specific verb+resource pair. It naturally distinguishes from sibling tools like create_schedule, delete_schedule, and get_schedule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes 'send only fields to change' which provides a usage hint for partial updates. However, it does not explicitly state when to use this tool versus create_schedule or delete_schedule, nor does it mention prerequisites like having an existing schedule_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses one behavioral trait: partial update semantics (PATCH). However, no annotations are present, so the description carries the full burden. It does not mention auth requirements, return format, or side effects, but for a simple update it provides minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is a single, efficient sentence that immediately communicates the action and method. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with two parameters, an output schema, and full schema coverage. However, the lack of usage guidance and behavioral detail (no annotations) means the description is only minimally sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters (team_id, fields), so the baseline is 3. The description adds no additional parameter meaning beyond what the schema already documents, so it neither helps nor hurts.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update team details (PATCH — partial update)' uses a specific verb ('Update'), identifies the resource ('team'), and adds the method/scope ('PATCH — partial update'). It is clear enough to distinguish from sibling tools like update_team_membership, though 'details' is somewhat broad.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives like update_team_membership or update_team_event_type. The PATCH note implies partial updates, but it does not explicitly state conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description only mentions the enterprise requirement and the conditional param requirement, but does not disclose any behavioral traits: what happens if the link expires, auth/permissions needed, rate limits, or that this creates a new resource (implying mutation and potential non-idempotency). This is a significant gap 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with only two sentences. It's front-loaded with the main purpose, then adds a critical requirement. It could potentially add a bit more behavioral context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a creation tool with a 4-parameter input schema and an output schema present (but no details provided), the description covers the basic purpose and a critical constraint. However, it lacks important context: what does the output look like? What permissions are needed? What's the effect of omissions? The enterprise qualifier helps but doesn't fully compensate for missing transparency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing baseline. The description adds meaningful value by explaining that at least one of expires_at or max_usage_count is required, which is an important constraint not obvious from individual property descriptions. However, it doesn't elaborate on what 'label' is used for or whether event_type_id refers to a specific event type ID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and resource ('private booking link for an event type'), and clearly distinguishes it from its siblings like list_private_links, update_private_link, and delete_private_link. The Enterprise edition mention adds helpful context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states a critical usage requirement: 'At least one of expires_at or max_usage_count is required.' This tells the agent what parameters must be provided for the tool to work correctly. However, it doesn't explicitly state when to use this tool vs alternatives like update_private_link for modifying existing links.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavior. It only states 'Get' implying a read operation, but fails to describe authentication requirements, behavior on invalid IDs, rate limits, or any side effects. This leaves significant gaps for such 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—one sentence—and front-loads the core purpose. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one required parameter, full schema coverage, and an output schema (not shown but present), the description is largely complete for a simple retrieval tool. It could hint at the return format or include a link to list_schedules, but is not critically lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the parameter 'schedule_id' already described as 'Schedule ID'. The description adds no extra semantic value beyond restating 'by ID'. Baseline 3 is appropriate given high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a schedule by ID' uses a specific verb and resource, clearly indicating it retrieves a single schedule. It distinguishes from sibling tools like list_schedules (which lists all) and create/update/delete operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 list_schedules should be used first to obtain an ID, nor does it exclude contexts or describe prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only indicates a partial update (PATCH) but does not state what happens to omitted fields, authentication requirements, rate limits, or side effects. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 7 words, front-loaded with the action and resource. No redundant information; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, an output schema exists but the description fails to provide essential behavioral context such as required permissions, error conditions, or whether the update is idempotent. The description is too terse for a mutation tool with complex parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both parameters documented). The description adds 'partial update' context, reinforcing that the 'fields' object contains only changed keys. This adds marginal value over the schema's 'Fields to update' description, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 'event type', and adds 'PATCH — partial update' to indicate the HTTP method and scope. This distinguishes it from create_event_type (new) and delete_event_type (removal).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes 'partial update' which implies only sending changed fields, but does not explicitly state when to use this tool versus alternatives (e.g., create_event_type for new, list_event_types for viewing). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It warns about a required parameter failing, which adds value. However, it doesn't disclose whether this is a read-only operation, what format the busy times return, or any rate limits. The behavioral disclosure is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences long and gets straight to the point, the second sentence provides critical usage guidance. However, 'calendars_to_load' is misspelled (missing 'd' in 'loaded') which is a minor distraction but not detrimental.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has a rich input schema (100% coverage) and an output schema, the description doesn't need to explain return values. The description adequately covers the mandatory parameter constraint. The main gap is around when to choose this tool versus 'get_available_slots', which is partially covered by the name difference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 a crucial warning about 'calendars_to_load' being required, which goes beyond the schema's basic description. For the other three params, it adds no additional 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Get busy time ranges across connected calendars' which is a clear verb+resource. However, it doesn't explicitly distinguish it from sibling tools like 'get_available_slots'; the purpose is clear but differentiation is implied rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a strong directive that 'calendars_to_load is REQUIRED' and mentions the API returns 400 without it, which is useful. But it does not explain when to use this vs other booking/calendar tools, nor mention any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral transparency. It only states the action without disclosing side effects (e.g., notifications, booking status change, reversibility), prerequisites (e.g., booking must exist, attendees must be valid), or permission requirements. This is minimal and insufficient for an agent to fully understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, 'Mark one or more attendees as no-shows for a booking.' It is concise, front-loaded with the action and resource, and contains no filler. Every word contributes to the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, array input, output schema exists), the description is adequate but incomplete. It does not cover error cases, prerequisites, or behavior with partial failures. However, the presence of an output schema reduces the need to explain return values. The description provides the core action but misses supporting context that an agent might need.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond what the input schema already provides for 'booking_id' and 'attendees'. The description does not compensate or elaborate on parameter usage or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Mark' and clearly identifies the resource: 'one or more attendees as no-shows for a booking'. This distinguishes it from sibling tools like cancel_booking (which cancels entire booking) and reschedule_booking. The purpose is unambiguous and well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any explicit guidance on when to use this tool versus alternatives. While it is implied that this is for marking no-shows (as opposed to canceling the entire booking), there is no explicit when-to-use, when-not-to-use, or comparison with similar tools. The usage context is only implied by the name and short description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It says 'Remove a calendar from conflict detection,' which implies a non-destructive disassociation rather than data deletion. However, it doesn't disclose whether the calendar connection remains or if this reverses what add_selected_calendar does, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero waste. Every word is meaningful and directly conveys the action and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is an output schema and 100% parameter coverage, the description is minimally adequate. It explains the core function but lacks contextual details like whether this affects the calendar's connection status or what happens if the calendar isn't currently selected. For a simple removal tool, it is sufficient but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 no additional parameter context beyond what the schema already provides (e.g., external_id as 'Calendar email or ID'). It doesn't explain how integration and credential_id relate to the removal process.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Remove a calendar from conflict detection' which specifies the verb (remove), resource (calendar), and context (conflict detection). It effectively distinguishes from sibling tools like add_selected_calendar and get_calendar_busy_times, though it doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage: use this when you need to stop conflict detection for a specific calendar. However, it does not explicitly state when to use this versus alternatives (like simply disconnecting the calendar) or what prerequisites might exist (e.g., that the calendar must first be selected via add_selected_calendar).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that this is a partial update (PATCH), which implies only provided fields are changed. However, no annotations exist, so the description carries full burden; it omits details on permissions, side effects, idempotency, or rate limits. The partial update cue is useful 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's purpose and HTTP method. No extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a nested object parameter, an output schema, and multiple sibling tools, the description could provide more context, such as permissible field keys or response behavior. It covers the basics but lacks completeness for an agent to fully understand when and how to invoke it without additional investigation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. The description adds no additional meaning beyond the schema—it does not elaborate on how 'fields' should be structured or validated. Baseline 3 is appropriate as the schema already handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (update), the resource (team event type), and specifies it's a PATCH partial update. This distinguishes it from siblings like 'update_event_type' (for non-team event types) and 'create_team_event_type'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives like 'update_event_type' or 'create_team_event_type'. There are no prerequisites, exclusions, or context about which scenarios require this specific tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only discloses that the tool performs a partial update (PATCH), but omits critical behavioral traits such as idempotency, required permissions, side effects, or rate limits. For a mutation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the key purpose and method. Every word earns its place, and there is no unnecessary information. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has an output schema and only two parameters, the description is minimally complete. However, it lacks guidance on usage context, prerequisites, and behavioral details, which are needed for an agent to confidently select and invoke the tool among many webhook siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add any parameter-specific meaning beyond what the schema already provides (e.g., the fields parameter example is in the schema). No additional enrichment is present.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 'a webhook', and specifies 'PATCH — partial update' which distinguishes it from other webhook operations like create_webhook, delete_webhook, or get_webhook. This provides a specific verb+resource+method, making the purpose immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is for partial updates via the 'PATCH' mention, but it does not explicitly state when to use it versus alternatives such as create_webhook or delete_webhook. No exclusions or context for when not to use are provided, relying on the agent to infer from the sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb 'Check' implies a read-only, non-destructive operation, which adds some behavioral clarity. However, it does not disclose the return format, possible error conditions, or whether this performs any network call that might have latency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that immediately conveys the tool's purpose. It is front-loaded and contains no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with one parameter and an output schema, so the description does not need to elaborate on return values. The description is adequate for the tool's simplicity, though it could benefit from a brief note on when to use it relative to sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for the single parameter, including a description that lists the allowed values ('google', 'office365', 'apple'). The tool description adds no additional semantic 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Check' with a clear resource 'calendar type connection', and the parameter 'calendar_type' clarifies scope. It distinguishes itself from siblings like 'check_ics_feed' (different type of calendar source) and 'get_calendar_connect_url' (retrieves a URL rather than checking status).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives such as 'get_calendar_connect_url' or 'check_ics_feed'. The usage context is only implied by the tool name and description, and no exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It includes a critical behavioral warning: using incorrect parameter names ('startTime/endTime') results in a 400 error. However, it does not disclose whether the operation is read-only, any authentication requirements, rate limits, or what happens with missing optional parameters. This is a partial but important disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences. The first sentence states the purpose directly, and the second sentence is a critical warning front-loaded with 'IMPORTANT'. Every sentence earns its place with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 8 parameters and an output schema, the description is very brief. It does not explain how the tool works (e.g., how event_type_id/slug are used, what 'username_list' does, how duration interacts with slots, or what the output contains). The schema covers parameter details, but the description lacks an overview of the tool's behavior, prerequisites, or typical usage flow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so parameters are well-documented. The description adds value beyond the schema by explicitly warning against using 'startTime/endTime' and directing to use 'start/end' instead. This prevents a common error and is not present in the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 available booking slots for an event type.' It uses a specific verb ('get') and resource ('available booking slots'), and distinguishes this from sibling tools like 'reserve_slot' (which reserves a slot) and 'list_bookings' (which lists existing bookings).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 it should be used before booking, nor does it contrast with similar tools like 'get_calendar_busy_times' or 'list_event_types'. The only usage hint is an implementation note about parameter names, not about tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. The description is clear about the action and resource but does not disclose any side effects, authorization needs, rate limits, or what happens if the event type ID is invalid. It is 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (7 words) but effectively communicates the core purpose. It is front-loaded and wastes no words, though it could benefit from a note on the output to improve completeness without adding fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (1 param, single required, simple schema) and presence of an output schema, the description is minimally adequate. It does not describe the return format or any pagination details, but the output schema likely covers structure. Siblings exist, but no differentiation is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with a single parameter ('event_type_id') that has a clear description. The tool description adds no further meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a specific resource ('webhooks for a specific event type'), making the action and scope clear. It also distinguishes itself from siblings like 'list_webhooks' (all webhooks) and 'list_team_event_type_webhooks' (team event type).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states it lists webhooks for a specific event type, implying the need for an event_type_id. However, it provides no guidance on when to use this versus siblings like 'list_webhooks' or 'list_team_event_type_webhooks', and lacks when-not-to-use or prerequisite context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It mentions the reservation expires, which is useful, but it doesn't disclose other behavioral traits such as whether the reservation can be extended, how long the window is (e.g., 'short window' is vague), or what happens if the reservation lapses (e.g., is it automatically released?). For a temporary reservation tool, more specificity is needed to avoid misuse.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short paragraphs, front-loading the purpose and then immediately providing the critical usage note. Every sentence adds value: the first defines the action, the second emphasizes the required parameter and the expiry warning. There is no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 required params, no enums, output schema present), the description is relatively sparse. It covers the essential usage but lacks details on reservation behavior (e.g., duration, guarantee), failure scenarios, or whether multiple reservations can be held. The presence of an output schema mitigates the need to describe return values, but the temporary nature of the resource demands more operational guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds one key piece of information: 'slotId is REQUIRED (use the slot ID from get_available_slots response)', which clarifies where to obtain this parameter. However, it doesn't explain the other parameters (start, event_type_id, attendee_time_zone) beyond their schema descriptions, so no additional value is provided for them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: temporarily reserve a slot before creating a booking. It uses a specific verb (reserve) and resource (slot), and distinguishes it from booking creation. However, it doesn't explicitly compare with sibling tools like 'create_booking' or 'delete_slot_reservation', though the phrase 'before creating a booking' implies the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: it states that the slot ID must be taken from 'get_available_slots' response and that the reservation expires after a short window, so the booking must be created before it lapses. This clearly tells the agent when to use the tool and the necessary follow-up action, though it doesn't mention alternatives or 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The description indicates a read-only operation ('list'), which is consistent with the lack of destructive hints. However, it doesn't disclose any additional behavioral traits such as pagination, rate limits, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with five words, perfectly concise. It front-loads the action and resource with scope, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has zero parameters and no nested objects, the description is complete enough for its simplicity. The output schema exists, so return values don't need elaboration. A minor gap is the lack of mention of pagination or limits, but for a simple list all tool, this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so the description doesn't need to add parameter semantics. The schema coverage is 100% (vacuously true), and the description correctly implies no filters are needed since it lists all user-level webhooks. This is a 4 because the description adds clarity in the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all user-level webhooks' clearly states the action (list) and the resource (webhooks), specifying the scope (user-level). This distinguishes it from siblings like list_team_event_type_webhooks and list_event_type_webhooks, which operate on different scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you need to list webhooks at the user level, but it doesn't explicitly state when to use this vs. alternatives like list_event_type_webhooks or list_team_event_type_webhooks. The context from sibling names helps, but the description lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility. It discloses the PATCH method and lists possible fields, but lacks details on required permissions, side effects (e.g., role changes affecting booking access), idempotency, constraints on fields (e.g., whether 'accepted' can be toggled), or handling of unknown fields (since 'fields' has additionalProperties: true). Behavioral context is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the core action and key examples. Structure is optimal for an AI agent to quickly parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and 100% parameter coverage, the description provides a basic but adequate overview. However, considering the sensitive nature of updating team memberships (role changes, acceptance status) and the lack of annotations, additional context about permissions, immutability, or required preconditions would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 marginal value by listing 'disableImpersonation' which isn't in the schema example, but otherwise repeats information already present. It does not clarify the full range of allowed keys in the 'fields' object or constraints on values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update a team membership' with the HTTP method PATCH and lists specific updatable fields (role, accepted, disableImpersonation). This distinguishes it from sibling tools like create_team_membership, get_team_membership, and delete_team_membership.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for modifying existing memberships via the PATCH method and example fields, but does not explicitly state when to use this tool versus alternatives (e.g., when to use create_team_membership, or prerequisites like needing the current membership state). No exclusions or when-not scenarios are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It mentions the HTTP method constraint (POST only) which is a behavioral trait. However, it does not disclose side effects, required permissions, or what the output schema contains (which exists but isn't referenced). 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the core purpose. Every word earns its place, with no filler. The reference to another tool is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 required params, clear siblings), the description covers the key points: purpose, HTTP restriction, and how to verify state. The existence of an output schema reduces the need to document return values. Adequate for its domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the 3 parameters, each documented in the schema. The description doesn't add any new detail beyond what's in the schema. Per guidelines, baseline is 3 when coverage is high; the description adds no extra value for parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Mark a calendar for conflict detection', using a specific verb and resource. It distinguishes itself from the sibling tool `remove_selected_calendar` by being its inverse, and hints at its place in a workflow alongside `list_calendars`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly notes this is 'POST only, no GET' and directs to `list_calendars()` to check status. It provides clear context for when to use it (to enable conflict detection) and how to verify the effect, though it doesn't explicitly mention alternatives or 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.
Behavior3/5
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. The description correctly indicates a read operation ('Get'). However, it does not mention whether the tool requires specific permissions, rate limits, or what happens if the event type does not exist (return value or error behavior). The minimalist description covers the basic safety profile but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 6 words. Every word is meaningful and front-loaded. There is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are only 2 required parameters, schema coverage is 100%, and the output schema exists (so return format is documented), the description is sufficiently complete for a simple retrieval tool. It could optionally mention that it differs from 'get_event_type' (non-team) but this is not a critical omission for a straightforward ID lookup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'team_id' and 'event_type_id' having clear descriptions ('Team ID', 'Event type ID'). The description adds no additional semantic meaning beyond what the schema already provides. A baseline of 3 is appropriate since 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get'), resource ('team event type'), and the lookup key ('by ID'). This distinguishes it from siblings like 'list_team_event_types' (which lists all) and 'update_team_event_type' (which modifies).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives (e.g., 'list_team_event_types' for retrieval without an ID, or 'get_event_type' for non-team event types). The purpose is implied by the name and presence of both team and event type parameters, but no when-not-to-use guidance or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It discloses that the tool is a PUT-only mutating operation (set destination), which is clear. It does not detail side effects (e.g., overwrites previous destination), authorization needs, or rate limits, but the essential behavioral trait is communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct with two sentences that front-load the main purpose. The second sentence adds instructional value about retrieval. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only 3 parameters with 100% schema coverage, an output schema exists (though not shown), and no annotations, the description is adequate. It explains the action, the method limitation, and how to verify the setting. It could note that existing bookings are unaffected, but overall it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 does not add any additional meaning beyond the schema descriptions (e.g., it references calendar email/ID and credential ID from list_calendars, but that information is already in the schema's property descriptions). No extra semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the destination calendar for new bookings and specifies it is a PUT-only operation. However, it does not explicitly differentiate from sibling tools like add_selected_calendar or remove_selected_calendar, which are related but distinct calendar operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool (to set destination calendar for new bookings) and when not (mentions that it is PUT only, and refers to list_calendars for retrieval). It lacks direct mention of alternatives or exclusions, but the context of destination calendar versus other calendar operations is reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 the partial update behavior (PATCH, send only fields to change). However, it does not mention authentication requirements, what happens to omitted fields, or any side effects beyond the scope of the update. The metadata parameter has a note in the schema about null response, but that is not in the tool description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys purpose, HTTP method, and usage guidance with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the schema covers all parameters and an output schema exists, the description is minimal. It does not explicitly state that the profile belongs to the authenticated user (though 'my' implies it), nor does it mention prerequisites or error conditions. For a tool with 10 optional parameters and no annotations, the description could provide more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter already has a detailed description. The tool description adds no additional information about parameters beyond what the schema provides. With high coverage, baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 'current user profile', and specifies the HTTP method PATCH plus guidance to send only changed fields. This distinguishes it from sibling tools like get_my_profile (read-only) and other mutation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly says when to use the tool (to update the current user's profile) and provides the PATCH guidance. It does not explicitly mention when not to use it or list alternatives, but given the sibling set, the usage context is clear and no exclusion is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states the tool creates a 'user-level webhook' and mentions real-time notifications, but doesn't disclose behavioral traits like whether the webhook is immediately active, what happens on duplicate creation, or permission requirements. The correction about `triggers` vs `eventTriggers` adds useful context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at two sentences, with a clear and helpful warning in the second sentence. It's front-loaded with the core purpose. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists (so return values need not be described), 4 parameters, and no nested objects, the description is adequate but minimal. It doesn't elaborate on scoping (what 'user-level' means vs event-type), rate limits, or troubleshooting guidance for webhook setup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by specifying the correct parameter name (`triggers` vs `eventTriggers`) and noting the `active` default is true. This addresses an important nuance not fully captured in the schema's individual parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this tool creates a user-level webhook for real-time event notifications, distinguishing it from sibling tools like list_webhooks, update_webhook, delete_webhook, and the event-type-specific webhook tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit usage correction (use `triggers`, not `eventTriggers`) and implies this is for user-level webhooks, which differentiates it from event-type webhook tools. However, it doesn't explicitly state when NOT to use this tool or list alternative tools for event-type webhooks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It correctly indicates a read operation ('Get'), but does not elaborate on authentication requirements, error handling, or potential side effects. For a zero-parameter read tool, this is adequate but not enriched.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb and resource, and lists example fields. Every word contributes value; there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, output schema exists), the description is sufficient. It names key fields returned, and the output schema covers the full structure. One might argue it could mention that the profile belongs to the authenticated user, but 'current user' already implies that. Minor gap: no mention of typical response format, but output schema compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is fully covered (100%). The description does not need to add parameter meaning. Baseline is 4 per rubric guidelines.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the resource ('current user profile'), and lists specific fields (name, email, timezone, bio, defaultScheduleId). This distinguishes it from siblings like update_my_profile (which modifies) and list_timezones (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage is for retrieving the authenticated user's profile, but it does not explicitly state when to use this tool over alternatives (e.g., for other users, use a different endpoint) or provide exclusion criteria. The context is clear but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It describes the return structure (connectedCalendars list, destinationCalendar, isSelected flag) which adds value, but does not explicitly state that the operation is read-only or safe, nor does it mention any side effects 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. The main purpose is front-loaded, and every sentence adds useful information about what is returned and how to interpret the data.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and the presence of an output schema, the description covers the key aspects: what is listed, the two return fields, and how to use isSelected. It could mention handling of edge cases like no connected calendars, but overall it's sufficient for a read-only list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and schema coverage is 100%. The description does not need to add parameter details. It already describes the output structure, which is more relevant than parameter semantics here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 'connected calendars and destination calendar'. It distinguishes from sibling tools like add_selected_calendar, remove_selected_calendar, and set_destination_calendar by focusing on listing rather than mutation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for viewing calendars and checking isSelected for conflict detection, but does not explicitly state when to use this tool versus alternatives or when not to use it. With many calendar-related siblings, more explicit guidance would be beneficial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It states the tool lists event types, which is a read operation, but does not mention pagination, rate limits, or any other behavioral traits. For a zero-parameter list tool, this is minimally 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with 7 words, front-loading the verb and resource. It contains no filler and earns its place by clearly stating the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, an output schema exists, and the context is low complexity, the description is mostly complete. It could benefit from mentioning what the output schema contains or any sorting/filtering behavior, but the presence of an output schema reduces the need for that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with zero parameters, so the schema fully describes the input. The description adds no param details, but this is acceptable because there are no parameters to document. Baseline 4 applies as per guidelines.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('all event types (meeting types)'). It clarifies the resource by adding '(meeting types)' which distinguishes it from sibling tools like list_team_event_types, which lists team-scoped event types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool vs alternatives like get_event_type or list_team_event_types. However, 'List all' implies it is for broad enumeration without filtering, and the zero parameters suggest it is a simple fetch-all operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states the basic operation and does not add behavioral traits such as read-only nature, authentication requirements, rate limits, or return format. For a tool with no parameters, more context about the output (e.g., pagination, ordering) 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 7 words, front-loaded with the verb 'List.' Every word earns its place; there is no redundancy or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero parameters, has output schema in the full definition), the description is complete: it tells the agent what the tool does and what it returns. No additional context is needed for a basic list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4. The description adds no parameter-level information because none is needed. The schema coverage is 100% (empty schema), so no additional meaning is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 'teams' with the scope 'the current user belongs to.' This distinguishes it from sibling tools like get_team (specific team), create_team, update_team, delete_team, and list_team_members (members of a team).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage context: listing all teams the user is a member of. It does not explicitly state when not to use it or name alternatives, but given the sibling tool names, the context is clear enough. No exclusions are needed for a simple list operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It adds the behavioral insight that webhooks are inherently event-type-scoped, not team-scoped. However, it does not disclose other traits like whether the operation is read-only, what happens if the event type doesn't exist, or if any auth is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, zero waste. The first sentence states the core purpose, and the second adds critical clarification. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has only 2 required parameters, 100% schema coverage, and an output schema exists, the description is sufficient. It explains the key nuance that webhooks are not team-level, preventing misuse. It lacks some behavioral details but is complete enough for the given context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter meaning beyond the schema. However, schema coverage is 100% with clear descriptions for both required parameters (team_id and event_type_id), so the baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists webhooks for a team event type, using the specific verb 'list' and resource 'team event type webhooks'. It distinguishes itself from the sibling tool 'list_event_type_webhooks' by the team-level scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly warns that there are NO team-level webhooks and that webhooks are always scoped to event types. This guides the agent to use the sibling 'list_event_type_webhooks' instead, providing a clear when-not-to-use scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It clearly discloses the worst-case behavior (returns all 7,072 entries at once), which is the most critical behavioral trait for an agent to know. The description does not contradict any annotations (none exist), and offers key context about data size.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that packs crucial information: what is returned, how many items, and the lack of pagination. Every word serves a purpose, and it is appropriately sized for a zero-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there are no parameters, no annotations, and an output schema exists (which presumably describes return structure), the description covers the essential behavioral context. It could optionally mention response size or performance impact, but the core completeness for safe agent usage is met.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters, and schema description coverage is 100%. The description adds no parameter-level detail because there are no parameters to document. A score of 3 is baseline since the schema already fully describes parameter expectations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 'all 7,072 available city/timezone entries'. It distinguishes itself from sibling tools, none of which deal with timezone listing, by being the only tool in the sibling set with this purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly flags that there is no pagination and that all entries are returned at once. This warns the agent about potential large data transfer, which is helpful context. However, it does not mention when to use this tool versus local timezone handling or other date-related tools, which limits the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 that the tool requires Stripe configuration and will fail with InternalServerError otherwise, which is a critical behavioral trait. It does not detail permissions or side effects, but the output schema exists, and the description is not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences with a clear purpose statement and a warning. It is front-loaded, no fluff, and every sentence adds value. Perfectly sized for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description does not need to explain return values. It covers the core purpose, a critical behavioral constraint (Stripe dependency), and usage guidance. For a 2-parameter creation tool, this is complete and sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no additional meaning or context for the 'name' and 'slug' parameters beyond what the schema already provides. No improvement over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new team' which is a specific verb+resource. It distinguishes from siblings like list_teams, get_team, update_team, delete_team, and other create tools by warning about Stripe dependency and suggesting using existing teams, clarifying the tool's unique purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly warns about the Stripe billing prerequisite and failure mode, and advises 'For most use cases, use existing teams' which tells the agent when to avoid this tool and consider alternatives like listing existing teams.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses the destructive behavior: the old key is invalidated immediately. It also states that the response contains the new key and mandates updating the environment variable. This is complete behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: the first states the action, the second warns of immediate invalidation, and the third gives a critical instruction. Every sentence is essential, front-loaded, and efficiently structured with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with an output schema, the description covers the action, side effect, and required follow-up action. It is fully self-contained and leaves no gaps in understanding the tool's impact and usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema description coverage is 100% by default. The description adds no parameter info, which is fine. The baseline for 0 params is 4, and the description's value lies in behavioral context, not parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Rotate the current API key' uses a specific verb and resource, clearly indicating the tool's purpose. It distinguishes itself from all sibling tools, none of which are related to API key management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly warns about immediate invalidation of the old key and instructs to update the CALCOM_API_KEY environment variable before making further requests. This provides clear when-to-use context and critical post-condition steps, leaving no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![booking_chest MCP server](https://glama.ai/mcp/servers/dsddet/booking_chest/badges/card.svg)](https://glama.ai/mcp/servers/dsddet/booking_chest)

Score Badge

Copy to your README.md:

[![booking_chest MCP server](https://glama.ai/mcp/servers/dsddet/booking_chest/badges/score.svg)](https://glama.ai/mcp/servers/dsddet/booking_chest)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/dsddet/booking_chest'

If you have feedback or need assistance with the MCP directory API, please join our Discord server