bookeo

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

Annotations only declare destructiveHint=true, but the description adds substantive behavior: the booking is not deleted (still visible via includeCanceled), seats are freed, the account's cancellation policy is bypassed, and therefore no cancellation fee is charged. These side effects are exactly what an agent needs before invoking a destructive operation.

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 short sentences, front-loaded with the action and its consequences, with no filler. Every sentence conveys information an agent would otherwise lack.

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 the critical unknowns for a destructive tool: soft-delete semantics, seat release, fee exemption. It does not say whether the cancellation can be reversed/restored or what the API returns, though no output schema exists to offset that 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?

Schema description coverage is 100%, so all six parameters (reason, notifyCustomer, notifyUsers, cancelRemainingSeries, trackInCustomerHistory, bookingNumber) are already documented in the schema. The description adds no parameter-level detail beyond what the structured fields provide, so the baseline of 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 precise verb+resource ('Cancel a booking') and is unambiguously distinct from siblings like bookeo_create_booking and bookeo_update_booking. The closing line even names the underlying API operation (DELETE /bookings/{bookingNumber}), removing any doubt about intent.

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 the effect of canceling (frees seats, stays in the system, no fee), which indirectly signals when it is appropriate, but it never states when to use this versus bookeo_update_booking or bookeo_create_hold, nor any prerequisites. Usage is implied rather than guided.

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 meaningful context beyond the destructiveHint annotation: the booking is created as confirmed, no payment is recorded, and it is reversible via bookeo_cancel_booking. The reversibility and payment-exclusion notes are exactly the sort of behavioral disclosure an agent needs. It stops short of 5 by not covering side effects like notifications firing or what happens to a released hold on failure.

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, then packed with the highest-value constraints (product-type routing, hold conversion, no payment, reversibility) in a handful of tight sentences. No filler and no redundancy with the schema.

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 an 18-parameter tool with nested objects and no output schema, the description covers the crucial branching (customer vs customerId, eventId vs startTime) that determines whether a call succeeds. It does not mention the returned booking identifier, which the agent would want in order to subsequently cancel or update the booking.

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 cross-parameter logic the schema does not encode: eventId is mandatory for fixed products and optional for flexibleTime, and previousHoldId links to bookeo_create_hold. That relational guidance is genuine added value above the per-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?

States a specific verb and resource ('Create a confirmed booking') and immediately scopes it to existing vs new customers. It also names the sibling tools that relate to it (availability tools, bookeo_cancel_booking), so an agent can distinguish it from bookeo_create_hold and bookeo_update_booking.

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 concrete conditional guidance: eventId required for fixed/fixedCourse, eventId or startTime for flexibleTime, customerId vs customer, and previousHoldId to convert a hold. It does not explicitly state when to prefer this over create_hold or update_booking, so it falls just short of full when/when-not coverage.

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 declare destructiveHint=true, so the description should carry most of the behavioral burden, yet it adds no information about permissions, whether duplicate customers are merged or created, idempotency, or what the response contains. The inline-booking note is workflow context rather than behavioral disclosure.

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 short sentences, front-loaded with the core action and followed by the routing hint. The raw API endpoint line ('Bookeo: POST /customers.') is low-value filler for an agent that already knows the tool name.

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 and near-empty annotations mean the description must cover behavior and parameters, but it does neither; a 10-parameter create tool with nested objects is described in two functional sentences. Adequate for routing, inadequate 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?

