g-guest

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

With no annotations provided, the description carries full behavioral burden and exceeds it. It discloses irreversibility, immediate effect, venue notification, idempotent retry behavior, and the error condition for past bookings. Nothing important about the tool's side effects is hidden.

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 covers confirmation, irreversibility, retry safety, failure condition, and alternative workflow in a compact sequence. Every sentence carries meaningful operational information, and none are 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 two-parameter action with no output schema and no annotations, the description is remarkably complete. It covers preconditions, side effects, error behavior, idempotency, and the migration path to a new booking. An agent has everything needed to invoke the tool correctly and manage user expectations.

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 both booking_id and manage_token. The description adds context that the pair matches check_booking's identification method, but it does not add substantial new meaning about the parameters themselves. 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 begins with a specific verb and resource: 'Cancel an upcoming booking and release its slot to other guests.' It clearly distinguishes this from siblings like create_booking and check_booking by focusing solely on cancellation and slot release. The purpose is unambiguous and actionable.

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 explicit usage context: confirm with the guest before calling, cancellation is immediate and irreversible, bookings with passed start times cannot be cancelled, and retries are safe. It also names the alternative workflow for moving a booking: cancel and create a new one. This gives the agent clear decision 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, the description carries the behavioral disclosure burden. It conveys a read-only list operation and the filtering behavior around 'available is true', which is useful. However, it does not mention response shape, edge cases, pagination, or explicitly state that it does not create a booking.

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 concise sentences, front-loaded with the core action and followed by a practical instruction. Every sentence earns its place and there is no redundant 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?

Adequate for a simple availability-listing tool, but with no output schema and no annotations, the description leaves out details about the returned slot structure and behavior when no slots are available. It gives enough to invoke correctly, but not complete clarity on the result.

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 33%, so the description must compensate. It maps slug to 'a business', and mentions date and party size in context, providing some added meaning. However, it does not fully describe slug's source/format or party_size semantics beyond the schema's minimum.

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 ('bookable time slots'), scoped by date and party size. The added instruction to only offer slots where available is true differentiates it clearly from sibling tools like create_booking and search.

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 clearly implies when to use this tool: when checking what times can be booked for a business on a given date and party size. It does not explicitly name alternatives or exclusion conditions, but the context is clear and 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 present, the description fully carries the behavioral burden. It discloses what fields are returned, the possible status values, that personal guest data is never returned, and that invalid or missing tokens are refused without revealing whether the booking exists. This is excellent transparency for a read operation.

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

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

The description is tightly written, with purpose stated first and every sentence contributing either usage, return, or privacy/security behavior. There is no redundant or filler content.

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

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

For a low-complexity tool with fully described parameters and no output schema, the description is exceptionally complete: it tells the agent what the call does, how to identify inputs, what the response contains, what it deliberately omits, and how authentication failures behave.

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

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

Schema coverage is 100% for both parameters, so the baseline is 3. The description adds extra value by explaining that both values appear in the guest's confirmation email as a manage link and giving the exact URL pattern, helping an agent extract parameters correctly from a real-world artifact.

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') and resource ('one existing booking'), making its purpose immediately clear. It also distinguishes itself from siblings like check_availability and create_booking by emphasizing existing bookings and the manage token requirement.

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 clearly states when to use the tool: when the guest needs to confirm an existing booking, and how to identify it using booking_id and manage_token from create_booking or the confirmation email link. It does not explicitly mention alternatives or exclusion cases, but the context is strong enough for correct selection among 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?

With no annotations provided, the description carries the full burden. It discloses the creation behavior, the pending_confirmation result state and the confirmation_url field, and warns against inventing guest details. It doesn't mention idempotency/retry behavior, but the idempotency_key parameter description covers that. Some notes on side effects or duplicate prevention could strengthen it, but the description is already unusually transparent for a creation tool.

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, each earning its place: what the tool does, the critical usage protocol, and the expected result handling. Front-loaded with the purpose and immediately actionable instructions. No 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?

For a 9-parameter creation tool with no annotations and no output schema, the description gives the essential protocol: source of start, real guest data policy, and post-creation behavior. It doesn't enumerate every parameter (e.g., slug, party_size, notes, source), but the schema and parameter descriptions cover some of those. The pending_confirmation/confirmation_url guidance is especially valuable in the absence of an output schema. Missing: no explicit statement about idempotency/duplicate retries, though the parameter description covers it.

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 33%, with only start, source, and idempotency_key getting descriptions in the schema. The tool description compensates by explaining that start must be copied from check_availability, that guest name/email/phone must be real (collected from the person), and that pending_confirmation maps to confirmation_url. It doesn't explain party_size or notes semantics, but the description's coaching on guest details adds real meaning 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?

