Dubai Table

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

The annotations already declare readOnlyHint, idempotentHint, destructiveHint false, and openWorldHint false, so safety behavior is covered. The description adds the status values and that the guest's phone is required, but it does not explain mismatch/not-found behavior or privacy/auth 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?

It is a single efficient sentence front-loaded with the resource and lookup keys, followed by the possible status values. The phrasing is slightly compact but contains no wasted text.

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

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

This is a low-complexity read lookup, an output schema exists, and annotations already cover safety behavior. The description covers purpose, required identifiers, reference format, and result states, though it omits what happens when the reference and phone do not match.

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 0%, so the description must carry parameter meaning. It names both required parameters and gives the reference format RZ-XXXXX, but phone format/normalization and error semantics remain unspecified.

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 read operation: retrieve a booking request status using a reference and guest phone number, and it enumerates the possible statuses. It is clear but does not explicitly distinguish itself from siblings such as cancel_booking or request_table, so it is not 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: use this to check the status of an existing booking request. However, it gives no explicit when-to-use, when-not-to-use, or named alternative such as cancel_booking for cancellations.

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 destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds genuinely new context — no booking fee and WhatsApp confirmation by the relationship manager — which tells the agent about a follow-up channel, but it never states that the cancellation is final or what happens on failure/invalid reference.

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, action front-loaded, which is good. But 'There is no booking fee' is low-value for an agent's decision-making and the WhatsApp sentence mixes in operational detail without stating the outcome the 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?

An output schema exists, so return values needn't be explained. Still, for a destructive, irreversible-feeling action with two undocumented required parameters, the description omits failure modes, whether cancellation can be undone, and how it relates to the checkout cancellation sibling.

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 0%, so the description carries the full burden. 'By reference and phone' merely restates the two parameter names without giving format, provenance (where the reference comes from), or phone number conventions (country code, digits only).

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 ('Cancel') and the identifying inputs ('by reference and phone'), so the action is immediately understandable. However, it calls the target a 'request' rather than a 'booking', and never distinguishes this from the sibling 'cancel_checkout', which an agent could easily confuse it with.

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

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

No guidance on when to use this versus alternatives — most notably 'cancel_checkout', whose name strongly overlaps. There are no stated preconditions (e.g., must the booking exist, must it be pre-confirmation) and no exclusion cases.

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 destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is covered. The description adds genuinely new context beyond that: cancelling also tears down the associated unpaid table request, which is exactly the kind of cascade-destruction detail an agent needs.

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 with zero filler. It is efficient, though so terse that it omits information the tool clearly needs rather than being an example of maximal clarity.

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?

An output schema exists so return values needn't be explained, but for a destructive, non-idempotent-looking mutation with an undocumented nested parameter, the definition omits prerequisites, permissions, and parameter meaning entirely. Sibling differentiation is also 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 0% across 2 parameters, including a nested `meta` object, so the description carries the burden and provides nothing — no explanation of what `id` identifies or what belongs in `meta`. The schema alone leaves the agent guessing.

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 ("Cancel a UCP checkout session") and even names a secondary effect, so an agent can distinguish it from cancel_booking or complete_checkout by resource. It stops short of explicitly contrasting with those siblings, so it isn't 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?

No when-to-use or when-not-to-use guidance, and no alternatives named despite a crowded sibling set (cancel_booking, complete_checkout, update_checkout). Usage is only implied by the tool name.

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 confirm read-only, idempotent and non-destructive, so safety is covered. The description adds valuable context about the data source (live floor plan minus requested/confirmed) and return fields (zone, seats, minimum spend in AED). It doesn't discuss rate limits or errors, but this exceeds the lower bar set by annotations.

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

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

Three sentences, front-loaded with the core purpose and no waste. Each sentence adds distinct value: scope, filtering, and returned fields.

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?

Given the output schema exists, the description needn't explain return values, yet it helpfully summarizes them. Missing explicit guidance on when to use this vs. alternatives like show_tables, but overall complete for a 5-param 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 coverage is 100% and all parameters are fully described in the schema. The description adds no extra syntax or format details, so 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?

