lacita

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

Annotations indicate this is a non-readOnly, non-destructive, non-idempotent, openWorld operation. The description adds valuable behavioral context beyond annotations: it specifies the max 5 reminders per calendar constraint and clarifies the two reminder types with examples ('X minutes before' vs 'specific time on day before'), which helps the agent understand the tool's behavior and limitations.

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

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

The description is two sentences, front-loaded with the core purpose, followed by key constraints. Every word earns its place—no redundancy or fluff. It's efficiently structured and easy to parse.

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

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

Given the tool's moderate complexity (5 parameters, mutation operation), annotations cover safety aspects, and schema covers parameters fully. The description adds useful context (reminder types, max limit). However, without an output schema, it doesn't describe return values (e.g., success confirmation or reminder ID), leaving a minor gap for a mutation tool.

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

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

Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description adds minimal parameter semantics beyond the schema—it mentions the two reminder types but doesn't provide additional syntax or format details. This meets the baseline of 3 when schema coverage is high.

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

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

The description clearly states the verb ('Add') and resource ('reminder configuration to a calendar'), specifies the two supported reminder types, and distinguishes this tool from siblings like 'delete_calendar_reminder' by its creation function. It's specific and unambiguous.

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

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

The description provides clear context by mentioning the two reminder types and the max 5 reminders per calendar, which helps guide usage. However, it doesn't explicitly state when to use this tool versus alternatives like 'update_calendar' or 'create_calendar_override', nor does it mention prerequisites (e.g., needing an existing calendar).

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

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

Annotations already indicate this is a destructive, non-idempotent write operation (destructiveHint: true, readOnlyHint: false, idempotentHint: false). The description adds value by specifying 'Requires full scope', which hints at authorization needs beyond what annotations provide. However, it doesn't detail side effects, rate limits, or error conditions, leaving behavioral context incomplete.

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

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

The description is very concise with two short sentences, front-loading the core action ('Cancel an existing appointment') and following with a constraint ('Requires full scope'). There is no wasted text, though it could be more structured with bullet points or examples for better clarity.

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

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

Given the destructive nature (per annotations) and lack of output schema, the description is somewhat incomplete. It mentions scope requirements but doesn't explain the cancellation process, return values, or error handling. For a tool that permanently modifies data, more context on behavior and outcomes would be beneficial to guide the agent effectively.

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

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

Schema description coverage is 100%, with clear descriptions for both parameters ('appointmentId' and 'reason'). The description adds no additional parameter semantics beyond what the schema already provides, such as format examples or constraints. This meets the baseline for high schema coverage but doesn't enhance understanding.

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

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

The description clearly states the action ('Cancel') and the resource ('an existing appointment'), making the purpose specific and unambiguous. It distinguishes itself from siblings like 'reschedule_appointment' and 'get_appointment' by focusing on termination rather than modification or retrieval.

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

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

The description provides minimal guidance, only mentioning 'Requires full scope' without explaining what that entails or when to use this tool versus alternatives like 'reschedule_appointment' or 'delete_calendar'. It lacks explicit when-to-use or when-not-to-use instructions, leaving the agent to infer context from sibling tool names.

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

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

Annotations indicate this is a write operation (readOnlyHint: false), non-destructive, and open-world (openWorldHint: true), which the description aligns with by stating 'Create'. However, the description adds minimal behavioral context beyond annotations—it doesn't mention side effects, permissions, or rate limits, leaving gaps 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.

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

The description is a single, efficient sentence that front-loads the core purpose ('Create a new booking calendar') and adds a useful qualifier ('with optional settings'). There is no wasted verbiage or redundancy.

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

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

For a mutation tool with 10 parameters, no output schema, and annotations covering basic safety, the description is minimal. It states what the tool does but lacks details on return values, error conditions, or integration context, making it adequate but incomplete for informed use.

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

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

Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds no specific parameter semantics beyond implying optional settings exist, which is already clear from the schema. This meets the baseline for high schema coverage.

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

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

The description clearly states the action ('Create') and resource ('booking calendar'), specifying it's a new calendar with optional settings. It distinguishes from siblings like 'update_calendar' or 'get_calendars' by focusing on creation, though it doesn't explicitly contrast with all siblings.

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

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

No guidance is provided on when to use this tool versus alternatives like 'update_cooking_settings' or 'create_calendar_override'. The description mentions 'optional settings' but doesn't specify prerequisites, dependencies, or typical use cases for calendar creation.

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

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

Annotations already indicate this is a non-readOnly, non-destructive, non-idempotent, open-world operation. The description adds context about what the tool does (create overrides for blocking or modifying hours), which complements the annotations but doesn't disclose additional behavioral traits like error conditions, rate limits, or authentication needs. No contradiction with annotations exists.

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

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

The description is a single, efficient sentence that front-loads the purpose with clear examples. Every word earns its place, providing essential information without redundancy or unnecessary elaboration.

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

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

Given the tool's complexity (mutation with 6 parameters), annotations cover safety and idempotency, but there's no output schema. The description adequately explains the tool's purpose but lacks details on return values, error handling, or interaction with other tools. It's minimally viable but has gaps for a mutation tool without output schema.

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

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

