WhenMeet.me — group scheduling

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

The description discloses key behaviors: writes to calendar, emails invites with ICS, returns share URL, and requires authentication. This adds value beyond the readOnlyHint annotation. It does not cover all edge cases (e.g., idempotency), but sufficiently describes the main side effects.

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

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

The description is two sentences, efficiently conveying the primary action, optional features, and authentication requirement. No unnecessary text. It is well-structured and front-loaded with the main purpose.

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

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

Given the tool has 6 parameters and no output schema, the description explains the return value (share URL) and side effects (email, ICS). It does not clarify the format of participants or time constraints, but the schema covers required fields. Overall, it is fairly complete for a meeting creation tool.

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

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

Schema coverage is 67% with descriptions for tz, startsAt, endsAt, and conference. The description does not add additional parameter information. Baseline 3 is appropriate as the schema does the heavy lifting, and no extra clarification is provided for parameters like participants or title.

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 confirms a meeting by writing to the host's calendar, adding optional conference links, emailing invites with ICS attachment, and returning a share URL. This is specific and distinguishes it from sibling tools like suggest_time or get_meeting.

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

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

It specifies the requirement for authentication, providing clear context. However, it does not explicitly mention when not to use this tool or compare it to alternatives like respond_to_suggestion or find_common_slots. The usage is implied but not fully delineated.

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

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

Annotations already declare readOnlyHint=true, so the description adds value by stating it merges live calendar data, hand-marked availability, and heat-map sources, and defaults to next 14 days. No contradictions, and it provides useful context beyond the annotation.

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, highly efficient with no wasted words. Every sentence adds value: first explains functionality, second adds default period and authentication requirement.

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

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

Given no output schema and 5 parameters, the description provides sufficient context about what the tool does, its inputs, and data sources. It could elaborate on output ranking or heat-map sources, but it is mostly complete for a read-only tool.

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

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

Schema coverage is 100% with descriptions. The description adds meaning by explaining the participants array includes the authenticated user as host, and it reiterates defaults for from, to, and durationMin. This supplements the schema effectively.

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 ranks best meeting times when all participants are free, using a verb ('rank') and resource ('best meeting times'). It distinguishes from siblings like suggest_time by emphasizing 'ALL given participants' and merging multiple data sources.

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 indicates when to use the tool, i.e., to find meeting times for a group. It mentions authentication is required, which guides usage. While it doesn't explicitly state when not to use or name alternatives, the context is clear enough for an agent.

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 context beyond the readOnlyHint annotation by specifying the resource type (hand-marked free slots) and the time window constraint. However, it could disclose more about behavior when no slots exist or return format.

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 concise sentence that front-loads key information. However, it sacrifices detail for brevity, especially regarding parameters.

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

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

Given the tool has 3 parameters and no output schema, the description is minimal. It does not explain what 'hand-marked free slots' means, how the time window is specified (timestamp format), or the expected return structure, making it incomplete for confident agent 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?

