g-guest

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

With no annotations present, the description carries the full disclosure burden and does so excellently. It reveals that cancellation is immediate, irreversible (the server cannot undo it), notifies the venue exactly as a manage-link cancellation would, is safe to retry (idempotent — cancelling an already-cancelled booking returns the same result rather than an error), and returns an error for bookings whose start time has passed. This is precisely the behavioral context an agent needs for a destructive operation.

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

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

The description is longer than average, but every sentence earns its place: purpose, identification, guest-confirmation requirement, irreversibility, retry safety, error condition, and rescheduling workflow. Information is front-loaded (purpose first) and densely packed without redundancy. For a destructive tool with no annotations, this length is justified, not bloated.

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 2-parameter tool with no annotations and no output schema, the description is remarkably complete: it covers the action, parameter derivation, failure modes, retry semantics, irreversibility, and the rescheduling path. The only gap is that it never describes the return value or success response format, which is somewhat expected given the absence of an output schema. An agent has everything necessary to invoke it safely.

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%; both booking_id and manage_token are already documented in the schema, including their provenance from create_booking or the guest's manage link. The description adds only the framing that the pair identifies the booking 'like check_booking,' which marginally reinforces that both are required together but adds little beyond the schema. 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 opens with a specific verb and resource: 'Cancel an upcoming booking and release its slot to other guests.' This states not just the action but its consequence, making it immediately distinguishable from siblings like check_booking, create_booking, and check_availability. No ambiguity about what operation is performed.

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 provides explicit when-to-use guidance ('Confirm with the guest before calling'), an explicit when-not condition (bookings whose start time has passed cannot be cancelled), and an explicit alternative for a related scenario ('To move a booking to another time, cancel it and create a new one'). It also signals the retry posture. It slightly misses an explicit statement of when to prefer sibling tools like check_booking first, but the key routing is covered.

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 no annotations, the description must carry behavioral disclosure. It reveals that returned slots may vary in availability and instructs the agent to surface only those with available: true, and 'List' conveys a read-only operation. However, it omits return format, ordering, timezone handling, and error behavior.

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 tool's core purpose. The second sentence adds actionable filtering guidance, though it is slightly customer-facing rather than a pure API behavior note.

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 list operation with no output schema, the description gives a basic but incomplete picture. It fails to explain the slug parameter or describe the slot response fields beyond the available flag, leaving an agent to guess at the output shape.

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 33%, so the description should compensate, but it mostly restates date and party_size without adding meaning. The slug parameter is entirely unexplained, and party_size gets no semantics beyond the schema's minimum of 1.

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 uses a specific verb ('List') with a clear resource ('bookable time slots for a business') and names the two key inputs, date and party size. It doesn't explicitly contrast with siblings like create_booking or search, but the function is unambiguous from the wording.

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

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

The description implies an availability-checking use case but provides no explicit when-to-use guidance, no exclusions, and does not route the agent away from related tools such as search, get_business, or create_booking.

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 no annotations present, the description carries the full behavioral burden. It discloses many important traits: it returns specific fields, never returns guest PII, and refuses wrong or missing tokens without revealing whether a booking exists. This gives the agent strong expectations about privacy and error behavior.

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 compact and each sentence earns its place: purpose, parameter source, return contents, and security behavior. It is front-loaded with the main action and avoids redundant restatement of the tool name or 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 lookup tool with no output schema, the description fully covers behavior, return fields, status values, parameter provenance, and error handling. Nothing essential is missing for an agent to select and invoke it 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?

Schema coverage is 100%, so the schema already documents both parameters thoroughly. The description adds extra value by explaining that both parameters come from create_booking and are embedded in the guest's manage link, including the exact URL shape and how to extract the token from it.

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

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

The description opens with a specific verb and resource: 'Look up one existing booking' and names the concrete purpose. It naturally distinguishes itself from siblings like check_availability and create_booking by focusing on retrieving an existing booking.

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

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

The description gives clear context: use this tool when a guest needs to confirm an existing booking, and identifies the required credentials from create_booking or the confirmation email. It does not explicitly enumerate when not to use it or name alternative tools, but the conditions are unmistakable.

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 no annotations provided, the description carries the full disclosure burden and does so well: it flags that this creates a real reservation, a consequential irreversible side effect, and forbids fabricating guest data. It also reveals response behavior — the pending_confirmation status and confirmation_url field — which an agent needs to act correctly on the result.

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 short sentences, each earning its place: purpose, prerequisite, data-integrity rule, and post-call handling. The core operating constraints ('real reservation', 'never invent guest details') are front-loaded ahead of workflow details, with zero filler.

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

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