Schema description coverage is 100%, so the schema fully documents all 6 parameters. The description mentions 'specific date' and examples like 'block a day off or modify hours', which loosely relates to the 'date', 'isBlocked', 'startTime', and 'endTime' parameters but doesn't add significant meaning beyond what the schema provides. Baseline 3 is appropriate given high schema coverage.

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

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

The description clearly states the verb 'create' and resource 'availability override', specifying it's for a specific date with examples of use cases (block a day off or modify hours). It distinguishes from sibling tools like 'delete_calendar_override' by indicating creation rather than deletion, though it doesn't explicitly differentiate from other creation tools like 'create_calendar' or 'create_contact'.

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

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

The description implies usage for modifying availability on specific dates, with examples suggesting when to use it (e.g., for blocking days or changing hours). However, it doesn't provide explicit guidance on when to use this tool versus alternatives like 'update_calendar_weekly_availability' or 'get_calendar_overrides', nor does it mention prerequisites or exclusions.

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

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

The description adds valuable context about the required 'write scope' that isn't captured in the annotations. While annotations already indicate this is a non-readOnly, non-destructive operation, the description provides authentication context that helps the agent understand permission requirements beyond the basic behavioral hints.

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

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

The description is extremely concise with just two short sentences that communicate essential information without any wasted words. It's front-loaded with the core purpose and follows with important prerequisite information.

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

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

For a creation tool with good annotations and full schema coverage, the description provides the minimum viable information. However, without an output schema, it doesn't describe what the tool returns (e.g., contact ID, success confirmation), leaving a gap in understanding the operation's result.

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

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

With 100% schema description coverage, the schema already documents all 4 parameters thoroughly. The description doesn't add any additional parameter information beyond what's in the schema, so it meets the baseline but doesn't provide extra value.

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

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

