WhenMeet.me

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

Beyond the readOnlyHint=false annotation, the description discloses write operations (calendar event creation, email sending) and the return of a share URL. However, it does not detail side effects like whether events are modifiable or rate limits.

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

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

The description is a single sentence that efficiently lists key actions, but could be better structured with clearer separation of steps.

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 no output schema, the description covers major side effects (calendar write, email, share URL) and authentication. It lacks detail on error cases or duplicate handling, but is sufficient for basic 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?

With 67% schema description coverage, the description adds only one new detail (optional Google Meet/Teams link) beyond what the schema provides. It does not clarify title or participants, which lack schema descriptions.

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

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

The description clearly states it confirms a meeting, writes to calendar, adds optional conference links, emails invites, and returns a share URL. This distinctively positions it among sibling tools like suggest_time or find_common_slots, which handle earlier scheduling phases.

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

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

The description implies use for finalizing a meeting after scheduling decisions, but lacks explicit when-to-use or when-not-to-use guidance compared to sibling tools. It does mention authentication as a prerequisite.

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 useful context beyond the readOnlyHint annotation, explaining that the tool merges multiple data sources and ranks times. It also explicitly states that authentication is required, which is not in the annotations. There is no contradiction with 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 concise, consisting of a single sentence that front-loads the main action and key details. It efficiently covers the tool's function, data sources, defaults, and requirements without unnecessary words. However, it could be slightly more structured by separating the authentication requirement as a distinct note.

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

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

Given the tool has 5 parameters (all documented in the schema), no output schema, and moderate complexity, the description adequately covers the input and merging behavior. However, it lacks explanation of the output format (e.g., what the ranking looks like, time slots returned) and does not describe behavior when participants are missing or provide examples of usage.

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

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

Schema description coverage is 100%, and the parameters are already well-described in the schema (e.g., 'to', 'from', 'tz', 'durationMin', 'participants'). The description adds only marginal parameter-specific value, such as mentioning default behavior and authentication, but does not elaborate on parameter formats or constraints 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 ('Rank the best meeting times'), specifies the condition ('when ALL given participants are free'), and identifies the data sources merged ('live Google/Microsoft calendar data, hand-marked availability and the heat-map sources'). It also mentions the default window and authentication, making the purpose highly specific and distinguishable from 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?

The description implies usage for finding common free times among participants, and notes that it requires authentication and defaults to 14 days. However, it does not explicitly state when not to use this tool versus alternatives like 'suggest_time' or 'get_meeting_availability', nor does it provide exclusions or prerequisites beyond authentication.

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 include readOnlyHint: true, consistent with the description. The description adds no additional behavioral context (e.g., what happens if no slots exist, data latency). No contradiction.

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

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

Single sentence with 12 words, front-loaded with the verb. No redundancy; every word adds value.

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

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

The description covers the basic purpose and key parameters but omits return format (e.g., array of slots, empty response). Given no output schema, this is a gap.

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

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

With 0% schema description coverage, the description partially explains 'email' and 'window' but fails to specify parameter format (e.g., timestamp units for 'from' and 'to'). This leaves ambiguity for an agent.

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 ('read'), resource ('previously hand-marked free slots'), and scope ('for an email within a window'). It effectively distinguishes from sibling tools like 'set_manual_availability' (write).

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

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

The description implies when to use (retrieve manual availability for a specific email and time window) but lacks explicit guidance on when not to use or compare to alternatives like 'get_meeting_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 declare readOnlyHint=true, so the description adds value by detailing the returned data (time, title, conference URL, etc.). It does not mention other behaviors like auth requirements or error handling, but for a simple read tool, this is sufficient.

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

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

A single sentence that front-loads the purpose and efficiently lists the return fields. No unnecessary words.

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

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

Given the tool's simplicity (1 parameter, no output schema), the description covers the core functionality and return values. It does not mention error cases, but it is fairly complete for a read 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?

With 0% schema description coverage, the description compensates by explaining that meetingId is a share-link ID (UUID from /m/<id>). This adds meaningful context beyond the schema's type string.

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, alternate times). This distinguishes it from sibling tools like create_meeting or find_common_slots.

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

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

