sync

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

Goes well beyond the annotations by disclosing that this is a real write which re-verifies every participant's availability and refuses if anyone is busy (never double-books), that the caller is the organizer so no organizer handle is needed, and that Sync Pro/Lucie Membership plus live booking pages are required. This is exactly the extra behavioral context annotations cannot carry.

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 and the key write semantics are front-loaded, and each sentence carries operational content (organizer identity, re-verification, prerequisite call, eligibility). It is on the long side for a single tool, with the eligibility sentence stacked at the end, but nothing is truly redundant.

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 non-idempotent, open-world write tool with no output schema, the description covers preconditions, failure behavior, and eligibility. The main remaining gap is what the caller gets back (event link, confirmation, invite status) and any rate/limit constraints.

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 the schema documents all five parameters; the description still adds meaning by clarifying that participantHandles covers only the *other* participants (the caller is the organizer) and that durationMinutes must be one the organizer offers. It adds some value but not syntax or format detail beyond 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?

States a specific verb (Confirm), resource (group meeting across several Lucie hosts), and the concrete side effect (ONE shared Google Calendar event with everyone invited). The scope and the 'one shared event' behavior clearly separate it from book_meeting and create_group_event.

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 an explicit prerequisite workflow ('Always call find_group_times first and copy an exact common-slot start') and a pre-call checklist (time per zone, participants, title, reason), plus eligibility constraints (Sync Pro/Lucie Membership, live booking pages). It does not explicitly say when to prefer book_meeting or create_group_event instead, so the alternative routing is only partial.

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?

Goes beyond the annotations by disclosing real side effects: it "creates a calendar event and emails both the host and the booker," and the reason is "shared with the host." It does not address duplicate bookings or what happens if the slot is taken, which matters given idempotentHint=false.

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 purpose in sentence one, then prerequisites in a numbered, scannable checklist. Every sentence carries actionable information with no filler.

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 still tells the agent what the call produces (event + emails) and what must be gathered first. It leaves unaddressed the failure path when a slot is taken and the non-idempotent double-booking risk.

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 (including startAt's ISO-8601 verbatim-copy rule and viewerTimeZone's purpose) is already documented in the schema. The description only restates the required-ness of name, email, and reason, adding little beyond the schema baseline.

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 ("Book") and resource ("a confirmed meeting on a Lucie Sync host's calendar") with a scope qualifier ("at a specific start time") that signals a one-on-one booking. Sibling differentiation from book_group_meeting is only implicit via the singular "a Lucie Sync host's calendar" framing; the alternative is never named.

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 explicit prerequisites: "Always call check_availability first and use one of the open slots it returns," plus a pre-call confirmation and data-collection protocol. Strong positive guidance, but no when-not-to-use or explicit routing to book_group_meeting for multi-party bookings.

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 establish readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds genuine context beyond them: the result is limited to bookable slots and policy and never exposes the raw calendar, slots are absolute ISO-8601 UTC instants, and timezone rendering depends on viewerTimeZone. It does not mention pagination or result-size 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?

Four tight sentences, each earning its place: scope, exclusivity of return data, workflow placement, and timezone semantics. The most decision-relevant facts (what is returned, what is not) are front-loaded.

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-value burden and does so adequately: it names the two return components (bookable slots plus booking rules such as durations, minimum notice, advance horizon, buffers) and the instant format. Combined with the annotation-covered safety profile, nothing essential for correct invocation is missing.

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 baseline is 3. The description goes further by explaining why viewerTimeZone should be the booker's own zone ('the booker should never have to do time-zone math') and that slots are absolute instants, adding rationale the schema does not carry.

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 ('Return the open meeting slots a Lucie Sync host offers, plus their booking rules') and explicitly scopes what is returned versus withheld ('never the host's raw calendar'). An agent can distinguish this read/reconnaissance tool from the booking siblings (book_meeting, book_group_meeting) without opening any 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?

Gives clear timing guidance — 'Use this to find a time before proposing one to the user' — which situates it in the workflow ahead of the booking tools. It does not explicitly name an alternative or state exclusions (e.g., when to prefer find_group_times for multi-party scheduling), 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?

Adds substantial context beyond the annotations: it is a write that 'sends no emails and touches no calendars', it returns a vote link, and non-Lucie participants can vote manually. It also discloses the Sync Pro/Membership gating, which the annotations (openWorldHint only) cannot convey. This is exactly the behavioral detail a caller needs before creating the poll.

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-loaded with the core action and outcome, then prerequisites; every sentence carries information. It is dense and slightly long for one paragraph, but no sentence is filler.

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 8 parameters, no output schema, and a mutation of medium complexity, the description covers what the tool creates, what it returns (a vote link), side effects (no emails/calendar writes), and the licensing prerequisite. Nothing essential for correct invocation is missing.

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 already documents all 8 parameters (handles, from/to window, timeZone, durationMinutes, organizer fields). The description explains the semantics of the seeded candidate times (intersection of availability) and confirms duration with the organizer, but adds no per-parameter format or constraint detail beyond the schema. Baseline 3 applies.

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 ('Create a Lucie group event (a poll)') and immediately clarifies the resource is a scheduling poll seeded with the intersection of participants' availability, which separates it from the read-only find_group_times and the booking-oriented book_group_meeting. An agent can tell what it produces (a poll + vote link) without opening the 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?

Gives clear context and prerequisites: confirm title/participants/duration with the organizer first, and the organizer must be on Sync Pro or hold a Lucie Membership. It does not explicitly name sibling alternatives ('use find_group_times first, then book_group_meeting when a time is chosen'), so routing is implied rather than stated.

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 openWorldHint=true, but the description adds real value: 'never books, never exposes anyone's raw calendar (only the shared open slots)' discloses a privacy property the annotations do not, and the note about absolute instants plus viewerTimeZone explains a behavioral quirk of the result. It doesn't discuss rate limits, handle-not-found behavior, or empty-result cases.

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 tight sentences with no filler; the core behavior (intersection of availability) is front-loaded, followed by the safety/privacy note and the time-zone caveat in priority order.

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 read-only query tool with full schema coverage and no output schema, the description covers what is returned (shared free slots for the requested duration), the safety profile, and the time-zone handling. It would be complete if it hinted at result ordering, pagination/limits, or what happens when no common slot exists.

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 baseline is 3. The description largely restates what the schema already documents (handles as @handle, viewerTimeZone as the organizer's zone, durationMinutes, from/to as the search window) and adds no syntax or constraint detail beyond it, such as the 8-handle max.

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 states a specific verb and resource ('return the meeting times when ALL of them are free'), and pins down the exact semantics with 'the intersection of their availability.' It also implicitly separates itself from the sibling booking tools by emphasizing that it never books and only computes shared open 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?

'Use it to propose a group time' gives a clear usage context, and the read-only framing signals when this is preferable to the booking siblings. It stops short of naming an explicit alternative (e.g., book_group_meeting once a time is chosen) or stating exclusions, so it is clear but not fully routing.

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