The description clearly states the action ('Create') and resource ('contact'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'update_contact' or explain what distinguishes creation from updating, which prevents a perfect score.

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

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

The description mentions 'Requires write scope' which provides some context about prerequisites, but doesn't explicitly guide when to use this versus alternatives like 'update_contact' or when not to use it. The guidance is implied rather than explicit.

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

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

Annotations already indicate destructiveHint=true and readOnlyHint=false, but the description adds critical behavioral context beyond this: it specifies that the action 'is irreversible' and deletes 'all its appointments', providing explicit consequences not covered by annotations. This enhances transparency about the tool's impact and permanence.

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

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

The description is extremely concise and front-loaded, consisting of only two sentences that efficiently convey purpose, prerequisites, and critical warnings. Every word earns its place, with no redundant or unnecessary information, making it easy to parse and understand quickly.

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

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

Given the tool's high complexity (destructive, irreversible action) and lack of output schema, the description is mostly complete: it covers purpose, scope, prerequisites, and consequences. However, it could benefit from mentioning potential errors or confirmation steps, slightly reducing completeness for such a critical operation.

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

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

The input schema has 100% description coverage, with the parameter 'calendarId' clearly documented. The description does not add any additional semantic details about the parameter beyond what the schema provides, such as format or examples. Thus, it meets the baseline for high schema coverage without extra value.

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

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

The description clearly states the specific action ('Delete a calendar and all its appointments'), distinguishing it from siblings like 'delete_calendar_override' or 'delete_calendar_reminder' which target specific components rather than the entire calendar. It explicitly mentions the scope of deletion (all appointments), making the purpose unambiguous and distinct.

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

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

The description provides clear context for usage with 'Requires full scope', indicating a prerequisite. It distinguishes from alternatives by implying this is for full calendar deletion versus partial deletions in siblings. However, it does not explicitly name when-not-to-use scenarios or list specific alternative tools, keeping it from a perfect score.

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

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

Annotations indicate this is a non-read-only, non-destructive, non-idempotent, open-world operation, which the description doesn't contradict. The description adds minimal behavioral context beyond annotations—it implies a deletion action but doesn't specify effects (e.g., whether deletion is permanent, requires permissions, or affects calendar availability). With annotations covering basic traits, the description adds some value 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.

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

The description is a single, direct sentence with zero wasted words, front-loading the key action and resource. It's appropriately sized for a simple deletion tool, making it easy for an agent to parse quickly.

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

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

Given the tool's complexity (a deletion operation with 2 parameters), annotations provide safety and idempotency hints, but there's no output schema. The description is minimal and doesn't explain return values or error conditions, leaving gaps. It's adequate but incomplete, as it could benefit from more context on behavior and outcomes.

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

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

Schema description coverage is 100%, with clear parameter descriptions ('calendarId' and 'overrideId'), so the schema carries the full burden. The description adds no additional meaning about parameters, such as where to find these IDs or format requirements, resulting in a baseline score of 3.

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

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

The description clearly states the action ('Delete') and the resource ('an availability override'), making the purpose immediately understandable. However, it doesn't explicitly distinguish this tool from sibling tools like 'delete_calendar' or 'delete_calendar_reminder', which would require mentioning it specifically removes overrides rather than entire calendars or reminders.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing override), exclusions, or related tools like 'get_calendar_overrides' to find override IDs or 'create_calendar_override' as a counterpart, leaving the agent to infer usage context.

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

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

Annotations already indicate this is a non-read-only, non-destructive, non-idempotent, open-world operation. The description adds minimal behavioral context beyond this, confirming it's a deletion action but not detailing effects like whether deletion is permanent or reversible, or if it requires specific permissions.

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

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

The description is a single, clear sentence with no wasted words. It's front-loaded with the key action and target, making it highly efficient and easy to parse.

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

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

Given the tool's complexity (simple deletion with two parameters), rich annotations, and full schema coverage, the description is minimally adequate. However, without an output schema, it doesn't explain return values or error cases, leaving gaps in completeness for a mutation tool.

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

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

With 100% schema description coverage, the input schema fully documents both parameters (calendarId and reminderId). The description doesn't add any semantic details beyond what's in the schema, such as how to obtain these IDs or format requirements, so it meets the baseline for high coverage.

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

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

The description clearly states the action ('Delete') and target ('a reminder configuration from a calendar'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'delete_calendar' or 'delete_calendar_override', but the specificity of 'reminder configuration' provides adequate distinction.

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

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

No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing existing reminders), exclusions, or relationships with sibling tools like 'get_calendar_reminders' for listing reminders before deletion.

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

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

The description adds 'Requires full scope,' which provides important context about authentication needs not covered by annotations. Annotations already indicate destructiveHint=true and readOnlyHint=false, so the description doesn't contradict them. However, it could mention potential side effects like data loss or idempotency (idempotentHint=false is in annotations, but not explained).

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

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

The description is extremely concise with just two sentences, front-loading the core action ('Delete a contact') and following with a critical constraint ('Requires full scope'). Every word serves a purpose, with no redundancy or unnecessary elaboration.

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

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

Given the tool's complexity (destructive operation with one parameter) and rich annotations, the description is somewhat complete but lacks details on output behavior (no output schema) and doesn't fully address behavioral traits like idempotency or error handling. It covers authentication needs but could be more comprehensive for a destructive tool.

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

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

The description doesn't add any parameter-specific information beyond what's in the input schema, which has 100% coverage. The schema fully describes the single required parameter 'contactId' as a string. No additional semantics about format, constraints, or examples are provided, so it meets the baseline for high schema coverage.

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

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

The description clearly states the verb ('Delete') and resource ('a contact'), making the purpose immediately understandable. However, it doesn't differentiate this tool from other deletion tools like delete_calendar or delete_calendar_override, which would require mentioning what specifically gets deleted (contact records vs calendar entries).

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

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

The description provides minimal guidance with 'Requires full scope,' which hints at permission requirements but doesn't explain when to use this tool versus alternatives. No explicit when/when-not instructions or comparisons to sibling tools like update_contact or create_contact are provided, leaving usage context vague.

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

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

Annotations already cover key behavioral traits (read-only, open-world, idempotent, non-destructive), so the bar is lower. The description adds minimal context by implying it retrieves 'detailed information,' but doesn't disclose aspects like rate limits, authentication needs, or error handling. No contradiction with annotations exists.

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

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

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it easy to parse quickly.

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

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

Given the tool's low complexity (one parameter), rich annotations, and no output schema, the description is minimally adequate. It covers the basic purpose but lacks details on usage context, return values, or error cases, which could help an agent use it more effectively despite the annotations providing safety information.

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

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

Schema description coverage is 100%, with the parameter 'appointmentId' fully documented in the schema. The description doesn't add any meaning beyond the schema, such as format examples or constraints, but meets the baseline since the schema handles parameter documentation adequately.

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

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

The description clearly states the verb ('Get') and resource ('detailed information about a specific appointment'), making the purpose understandable. However, it doesn't explicitly distinguish this tool from its sibling 'get_appointments' (plural), which retrieves multiple appointments rather than a single one, missing an opportunity for full sibling differentiation.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites like needing an appointment ID, contrast it with 'get_appointments' for multiple appointments, or specify scenarios where detailed information is required over a list view.

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

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

Annotations already provide comprehensive behavioral hints (readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false), so the description's burden is lower. The description adds minimal context about filtering capabilities but doesn't disclose important behavioral aspects like pagination behavior (implied by 'limit' parameter), ordering of results, authentication requirements, or rate limits. It doesn't contradict annotations, but adds limited value beyond them.

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

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

The description is extremely concise - a single sentence that efficiently communicates the core functionality. It's front-loaded with the main purpose and includes the key filtering capabilities. There's no wasted language or unnecessary elaboration, making it easy for an agent to quickly understand the tool's basic function.

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

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

Given the tool's moderate complexity (4 parameters, no output schema) and rich annotations, the description is minimally adequate. It covers the basic purpose but lacks important contextual information about result format, pagination behavior, error conditions, and differentiation from sibling tools. The annotations provide safety information, but the description doesn't complement them with operational context that would help an agent use the tool effectively.

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

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

With 75% schema description coverage (3 of 4 parameters have descriptions), the schema does substantial documentation work. The description mentions 'filtering by status and date' which aligns with parameters but doesn't add meaningful semantic context beyond what the schema provides. It doesn't explain parameter interactions, default behaviors, or provide examples of effective filtering combinations.

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

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

The description clearly states the tool's purpose: 'List appointments with optional filtering by status and date.' It specifies the verb ('List') and resource ('appointments'), and mentions filtering capabilities. However, it doesn't explicitly distinguish this from sibling tools like 'get_appointment' (singular) or 'get_calendar_availability', which reduces clarity about when to choose this specific listing tool.

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

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

The description provides no guidance on when to use this tool versus alternatives. With many sibling tools available (like 'get_appointment' for single appointments, 'get_calendar_availability' for availability checks, or 'get_calendars' for calendar listings), there's no indication of when this appointment listing tool is preferred. The mention of 'optional filtering' hints at usage context but doesn't provide explicit when/when-not guidance.

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

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

Annotations cover key behavioral traits (read-only, open-world, idempotent, non-destructive), so the description's burden is lower. It adds value by specifying that it retrieves 'detailed information' and 'all settings', which clarifies the scope beyond what annotations provide. However, it lacks details on rate limits, authentication needs, or error handling, which could enhance transparency.

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

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

The description is a single, efficient sentence that front-loads the core action ('Get detailed information') and specifies the resource and scope ('about a specific calendar including all settings'). There is no wasted verbiage, making it highly concise and well-structured for quick understanding.

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

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

Given the tool's low complexity (single required parameter), rich annotations (covering safety and idempotency), and lack of output schema, the description is reasonably complete. It specifies the retrieval of 'detailed information' and 'all settings', which helps the agent understand the output scope. However, it could improve by hinting at the return format or linking to sibling tools for broader context.

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

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

Schema description coverage is 100%, with the parameter 'calendarId' clearly documented in the schema. The description does not add any additional meaning or context about the parameter, such as where to obtain the ID or format examples. Baseline score of 3 is appropriate as the schema handles the parameter documentation adequately.

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

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

The description clearly states the verb ('Get') and resource ('detailed information about a specific calendar including all settings'), making the purpose evident. However, it does not explicitly differentiate from sibling tools like 'get_calendars' (plural) or 'get_calendar_availability', which might retrieve similar information but with different scopes or focuses.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as needing a calendar ID, or compare it to siblings like 'get_calendars' for listing multiple calendars or 'get_calendar_availability' for scheduling purposes, 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.

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

Annotations already provide strong behavioral hints (read-only, open-world, idempotent, non-destructive), so the description's burden is lower. It adds useful context about the tool's purpose ('open for booking'), but does not disclose additional traits like rate limits, authentication needs, or output format. No contradiction with annotations exists.

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

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

The description is two sentences, front-loaded with the core purpose and followed by a usage guideline. Every word contributes value without redundancy, making it highly efficient and easy to parse.

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

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

Given the annotations cover safety and idempotency, and the schema fully describes parameters, the description provides adequate context for a read-only query tool. However, without an output schema, it could better explain the return format (e.g., list of time slots). It remains mostly complete but has a minor gap in output clarity.

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

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

Schema description coverage is 100%, with all parameters well-documented in the schema (e.g., date format, timezone default). The description adds no extra parameter details beyond implying the tool returns availability slots, which aligns with the schema but does not enhance it. This meets the baseline for high schema coverage.

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

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

The description clearly states the specific action ('Get available time slots'), target resource ('for a specific calendar'), and scope ('on a given date'), distinguishing it from siblings like 'get_calendar_weekly_availability' which handles weekly patterns. It uses precise verbs and avoids tautology.

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

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

The description provides clear context for when to use the tool ('to check what times are open for booking'), which implicitly differentiates it from tools like 'get_appointments' (which retrieves scheduled events). However, it does not explicitly state when not to use it or name alternatives, such as 'get_calendar_weekly_availability' for recurring availability.

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

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

Annotations already indicate read-only, open-world, idempotent, and non-destructive behavior, so the description doesn't need to repeat these. It adds context by specifying what 'availability overrides' are (modified or blocked availability for specific dates), which is useful beyond annotations, but doesn't detail response format or error handling.

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

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

The description is a single, efficient sentence that front-loads the purpose ('Get availability overrides for a calendar') and adds clarifying detail ('specific dates with modified or blocked availability') without unnecessary words. Every part earns its place.

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

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

Given the tool's simplicity (1 parameter, no output schema) and rich annotations covering safety and behavior, the description is mostly complete. It explains what 'availability overrides' are, but could benefit from mentioning return format or error cases to be fully comprehensive.

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

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

Schema description coverage is 100%, with the parameter 'calendarId' fully documented. The description doesn't add any meaning beyond the schema, such as format examples or constraints, so it meets the baseline for high schema coverage without extra value.

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

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

The description clearly states the verb 'Get' and the resource 'availability overrides for a calendar', specifying it retrieves modified or blocked availability for specific dates. It distinguishes from siblings like 'get_calendar_availability' or 'get_calendar_weekly_availability' by focusing on overrides, but doesn't explicitly contrast them.

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

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

No guidance is provided on when to use this tool versus alternatives like 'get_calendar_availability' or 'get_calendar_weekly_availability', nor does it mention prerequisites such as needing a valid calendar ID. The description implies usage for retrieving overrides but lacks explicit context or exclusions.

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

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

Annotations cover key behavioral traits (read-only, open-world, idempotent, non-destructive), so the description's bar is lower. It adds context about the 'up to 5 reminders' limit, which is useful beyond annotations. However, it doesn't disclose other behaviors like response format, pagination, or error handling, leaving some gaps.

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

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

The description is a single, efficient sentence that front-loads the core action ('Get all reminder configurations for a calendar') and adds a useful constraint. There's no wasted text, but it could be slightly more structured by explicitly separating purpose from limitations.

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

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

Given the tool's low complexity (1 parameter, no output schema) and rich annotations, the description is somewhat complete but has gaps. It covers the basic purpose and a constraint, but lacks usage guidelines, output details, and error information, making it minimally adequate but not fully comprehensive.

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

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

Schema description coverage is 100%, with the single parameter 'calendarId' fully documented in the schema. The description adds no additional meaning about parameters beyond what the schema provides, such as format examples or constraints. Baseline 3 is appropriate since the schema handles the heavy lifting.

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

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

The description clearly states the verb 'Get' and resource 'reminder configurations for a calendar', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_calendar_overrides' or 'get_notifications', which might also retrieve calendar-related settings, so it misses full sibling distinction.

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

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

The description provides no guidance on when to use this tool versus alternatives. It mentions 'Each calendar can have up to 5 reminders,' which is a constraint but not usage advice. There's no indication of prerequisites, alternatives like 'get_calendar' for general info, or when to choose this over other get_* tools.

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

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

Annotations already provide key behavioral hints (readOnlyHint, openWorldHint, idempotentHint, destructiveHint), so the description adds minimal value. It mentions the return format ('array of calendars with their settings'), which is useful context not covered by annotations, but lacks details on pagination, error handling, or auth needs. No contradiction with annotations.

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

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

The description is two concise sentences with zero waste: the first states the purpose, and the second details the return format. It is front-loaded and efficiently communicates essential information without redundancy.

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

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

Given the tool's simplicity (0 parameters, no output schema) and rich annotations, the description is adequate but has gaps. It explains the return data, which is helpful, but doesn't address potential complexities like error cases or how it differs from sibling tools, making it minimally viable for the context.

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

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

The tool has 0 parameters, and schema description coverage is 100% (though empty). The description doesn't need to add parameter details, so it appropriately focuses on output semantics. A baseline of 4 is justified as it compensates for the lack of parameters by describing the return data.

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

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

The description clearly states the verb ('List') and resource ('booking calendars owned by the user'), making the purpose specific and understandable. However, it doesn't explicitly distinguish this tool from sibling tools like 'get_calendar' or 'get_calendar_availability', which might have overlapping or related functionality.

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

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

The description provides no guidance on when to use this tool versus alternatives. With many sibling tools (e.g., 'get_calendar', 'get_calendar_availability'), there is no mention of context, prerequisites, or exclusions, leaving the agent to infer usage from the purpose alone.

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

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

Annotations already cover read-only, open-world, idempotent, and non-destructive behavior. The description adds context about returning recurring weekly slots, which is useful but doesn't detail format, pagination, or error conditions. No contradiction with annotations exists.

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

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

Single sentence is front-loaded and efficient, with no wasted words. It directly conveys the core purpose without redundancy.

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

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

For a simple read tool with rich annotations (safety profile covered) and one parameter, the description is reasonably complete. However, without an output schema, it could benefit from mentioning return format (e.g., time slots, days).

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

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

Schema coverage is 100% with one parameter (calendarId) fully described. The description doesn't add meaning beyond the schema, such as format examples or constraints. Baseline 3 is appropriate given high schema coverage.

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

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

The description clearly states the verb ('Get') and resource ('weekly availability schedule for a calendar'), specifying it's for recurring slots per day. It distinguishes from sibling 'get_calendar_availability' by focusing on weekly patterns, though it doesn't explicitly name that sibling.

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

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

The description implies usage for recurring weekly schedules, but doesn't explicitly state when to use this vs. alternatives like 'get_calendar_availability' or 'get_calendar_overrides'. No guidance on prerequisites or exclusions is provided.

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

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

Annotations already declare this as read-only, non-destructive, idempotent, and open-world, covering key behavioral traits. The description adds minimal context by specifying what data is retrieved (confirmation mode and channel), but doesn't disclose additional behaviors like error conditions, authentication needs, rate limits, or response format. No contradiction with annotations exists.

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

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

The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part earns its place by specifying the action, target, and exact data retrieved, making it easy to scan and understand quickly.

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

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

Given the tool's low complexity (single required parameter), rich annotations (covering safety and idempotency), and lack of output schema, the description is minimally adequate. It states what data is returned but doesn't explain the response structure or potential errors. For a read-only tool with good annotations, this is acceptable but leaves gaps in usage context.

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

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

Schema description coverage is 100%, with the single parameter 'calendarId' fully documented in the schema. The description doesn't add any meaning beyond the schema—it doesn't explain what a calendar ID is, where to find it, or format constraints. Baseline 3 is appropriate since the schema carries the full parameter documentation burden.

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

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

The description clearly states the action ('Get') and the resource ('confirmation settings for a calendar'), specifying the exact data retrieved ('confirmation mode and communication channel'). It distinguishes from general calendar retrieval tools like 'get_calendar' by focusing on confirmation settings, but doesn't explicitly differentiate from the sibling 'update_confirmation_settings' beyond the verb difference.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid calendar ID), when not to use it, or how it relates to sibling tools like 'get_calendar' (which might return broader settings) or 'update_confirmation_settings' (the corresponding write operation).

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

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

Annotations cover key behavioral traits (read-only, open-world, idempotent, non-destructive), so the description's burden is lower. It adds minimal context by implying it retrieves 'detailed information,' but doesn't elaborate on what details are included, error handling, or authentication needs beyond what annotations provide.

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

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

The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part of the sentence contributes directly to understanding the tool's function.

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

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

Given the tool's low complexity (one parameter) and rich annotations, the description is minimally adequate. However, without an output schema, it doesn't explain what 'detailed information' includes, leaving a gap in completeness for a retrieval tool.

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

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

Schema description coverage is 100%, with the parameter 'contactId' fully documented in the schema. The description doesn't add any meaning beyond this, such as format examples or sourcing instructions, so it meets the baseline for high schema coverage without extra value.

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

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

The description clearly states the verb ('Get') and resource ('detailed information about a specific contact'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'get_contacts' (plural) or 'update_contact', which would require explicit comparison to achieve a perfect score.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention siblings like 'get_contacts' for listing multiple contacts or 'update_contact' for modifications, nor does it specify prerequisites such as needing a valid contact ID.

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

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

Annotations already provide comprehensive safety information (readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true). The description adds minimal behavioral context beyond this - it mentions 'optional search' which hints at filtering capability, but doesn't describe pagination behavior, rate limits, authentication needs, or what constitutes a 'contact' in this system.

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

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

The description is extremely concise - a single 5-word sentence that communicates the core functionality without any wasted words. It's front-loaded with the primary action and resource.

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

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

Given the comprehensive annotations (which cover safety and idempotency) and 100% schema coverage, the description is minimally adequate. However, for a data retrieval tool with no output schema, it doesn't describe what a 'contact' object contains, how results are ordered, or pagination behavior. The annotations do much of the heavy lifting here.

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

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

With 100% schema description coverage, both parameters ('limit' and 'search') are fully documented in the schema. The description mentions 'optional search' which aligns with the schema, but adds no additional semantic context about how search works, what fields are searched, or the meaning of the limit parameter beyond what's already in the schema.

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

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

The description 'List contacts with optional search' clearly states the verb ('List') and resource ('contacts'), and specifies the optional search capability. It distinguishes from siblings like 'get_contact' (singular) by indicating it returns multiple contacts, but doesn't explicitly differentiate from other list-like tools on the server.

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

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

The description provides no guidance on when to use this tool versus alternatives. There are multiple sibling tools like 'get_contact' (singular), 'get_appointments', and 'get_calendars', but no indication of when this specific contacts listing tool is appropriate versus other data retrieval tools.

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

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

Annotations already provide comprehensive behavioral hints (read-only, open-world, idempotent, non-destructive). The description adds minimal context about retrieving 'recent' notifications, which suggests temporal filtering not captured in annotations. However, it doesn't disclose important behavioral details like pagination, sorting, or what 'recent' means.

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

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

The description is a single, efficient sentence that communicates the core purpose without any wasted words. It's appropriately sized for a simple retrieval tool and front-loads the essential information.

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

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

For a simple read operation with comprehensive annotations but no output schema, the description is adequate but minimal. It covers the basic purpose but lacks details about return format, error conditions, or the meaning of 'recent' that would help an agent use it effectively.

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

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

With 100% schema description coverage, the schema already fully documents the single optional 'limit' parameter. The description adds no additional parameter information beyond what's in the schema, maintaining the baseline score for high schema coverage.

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

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

The description clearly states the action ('Get') and resource ('recent in-app notifications'), making the purpose immediately understandable. However, it doesn't distinguish this tool from potential sibling notification tools (none exist in the provided list, but the description doesn't clarify this scope).

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

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

The description provides no guidance on when to use this tool versus alternatives. While there are no direct sibling notification tools, it doesn't mention whether this should be used instead of other data retrieval tools or under what specific circumstances it's appropriate.

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

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

Annotations already indicate it's not read-only, not idempotent, not destructive, and open-world, covering key behavioral traits. The description adds value by specifying 'Requires write scope,' which clarifies authentication needs beyond annotations. It doesn't contradict annotations (e.g., 'destructiveHint: false' aligns with rescheduling rather than deleting), and provides useful context without redundancy.

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

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

The description is extremely concise with two short sentences that are front-loaded and waste-free. Every word contributes essential information (action and scope requirement), making it efficient and easy to parse without unnecessary elaboration.

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

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

Given the tool's complexity (a mutation with 3 parameters), annotations cover safety and behavior well, and schema coverage is complete. However, there's no output schema, and the description doesn't explain return values or potential side effects (e.g., notifications sent). For a rescheduling tool, more context on outcomes would enhance completeness, but it's minimally adequate with existing structured data.

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

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

Schema description coverage is 100%, with all parameters well-documented in the schema (e.g., 'newStartTime' as ISO 8601 format). The description doesn't add any parameter-specific details beyond the schema, so it meets the baseline of 3 for high coverage. No parameters are left unexplained, but no extra semantic value is provided.

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

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

The description clearly states the verb ('Initiate a reschedule request') and resource ('for an appointment'), making the purpose specific and understandable. It distinguishes from siblings like 'cancel_appointment' by focusing on rescheduling rather than cancellation. However, it doesn't explicitly differentiate from potential overlapping tools like 'update_calendar' that might also modify appointments, keeping it from a perfect score.

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

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

The description provides some guidance by mentioning 'Requires write scope,' which implies a prerequisite for usage. However, it lacks explicit when-to-use instructions compared to alternatives like 'cancel_appointment' or 'update_calendar,' and doesn't specify scenarios or exclusions for rescheduling versus other appointment modifications.

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

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

Annotations already indicate this is a non-readOnly, non-destructive, non-idempotent operation with openWorldHint. The description adds valuable context: it reveals that the invitation triggers a 'confirmation request' to the visitor, which is a key behavioral outcome not captured in annotations. However, it doesn't mention potential side effects like calendar updates or notification behavior.

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

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

The description is perfectly front-loaded with the core purpose in the first sentence, followed by two concise sentences providing critical usage guidance. Every sentence adds value with zero redundant information, making it highly efficient for an agent to parse.

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

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

For a mutation tool with 10 parameters and no output schema, the description does well by explaining the action, prerequisite, and contact identification options. However, it doesn't describe what happens after sending (e.g., does it return a confirmation ID? what's the failure mode?). Given the complexity and lack of output schema, a bit more about expected outcomes would make it fully complete.

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

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