States a specific verb+resource ('Tables still free at a venue on a date') and clarifies the source ('live floor plan minus tables already requested or confirmed'), which distinguishes it from siblings like show_tables and request_table.

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?

Implies use for pre-booking availability search, but does not explicitly compare to alternatives like show_tables or request_table. Clear context is provided but no exclusions.

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

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

Annotations declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and the description adds useful context: no booking fee, no payment step, relationship manager confirms on WhatsApp. However, it omits the state consequences (what happens to the checkout session after completion, whether it becomes immutable, what confirmation response looks like) and doesn't reconcile the payment object in the schema with the claim of 'no payment'. Useful but incomplete.

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 efficient sentences, front-loaded with the action and followed by the key behavioral fact (no fee/no payment). No filler, though the WhatsApp detail is helpful rather than wasteful.

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?

An output schema exists, so return-value explanation isn't required. But for a non-idempotent mutation with nested, undocumented parameters, the description should cover preconditions and post-completion state; those gaps keep it at 'adequate but 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 0% for 3 parameters, including nested 'meta' (idempotency-key) and 'checkout' (buyer, payment). The description adds no parameter meaning at all — it doesn't explain the required 'id' or the role of the checkout/payment objects, and its 'no payment' statement sits uneasily with a 'payment' parameter. Below the low-coverage 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?

The description states a specific verb and resource ('Complete a UCP checkout: places the table request(s) with Dubai Table'), clearly distinguishing it from siblings like create_checkout or update_checkout. It adds real-world semantics (tables are placed with the venue) beyond the name. It lacks an explicit contrast to get_checkout/cancel_checkout, but the purpose is unmistakable.

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

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

Usage is implied by the verb 'complete' and the surrounding lifecycle (create_checkout, update_checkout, complete_checkout), but the description never explicitly says when to call this versus those siblings or what prerequisites exist (e.g., an open checkout from create_checkout). An agent must infer the workflow.

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=false, destructiveHint=false, idempotentHint=false and openWorldHint=false, so the safety profile is covered without description help. The description adds the returnable status lifecycle (incomplete | ready_for_complete | requires_escalation | completed | canceled), which is useful context. However, it never mentions the idempotency-key available under meta even though idempotentHint=false makes retry semantics a real concern.

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 what the tool does, then the identifier grammar, then the return shape — each sentence carries distinct information. The status enumeration is somewhat redundant against the existing output schema, but the overall density and ordering are efficient.

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

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

For a non-idempotent mutation tool with deep nested objects and 0% schema description coverage, the description covers the critical line_items identifier grammar but leaves meta, buyer, and context unexplained. Since an output schema exists, not detailing return values beyond the status list is acceptable, but the missing input-side detail keeps this at a minimum-viable level.

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 0%, so the description is the only source of parameter meaning, and it does decode the most important one: line_items[].item.id using the rz:<venue>:<table_id|zone:<Zone>|any>:<YYYY-MM-DD>:<party> grammar. It says nothing about meta.idempotency-key, meta.ucp-agent.profile, buyer fields, context, or line_items[].quantity, leaving several parameters undocumented in both places.

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

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

The description opens with a specific verb and resource: "Creates a checkout session for one or more table requests," which separates it cleanly from get_checkout, update_checkout, complete_checkout, and cancel_checkout by action. It does not explicitly name those siblings or state the workflow position, so it falls short of the top band.

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 call this versus complete_checkout, update_checkout, or request_table, and no stated prerequisites or lifecycle conditions. The only implicit usage signal is that the session must exist before the other checkout tools can act on it, which the agent must infer.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds the useful fact that outreach happens via WhatsApp or email, but the second sentence about the concierge is promotional rather than behavioral, and nothing is said about response expectations.

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 primary sentence is front-loaded and efficient, but the trailing sentence about the Dubai Table concierge does not help an agent decide whether or how to call this tool, and 'these venues' is vague without prior context.

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, an output schema to cover return values, and complete annotations, the description supplies what is needed: the escalation scenarios and the contact channels. Only the dangling venue reference keeps it from being fully self-contained.

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 the baseline is 4 and there is nothing parameter-related for the description to compensate for.

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 action (contacting a relationship manager) and the concrete channels (WhatsApp or email), which clearly separates it from the booking-oriented siblings like request_table or show_tables. It stops short of explicitly naming a sibling alternative, but the purpose 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?

