checkfront

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

Annotations only supply destructiveHint=true and a title, so the description carries most of the burden. It usefully discloses attribution ('logged under the staff account the API acts on behalf of') and the underlying endpoint, but says nothing about note visibility (internal vs customer-facing), editability, or rate/permission requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences with the core purpose front-loaded and no filler. The trailing API route is mildly redundant for an agent but cheap and useful for API 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?

For a simple 2-parameter write with a fully documented schema and no output schema, the description covers what the tool does, on whose behalf, and where it maps in the API. Only note-visibility semantics are left unspecified, which is 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%: booking_id is documented with a concrete example format (CFPP-290317) and body with its 1-3000 character bounds. The description adds no parameter-level detail beyond that, 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 concrete verb+resource ('Add a note to a booking') and even names the backend route (POST /api/3.0/booking/{booking_id}/note), so the operation is unambiguous. It does not explicitly contrast itself with the sibling checkfront_list_booking_notes, though the verb difference makes them easy to tell apart.

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 name and description (create a note on an existing booking), but there is no explicit when-to-use guidance, no prerequisites for the booking_id, and no mention of the read counterpart checkfront_list_booking_notes or of booking-creation sibling tools.

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 carry destructiveHint=true, so the safety bar is lower, but the description adds genuinely useful non-structured context: it holds inventory while open and commits nothing until create_booking returns a session_id to reuse. It does not spell out what happens to held inventory on abandonment or expiry, which would be the remaining valuable 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?

Front-loaded with the three supported operations and the key safety fact ('NOTHING is booked until create_booking') in the same breath. It is dense and slightly run-on with parentheticals, but every sentence 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?

With no output schema, the description correctly states the return value (session_id to reuse) and the post-call state (inventory held, not booked). For a 4-parameter nested-object mutation tool it covers the essentials; error and expiry behavior are the only notable 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%, so the baseline is 3, but the description adds semantics the schema lacks: where SLIP strings originate (a rated get_item call) and the combination rule that line_id + a single slip replaces an existing line. The alter value semantics are largely redundant with 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 and resource (start/modify a booking session) and enumerates the three operations it supports: add SLIPs, replace a line, alter lines. It also names the terminal sibling checkfront_create_booking, so an agent can tell what this tool does NOT do without opening any schema.

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

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

Gives clear workflow context: SLIPs come from a rated checkfront_get_item / checkfront_list_items call, and nothing is booked until checkfront_create_booking. That routes the agent correctly between session-building and committing. It does not mention end_booking_session or get_booking_session as alternatives, so it stops short of full when/when-not 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?

The description adds useful behavioral context beyond the destructiveHint annotation: it discloses the side effect of adding a note under the acting account and states which booking states are ineligible. It does not clarify permissions, reversibility, or response behavior, but it adds meaningful operational 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?

The description is front-loaded with the core action, then adds side-effect context, eligibility restriction, and implementation endpoint in three compact sentences. Every sentence contributes useful information without 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?

For a simple two-parameter tool with no output schema, the description covers purpose, restrictions, and side effects adequately. It could more fully describe what a successful check-in/out returns, but the core context an agent needs is present.

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 both parameters are already documented in the schema. The description does not add new semantic detail about booking_id or action beyond what the schema provides, making the baseline score of 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?

The description states a specific action and resource: marking a guest as arrived or departed for a booking. It is immediately distinguishable from siblings like update_booking_status or add_booking_note, which do not describe check-in/check-out semantics.

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

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

It gives clear usage context ('mark a guest as arrived or departed') and a when-not condition ('VOID and cancelled bookings cannot be checked in or out'). However, it does not name a sibling alternative or explain when to prefer update_booking_status over this tool.

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 provide destructiveHint=true; the description meaningfully expands on this by disclosing that it creates a real reservation, consumes inventory, may notify the customer, and returns booking ids plus an invoice/payment URL. It stops short of stating permission/auth requirements, which keeps 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?