With 100% schema description coverage, all parameters are documented in the schema. The description adds some semantic context by explaining the relationship between contactId and other fields ('if provided, firstName/email/phone are used from the contact'), which clarifies parameter interdependencies. This goes beyond the schema but doesn't provide extensive additional parameter meaning.

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

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

The description clearly states the specific action ('send an appointment invitation'), target ('to a client'), and context ('on behalf of the service provider'). It distinguishes this tool from sibling tools like 'create_contact' or 'reschedule_appointment' by focusing on invitation sending rather than contact management or appointment modification.

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

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

The description provides explicit guidance: 'Check availability first using get_calendar_availability' (prerequisite), and offers clear alternatives for contact identification ('reference an existing contact by contactId, or provide firstName/email/phone directly'). This tells the agent when and how to use this tool versus other approaches.

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

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

Annotations indicate this is a mutable (readOnlyHint: false), non-destructive (destructiveHint: false), non-idempotent (idempotentHint: false) operation with open-world semantics (openWorldHint: true). The description adds value by specifying the type of settings being updated (booking constraints) but doesn't elaborate on behavioral aspects like permission requirements, error conditions, or side effects beyond what annotations cover.

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

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

The description is a single, efficient sentence that directly states the tool's purpose with zero wasted words. It's appropriately front-loaded and avoids unnecessary elaboration.

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

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