For a 10-param mutation tool with no annotations and no output schema, the description covers the full call sequence: obtaining a valid start, collecting honest guest data, creating the booking, and reacting to the pending_confirmation result. The only notable gap is the lack of guidance for other possible result statuses or failure handling, which is a minor omission given the overall clarity.

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 40%, and the description compensates where it matters most: start must come verbatim from check_availability, and name/email/phone must be real details supplied by the person rather than invented. It leaves party_size, slug, and notes semantically uncovered, but the riskiest hallucination-prone fields are addressed.

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 ('Create a real reservation') up front, and the qualifier 'real' signals live side effects. The verb set clearly differentiates it from siblings such as cancel_booking, check_booking, and check_availability without needing to open 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 routes the agent to check_availability as the required source of the start value, establishing a clear precondition and naming the sibling to call first. It also sequences the workflow — ask the guest for real name/email/phone before calling — and specifies how to handle the pending_confirmation response. It stops short of a full when-not-to-use inventory, but the context is unambiguous.

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 no annotations provided, the description carries the full burden of disclosing behavior. It indicates a read-only retrieval operation by saying 'Fetch full details' and lists output content, but it does not mention error behavior, required permissions, or whether the response is complete or paginated. This is adequate for a simple lookup but not richly transparent.

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 a single sentence that front-loads the core action, resource, and key output categories. There is no filler or redundant content, and it remains highly readable despite packing in the input constraint and return scope.

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 one-parameter tool, the description covers the input source (search result) and the output facets (services, hours, timezone, booking). However, it does not address the existence of get_business, which is a likely alternative, nor does it explain when to use one over the other. Without an output schema or more detail, the description is adequate but leaves a notable gap in tool selection.

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

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

The schema only defines 'id' as a string with no description, leaving 0% schema coverage. The description compensates by specifying that the id is a 'business id returned by search', which tells the agent both the semantic meaning of the parameter and its expected provenance. This is useful context beyond the raw schema.

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

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

The description states a specific action ('Fetch full details') and resource ('one business id'), and enumerates the returned information: services, hours, timezone, and booking. It is clear about what the tool does, but it does not differentiate from the sibling get_business, which likely overlaps in purpose.

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

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

The phrase 'returned by search' implies the tool should be used with a business id obtained from the search tool, giving some usage context. However, no explicit exclusions or comparisons are provided against get_business, check_availability, or create_booking, so the agent must infer when this is the right choice.

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 no annotations, the description carries the burden of behavioral disclosure. It clearly indicates this is a lookup operation and lists what data is retrieved, but it does not explicitly state that it has no side effects or that it is read-only. For a simple lookup this is adequate, though not richly transparent.

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 with no wasted words. The main purpose and return scope are front-loaded, and the usage hint is appended concisely.

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

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

For a single-parameter lookup tool with no output schema, the description covers purpose, returned fields, and when to call it. It lacks an explicit fallback instruction for when the slug is not known, but the guidance is otherwise sufficient for correct selection and invocation.

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

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

Schema coverage is 100% and the slug parameter already has a clear description with an example. The tool description adds little beyond the schema, so the baseline 3 applies.

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

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

The description uses a specific verb ('Look up'), names the resource ('a business on G-Guest'), and spells out the key data returned (services, opening hours, timezone, maximum party size). It also differentiates from siblings by positioning itself as the lookup to call when you only know the slug.

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

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

The description gives clear usage context: 'Call this first if you only know the slug' tells the agent when this tool is the entry point. It does not explicitly name alternatives like search for when the slug is unknown, so it falls just 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?

With no annotations provided, the description fully carries the burden, and it does so exceptionally. It discloses that nothing is published immediately, the request becomes a lead, a human reviews and contacts the business, and only then is anything set up. It also explains the async nature, email dependency, and that no timeline is promised.

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 compact yet information-dense, with the purpose front-loaded and every sentence contributing new information. It covers what, when, how, not-when, authorization, and return value without any fluff or repetition.

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?

Despite having no annotations or output schema, the description covers the tool's purpose, usage conditions, async side effects, required contact method, authorization constraint, and return value (receipt with reference id). It also sets expectations about the lack of a timeline, making it effectively complete for a lead-submission 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%, so the baseline is 3. The description adds useful meaning by explaining why contact_email is required ("the reply comes by email") and that contact_phone is optional. This helps an agent understand the intent behind the required and optional parameters beyond raw schema definitions.

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: "Ask G-Guest to list a business that is not on it yet." This clearly distinguishes it from sibling booking and query tools, and the following sentence names the exact business types (restaurant, cafe, bar, salon, spa, studio, clinic) it applies to.

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

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

It explicitly states when to use the tool: when a business owner wants reservations that assistants can make. It also gives strong negative guidance: "Do not call it for a guest who merely wants to book somewhere, and never submit a business without its owner's or manager's say-so." This makes the trigger conditions and exclusions unambiguous.

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 no annotations, the description carries full responsibility. It discloses the core behavior—searching only bookable businesses by name/slug and returning IDs—but does not mention result limits, ordering, exact/partial matching, or failure behavior. It is not misleading but leaves some behavioral unknowns.

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 entire description is one efficient sentence that front-loads the action and resource, then adds the return contract and downstream usage. No filler; every clause contributes.

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

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

For a one-parameter search tool with no output schema, the description covers the input semantics, the scope, and the output in sufficient detail for an agent to call it and connect results to fetch or booking tools. Additional details like pagination or empty-result handling would be helpful but are not critical.

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

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

The schema only defines a 'query' string with no description. The description adds critical meaning: the query should be a business name or slug, and the search is limited to bookable businesses. This compensates for the 0% schema coverage, though format details (case sensitivity, partial matches) are absent.

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?

Description uses a specific verb ('Search'), identifies the resource ('bookable businesses on G-Guest'), and states the query method ('by name or slug'). It also explains the return value ('ids'), which clearly separates it from sibling tools like fetch and get_business that presumably operate on already-known IDs.

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

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

The description explains that the tool returns IDs usable with fetch or booking tools, giving an implicit usage path for when search is the appropriate first step. It does not explicitly state exclusions (e.g., use fetch when you already have an ID), 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.