Gives a clear use condition: large groups, special arrangements, or anything outside the listed venues. It does not state when *not* to use it or route the agent to a named alternative, and the phrase 'these venues' is a dangling reference with no antecedent in the description.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=false, covering the safety profile. The description adds no behavioral context beyond that, such as error handling, not-found behavior, 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?

A single clear sentence that is front-loaded with the verb and resource. There is no wasted text or unnecessary preamble.

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?

Output schema exists, so return values need not be explained, and annotations cover safety. However, with 0% schema description coverage, the unexplained optional meta parameter and lack of usage alternatives leave gaps for an agent.

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 0%. The description mentions 'by id' but provides no semantic detail for the required id or the optional meta object. It does not compensate for the schema's lack of parameter documentation.

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), resource (UCP checkout session), and lookup key (by id). The read-only intent distinguishes it from write-oriented siblings like create_checkout or update_checkout, but it does not explicitly name alternatives or scope differences.

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

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

No when-to-use guidance, no conditions for selecting this over cancel_checkout or complete_checkout, and no prerequisites or exclusions. The description only states the basic operation.

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 readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds the useful completeness claim ('Every room ... books') implying a full catalog rather than a filtered subset, plus the 'no booking fee' attribute. However, it mostly enumerates response fields that the output schema already exposes, so the net behavioral gain beyond structured data is modest.

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

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

A single dense sentence covering all salient attributes with no filler. It is front-loaded with scope ('Every room ... across Dubai') and spends the rest on the attribute list, though the long comma-separated tail is a little list-like rather than prose.

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

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

With an output schema present, the description need not explain return values, and annotations cover safety; the description supplies scope and completeness framing, which is the key remaining need for a no-parameter catalog tool. What it lacks is a pointer to the next step in the flow (show_tables / check_availability), which would make it fully self-sufficient.

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

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

There are zero parameters and the schema is closed (additionalProperties: false), so there is nothing for the description to disambiguate. Baseline 4 applies; the description correctly does not invent parameter talk.

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 sentence enumerates exactly what a caller gets back — rooms/venues with kind, area, Dubai Table nights, table-selection capability, zones, fee, and links — which makes the resource unambiguous. It never states an explicit verb like 'list' or 'returns', but the 'Every room ... across Dubai' framing makes the enumeration purpose unmistakable and clearly distinct from siblings such as show_tables or check_availability.

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: it reads as the discovery entry point for venues, but nothing says when to call this versus show_tables, check_availability, or request_table. No exclusions or prerequisites (e.g., 'call this before request_table') are given.

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

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

Goes well beyond the annotations by disclosing that there is no booking fee or payment link, that a relationship manager confirms with the venue over WhatsApp (a human-in-the-loop step), and that a booking reference is returned. It does not state what happens on failure or that repeated calls create duplicate requests, which is the main remaining behavioral 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?

Four tight sentences, front-loaded with what the tool does and what it returns, then prerequisites, then the location-selection branching. No filler and nothing redundant with the schema.

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

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

For a 14-parameter mutation tool this covers the essentials: outcome, no-fee/no-payment behavior, human confirmation path, and required guest identity fields. With an output schema present, return-value detail is rightly omitted; a note on duplicate-request behavior would make it complete.

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

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

Schema coverage is 71%, and the description fills a meaningful gap by explaining the table_id / zone / neither interaction — that omitting both means the relationship manager chooses the party's table. It also reinforces the country-code requirement on phone. It does not cover whatsappConsent or source, so it is not exhaustive.

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 ('Place a real table request with Dubai Table') and immediately clarifies the outcome: a recorded request plus a booking reference. This is clearly distinguishable from read-only siblings like check_availability and show_tables.

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 closing sentence gives real branching guidance ('Accepts an exact table_id, a zone, or neither'), and the phone/name requirement is stated. But it never says when to prefer this over check_availability or show_tables, nor that booking_status should be used to follow up — the agent must infer the workflow position.

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 the full safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower, and the description adds genuinely new context: this renders a visual picker, embeds a request-and-pay form, and is host-dependent. The only wrinkle is that 'pay the platform service fee' sits inside a readOnly tool, which could momentarily mislead, though the mutation is actually delegated to sibling tools like request_table/create_checkout.

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 primary action front-loaded and zero filler; the host qualifier and the data-source comparison each earn their place. It stops just short of a 5 because the payment clause adds a slight ambiguity without clarifying the actual flow.

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?