For a mutation tool with no output schema, the description adequately covers the core purpose but lacks details on return values, error handling, or integration with sibling tools. Given the rich annotations and full schema coverage, it's minimally complete but could benefit from more contextual guidance.

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

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

Schema description coverage is 100%, so all parameters are documented in the schema. The description adds minimal context by listing examples of constraints (min notice, max advance, buffers), which correspond to some parameters, but doesn't provide additional semantic details beyond what the schema already specifies.

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

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

The description clearly states the action ('Update') and target resource ('booking constraints for a calendar'), with specific examples of constraints (min notice, max advance, buffers). However, it doesn't explicitly differentiate from sibling tools like 'update_calendar' or 'update_calendar_weekly_availability', which might also modify calendar settings.

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

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

No guidance is provided on when to use this tool versus alternatives like 'update_calendar' or 'update_calendar_weekly_availability'. The description implies usage for updating booking constraints but doesn't specify prerequisites, exclusions, or contextual triggers.

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

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

Annotations indicate this is a mutable (readOnlyHint: false), non-destructive (destructiveHint: false), non-idempotent (idempotentHint: false), open-world (openWorldHint: true) operation. The description adds minimal behavioral context beyond this—it mentions 'settings' but doesn't clarify what happens with partial updates, whether changes are immediate, or if there are side effects. It doesn't contradict annotations, but adds little value beyond them.

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

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

