WhenMeet.me

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

Annotations only declare readOnlyHint=false, so the description carries most of the burden and does add real value: it discloses the calendar write, auto-generated Google Meet/Teams link, ICS invite emails to guests and host, and the auth/human-bot-check requirement. However, it omits failure modes, whether a confirmed slot is atomic/locked, and rate limits, so it stops short of a full behavioral picture.

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?

Front-loads the purpose and the critical startsAt constraint in the first two sentences, then covers side effects and return values. Dense but slightly redundant with the schema on defaults and the startsAt source, which keeps it short of a 5.

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

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

With no output schema, the description compensates by naming the return fields (bookingId, conferenceUrl, meetingUrl, manageUrl) and their cancel/reschedule purpose. Combined with side effects and auth requirements, an agent has everything needed to call this correctly.

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

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

Schema coverage is 100%, so every parameter already has a documented meaning and defaults. The description mostly restates schema content (startsAt source, name/email defaults) rather than adding new syntax or constraint meaning, which lands at the baseline for full-coverage schemas.

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?

States a specific verb and resource ('Book a time on someone's WhenMeet.me booking link') and immediately names the sibling it depends on (get_booking_slots). It does not explicitly distinguish itself from create_meeting, the other scheduling-write sibling, so sibling differentiation is only partial.

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?

Gives a hard prerequisite ('startsAt must be a slot start from get_booking_slots') and a clear alternate-case rule for name/email ('pass them to book for someone else'). It also states an authentication requirement and the bot-check exception, though it never states when NOT to use this tool vs create_meeting.

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?

readOnlyHint already signals a safe read, and the description adds substantial context on top: the exact returned fields, the privacy guarantee ('only times and counts... never anyone's calendar'), the token-dependent behavior of othersFree/othersTotal, and the default window. That is well beyond what the annotation conveys.

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?

Purpose is front-loaded in the first clause and every sentence carries information. Some fragments are dense and slightly telegraphic ('team mode', 'No auth needed'), but there is no padding or repetition.

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

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

With no output schema, the description carries the return-shape burden and does so — it enumerates title, durationMin, required questions, team mode, timezone, and the slot fields. Combined with the privacy note and defaults, an agent has everything needed to call and interpret this 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%, so baseline is 3, but the description goes further — it decodes the handle format (whenmeet.me/@nickname[/slug]), explains how guests are folded into othersFree, and gives the interpretation rule othersFree === othersTotal = good for everyone. It does not restate the numeric bounds already in the schema, so it is additive rather than redundant.

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?

States a specific verb and resource — 'Bookable times on someone's WhenMeet.me booking link' — and scopes it by link form (personal or team, nickname[/slug]). An agent can immediately separate this from siblings like find_common_slots or get_meeting_availability, which concern other resources.

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

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

Explains the calling context (token vs. no token, no auth needed, default 14-day window) and what the token buys you, which is genuine usage guidance. It never names an alternative sibling or states a when-not-to-use condition, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true, and description confirms it's a read operation. It adds context about 'hand-marked' slots and 'within a window', but lacks details on authorization needs, empty results, or rate limits. 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?

Single sentence, no fluff. Perfectly sized for the tool's simplicity (3 parameters, straightforward 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?

No output schema, so description should hint at return format (e.g., list of time slots). It doesn't. However, tool complexity is low and annotations cover read safety, making it marginally adequate.

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

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

Schema description coverage is 0%, so description must compensate. It indicates 'email' and a 'window' (from/to), but does not specify that 'from' and 'to' are Unix timestamps or provide format/units. This leaves ambiguity for an AI 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?

Description clearly states it reads hand-marked free slots for an email within a window. Verb 'Read' and resource 'previously hand-marked free slots' are specific, and it distinguishes from siblings like 'set_manual_availability' and 'get_meeting_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?

Description implies usage after manual availability has been set, but does not explicitly state when to use this tool vs alternatives like 'get_meeting_availability' or 'find_common_slots'. No exclusion criteria 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?

The annotations already indicate readOnlyHint=true, and the description confirms a read operation. It adds transparency by detailing the response content (time, title, etc.), going beyond the annotation. The description is consistent and provides additional context.

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 and includes all necessary details without extraneous 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 (one parameter, no output schema), the description covers input format and output fields sufficiently. It does not mention error handling or access permissions, but these are minor for a read operation. The sibling list provides 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?

The schema has 0% description coverage for 'meetingId', but the description compensates fully by explaining that it is the UUID from the share-link URL (/m/<id>). This adds significant meaning beyond the raw schema definition.

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

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

The description explicitly states it reads a meeting by its share-link id, listing specific fields returned (time, title, conference URL, host, alternate times). This is a clear verb+resource with a distinct identifier method, and it distinguishes from sibling tools which handle creation, availability search, and 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 implies when to use this tool (when you have a share-link id) and by listing sibling tools, the agent can infer alternatives. However, it does not explicitly state when not to use it or provide exclusion criteria.

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

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

Annotations state readOnlyHint=true, and the description adds valuable behavioral context: 'Individual calendars are never exposed' and 'No auth needed — the meeting id is the capability.' This goes beyond annotations to explain privacy and access requirements.

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 (two sentences) and front-loads the core purpose. Every part adds value, with no extraneous words. However, some technical details (like the output structure) are packed densely, which could be clearer.

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 structure well (counts, ranked slots, allFree) and notes auth requirements. However, given no output schema and 5 parameters, it lacks details on how parameters like 'tz' or 'durationMin' affect results, leaving gaps for an agent to apply the tool correctly.

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

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

Schema coverage is only 40% (2 of 5 parameters described). The description only implicitly references 'meetingId' (as 'existing meeting') and does not explain 'to', 'from', 'tz', or 'durationMin'. With low coverage, the description fails to compensate, leaving significant parameter 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?

The description clearly states the tool returns 'aggregated group availability' for an existing meeting, specifying the output format (per-30-min-slot counts, ranked slots, allFree slots). It distinguishes from siblings like 'find_common_slots' and 'get_manual_availability' by emphasizing aggregation and privacy (individual calendars not exposed).

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

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

No explicit when-to-use or when-not-to-use guidance is provided. The description mentions 'No auth needed' as a usage note, but fails to differentiate use cases from sibling tools like 'find_common_slots' or 'suggest_time'. Usage is implied but not clarified.

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 declare readOnlyHint=false and idempotentHint=true, and the description usefully explains why a 'list' tool writes: the zero-config provisioning of a default 30-minute link when a calendar is connected but /links was never opened, explicitly called out as idempotent. It also states the authentication requirement and clarifies team-link mode semantics ('all' vs 'any'), adding real context 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 content is front-loaded around the return structure, but it is delivered as a dense run-on sentence stuffed with parenthetical detail. Every clause is informative, yet the wall-of-text format makes it harder to scan than a structured breakdown would be.

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

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

With no output schema, the description carries the burden of describing return values, and it does so thoroughly (profile fields, publicUrl, eventTypes[] with url/duration/settings, team mode and members). It also flags authentication and the provisioning behavior, leaving little an agent needs missing for correct invocation.

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

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

Schema description coverage is 100% and the single tz parameter is fully documented in the schema. The description adds nothing about tz, so the baseline of 3 is appropriate since the schema already does the work.

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 names the resource (your own booking link) and enumerates what it contains — profile, publicUrl, eventTypes[] — so an agent can tell this apart from the booking/meeting siblings. It is more of a return-shape inventory than a crisp verb+resource statement, but the intent to list your booking links is 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?

There is no explicit guidance on when to call this versus the many siblings (get_booking_slots, find_common_slots, book_slot, etc.). The zero-config note explains a side effect but not the selection context, so the agent must infer usage from the name alone.

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

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

Discloses that accepting moves the meeting, includes calendar event, re-sends invites, and requires host authentication. Adds value beyond the readOnlyHint annotation (which is false, consistent).

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 wasted words. Front-loads the core action and provides essential behavioral detail efficiently.

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?

Fairly complete for a mutation tool with 3 params and no output schema. Covers purpose, behavior, and auth. Could mention what happens on decline (likely no action), but not essential.

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% (no parameter descriptions in schema). The description does not detail the parameters (meetingId, suggestionId, action) or their formats. Only implies usage through context.

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

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

Clearly states the verb 'accept or decline' and the resource 'proposed alternate time'. Distinguishes from siblings like suggest_time (which proposes) and create_meeting (which creates).

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

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

Provides clear context: when there is a proposed alternate time, and who can call (only host, requires auth). Lacks explicit when-not-to-use or alternatives, but the context is sufficient.

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