Ten parameters at 20% schema description coverage, with a nested address object and phone-number array, and the description adds zero parameter meaning. Names of required fields, format expectations, or constraints are left entirely to the thin 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 and resource ('Create a customer record') and explicitly routes against the sibling that could do the same job implicitly ('bookeo_create_booking can create the customer inline'). An agent can tell this apart from create_booking and update_customer without opening a 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 a clear when-not-to-use condition tied to a named alternative tool, which is genuinely useful routing. It does not cover the other relevant alternatives (update_customer, get_customer) or state prerequisites such as duplicate handling.

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 carry destructiveHint=true, and the description usefully clarifies the mutation is transient rather than permanent: 'Holds expire automatically', plus the duration window (default 300 s, max 600 s). It also discloses that pricing returned is final, which is behaviorally meaningful for a price-check step. It doesn't cover failure semantics (what happens when the requested seats are already held).

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 short sentences, front-loaded with the core action and price outcome, then the sibling handoff, then expiry/API mapping. No filler and no repetition of schema prose.

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 14-parameter, nested-object mutation with no output schema, the description covers purpose, the critical chaining parameter, expiry behavior and the price return, which is enough to call it correctly. Minor gaps remain around error/conflict behavior and what exactly the hold response contains beyond the id and price.

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 and the schema already documents all 14 parameters. The description adds workflow-level meaning the schema lacks: that the holdDurationSeconds window is bounded and defaulted, and that previousHoldId is the mechanism for chaining a hold into the subsequent booking call.

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 concrete verb+resource ('temporarily reserve the seats/resources for a draft booking') and adds the secondary outcome ('get the FINAL price, taxes and amount payable'), which cleanly separates it from bookeo_create_booking. An agent can identify the tool's role 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?

Explicitly positions itself as 'the recommended step before bookeo_create_booking' and states the handoff ('pass the returned hold id as previousHoldId there'), which gives clear when-to-use routing. It stops short of stating when a hold can be skipped (e.g. pure price enquiry or read-only availability checks).

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 safety profile is covered. The description adds useful context beyond that: it is a cheap/read-only sanity check and it returns account identity plus the granted permission strings, which is the key behavioral payoff.

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 tight sentences front-load the return content before the usage hint, with no filler. The trailing "Bookeo: GET /settings/apikeyinfo." endpoint mapping is mildly redundant but conventional and cheap.

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?

There is no output schema, so the description must carry the return-value burden, and it does by naming the two returned facts and giving permission-scope examples. A slightly fuller enumeration of possible permission values would make it complete.

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?

Zero parameters, so the baseline of 4 applies; the schema is empty by design and there is nothing further for the description to explain.

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 (show) and resource (Bookoo account + granted permissions for the current credentials), with concrete permission-scope examples. No sibling tool does anything comparable, so it is immediately distinguishable from the CRUD/list/get family.

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?

"A cheap way to confirm the setup works" gives a clear triggering condition for when to call it. It does not name an alternative, but no sibling overlaps this capability, so no exclusion is needed.

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 the description adds real behavioral context beyond that: the 31-day maximum window and the product-type restriction. It also discloses the underlying endpoint, aiding predictability, though it doesn't discuss pagination behavior explicitly.

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 tight sentences plus an endpoint reference; the scope and routing constraint are front-loaded and nothing is redundant. 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 helpfully enumerates the returned fields (eventId, start/end, seats available), and the schema covers paging. It is nearly complete, though it could note response shape or paging semantics in the description itself for a list endpoint.

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 all seven parameters are already documented in the schema, including the paging trio and mode enum. The description reclarifies productId's scope ('fixed and fixedCourse products') but adds little beyond what the schema already states, so the 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 (List) and resource (available slots), names the returned fields (eventId, start/end, seats available), and explicitly limits scope to fixed/fixedCourse products. It cleanly distinguishes itself from the unrelated list_* siblings and from search_matching_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?

Explicitly states when-not to use it ('Not for flexibleTime products') and names the alternative tool to use instead, which is exactly the routing an agent needs. The 31-day window constraint further bounds correct usage.

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=true already declares this is a safe read. The description adds real value beyond the annotation by enumerating what the response contains (product, times, participants, options, price, paid amount, status) and noting the status enum values, which helps the agent interpret 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?

A single front-loaded sentence pairing the core operation with the returned fields, plus a short endpoint reference. Every clause earns its place with no padding.

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 usefully compensates by listing returned fields and status values, so an agent knows what to expect. It could be slightly stronger on pagination/auth specifics, but it is complete for a simple single-record getter.

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 bookingNumber, expandCustomer, and expandParticipants are all documented in the schema; baseline 3 applies. The description adds no syntax or format detail for the parameters 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 (get) and resource (one booking) scoped by booking number, and enumerates the fields returned. It is clearly distinguishable from bookeo_list_bookings, though it does not explicitly name the list tool as the alternative.

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 phrase 'by its booking number' implies the single-record lookup context, but there is no explicit when-to-use vs bookeo_list_bookings or bookeo_search_matching_slots, and no stated prerequisites or conditions.

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 safe-read nature is covered structurally. The description adds the read scope (which business fields are exposed) and the underlying endpoint GET /settings/business, but says nothing about auth requirements, rate limits, or whether the call can fail when settings are unset.

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 short, front-loaded sentences with no filler; the returned-field list comes first and the API endpoint mapping second. The trailing 'Bookeo: GET /settings/business' is marginally redundant with the tool itself but is cheap and aids endpoint mapping.

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 reasonably by enumerating the returned fields (name, contact details, address, website, description). For a parameterless read tool this is close to sufficient; a note on the error/empty case would fully close the 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?