Front-loaded with the core action and both input paths, then dependencies, side effects, follow-up, and endpoint. Three dense sentences with essentially no filler, though it is packed tightly.

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, and the description compensates by noting the returned booking ids and invoice/payment URL. Combined with the side-effect disclosure and dependency routing, an agent has what it needs to call this correctly; only auth/permission detail is absent.

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, but the description adds real meaning: it says the form fields are the customer fields, names typical required values (customer_name, customer_email), and states that session_id comes from the add-to-session tool. This is value 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 (Commit/create) and resource (booking), and immediately distinguishes the two input modes: from a session_id or directly from SLIPs. An agent can identify exactly what this tool does 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 routes the agent: build a session with checkfront_add_to_booking_session, look up required fields with checkfront_get_booking_form, and change the result later via checkfront_update_booking_status. Names both prerequisites and the follow-up alternative.

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

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

Annotations declare destructiveHint=true, and the description usefully scopes that destruction: it destroys the session and its held inventory, but explicitly states 'no booking is affected.' That scoping is genuine added value beyond the annotation. It does not mention auth requirements or whether the operation is reversible, 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?

Three short clauses plus an endpoint line, all front-loaded with the core action and its effect. No filler; every sentence carries information an agent needs.

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 two-parameter mutation tool with no output schema and full annotation coverage, the description supplies the key consequences (inventory release, no booking impact) and the underlying endpoints. Sufficient to call correctly, with only minor gaps around reversibility/failure 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 coverage is 100% and the enum already documents that 'end' closes and 'clear' empties, so the description largely restates the schema. It does not clarify session_id format or the default behavior beyond the schema, making the 3 baseline 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?

Opens with a specific verb+resource ('Abandon a booking session') and immediately differentiates the two modes ('clear' empties items, 'end' closes it). This cleanly separates it from siblings like get_booking_session and add_to_booking_session, which operate on the same session object without abandoning it.

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?

Signals its context clearly ('Abandon a booking session') and explains the consequence that drives the choice ('Releases the inventory it was holding; no booking is affected'). It does not explicitly name alternative siblings or state when-not-to-use, so it stops short of a 5 despite the clear semantic framing of clear vs end.

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 establishes the safe, non-destructive nature of the call. The description adds useful context that the output is day-by-day available inventory and can span one or many items, but it does not describe return format, date-range limits, pagination, or other operational 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?

The description is front-loaded with the core purpose, then gives the key scoping modes and a practical use case. It is compact and each sentence contributes to selection or invocation without wasted wording.

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 availability calendar with full parameter schema coverage and no output schema, the description is nearly complete: it explains the returned concept and supported scopes. It could be slightly stronger by noting expected response structure or any range limits, but no critical invocation detail 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 the schema already documents all four parameters and supported date formats. The description adds relational meaning by clarifying that item_ids with a single id queries one item's calendar, several ids query them together, and category_id is an alternative scope — useful semantics beyond the schema 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?

The description states a specific verb and resource: retrieving a day-by-day availability calendar over a date range. It distinguishes supported scopes — single item, multiple items, or a whole category — so the agent can identify it apart from sibling tools like list_items or get_item.

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

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

It gives a clear use case: answering 'which days next month still have space?' and explains the scoping options. It does not name when not to use it or point to an alternative tool, so it stops short of full when/when-not 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?

Annotations already declare readOnlyHint=true, and the description adds real value beyond them by enumerating the returned fields and naming the REST endpoint. With no output schema, this return-content disclosure is the only place an agent learns what it gets back. It stops short of error behavior (e.g. an invalid booking code) or field formats.

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, front-loaded with the core action and payload before the endpoint reference. Every clause earns its place; 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?

For a single-record read-only GET with a fully documented required parameter, the definition covers purpose, target, and return fields adequately. The only missing piece is failure behavior for an unknown booking code, a minor gap for a read tool whose annotations carry the safety profile.

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

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

Schema coverage is 100% and the single booking_id parameter is fully documented in the schema, including the CFPP-290317 example. The description adds only the URL template ({booking_id}), which is redundant with the schema. Baseline 3 applies.

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

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