The description is a single, efficient sentence that front-loads the core purpose. It uses 'etc.' to imply additional fields without listing all 14 parameters, avoiding redundancy. However, it could be slightly more structured by explicitly noting it's for partial updates of existing calendars.

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

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

Given the tool's complexity (14 parameters, mutation operation) and rich annotations, the description is minimally adequate. It lacks output details (no output schema provided) and doesn't explain error conditions or side effects. For a tool with many parameters and no output schema, more context on what to expect post-update would be helpful, but annotations cover key behavioral traits.

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

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

Schema description coverage is 100%, so all parameters are documented in the schema. The description lists examples of updatable fields (name, description, duration, buffers, reminders, etc.), which aligns with the schema but doesn't add meaningful semantics beyond it. The baseline of 3 is appropriate since the schema does the heavy lifting.

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

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

The description clearly states the verb 'Update' and resource 'calendar settings' with examples of what can be updated (name, description, duration, buffers, reminders, etc.). It distinguishes itself from sibling tools like 'create_calendar' or 'delete_calendar' by focusing on updates, though it doesn't explicitly differentiate from similar update tools like 'update_booking_settings' or 'update_calendar_weekly_availability'.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (like needing an existing calendar), when to use this versus 'update_booking_settings' or 'update_calendar_weekly_availability', or any constraints (e.g., permissions required). The agent must infer usage from the tool name and context alone.

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

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

