List events, open dates, orders, payments, vouchers and coupons in bookingkit.
The last two health checks of this connector failed. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
Scored across 14 tools
Each tool maps to a distinct resource-action pair: events, event dates, orders, order tickets, order payments, vendors, products, coupons, vouchers, categories, users. Sub-resource lists (order_tickets, order_payments) are clearly scoped to one order and are distinguishable from the parent get_order/list_orders tools. Descriptions explicitly state the entity and endpoint, leaving little room for misselection.
All tools follow the same bookingkit_verb_noun convention with a uniform prefix and only two verbs (get for single-entity lookups, list for collections). Resource names are singular/plural used correctly, and sub-resources are named consistently as order_tickets, order_payments, event_dates.
14 tools is well within the ideal range and each one covers a distinct entity in the bookingkit domain. No redundant or filler tools are present; every list/get has a clear counterpart purpose.
The read surface is broad and coherent (events, dates, orders, tickets, payments, vendors, products, coupons, vouchers, users, categories), but the server is entirely read-only. Core transactional operations such as creating/canceling an order, redeeming a voucher, or updating an event are absent, which limits agents to reporting rather than acting.
Get one event (experience) by id: description, price categories, durations, booking rules. bookingkit API: GET /v3/events/{id}.
| Name | Required | Description | Default |
|---|---|---|---|
| event_id | Yes | The event id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already tells the agent this is a safe read. The description adds value by naming the data returned and the underlying endpoint (GET /v3/events/{id}), which helps the agent anticipate the response shape. It does not cover not-found behavior, permissions, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core action and resource, then the return contents and endpoint. Nothing is wasted or buried.
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 one-parameter read tool with annotations covering safety, the description is nearly complete, and it compensates for the missing output schema by enumerating the returned fields. Minor gaps remain around error/failure cases.
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?
Single required parameter with 100% schema description coverage, so the schema already documents event_id. The description only restates 'by id' and adds no format, source, or lookup guidance beyond the schema — 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 (get) and resource (one event/experience) by id, and enumerates the payload returned (description, price categories, durations, booking rules). The cardinality ('one event by id') implicitly separates it from bookingkit_list_events, though no sibling is named 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 by 'by id' versus the list_* siblings, but the description never says when to prefer this over bookingkit_list_events or bookingkit_list_event_dates, nor what to do when the id is unknown. An agent can infer the case but is given no explicit routing or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one order by id: customer, tickets, price, status, additional fields. bookingkit API: GET /v3/orders/{id}.
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes | The order id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safe-read profile is covered; the description adds genuine value by listing the returned payload fields and the underlying API endpoint (GET /v3/orders/{id}). It does not mention auth requirements or error behavior for an unknown id, keeping it from a 5.
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 clauses with zero filler; the resource and returned fields are front-loaded before the API mapping. Every phrase 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?
A simple single-parameter read with a safety annotation and no output schema; listing the returned fields compensates for the absent output schema. Only minor gaps remain (auth context, behavior on invalid id).
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 there is only one parameter, whose schema already documents 'The order id.' The description adds no format or validation detail beyond that, 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 and resource ('Get one order by id') and enumerates the returned fields (customer, tickets, price, status, additional fields). The emphasis on 'one ... by id' cleanly separates it from the sibling bookingkit_list_orders.
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 'by id' — an agent knows to use it when a single order_id is available — but the description never names the alternative (bookingkit_list_orders) or states when not to use it. Guidance must be inferred rather than read.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one vendor by id. bookingkit API: GET /v3/vendors/{id}.
| Name | Required | Description | Default |
|---|---|---|---|
| vendor_id | Yes | The vendor id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already tells the agent this is a safe read; the description adds only the underlying REST endpoint (GET /v3/vendors/{id}), which is mild context. It does not disclose error behavior (e.g. 404 on unknown id) or the shape of the returned vendor, so it adds limited 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 short sentences, front-loaded with the action and resource, with the endpoint as secondary detail. Nothing is redundant or padded.
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 single-id read with full schema coverage and a readOnly annotation, this is close to sufficient, but with no output schema the description could say a vendor object is returned or what to expect on a missing id. It is adequate but leaves those gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single vendor_id parameter, so the schema already documents it fully. The description's 'by id' restates the same idea without adding format or source guidance, which matches the baseline-3 expectation 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?
States a specific verb and resource ('Get one vendor by id'), and the singular 'one' implicitly distinguishes it from the sibling bookingkit_list_vendors. It does not explicitly name the sibling, but the retrieval-vs-list distinction is clear.
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 'by id' phrasing implies you must already have a vendor id, and 'one' hints that listing is a different tool, but no explicit when-to-use or alternative (e.g. list_vendors for discovery) is stated. Usage is inferable rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List event categories. Use the ids to filter bookingkit_list_events. bookingkit API: GET /v3/categories.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results per page. | |
| fields | No | Comma separated list of properties to return. | |
| offset | No | Number of results to skip (for paging). |
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 REST endpoint, which helps an agent reason about semantics, but says nothing about pagination defaults, result size, or ordering despite offering limit/offset.
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 with zero filler; the core purpose leads and the cross-tool routing and endpoint follow. 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?
No output schema exists, but the description implicitly signals that results carry ids usable elsewhere and that paging params are available. A brief note on what a category record contains would close the last 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 limit, offset and fields are fully documented in the schema itself. The description adds no extra meaning (no default limit, no note on which fields are valid), 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 and resource ("List event categories") and pins it to a concrete backend endpoint (GET /v3/categories). It is unambiguous among the siblings, though it doesn't explicitly contrast itself with bookingkit_list_events or bookingkit_list_products.
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 the ids to filter bookingkit_list_events" gives an explicit downstream use and names the sibling it feeds, which is exactly the routing an agent needs. It stops short of stating when one would skip this call (e.g., if you already have category ids).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List discount coupons. bookingkit API: GET /v3/coupons.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results per page. | |
| accept | No | Comma separated list of ids to return only. | |
| fields | No | Comma separated list of properties to return. | |
| offset | No | Number of results to skip (for paging). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already tells the agent this is a safe read, so the description's only added content is the REST endpoint mapping, which does not affect invocation. It says nothing about pagination defaults, total counts, response shape, or whether coupons and vouchers overlap – behavior an agent actually needs for a paged list call.
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 sentences, resource first, with zero filler. The endpoint sentence is marginally useful for API cross-referencing but is close to padding given the tool already names the resource.
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-required-parameter read-only list with fully documented parameters and no output schema, this is minimally viable. It falls short on the one thing the description alone could supply: how coupons relate to the similarly named voucher listing.
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 each of limit, offset, accept, and fields is documented in the schema itself. The description adds no extra meaning (e.g., default page size or typical use of 'accept'), 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 and resource ('List discount coupons') plus the underlying API endpoint, so the agent knows exactly what it retrieves. It does not distinguish the tool from the sibling bookingkit_list_vouchers, which is a real ambiguity for an agent choosing between coupon and voucher listings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool versus bookingkit_list_vouchers or any other listing sibling, and no exclusions or prerequisites. The agent must infer usage purely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List bookable dates with free capacity. Give event_id for one event, else all events. Use available=true to see only dates with free places. bookingkit API: GET /v3/events/{id}/dates or GET /v3/dates.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results per page. | |
| fields | No | Comma separated list of properties to return. | |
| offset | No | Number of results to skip (for paging). | |
| end_date | No | Dates on or before this time. | |
| event_id | No | Only dates of this event id. | |
| available | No | true = only dates with at least one free place. | |
| start_date | No | Dates on or after this time. | |
| delta_since | No | Only dates changed since this time. | |
| accept_vendors | No | Comma separated vendor ids. |
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 context by disclosing the underlying endpoints (GET /v3/events/{id}/dates vs. GET /v3/dates), but says nothing about pagination limits, result ordering, or what a date record contains.
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 the scoping rule front-loaded and no filler. The trailing API-endpoint sentence is marginally useful context rather than wasted space, though it is the least load-bearing part.
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 9-parameter, all-optional read-only list tool with no output schema, the description covers the decisions that matter (event scope, availability filter) and the schema documents the rest at full coverage. Only paging and delta-sync behavior are unaddressed in prose.
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 reinforces event_id and available semantics but adds nothing for limit/offset/fields/delta_since/accept_vendors beyond what the schema already states, and introduces no format or interaction details.
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?
Names a specific verb and resource ("List bookable dates") plus its two scoping modes (per-event vs. all events), which separates it from bookingkit_list_events. The lead phrase "with free capacity" slightly overstates the default behavior, since filtering by free places actually requires available=true — a small ambiguity but not enough to obscure the purpose.
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 conditional guidance: supply event_id for a single event, omit it for all events, and set available=true to restrict to dates with free places. It does not name an alternative sibling or state exclusions, so it stops short of full when/when-not routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List events (the bookable experiences, tours and activities) with prices, durations and categories. Optionally limit to one vendor. bookingkit API: GET /v3/events or GET /v3/vendors/{vendor_id}/events.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Filter by event type. | |
| limit | No | Number of results per page. | |
| match | No | Search text in event name. | |
| accept | No | Comma separated list of ids to return only. | |
| fields | No | Comma separated list of properties to return. | |
| offset | No | Number of results to skip (for paging). | |
| category | No | Only events in this category id (see bookingkit_list_categories). | |
| vendor_id | No | Only events of this vendor id. | |
| delta_since | No | Only events changed since this time. | |
| available_from | No | Only events with at least one date on or after this time. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already tells the agent this is a safe read, so the description only needs to add context. It does add real value by disclosing the underlying endpoints (GET /v3/events vs GET /v3/vendors/{vendor_id}/events), which reveals a branching behavior, but it says nothing about pagination behavior, result volume, or auth/rate constraints.
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 definition front-loaded and the API mapping last. Nothing is wasted and there is no repetition of schema content.
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-param, fully optional, read-only list tool with no output schema, this covers purpose, returned data shape, and endpoint semantics adequately. It leaves pagination/result-size behavior implicit, which is the main remaining gap for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% across all 10 optional params, so the baseline is 3. The description only reinforces vendor_id scoping and the returned fields; it adds no meaning for the non-obvious filters (delta_since, available_from, accept, fields) 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?
Specific verb + resource ("List events") plus a genuinely useful gloss on the domain term ("the bookable experiences, tours and activities") and the payload contents ("prices, durations and categories"). It is clearly distinct from bookingkit_get_event by the List/Get distinction, though it never names a sibling 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?
The only usage hint is "Optionally limit to one vendor," which is a parameter remark rather than guidance on when to pick this tool. Nothing says when to use this versus bookingkit_list_event_dates, bookingkit_get_event, or bookingkit_list_products, and no prerequisite or exclusion is stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the payments recorded for one order. bookingkit API: GET /v3/orders/{id}/payments.
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes | The order id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description reinforces this by citing a plain GET endpoint. However, it says nothing about pagination, result ordering, or what happens when an order has no payments, which are the behaviors an agent would still need.
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 sentences with the purpose front-loaded and no filler. The API endpoint sentence is somewhat redundant for an agent but is compact and arguably aids developer traceability, so only a minor deduction.
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 one-parameter read tool with no output schema and clear readOnly annotations, the description covers what is needed to invoke it correctly. The remaining gap is the shape of a payment record, which is not documented anywhere given the absence of an output 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 coverage is 100% for the single order_id parameter, so the schema already carries the semantics. The description only implies the id refers to an order ('for one order') and adds no format or sourcing detail beyond that, making the baseline 3 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?
States a specific verb and resource ('List the payments') scoped to a single order, which distinguishes it from sibling list tools like bookingkit_list_orders or bookingkit_list_order_tickets. It does not explicitly name a sibling alternative, so it falls 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: the tool clearly applies when you have one order and need its payments, but there is no explicit when-to-use/when-not guidance and no alternative tool is named. The endpoint reference hints at the underlying resource but adds no selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List orders (bookings) with customer, tickets and status. Filter by order date, event date, status or order code. Optionally limit to one vendor. bookingkit API: GET /v3/orders or GET /v3/vendors/{id}/orders.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results per page. | |
| match | No | Search text in customer name/email. | |
| order | No | Sort: date, name or vendor_id; prefix - for descending (e.g. -date). | |
| fields | No | Comma separated list of properties to return. | |
| offset | No | Number of results to skip (for paging). | |
| status | No | Order status. | |
| end_date | No | Orders placed on or before this time. | |
| vendor_id | No | Only orders of this vendor id. | |
| start_date | No | Orders placed on or after this time. | |
| accept_code | No | Comma separated order codes (booking reference codes). | |
| delta_since | No | Only orders created or changed since this time. | |
| end_event_date | No | Orders with a ticket for a date on or before this time. | |
| start_event_date | No | Orders with a ticket for a date on or after this time. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true, so safety is covered. The description adds that results include customer, tickets, and status and lists primary filter axes, plus API endpoints, but omits pagination behavior, default ordering, and rate/limit details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the purpose, then filtering capabilities, then optional vendor scoping, with no filler. The API endpoint reference is compact and useful for agents familiar with the 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?
For a 13-parameter list operation with no output schema, the description only partially covers returned data and ignores paging, sorting, field selection, and delta_since behavior. The detailed schema compensates substantially, but operational context is still incomplete.
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 13 parameters, including limit, offset, order, fields, match, and delta_since. The description only names a subset of filters (order date, event date, status, order code, vendor) and adds no format or default semantics beyond the schema, making 3 the appropriate 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 and resource ('List orders (bookings)') and names included data (customer, tickets, status). It does not explicitly distinguish itself from sibling tools like bookingkit_get_order or bookingkit_list_order_tickets, but the resource scope is clear enough for selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains that results can be filtered by order date, event date, status, order code, and vendor, implying exploratory listing use. It gives no explicit when-to-use guidance versus bookingkit_get_order or bookingkit_list_order_tickets, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the tickets (one per booked event date and price category) of one order. bookingkit API: GET /v3/orders/{id}/tickets.
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes | The order id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already covers the safety profile, so the description's job is to add context, which it does: it discloses the cardinality semantics of the result set (one ticket per event date × price category) and the underlying endpoint. It omits pagination behavior and what an empty result means, keeping it short of a 5.
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: purpose and return granularity first, endpoint reference second. No filler, nothing buried.
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 read tool with no output schema, the description supplies enough about what the returned collection contains to call it confidently. Minor gaps remain around pagination and result ordering, but nothing essential 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?
Only one parameter and schema description coverage is 100%, so the schema fully documents order_id. The description's phrase 'of one order' confirms the scoping semantics but adds no format or sourcing detail beyond the schema, matching the 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 and resource ('List the tickets ... of one order') and clarifies the unit of return: one ticket per booked event date and price category. That granularity distinguishes it cleanly from siblings such as bookingkit_list_order_payments or bookingkit_get_order.
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 — the agent must infer this is the follow-up call after obtaining an order id via bookingkit_get_order. There is no explicit when-to-use/when-not guidance and no mention of alternatives for retrieving ticket data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List additional products (extras such as merchandise or add-ons) sold with bookings. bookingkit API: GET /v3/products.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results per page. | |
| fields | No | Comma separated list of properties to return. | |
| offset | No | Number of results to skip (for paging). | |
| available | No | true = only available products. | |
| accept_vendors | No | Comma separated vendor ids. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true is consistent with a list operation, so the safety profile is already carried by annotations. The description adds the backing endpoint (GET /v3/products) but says nothing about pagination behavior, default page size, or what a product record contains.
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 sentences, zero filler, with the scope-defining parenthetical 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?
All five optional parameters are fully documented in the schema, there is no output schema to explain, and the read-only nature is annotated. What remains missing is minor: expected result shape and default paging behavior.
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 limit, offset, fields, available, and accept_vendors are all documented in the schema. The description adds no meaning beyond that, which is the baseline 3 case.
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 ('List additional products') and disambiguates 'products' as extras/merchandise/add-ons, which is valuable in an API where 'product' could be confused with events or tickets. It does not explicitly name a sibling to contrast with, so it falls 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?
The parenthetical hints at the domain ('sold with bookings') but there is no explicit when-to-use guidance, no exclusions, and no pointer to alternatives such as bookingkit_list_events or bookingkit_list_vouchers when the agent actually needs tickets or vouchers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the users (staff accounts) of the vendor. bookingkit API: GET /v3/users.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results per page. | |
| fields | No | Comma separated list of properties to return. | |
| offset | No | Number of results to skip (for paging). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already tells the agent this is a safe read, so the description's burden is lighter. It adds that the records are staff accounts scoped to the vendor, but says nothing about pagination defaults, total counts, or what a user record contains.
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 sentences, front-loaded with what the tool does; the API endpoint tag is minor extra but plausibly useful for agents cross-referencing the bookingkit API. No wasted hedging.
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 read-only listing tool with full schema documentation and a safety annotation; the description covers scope and endpoint. The only gap is that without an output schema it never characterizes the returned user objects, which is a small omission for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (limit, offset, fields all documented in-schema), so the baseline of 3 applies. The description adds no extra meaning about filtering or field selection 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 and resource ('List the users (staff accounts) of the vendor') and even maps it to the underlying API call GET /v3/users, so an agent knows exactly what is returned at a high level. It does not explicitly contrast with siblings, though 'users' is a resource none of the sibling tools cover.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage only: the parenthetical '(staff accounts)' hints at when it is appropriate, but there is no explicit when-to-use, prerequisite, or alternative named. Since no sibling lists users, omission of alternatives is tolerable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the vendors (bookingkit customers: tour, activity and attraction providers) the API client can access. A vendor client sees only its own vendor. bookingkit API: GET /v3/vendors.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results per page. | |
| match | No | Search text in vendor name/email. | |
| accept | No | Comma separated list of ids to return only. | |
| fields | No | Comma separated list of properties to return. | |
| offset | No | Number of results to skip (for paging). |
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 real value by disclosing that results are permission-filtered (vendor clients see only their own vendor), which an agent cannot infer from the schema. It stops short of describing ordering, default page size, or result shape, but the access-scoping disclosure is a meaningful behavioral detail.
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 sentences plus an endpoint reference, front-loaded with the action and resource. Nothing is redundant and the parenthetical definition earns its place by clarifying an ambiguous domain term.
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 parameterless-required, read-only list tool with full schema coverage and annotation-declared safety, the description covers purpose, scope, and access semantics. Minor omissions such as pagination defaults or result ordering are tolerable given the schema already documents all five parameters.
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%, with limit, match, accept, fields, and offset all documented inline, so the baseline is 3. The description adds no additional meaning about filtering, paging interaction, or whether 'accept' behaves as an ID allowlist applied post-scoping, leaving all parameter semantics to 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?
Specific verb 'List' plus resource 'vendors', with an inline definition of what a vendor is (bookingkit customers: tour/activity/attraction providers) and the exact API endpoint. The visibility rule ('A vendor client sees only its own vendor') further distinguishes it from bookingkit_get_vendor, which retrieves a single vendor.
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 makes clear this is the collection-listing operation and notes that results are scoped by client type, which implicitly tells an agent when it is appropriate. However, it never explicitly routes the agent: it does not say to use bookingkit_get_vendor when a specific vendor ID is known instead of listing, nor does it mention pagination expectations for large result sets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List gift vouchers with code, value, status and redemption data. bookingkit API: GET /v3/vouchers.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results per page. | |
| accept | No | Comma separated list of ids to return only. | |
| fields | No | Comma separated list of properties to return. | |
| offset | No | Number of results to skip (for paging). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already tells the agent this is a safe read. The description adds the underlying endpoint and the shape of the returned records, but says nothing about pagination defaults, total counts, or whether all vouchers are returned when limit/offset are omitted.
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: the payload description is front-loaded and the endpoint reference trails as a short supplementary note. Nothing is padded or repeated from the title.
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 list tool with full schema coverage and no output schema, the description covers the resource and the returned fields adequately. Only the pagination/total-count behavior is left implicit, which the schema mostly handles.
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 limit, offset, accept and fields are already documented in the schema. The description adds no extra meaning about filtering or field selection, 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 and resource ('List gift vouchers') and enumerates the returned fields (code, value, status, redemption data), which separates it from bookingkit_list_coupons and the order-related siblings. It stops short of explicitly naming the sibling it differs from, but the resource is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this versus bookingkit_list_coupons or a get-by-id call, and no prerequisites or exclusions are stated. The only context is the raw endpoint, which describes transport rather than when to choose the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
bookingkit_get_eventbookingkit_get_orderbookingkit_get_vendorbookingkit_list_categoriesbookingkit_list_couponsbookingkit_list_event_datesbookingkit_list_eventsbookingkit_list_order_paymentsbookingkit_list_order_ticketsbookingkit_list_ordersbookingkit_list_productsbookingkit_list_usersbookingkit_list_vendorsbookingkit_list_vouchersRead activities, bookings, guests and open departures in TrekkSoft.
Check Bookeo availability and manage bookings, holds and customers; read payments.
Read Nookal locations, practitioners, availability, appointments, clients, cases and invoices.
Read Corsizio events, attendees and registrations, including payment status. Read-only.
Add one secure layer between your agents and this server.