States a specific verb (fetch) and resource (one booking) and enumerates the exact payload it returns — status, dates, customer, form fields, line items, totals — plus the underlying endpoint. An agent can distinguish this from checkfront_list_bookings purely from the text.

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 'one booking' implies the single-record counterpart to checkfront_list_bookings, but the description never states when to use this tool versus that sibling, nor any prerequisite such as needing a prior list/search to obtain the booking code. Usage is implied 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.

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

Annotations cover the safety profile (readOnlyHint=true), so the description only needs to add context. It does: it identifies the underlying API route (GET /api/3.0/booking/form), names the payload shape (booking_form_ui) and describes the returned field attributes. It is silent on auth or rate limits, but for a 0-param read those are minor.

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, zero filler. What is returned is front-loaded, the required sequencing follows, and the API route is tucked at the end where it belongs.

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 carries the burden of describing returns, and it does so concretely (field id, label, type, required). Combined with the read-only annotation and zero-parameter schema, an agent has everything needed to call this correctly.

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

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

Zero parameters, so per the rubric the baseline is 4. The description correctly adds no parameter guidance because there is nothing to parameterize.

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 (Fetch) plus a precisely scoped resource (the customer-details booking form / booking_form_ui) and an enumeration of what is returned: field id, label, type, required. Nothing about this overlaps with siblings like checkfront_get_booking or checkfront_get_item, so the agent can select it without opening any schema.

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

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

Explicitly states the sequencing rule: call this before checkfront_create_booking to learn which `form` fields to send. That names the consuming sibling and the condition that warrants this call. There is no explicit when-not or negative case, which is all that separates it from a 5.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds value beyond annotations by previewing the return payload (line items, dates, sub_total, tax, total, amount due), which matters since no output schema exists.

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 that identifies the resource, its return contents, and the underlying API endpoint with zero waste.

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 enumerates the fields the session returns, which is the main thing an agent needs. It could add a note about empty/invalid session behavior, but it is largely complete 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?

Schema description coverage is 100%; the sole session_id parameter is fully documented in the schema, including its origin from checkfront_add_to_booking_session. The description adds no parameter detail beyond this, 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 ('Read') and resource ('booking session') and immediately disambiguates it as the in-progress cart rather than a finalized booking. An agent can distinguish it from checkfront_get_booking and checkfront_create_booking without opening any schema.

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

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

Usage is implied rather than stated: the session_id reference to checkfront_add_to_booking_session hints at the cart workflow, but there is no explicit 'use this when...' or exclusion vs checkfront_get_booking, checkfront_end_booking_session, or checkfront_list_bookings. Adequate but leaves routing 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 safety is covered. The description adds real value beyond that: it is framed as a low-cost call, explains its role as a credential/host validator, and discloses the underlying endpoint (GET /api/3.0/company), which is useful diagnostic context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences plus the endpoint reference. The returned-field list is front-loaded and every clause earns its place — 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 zero-parameter read with no output schema, the description compensates by enumerating the shape of the returned configuration, so an agent knows what to expect without 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?

The tool takes zero parameters, which is the baseline-4 case. The schema confirms an empty properties object, so there is no parameter meaning for the description to add or omit.

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 (Fetch) and resource (company configuration) and enumerates the concrete fields returned (name, URL, plan, currency, timezone, locale, formats). An agent can distinguish this instantly from sibling read tools like get_booking or list_items.

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 host and credentials work" gives an explicit when-to-use scenario (connectivity/auth smoke test). It does not name a competing tool or state when-not to use it, but the usage context is clear enough to guide selection.

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 goes beyond that by disclosing what the read returns – contact details plus the customer's bookings as codes with created dates – which is genuinely useful behavioral context given no output schema exists.

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 substantive payload description, followed by the API mapping. Every fragment carries information; nothing is 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?