Annotations provide readOnlyHint=false, destructiveHint=false, openWorldHint=true, and idempotentHint=false. The description adds valuable context beyond annotations: it specifies that this operation 'replaces all existing slots,' which clarifies the destructive nature of the update (overwrites rather than merges). This behavioral detail isn't captured in annotations, enhancing transparency.

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

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

The description is a single, well-structured sentence that front-loads the core purpose and adds a critical behavioral detail ('replaces all existing slots'). There is no wasted text, and every word contributes to understanding the tool's function.

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

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

Given the tool's complexity (a mutation with array input), annotations cover safety aspects, and the schema fully describes parameters. The description adds key behavioral context about replacement semantics. However, without an output schema, it doesn't explain return values or error conditions, leaving a minor gap in completeness.

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

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

Schema description coverage is 100%, with clear documentation for both parameters (calendarId and slots). The description doesn't add any semantic details beyond the schema, such as format examples or constraints. However, the baseline score is 3 since the schema adequately covers parameter meanings.

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

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

The description clearly states the specific action ('Update'), target resource ('weekly availability schedule for a calendar'), and scope ('replaces all existing slots'). It distinguishes from siblings like 'update_calendar' (general updates) and 'get_calendar_weekly_availability' (read-only).

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

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

The description implies usage context by specifying 'replaces all existing slots,' suggesting this is for bulk updates rather than incremental changes. However, it doesn't explicitly state when to use this versus alternatives like 'update_calendar' or 'create_calendar_override,' nor does it mention prerequisites or exclusions.

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

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