The description opens with 'Create a real reservation,' a specific action+resource. It also distinguishes itself from siblings by referencing check_availability, making clear this is the booking counterpart to the availability-checking tool. No ambiguity about its 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 description gives strong usage guidance: use a start value from check_availability, never invent guest details, ask for real name/email/phone first, and handle pending_confirmation results by showing confirmation_url. It doesn't explicitly say 'do not use this tool for checking availability,' but the reference to check_availability and the 'real reservation' framing make the boundary clear. Loses one point for not explicitly naming when to use a sibling instead.

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 full burden, and it conveys that this is a read operation that returns details like services, hours, timezone, and booking information. It does not address errors, permissions, or edge cases, but 'Fetch' and the listed output make the general behavior 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?

One concise sentence, no wasted words, and the main action plus output categories are front-loaded. The description is easy to scan and understand.

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 tool with one required parameter and no output schema, the description covers the core need: what id to supply and what details will be returned. It could mention error behavior or explicitly confirm no side effects, but it is largely complete for this simple 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 0%, so the description must compensate. It does by clarifying that the id parameter is a 'business id returned by search', telling an agent where the value comes from. It omits format or validation details, but for a single simple parameter this is adequate.

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 full details') and a specific resource ('one business id returned by search'), and lists concrete content categories: services, hours, timezone, and how to book. It does not explicitly distinguish itself from the sibling get_business, which keeps it from a 5.

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

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

The description clearly frames usage as the follow-up to a search, using an id returned by search. It provides practical context but does not mention alternatives or when not to use 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?

With no annotations, the description carries the behavioral burden itself. It communicates that this is a lookup operation and discloses the key returned business attributes. It does not mention error behavior, but for a simple slug-based lookup the provided context is adequate.

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

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

The description is two short sentences, front-loads the tool's core purpose and return fields, and ends with a practical usage directive. Every sentence contributes value without 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?

This is a simple one-parameter lookup tool with no output schema. The description provides the resource, the returned fields, and a clear usage condition, which is sufficient for an agent to select and invoke the tool 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 description coverage is 100%, so the schema already documents the slug parameter fully. The description adds light usage context by referencing the slug, but it does not add new parameter format or constraint information beyond what the schema provides.

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

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

The description clearly states the tool looks up a business on G-Guest and lists the returned data: services, opening hours, timezone, and maximum party size. It is specific about the resource and action, though it does not explicitly name or contrast sibling tools to differentiate them.

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

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

The description gives clear usage context: "Call this first if you only know the slug." This tells an agent when to prefer this tool, but it does not mention alternatives or explicit exclusions, so it falls just short of a full 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?

With no annotations provided, the description carries the full behavioral burden and handles it well. It discloses that nothing is published immediately, the call creates a lead reviewed by a person, and setup happens only after contact. It also sets output expectations: 'Returns a receipt with a reference id; 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?

Six sentences, each earning its place: purpose, when to use, async/no-publication behavior, email requirement, exclusions, and return shape. The most important scoping information is front-loaded and there is no fluff.

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 8-parameter tool with no annotations and no output schema, this description is complete: it covers intended use, prerequisites, consent, what happens after the call, and what the caller can expect back. Remaining details are properly left to the already-rich input schema.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning by explaining why contact_email is required ('because the reply comes by email') and confirming phone is optional. It also ties business_type to the real-world use case. This is modest but real additional 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?

The description opens with a specific verb and object: 'Ask G-Guest to list a business that is not on it yet.' It also explicitly says not to call it for a guest who wants to book, distinguishing it from the sibling booking tools without ambiguity.

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

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

'Use it when the person you are helping runs a restaurant, cafe, bar, salon, spa, studio or clinic and wants reservations that assistants can make' gives a concrete when-to-use condition. It also gives a clear when-not-to-use: 'Do not call it for a guest who merely wants to book somewhere,' plus the ownership-consent prerequisite.

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?

No annotations exist, so the description carries the full burden of behavioral disclosure. It states what is searched and that ids are returned, but it omits notable behavioral details such as whether matching is partial or exact, any result limits, pagination, or the shape of the returned ids. It is not contradictory, but it leaves these traits unspecified.

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

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

The description is two sentences with no wasted words. It front-loads the action and resource in the first sentence, and the second sentence adds value by explaining the output's purpose. Every phrase earns its place.

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 tool's low complexity (one parameter, no output schema, no annotations), the description covers the core invocation context: what to search for, how the query is used, and what to do with the returned ids. Gaps such as pagination or exact match semantics remain, but the description is adequate for a simple search tool that feeds other 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 coverage is 0% for the 'query' parameter, but the description adds the crucial semantic detail that the query is a business name or slug. For a single-parameter tool, this is a meaningful addition beyond the raw schema. It stops short of describing matching behavior or formatting, but it sufficiently compensates for the missing 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?

The description uses a specific verb ('Search') and a clear resource ('bookable businesses on G-Guest'), and specifies the lookup mode ('by name or slug'). It also differentiates itself from siblings by noting that it returns ids used by fetch and booking tools, which clarifies its role relative to fetch/get_business.

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 when to use it: when you want to find businesses by name or slug and obtain ids for fetch or booking tools. However, it does not explicitly contrast search with fetch or get_business, nor does it state exclusions such as 'use fetch when you already have an id'. The guidance is inferred rather than explicit.

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