The description implies usage when you have a share-link ID but does not explicitly state when to use this tool versus alternatives or provide exclusions. It lacks guidance on prerequisites or context.

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

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

Beyond the readOnlyHint annotation, the description adds behavioral details: it uses a symmetric heat-map concept, aggregates per-30-min slots, ranks everyone-free slots, and explicitly states individual calendars are not exposed. No contradiction with annotations.

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

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

Two sentences, front-loaded with the core purpose. No wasted words; every sentence provides 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?

The description explains the output format (counts, ranked slots), privacy behavior, and authentication. However, it lacks details on pagination or behavior for large meetings. Given the tool's complexity and lack of output schema, a score of 4 indicates it is mostly complete but has minor 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?

Schema has 5 parameters with 40% description coverage. The description does not explain individual parameters (to, from, tz, durationMin) beyond the general context. It adds minimal value over the schema, which already provides some descriptions for to, from, and durationMin. A score of 3 is appropriate as the description does not compensate for the coverage gap.

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 returns aggregated group availability for an existing meeting, described as a symmetric heat-map with per-30-min slot counts and ranked free slots. It distinguishes itself from siblings by focusing on existing meetings and not exposing individual calendars.

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

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

Implied usage: use when you need to see availability for an existing meeting. Description notes individual calendars are never exposed, which helps agents understand privacy. However, it does not explicitly state when not to use or provide alternatives among siblings.

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

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

Annotations already indicate a write operation (readOnlyHint=false). The description adds that accepting moves the meeting and re-sends invites, which is key behavioral context. 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?

Three concise sentences front-loading the core purpose and key behavioral notes. No wasted words; every sentence adds value.

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

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

Covers main effects and auth requirement but omits return behavior and parameter semantics. Adequate for a simple tool but has clear 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?

Schema description coverage is 0%. The description explains the action enum (accept/decline) but provides no detail for meetingId or suggestionId. It adds some meaning but insufficiently compensates for the lack of 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 'Accept or decline a proposed alternate time,' specifying the verb and resource. It distinguishes from sibling tools like suggest_time and find_common_slots by focusing on responding to suggestions.

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: only the meeting host can call, requires authentication, and explains consequences of acceptance. However, it does not explicitly exlude scenarios or compare with siblings.

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

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

Beyond readOnlyHint=false, it explains replacement behavior and immediate heat-map update. It also details authentication paths and turnstile requirement. Could add idempotency or error 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?

Three efficient sentences front-loading the main action, then behavioral and auth details. No wasted words.

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

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

Covers purpose, parameters, auth, and behavior. Lacks return value or error handling, but for a set operation this is sufficient.

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 60%; description adds context for freeSlots and window but doesn't explain email or freeSlots format beyond schema. Baseline 3 is appropriate.

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

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

The description clearly states the verb 'Publish hand-marked FREE time slots' and specifies the resource (email address for no-calendar fallback). It distinguishes from siblings like get_manual_availability by implying setting vs getting.

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 gives context: for email addresses without a calendar (iCloud users), and when to use turnstile token. However, it doesn't explicitly contrast with sibling tools like create_meeting or suggest_time.

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

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

The description discloses key behaviors: host notification by email, bot challenge skipping for authenticated callers, and Turnstile token requirement. This adds significant context beyond the readOnlyHint=false 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 concise yet comprehensive, with the purpose front-loaded and each sentence adding necessary detail 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 tool with 6 parameters and no output schema, the description covers purpose, authentication, and a parameter condition, but lacks explanation of the return value or side effects beyond notification.

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%, but the description adds value by explaining the conditional requirement for turnstileToken. However, it does not elaborate on meetingId or message, which are missing from schema descriptions.

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

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

The description clearly states the action (Propose a different time) and the resource (existing meeting), and distinguishes it from siblings like respond_to_suggestion and create_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 explains when to use the tool (proposing a time for a meeting) and provides context on authentication and Turnstile token, but does not explicitly exclude when not to use or compare to siblings.

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