Annotations cover key behavioral traits (readOnlyHint=false, destructiveHint=false, etc.), so the bar is lower. The description adds context by specifying what settings are updated (manual vs auto-verify, email vs SMS), but doesn't disclose additional traits like permissions needed, rate limits, or side effects beyond the annotations.

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

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

The description is a single, efficient sentence with zero waste. It's front-loaded, immediately stating the tool's purpose without unnecessary details, making it easy to parse.

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

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

Given the tool's moderate complexity (3 parameters, no output schema) and rich annotations, the description is adequate but incomplete. It covers the purpose but lacks usage guidelines and behavioral details beyond annotations, leaving gaps for an AI agent to infer correct invocation.

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

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

Schema description coverage is 100%, providing full parameter documentation. The description adds minimal value by mentioning the settings (manual vs auto-verify, email vs SMS), which aligns with the enum descriptions but doesn't elaborate beyond what the schema already states.

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

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

The description clearly states the action ('Update') and resource ('confirmation settings for a calendar'), specifying what gets updated. It distinguishes the tool from siblings like 'update_calendar' or 'update_booking_settings' by focusing on confirmation settings, though it doesn't explicitly mention sibling differentiation.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, such as needing an existing calendar, or compare it to sibling tools like 'get_confirmation_settings' or 'update_calendar', leaving usage context unclear.

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

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

The description adds valuable context beyond annotations by specifying the 'write scope' requirement, which isn't covered by the annotations (they only indicate it's not read-only, not open-world, not idempotent, and not destructive). This helps the agent understand authentication needs. However, it doesn't mention rate limits, error conditions, or what happens to unspecified fields during partial updates.

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

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

The description is extremely concise—just two short sentences that are front-loaded with the core purpose and essential requirement. There's no wasted verbiage, repetition, or unnecessary details, making it efficient and easy to parse.

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

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

Given the tool's complexity (a mutation operation with 6 parameters), lack of output schema, and annotations that cover basic behavioral hints, the description is somewhat incomplete. It misses details like response format, error handling, and whether updates are partial or full. However, it does include the critical 'write scope' requirement, which partially compensates for gaps.

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

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

The description doesn't add any parameter-specific information beyond what's already in the input schema, which has 100% description coverage. It doesn't explain how parameters interact (e.g., partial updates) or provide examples. With high schema coverage, the baseline is 3, as the schema adequately documents the parameters without extra help from the description.

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

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

The description clearly states the action ('Update') and resource ('an existing contact'), making the purpose immediately understandable. However, it doesn't distinguish this tool from its sibling 'update_calendar' or other update tools, nor does it specify what fields can be updated beyond what's implied by the input schema.

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

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

The description provides some guidance by stating 'Requires write scope,' which indicates an authentication prerequisite. However, it doesn't explicitly say when to use this tool versus alternatives like 'create_contact' or 'delete_contact,' nor does it mention any specific scenarios or exclusions for its use.

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