Nolizi Calendar

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

The description discloses side effects not captured by annotations: it notifies the attendee, removes from connected calendars, and is irreversible. The warning that cancelling one occurrence of grouped/recurring bookings can affect several meetings adds behavioral nuance beyond the destructiveHint annotation. No contradiction with annotations; idempotentHint and destructiveHint are 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?

The description is three sentences, each carrying essential information: action and effects, ID provenance, and caution for grouped/recurring bookings. It is front-loaded with the core purpose and contains 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?

For a single-parameter cancellation tool with no output schema, the description covers purpose, side effects, irreversibility, ID source, and a critical edge case. The presence of annotations further covers safety profile, and nothing an agent needs to call correctly 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?

The schema already describes booking_id as 'Exact booking_id from list_upcoming_bookings' with 100% coverage, so baseline is 3. The description reinforces this and adds 'never a guessed or reconstructed one', and explains that a booking_id may represent grouped/recurring bookings affecting multiple meetings, adding semantic nuance 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?

The description opens with 'Cancel a confirmed booking', a specific verb and resource. It distinguishes from siblings by focusing on the cancellation action, contrasting with the list_* tools and create_booking. Mentioning attendee notification and calendar removal further clarifies its unique 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?

It explicitly instructs using an exact booking_id from list_upcoming_bookings, never a guessed or reconstructed one, providing a clear source and constraint. The warning to confirm which meetings the person means for grouped/recurring bookings gives practical usage guidance. However, it doesn't explicitly contrast with alternatives beyond the ID source, so not a full 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 only signal readOnly=false and idempotent=false, but the description adds crucial behavioral context: invitations are sent, writes are irreversible except by cancellation, the server re-checks live availability, and there is no idempotency key. This fully discloses the side effects beyond the structured 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?

Every sentence earns its place: consequences, confirmation requirements, input validity rules, and failure-handling guidance are all included without repetition. The most important operational constraint is front-loaded near the beginning.

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 and no idempotency, the description covers everything an agent needs to call it safely: prerequisites, exact input sourcing, side effects, irreversibility, and recovery behavior. The only minor omission is explicitly naming cancel_booking as the undo path, but 'except by cancelling' 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 100%, so the baseline is 3, but the description adds meaning beyond the schema: start/end must be copied verbatim and are validated against live availability, and name/email must be real, never placeholders. Not every parameter is enriched, but the highest-risk ones are.

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 opens with 'Book a real meeting' and immediately states the concrete effects: sending invitations and writing to connected calendars. It is clearly distinguished from the sibling tools like cancel_booking and list_available_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 gives explicit pre-conditions: confirm the event, time, and attendee details before calling, and copy start/end verbatim from list_available_slots. It also tells the agent what to do on an uncertain outcome — do not retry, instead call list_upcoming_bookings — which is strong alternative routing.

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 and destructiveHint, covering safety. The description adds valuable behavioral context: times are real/live, must not be invented or rounded, and original values must be passed unchanged to create_booking. This goes beyond the structured annotations and informs safe handling of results.

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, front-loaded with the core purpose, then important usage and data-handling caveats. No wasted words; 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?

For a simple read-only tool with one parameter, the description is complete: it explains the purpose, usage flow, and data-handling constraints. It does not detail the exact response structure beyond 'start/end pairs', but that is sufficient for an agent to use the results appropriately.

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% and the parameter description already clarifies that event_type is an event slug from list_event_types, not a schedule_id. The tool description adds no additional parameter detail, so it meets the baseline for high coverage but does not exceed it.

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 ('Return') and resource ('live available start/end pairs for one event type'). It clearly distinguishes from siblings: it's about availability for a single event type, not booking or listing event types. The purpose is unambiguous and unique among the sibling 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 gives explicit usage context: 'show them to the person and let them choose' and instructs to pass original values to create_booking. It implies this tool is a prerequisite for booking, but does not explicitly compare to alternatives or state when not to use it. Still, the context is clear and actionable.

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, openWorldHint=true, and destructiveHint=false. The description adds value beyond that by warning that some event types cannot be booked through the API and that the slug is a prerequisite for other tools. This gives useful behavioral context without contradicting 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?

Three sentences with no wasted words: purpose first, then usage guidance, then an important limitation. The message is front-loaded and 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?

For a zero-parameter read-only catalog tool, the description covers purpose, usage ordering, the critical return field, and a booking limitation. While there is no output schema and no explicit listing of all return fields, the slug is the essential output and the description names it clearly.

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 zero parameters and schema description coverage is 100%, so there is no parameter documentation burden. The description compensates by highlighting the key output field (the slug), which is the actionable piece of information an agent needs.

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: 'List the bookable event types owned by the configured Nolizi Calendar account.' This clearly distinguishes it from the sibling tools, which deal with bookings and available slots rather than the event type catalog.

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 explicitly says to 'Start here' and explains that the returned slug is required by every other tool, with a direct instruction to 'Never guess a slug.' It also provides an exclusion: events with required custom questions or email verification should use the public booking page instead of this API.

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 destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: it caps results at 100 and explicitly states this is the only verification mechanism, which is useful for an agent reasoning about side effects and reliability. It doesn't describe pagination or ordering, but for a read-only list tool with annotations, this is solid.

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, and the most important operational guidance ('use after every create or cancel') is 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?

For a zero-parameter read-only tool with annotations covering safety, the description is nearly complete. It explains the result cap and the verification role. It doesn't mention return format, but there is no output schema and the tool is simple enough that an agent can infer a list of bookings. Minor gap: no mention of ordering or time horizon, but not critical.

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 zero parameters, so there is no parameter semantics burden. The description's mention of 'upcoming confirmed bookings' clarifies the implicit filter, which is the only meaningful semantic context an agent needs. Baseline 4 for zero params 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 states a specific verb ('List'), a resource ('upcoming confirmed bookings'), and a scope ('up to 100'). It also distinguishes itself from siblings by noting it is the only way to verify a booking exists, which clearly separates it from list_available_slots and list_event_types.

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 explicit when-to-use guidance: use after every create or cancel, and use it first whenever a write returned an uncertain outcome. This is strong usage direction that tells an agent exactly when to invoke this tool versus alternatives.

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