There are zero input parameters, so the baseline is 4 per the rubric. Schema coverage is 100% and no parameter semantics need to be conveyed.

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 ('Get') and resource ('the business') and enumerates what is returned: name, contact details, address, website, description. It is clearly distinct from the booking/customer siblings by topic, though it does not explicitly name an alternative or contrast itself with them.

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 statement or named alternatives are given. For a zero-parameter read of a singleton settings resource, usage is strongly implied (retrieve account/business metadata), which lands at the 'implied usage' level rather than explicit guidance.

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=true already tells the agent this is a safe read, and the description goes beyond that by disclosing the shape of what comes back (booking history, cancellations/no-shows, membership, store credit). It does not cover error behavior (e.g. unknown id) or rate/permission constraints, so it stops short of full transparency.

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 tight sentences, front-loaded with the operation and its returned fields; the trailing 'Bookeo: GET /customers/{id}' is mildly redundant but usefully anchors the endpoint. 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 carries the burden of describing returns and does so by enumerating the customer data fields. For a one-parameter read tool this is nearly complete; only error/not-found behavior is unaddressed.

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?

There is a single parameter whose schema description coverage is 100%, so the schema already fully documents 'id'. The description adds no format or sourcing guidance for that id, so the baseline of 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 precise verb+resource ('Get one customer') and enumerates the returned data (contact details, bookings, cancellations/no-shows, membership, store credit), which cleanly separates it from bookeo_list_customers and bookeo_update_customer. It stops short of naming those siblings, so the differentiation is implicit rather than explicit.

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?

Usage is implied: fetch a single customer when you already have the id, as opposed to bookeo_list_customers or bookeo_search_matching_slots. However, no when-to-use/when-not-to-use conditions, no prerequisites, and no alternative is named, so the agent must infer the 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=true, so the safety profile is covered. The description adds the underlying endpoint (Bookeo: GET /payments/{id}) and the returned fields, but says nothing about auth, error behavior for an invalid id, or rate limits. Modest value beyond 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 compact sentences with zero waste; the core purpose and returned fields are front-loaded before the endpoint reference.

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 enumerated returned fields give the agent a sense of the response shape, which is genuinely useful for a single-entity fetch. Some detail (what happens on unknown id, response envelope) is absent, but the definition is adequate for a simple read 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?

Only one parameter (id) with 100% schema coverage, so the schema already documents it fully. The description adds no format, example, or sourcing detail for the id beyond what the schema provides — baseline 3.

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 (get) and resource (one payment), and enumerates the fields returned (amount, method, reason, received time, customer, gateway transaction id). The singular 'one payment' implicitly distinguishes it from the sibling list tools bookeo_list_payments and bookeo_list_booking_payments, though it never names them.

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 guidance on when to use this versus bookeo_list_payments or bookeo_list_booking_payments, and no stated prerequisites. The agent must infer that a known payment id is required.

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=true already declares this a safe read, so the bar is lower. The description usefully adds that refunds appear as negative amounts, but says nothing about ordering, pagination behavior in practice, or what a payment record contains (no output schema exists to cover this).

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 tight sentences, front-loaded with what is returned, followed by the underlying endpoint mapping. No filler; the endpoint reference grounds the call semantics rather than padding.

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?