With only one parameter and no output schema, the description usefully compensates by naming the returned fields (contact details, booking codes, created dates). What is missing is error/not-found behavior and any pagination note for the embedded bookings list, which slightly caps this below 5.

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 parameter with 100% schema description coverage, so the schema already documents that customer_id accepts an id or customer code. The description adds no additional parameter meaning (no format rules, no alternate lookup keys beyond what the schema lists), 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 specific verb and resource ('Fetch one customer's contact details and their bookings') with scope precision ('one customer'), which cleanly separates it from the plural sibling checkfront_search_customers and checkfront_list_bookings. The added endpoint reference reinforces exactly what is being retrieved.

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: an agent can infer this is the tool to call when it already has a customer id/code rather than needing to search. However, there is no explicit when-to-use or when-not guidance (e.g., 'use search_customers first if you only have a name or email'), so the routing decision against checkfront_search_customers 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?

With readOnlyHint already declaring a safe read, the description earns credit for disclosing the shape of the rated response (rate.status, rate.available, price breakdown, SLIP used to book). It does not mention auth/permission needs or rate limits, but for a read-only GET tool that is a minor gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the core action, then the rated-mode mechanics, then the raw endpoint reference. Efficient and mostly free of waste, though the endpoint line is somewhat redundant boilerplate.

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 primary use case, the mode trigger, and the notable return fields for a 10-parameter nested tool with no output schema. It leaves the secondary parameters (rules, packages, discount_code, start/end_time) entirely to the schema, but does not create confusion about how to invoke the 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%, so the baseline is 3. The description adds some value by linking start_date/end_date plus param quantities to the combined effect of a rated response (an interaction the per-parameter schema notes don't fully convey), but the individual parameter meanings are already fully documented in 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 and resource ('Fetch one inventory item's details') and scopes it to a single item, which implicitly separates it from the sibling checkfront_list_items. It also names the concrete endpoint (GET /api/3.0/item/{item_id}), removing any ambiguity about what is being retrieved.

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?

Clearly explains the two modes: a plain detail fetch versus a RATED response triggered by passing start_date/end_date and param quantities, and gives a domain-specific rule ('for parent/child grouped items, rate the CHILD item'). It stops short of naming an alternative sibling tool or explicit exclusions, so it lacks the 'when-not' element of a 5.

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

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

Annotations already declare readOnlyHint=true, so the description gets credit for adding real context instead of repeating safety: the default look-back window, the returned field set, the private-flag disclosure, and the 0 = customer convention for author id. It omits pagination or result-count limits, keeping it just 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 tight sentences with no filler; the scoping constraint (default 30 days) and output fields are front-loaded, and the raw endpoint is appended in a compact form.

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 compensates by naming what each returned note contains, and it pins down the default time window. It is nearly complete for a zero-required-parameter list tool, with only pagination/volume behavior 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?

Schema coverage is 100%, so the baseline is 3, but the description adds semantics the schema lacks: the omitted-parameter behavior (defaults to the past 30 days). It still doesn't restate the accepted day/month formats, which the schema already covers.

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 (notes left on bookings) plus scope (across the account) and even enumerates the returned fields. An agent can immediately distinguish it from the sibling checkfront_add_booking_note, which writes rather than reads.

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 default window (past 30 days) is useful implicit usage context, but the description never states when to prefer this over checkfront_get_booking or checkfront_list_bookings, nor whether there is any way to scope it to a single booking. 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?

With only readOnlyHint in the annotations, the description carries the behavioral load and does so well: it discloses pagination behavior (default 100/page, request.pages for page count) and enumerates the exact fields returned in each row (booking code, status, totals, customer name/email, summary, date_desc). This is valuable context beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tightly written sentences: purpose and filters first, return fields second, pagination and API endpoint third. Every sentence adds distinct information with zero waste, and the most important details are front-loaded.

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

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

For a list tool with 11 fully documented parameters, no output schema, and a readOnly annotation, the description supplies the missing return-field and pagination context. An agent has everything needed to call it correctly and interpret the response structure.

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 every parameter precisely. The description groups filters into categories ('by status, customer, dates, item or partner') but adds no syntax, format, or constraint details beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description states a specific verb and resource ('List bookings') and enumerates supported filters, making the tool's core operation immediately clear. However, it does not explicitly distinguish this list endpoint from siblings like checkfront_get_booking or checkfront_search_customers, leaving that differentiation to the tool name 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?

The description lists available filters but provides no guidance on when to use this tool versus alternatives such as checkfront_get_booking for a single booking or checkfront_search_customers. No exclusions, prerequisites, or contextual triggers are offered.

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 establishes that this is a non-mutating read, so the description's job is lighter. It usefully discloses the concrete return fields (ids, names, display order, item counts) and maps the call to GET /api/3.0/category, but says nothing about ordering guarantees, pagination, or account/permission scope.

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?

One front-loaded sentence carrying the purpose and returned fields, with the endpoint reference appended. Nothing is wasted, though the raw 'Checkfront: GET /api/3.0/category' line is mostly redundant API trivia for an agent that does not call the REST path directly.

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

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

For a zero-parameter, read-only list tool with no output schema, the description compensates by naming the shape of the returned objects. Nothing critical is missing, though a note on result volume or ordering would close the remaining 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The listed return fields are extra context rather than parameter clarification.

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 inventory categories') and enumerates the fields returned (ids, names, display order, item counts) with concrete examples (Tours, Rentals, Accommodations). It does not explicitly distinguish itself from the adjacent checkfront_list_items or checkfront_list_events siblings, so an agent must infer the category-vs-item boundary.

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 when-to-use statement, no prerequisite or scoping guidance, and no named alternative. The only implied use — fetching category ids to feed other calls — must be inferred entirely by the reader.

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 genuinely useful behavioral context beyond that: what each event record contains (dates, recurrence, pricing rule, and the items/categories it applies to) and the underlying API call. It omits pagination and auth/scope requirements, which keeps 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?

One dense sentence carrying the verb, scope, event taxonomy and return fields, followed by the endpoint reference. Nothing is redundant and the most decision-relevant content (what the events affect) is front-loaded.

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

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

With no parameters, trivial schema and no output schema, the description carries the burden of explaining return content and does so well. A minor gap is that it does not signal that the listing is unfiltered/unpaginated (no parameters at all), which an agent might otherwise assume.

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 rubric the baseline is 4. There is nothing parameter-wise for the description to compensate for, and it correctly does not invent filtering options that the schema does not expose.

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 ('date-based events that change price or availability'), then enumerates the concrete event types (SE, SP, DC, closures) and the endpoint. An agent immediately knows this returns pricing/availability modifiers rather than bookings or items. It does not explicitly name which sibling it is not, so it falls just 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 implied rather than stated: the description makes clear this is the tool for seasonal rates, specials, discounts and closures, but gives no when-to-use/when-not guidance, no mention of prerequisites, and no routing against alternatives such as checkfront_get_availability_calendar or checkfront_list_items, which are the closest siblings for pricing/availability data.

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 covers the safety profile, so the bar is lower; the description still adds real behavioral context by disclosing that dates change the response shape and that the rated response carries a SLIP token needed for booking. No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four tight sentences, front-loaded with the core action and then the mode difference and the SLIP hand-off. Nothing is repeated from the schema and 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?

With 13 params, one nested object and no output schema, the description compensates well by explaining that the no-date and dated responses differ and what the dated one contains. It leaves minor gaps around filtering params (keyword, category_id, item_id) but those are fully documented 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 the schema already marks each rated parameter with '(rated)' plus formats, so the description earns only the baseline. It does add the pairing intuition (start_date plus end_date / param quantities) but no syntax or constraint detail beyond the schema.

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

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

States a specific verb and resource ('List the enabled inventory items') and enumerates the item types covered (tours, activities, rentals, rooms). It also distinguishes the two modes of the tool — plain catalogue vs RATED response — which no sibling duplicates.

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 says when to omit dates (plain catalogue) vs when to pass start_date/end_date (rated response with availability, pricing, SLIP). It even names the downstream consumer, checkfront_add_to_booking_session. It does not, however, route the agent away from near-neighbours like checkfront_get_item or checkfront_get_availability_calendar.

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 establishes the safety profile, so the description's job is lighter. It adds real value by disclosing the fields returned and the cross-tool linkage to CHECKFRONT_ON_BEHALF, though it says nothing about pagination, account size limits, or permission requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the purpose and scoped fields. The trailing API route reference ('Checkfront: GET /api/3.0/account.') is mildly redundant but harmless and consistent with the API-documentation convention.

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 and no parameters, so the description must carry the return-value burden itself — and it does, listing the fields an agent will receive. The lack of any note on result size or pagination is the only meaningful gap for a simple read-only 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?

Zero parameters, so the baseline is 4 with no schema semantics to explain. The description correctly spends its space on the output shape instead of inventing parameter 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 and resource with scope ('staff (and partner) accounts on the Checkfront account') and enumerates the returned fields (ids, names, emails, login ids, enabled). This clearly distinguishes it from siblings like checkfront_get_company or checkfront_search_customers that also deal with people.

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 concrete reason to call it: 'The account_id is what CHECKFRONT_ON_BEHALF takes', tying this listing to a downstream parameter an agent needs. It does not state when not to use it or name an alternative, so it stops short of full routing 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 declares the safety profile, so the bar is lower, and the description still adds real value: matches are exact-only, non-unique fields like name can return multiple records, and results land in the `customers` object. It does not mention pagination or result caps, which is a minor remaining gap.

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?

One tight sentence carrying the matching rules, multiplicity caveat, and result location, plus the endpoint reference. Nothing is wasted and the key constraint (exact matches) is front-loaded.

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

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

For a read-only search tool with full schema coverage and no output schema, the description covers matching semantics, multiplicity, and where results appear. Missing only the relationship to checkfront_get_customer, which is what an agent would most want to disambiguate.

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 each parameter is already documented with the same 'exact' semantics. The description reinforces exact-match behavior and adds the non-uniqueness caveat, but provides no new syntax, format, or field-combination guidance 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 ('look up customers') plus the fields used for matching (email, full name, phone), so the agent knows exactly what this does. It does not differentiate itself from the closest sibling checkfront_get_customer (single-record fetch by id), leaving that routing decision 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 by the constraint that all matches are exact, which tells the agent this is not a fuzzy search. However, there is no explicit guidance on when to use this versus checkfront_get_customer, nor any statement that at least one search field should be supplied.

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 carries most of the load and does it well: it discloses reversibility ('set it back to the previous status the same way'), the absence of a payment side effect, and the optional customer-notification trigger. It stops short of stating whether a VOID/STOP cancel has other irreversible consequences (refunds, inventory release), which would complete the destructive profile.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action and its outcomes, then reversibility and exclusions, then the API reference. Dense and nearly waste-free; the trailing endpoint string is the only element 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 three-parameter mutation tool with no output schema, it covers the mutation outcome, reversibility, side effects, and the no-payment constraint. The remaining gap is what happens to dependent state (payments, inventory, notifications already sent) on cancellation.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds real semantic grouping by mapping intent phrases to codes (PAID/PART = confirm, HOLD/WAIT = park, VOID/STOP = cancel), which the schema's flat code list does not. It also surfaces the notification side effect tied to the 'notify' parameter.

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 (Set) and resource (a booking's status), then enumerates the concrete outcomes (confirm, hold/waitlist, cancel) with the status codes that produce them. It also explicitly scopes out adjacent behavior ('Does NOT record a payment'), which separates it from the booking-creation and payment-adjacent siblings.

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 situations for use (confirm a pending booking, put it on HOLD/WAIT, cancel it) and an explicit exclusion (does not record a payment), plus the reversibility path. It stops short of naming a sibling alternative, but the intent-to-status mapping is clear enough for selection.

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