An output schema exists, so return values need not be described, and the description adequately conveys that this is a visual rendering of availability data plus a request/pay form. It is nearly complete for a UI-render tool, with only minor gaps around host-capability fallback and how the embedded form maps to sibling tools.

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

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

Schema description coverage is only 40% (5 params, 2 required), so the description is expected to compensate but largely does not. It references 'venue' and 'night' (the date), yet adds no format, default, or meaning for zone, party, or max_min_spend, and provides no syntax detail beyond the schema's own 'YYYY-MM-DD' and venue-id notes.

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 names a specific verb and resource ('Render the interactive table picker') and pins the scope to 'a venue and night.' It also distinguishes itself from the availability list by noting it shows 'Same table data as the availability list,' implicitly separating it from check_availability, though it never names that 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 parenthetical '(ChatGPT / MCP Apps hosts)' gives a real host-capability constraint for when this tool is usable. However, it never states when to prefer this over check_availability (the list form of the same data) or what happens if the host lacks interactive UI support, leaving the main routing decision 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 readOnly=false, idempotent=false, destructive=false, openWorld=false, so the safety profile is covered. The word 'Replace' usefully signals overwrite semantics rather than a merge, but nothing is said about whether omitted fields are cleared, whether the session must be in a particular state, or what auth is needed.

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 with no filler and the mutating field names early. However, at this length it is arguably under-specified rather than truly concise for a tool with a nested, undocumented schema.

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

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

An output schema exists, so return values need not be explained, but with 0% parameter coverage, nested objects, and no usage or state guidance, an agent lacks what it needs to call this correctly. 'UCP' is never expanded or contextualized.

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 0% and three parameters (id, meta, nested checkout) are entirely undocumented. The description names line_items and buyer, which appear to be fields nested inside the checkout object, but it says nothing about 'id' or the mysterious 'meta' object, so it only partially compensates for the coverage gap.

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 ('Replace') and resource ('line_items and/or buyer on a UCP checkout session'), so an agent knows exactly what is mutated. It is distinguishable from create_checkout/complete_checkout/cancel_checkout by the word 'Replace', but it never names or contrasts those siblings explicitly.

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

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

No when-to-use guidance, no prerequisites, and no routing to alternatives such as get_checkout or complete_checkout. The agent must infer from the name alone when this step belongs in the checkout flow.

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, idempotentHint, and destructiveHint=false, so safety is covered. The description adds genuinely useful behavior: the date defaults to today in Dubai timezone and the range is capped at 14 days. It does not describe result ordering or how the two night categories are combined.

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 with no filler; the defaults and cap are packed into the parenthetical. The em-dash-heavy structure is slightly dense but 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?

An output schema exists, so return values need not be explained. For a simple, zero-required-parameter read tool, the description covers scope, timezone, defaults, and the cap — enough to invoke correctly. Only the meaning of 'signature nights' vs 'venue nights' is left undefined.

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 only 50% — 'days' has no schema description — and the description compensates by stating the default (7) and maximum (14) plus the minimum-implied range. The date parameter's default and Dubai timezone are also confirmed in prose, so both parameters are semantically complete.

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 the specific resource ('the programme night by night') and its scope ('Dubai Table signature nights and venue nights'), which distinguishes it from sibling venue tools like list_venues. It is clear what an agent gets back conceptually, though it never states the return entity type (events vs. venues) 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?

No when-to-use or when-not-to-use guidance, and none of the relevant siblings (list_venues, show_tables, request_table) are referenced. The agent must infer that this is the browsing/discovery tool from the name alone.

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