This is a low-complexity read-only list with one required parameter and full schema coverage, so little burden remains. Scope, the refund convention, and the endpoint are stated; only the shape of individual payment records is left implicit, which is acceptable given the simplicity.

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% (pageNumber, itemsPerPage, pageNavigationToken, bookingNumber all documented in the schema), so the baseline is 3. The description adds no parameter-level meaning beyond what the schema already says.

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 (List) and resource (payments/refunds) scoped to 'one booking', which cleanly separates it from the sibling bookeo_list_payments (all payments). The negative-amount convention for refunds is a concrete detail that further pins down what is returned.

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 phrase 'for one booking' implies you must already have a bookingNumber and want its payment history, but there is no explicit when-to-use guidance, no mention of the alternative bookeo_list_payments or bookeo_get_payment, and no stated prerequisites. Usage is left to inference.

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 safety profile is covered and the bar is lower. The description usefully adds the required-parameter-pair rule and the 31-day span cap, but says nothing about result volume, pagination behavior, or what 'expand' actually returns.

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 tight sentences plus the endpoint reference, with the hard requirement front-loaded rather than buried after the optional features. Every clause carries 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?

For a read-only list tool with no output schema and 11 fully documented parameters, the description covers the essential invocation constraints. It is nonetheless silent on return shape and on how paging interacts with the required search windows.

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 per-parameter baseline is 3. The description earns above baseline by surfacing the cross-parameter constraint (startTime+endTime or lastUpdatedStartTime+lastUpdatedEndTime, at least one pair, max 31 days) that no individual schema field expresses.

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 plus the two filtering modes (start-time window vs. last-changed window), which is far more informative than the title 'List bookings'. An agent can distinguish this bulk/range listing from bookeo_get_booking and bookeo_list_customer_bookings without opening a 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?