The input schema has 0% description coverage for its 3 parameters (email, from, to). The description mentions 'email' and 'window' but provides no details on parameter formats, allowed values, or semantics, failing to compensate for the schema gaps.

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 reads previously hand-marked free slots for a specific email within a time window. It distinguishes from sibling tools like set_manual_availability (write) and get_meeting_availability (system 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 implies usage for reading manual overrides but does not explicitly state when to use this tool versus alternatives like find_common_slots or get_meeting_availability. No prerequisites or exclusions are mentioned.

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

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

The annotations already indicate read-only (readOnlyHint=true), and the description adds value by specifying the exact return fields (time, title, conference URL, host, alternate times status). No contradictions. However, it does not disclose behavior for invalid IDs or errors.

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

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

The description is a single sentence that front-loads the purpose ('Read a meeting') and immediately follows with the input format and return fields. No redundant words.

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

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

For a simple read tool with one parameter and no output schema, the description adequately covers what the tool does, what it returns, and how to use it. No additional information is necessary.

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

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

The input schema has no description for meetingId (0% coverage), but the description explicitly explains it as 'the UUID from /m/<id>', providing crucial context for correct usage.

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

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

The description clearly states the tool reads a meeting by its share-link ID and lists the specific fields returned (time, title, conference URL, host, proposed alternate times with status). It distinguishes itself from sibling tools like create_meeting, which create, or suggest_time, which suggest, by focusing on reading an existing meeting.

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 (use with a share-link ID), but does not explicitly state when not to use this tool or mention alternatives for other operations (e.g., creating or modifying meetings).

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

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

Adds value beyond annotations: describes output granularity (30-min slots), privacy (individual calendars never exposed), and auth requirements. No contradiction with readOnlyHint.

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

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

Three succinct sentences: purpose, output, privacy, auth. No filler, front-loaded, every sentence adds unique value.

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

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

Covers main behavioral aspects despite no output schema. Could elaborate on how durationMin affects slot counts, but overall sufficient for a read-only aggregation tool with clear output shape.

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 40%, yet description adds no parameter-specific meaning (e.g., explanation of meetingId, from, to, tz, durationMin). Does not help agent map parameters to behavior.

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

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

The description specifies 'aggregated group availability for an existing meeting' with clear output details (per-30-min-slot counts, ranked everyone-free slots). It distinguishes from siblings like 'get_manual_availability' and 'find_common_slots' by focusing on an existing meeting's symmetric group view.

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

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

States 'No auth needed' and 'meeting id is the capability' implying use when meeting ID is known. Does not explicitly compare to sibling tools or state when not to use, but the context is clear enough for an agent to infer.

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 readOnlyHint=false. Description adds critical behavioral details: accepting moves the meeting, re-sends invites, and requires authentication/host role. No contradictions.

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

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

Two sentences, no filler. Purpose, effect, and constraints are front-loaded. Every sentence earns its place.

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

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

Covers purpose, host requirement, and side effects. However, with 3 parameters and no output schema, additional detail on parameter semantics would improve completeness.

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

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

Schema coverage is 0%, yet description does not explain parameters individually. Only 'action' is clear from enum. 'meetingId' and 'suggestionId' lack semantic context, leaving ambiguity.

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

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

Description clearly states the tool's function: 'Accept or decline a proposed alternate time.' It specifies the resource (suggestion) and action (respond), and differentiates from siblings like suggest_time which proposes rather than responds.

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

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

Explicitly states 'Only the meeting host may call this — requires authentication,' which provides clear usage conditions. It doesn't directly list alternatives but implies when not to use (if not host).

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

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

Beyond the annotation (readOnlyHint=false), the description reveals that previously marked slots are replaced, the group heat-map updates immediately, and different authentication methods are required (Bearer PAT vs. Turnstile token for anonymous callers). This fully discloses behavioral traits.

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

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

Three sentences, each adding value: purpose, behavioral effects, and authentication. No redundant or unnecessary information. Front-loaded with the main action.

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

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

Given the complexity (5 parameters, no output schema), the description covers purpose, behavior, and authentication well. It mentions the group heat-map update but could address error conditions or rate limits. Overall, it provides sufficient context for agent decision-making.

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

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

Schema description coverage is 60% (3 of 5 parameters have schema descriptions). The description adds context for 'turnstileToken' (required for anonymous callers) but does not elaborate on 'email' or 'freeSlots' beyond what the schema provides. It does not fully compensate for the missing parameter descriptions.

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

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

The description clearly states the action ('Publish hand-marked FREE time slots') and the resource ('for an email address'), distinguishing it as a fallback for non-calendar users like Apple iCloud. This is a specific verb+resource that separates it from calendar-based tools.

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

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

The description identifies the tool as a fallback for non-calendar users and explains authentication requirements, providing clear usage context. However, it does not explicitly state when not to use this tool versus siblings like 'get_manual_availability' or 'suggest_time', nor list alternatives.

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

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

Beyond the annotation (readOnlyHint=false), the description discloses side effects (host notified by email, can accept/decline) and authentication requirements (Bearer PAT vs. Turnstile token). This adds value and is consistent 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 sentences, front-loading the core purpose and side effect, then adding authentication context. Every sentence contributes meaning with no waste.

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

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

The description covers purpose, side effects, and auth, but lacks explanation of error scenarios, response format (no output schema), and the role of the caller (guest vs. organizer). It is adequate but leaves gaps for a tool with 6 parameters and authentication nuances.

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 67%, covering 4 of 6 parameters. The description adds meaning only for turnstileToken, explaining when it is required. It does not compensate for the missing descriptions for meetingId and message, nor does it add detail for other parameters beyond what the schema provides.

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

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

The description clearly states the tool's action: 'Propose a different time for an existing meeting on behalf of a guest.' This verb-resource pairing is specific and distinguishes it from siblings like create_meeting (creates new meetings) and respond_to_suggestion (responds to proposals).

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

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

The description implies usage when an alternative time is needed for an existing meeting, but it does not explicitly compare to sibling tools or provide exclusion criteria. There is no guidance on when not to use it or when to prefer alternatives like find_common_slots or respond_to_suggestion.

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