Explicitly states the gating rule — 'at least one pair is required, each spanning at most 31 days' — which is exactly the context needed to call it successfully. It does not, however, name when to prefer it over siblings such as bookeo_list_customer_bookings or bookeo_search_matching_slots.

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 safety profile is covered. The description only restates the date-range option that the schema already documents and adds an API endpoint reference; it discloses nothing further about pagination behavior, defaults, or result shape for this read operation.

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 compact sentences with no filler, and the core operation is front-loaded ahead of the endpoint reference.

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 list tool with complete schema coverage and annotations carrying the safety profile, the description is largely sufficient. It is slightly thin on return/pagination expectations, though the pagination parameters are self-explanatory in the schema.

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 all seven parameters (including pagination and expandParticipants) are documented there. The description adds no syntax, format, or default detail beyond the schema, so the 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 (List), resource (bookings), and scope (one customer's, optionally date-bounded), which clearly separates it from the sibling bookeo_list_bookings that lists bookings broadly. However, it never names that sibling or any alternative, so differentiation is left to inference.

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?

Usage is implied: use this when you have a customer id and want that customer's bookings. There is no explicit when-to-use versus bookeo_list_bookings or bookeo_get_booking, and no stated prerequisites or exclusions.

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 safety profile is covered by structured data. The description adds only the upstream endpoint (GET /customers) and the filter semantics; it says nothing about pagination limits or result shape, so the additional behavioral context is modest.

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 tight sentence that front-loads the action and the searchable fields, with the endpoint reference trailing. Nothing is padded, though the field enumeration is somewhat redundant with the schema.

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 list tool with a fully documented 8-parameter schema and no output schema, the description covers the purpose and filter surface adequately. It omits any mention of pagination behavior, which is handled entirely by the schema, leaving only a minor 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?

Schema description coverage is 100%, so every parameter, including pageNavigationToken and itemsPerPage, is already fully documented. The description's field list (name, firstName, lastName, emailAddress) merely restates what the searchField enum already provides, adding no syntax or edge-case detail.

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 clear verb and resource ('List or search customers') and enumerates the searchable fields, which separates it in spirit from the singular bookeo_get_customer. It never names a sibling outright, so the differentiation relies on inference rather than an explicit contrast.

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 conveys the tool's optional modes (search vs. plain list, members/non-members, created-since) which implies when to use it, but it gives no explicit guidance about when to prefer bookeo_get_customer or bookeo_search_matching_slots, and no prerequisites are 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?

The readOnlyHint annotation already covers the safety profile, and the description adds a useful behavioral detail: refunds are included with a negative amount. It also names the underlying Bookeo endpoint, which helps confirm the operation. It does not discuss auth requirements or rate limits, but with annotations present, the added refund semantics are valuable.

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 short, front-loaded sentences with no wasted words. The key behavior, refunds as negative amounts, is stated directly after the main purpose. The endpoint reference is compact and useful.

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 list tool with 7 optional parameters and full schema coverage, the description covers the essential purpose and a notable return-value behavior. Pagination and filtering details are adequately handled by the schema, so the description need not repeat them. It could be strengthened by mentioning when to use this versus bookeo_list_booking_payments.

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 parameters are already well documented in the schema itself. The description only echoes the time-period and payment-method filtering semantics without adding format details, examples, or constraints beyond what the schema provides. A baseline score of 3 is appropriate when the schema does the heavy lifting.

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 clear verb and resource: list payments received in a time period, optionally by payment method. It also notes that refunds are included with a negative amount, distinguishing the result semantics. However, it does not explicitly distinguish this tool from related siblings like bookeo_list_booking_payments or bookeo_get_payment.

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 by specifying a time period and an optional payment-method filter, which gives enough context to know when this tool is appropriate. It does not state when to use it instead of alternatives such as bookeo_get_payment or bookeo_list_booking_payments, nor does it offer exclusions.

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 safety is covered. The description adds useful behavioral detail about the payload (ids and seats taken, defaults vs custom) but says nothing about pagination, refresh behavior, or whether custom categories can be created here, so 3 is appropriate.

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 tight sentences, front-loaded with the purpose and the value of the return data. The trailing 'Bookeo: GET /settings/peoplecategories' is mild redundancy but also a useful anchor to the underlying API.

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 parameters, no output schema, and only a readOnly annotation, the description still conveys what the call yields (category ids and seat usage) and why it matters. This is nearly complete; only enumeration/pagination behavior is undocumented.

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 takes zero parameters, so per the baseline this is a 4. The description correctly does not invent parameters to explain.

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 precise verb+resource ('List the participant categories the account uses') and enumerates the content returned (default plus custom categories, ids, seats taken). This clearly distinguishes it from sibling list tools such as bookeo_list_products or bookeo_list_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?

'Needed for peopleNumbers' gives a concrete reason to call this tool (resolving category ids used when creating bookings), which is more than most list tools offer. It stops short of naming alternatives or when-not-to-use conditions, but the use context is clear.

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=true already tells the agent this is a safe read, and the description adds the concrete return shape (types, durations, participant limits, default rates and options), which is genuinely useful since there is no output schema. However, it says nothing about pagination behaviour or rate limits, and with annotations covering safety the bar for extra credit is higher. Solid but not rich.

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 resource and its contents, followed by the API endpoint for traceability. Every clause carries information; nothing is padding.

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 correctly fills the gap by enumerating the salient returned fields, and the input side is fully covered by the schema. It could still say something about pagination strategy or that the returned ids are used by other tools, which keeps it just below complete.

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 all five parameters are documented there, including the type enum values and pagination token semantics, so the description need not explain them. It restates the type values from the enum but adds no new syntax, format, or default guidance.

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+resource ('List the bookable products') and enumerates the domain (tours, classes, courses, appointments) plus the returned fields (ids, type, duration, participant limits, rates, options). It is clearly distinguishable from siblings like bookeo_list_people_categories or bookeo_list_resources by naming its resource. No explicit sibling comparison, so it stops short of a 5.

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?

Usage is only implied by the verb 'List' and the API mapping 'Bookeo: GET /settings/products'; there is no statement of when to prefer this over bookeo_search_matching_slots or bookeo_get_availability_slots, nor any prerequisite (e.g. that ids here feed downstream tools). Adequate but with a clear gap.

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 safety profile is covered. The description adds useful context by saying the result carries ids and by mapping to Bookeo GET /settings/resources, but it says nothing about pagination behavior or result ordering.

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 compact sentences with the resource identity front-loaded and the endpoint mapping trailing. No filler, though it is quite terse.

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?

A simple, zero-required-param read tool whose annotations cover the safety profile and whose schema fully documents pagination. The description adequately explains what is returned; only pagination nuance is left implicit.

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?

All three pagination parameters are fully documented in the schema, so the baseline of 3 applies. The description adds no parameter-level detail beyond what the schema already 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?

States a specific verb (list) and resource (resource types and their resources), and gives concrete examples (guides, instructors, rooms, boats) plus the underlying Bookeo endpoint. It is clearly distinct from siblings like list_products and list_people_categories, though it does not explicitly name those alternatives.

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 no when-to-use guidance, no prerequisites, and does not point to any alternative or related listing tool. For a simple read this is tolerable, but the agent gets no routing help.

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 the description's 'Read-only' largely restates that. However it adds real behavior beyond the annotations: the 31-day maximum search window, the token-only paging rule, that results carry an estimated price, and the underlying Bookeo endpoints.

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 and price estimate, then layers scope, window limit, paging, and endpoints. Every sentence carries information, though the endpoint listing is slightly dense tail matter that could be trimmed.

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 10-parameter search tool with a fully-covered schema and no output schema, the description covers what the tool returns (slots with estimated price), the scope of products supported, the time window limit, and how to paginate. Nothing an agent needs to invoke it 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?

Schema coverage is 100%, so all ten parameters are already documented in the schema, including the -00:00 timezone convention and id-vs-name alternatives. The description only adds the cross-cutting 31-day window constraint, which is a marginal increment over the schema's own text.

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+resource ('Find slots that can take a given party') plus the distinguishing capability of returning an estimated price and supporting all product types including flexibleTime. An agent can distinguish this from bookeo_get_availability_slots by the party-composition filtering and pricing.

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 operational context: works for all product types including flexibleTime, 31-day window cap, and the exact rule for paging (pass only pageNavigationToken + pageNumber). It stops short of explicitly naming when to prefer a sibling such as bookeo_get_availability_slots, so no exclusion guidance.

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 meaningfully beyond the single destructiveHint annotation by disclosing the read-modify-write mechanics: the tool fetches the current booking and PUTs it back with only your changes applied, which matters because Bookeo's PUT requires the full booking object. The raw endpoints (GET then PUT /bookings/{bookingNumber}) are also given. It stops short of covering auth/permission needs or whether the change is reversible.

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 zero filler, front-loaded on the mutation scope. The implementation detail about full-booking PUT is placed last, after the agent already knows what the tool does.

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 12-parameter mutation tool with destructiveHint=true and no output schema, the description covers the essential operational risk (whole-booking PUT) plus the schedule/participant/resource change surface. The main remaining gap is that two parameters (externalRef, promotionCodeInput) have no description anywhere and notification side effects are only lightly touched.

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 already 83%, so the schema carries most parameter meaning. The description usefully groups the reschedule parameters (eventId for fixed/fixedCourse vs startTime/endTime for flexibleTime) and calls out externalRef, but adds nothing for promotionCodeInput or the notify flags beyond what the schema already states.

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 ('Change an existing booking') and enumerates exactly what can be changed — reschedule via eventId or startTime/endTime, participant counts, options, resources, external reference. It implicitly separates itself from bookeo_create_booking/bookeo_cancel_booking by scoping to 'existing' bookings, but never names those siblings explicitly.

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?

Usage is implied rather than stated: you reach for this tool when a booking already exists and must be modified. There is no explicit when-not guidance, no note about when to prefer cancel+recreate over update, and no mention of prerequisites such as needing the bookingNumber from bookeo_get_booking or bookeo_list_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?

With only destructiveHint=true and a title in annotations, the description adds real value by disclosing the read-modify-write behavior: it fetches the current record and resubmits it with only the caller's changes, which tells the agent that omitted fields are preserved. It stops short of noting auth requirements, concurrency risk, or what is returned.

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 short sentences, front-loaded with the action, then the behavior that matters most, then the underlying API call. No filler or 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 mutation tool with 11 parameters, nested objects, no output schema, and thin schema coverage, the description covers the write mechanics adequately but omits everything about how nested/array fields merge and whether the updated customer is returned. It is enough to call the tool, not enough to call it confidently.

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 only 27% across 11 parameters, so the schema does not carry the burden. The description offers no field-level guidance, such as how nested streetAddress or phoneNumbers arrays are treated under the full-customer PUT, leaving the highest-risk semantics undocumented.

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?

It states a specific verb+resource ('Update a customer') and scopes the intent to contact details, which naturally separates it from bookeo_create_customer and bookeo_get_customer. It never names a sibling explicitly, so differentiation relies on the verb alone.

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?

Usage is implied by the verb, but there is no statement of when to use this versus booking-level tools or create_customer, and no prerequisites (valid id, existing customer) are mentioned. The GET-then-PUT note explains mechanics rather than routing.

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