booking

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

No annotations are provided, so the description must disclose behavioral traits. It states the tool returns products, but does not mention pagination, read-only nature, side effects, permissions, or error conditions. The transparency is minimal.

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, short sentence that is front-loaded with the key information (products of collection). It is efficient and avoids redundancy, though it could include slightly more detail without harming conciseness.

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?

The tool has one parameter and no output schema. The description lacks details about the return structure, error handling, or usage context (e.g., authentication). While simple, it is incomplete for a tool that could benefit from specifying output format.

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. The description adds context by linking the slug to list_collections, which is meaningful beyond the schema's simple 'Slug kolekcie'. However, it does not elaborate on format or constraints.

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 it retrieves products of a collection by slug, referencing list_collections as the source. It uses a specific verb ('Produkty' meaning products) and resource (collection), differentiating it from siblings like get_product or list_collections. However, it does not explicitly contrast with all sibling tools.

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 that the slug comes from list_collections, but provides no explicit when-to-use or when-not-to-use guidance. There is no mention of alternatives or prerequisites beyond the implied reference.

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 behavioral disclosure. It adds the constraint of verified reservations, which is useful, but does not mention authorization needs, rate limits, error behavior for invalid codes, or whether the operation is read-only. The disclosure is minimal but not misleading.

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 conveys the core purpose and a key constraint. Every word serves a purpose, with 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?

Given the tool's simplicity (one parameter, no output schema), the description sufficiently covers its purpose and a key constraint. It could hint at the return format or pagination behavior, but the existing information is adequate for basic understanding.

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% (the only parameter partner_code has a description in the schema: 'Kód partnera (z get_partners)'). The tool description does not add additional parameter-level detail beyond that. Baseline of 3 is appropriate as the schema already provides clear parameter semantics.

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 clearly states the tool returns reviews and ratings of partner services from verified reservations. The verb 'get' is implied by the name, and the resource 'partner_reviews' is explicitly described, distinguishing it from sibling tools like get_partners or get_product.

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 mentions the constraint 'len z overených rezervácií' (only from verified reservations), which implies when the tool is appropriate, but it does not explicitly state when to use or not use this tool, nor does it reference alternatives or prerequisites like obtaining the partner_code from get_partners.

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 provided, so description carries the burden. It discloses that the tool returns partner data (cities, names, links) and explains that reservations can be made via web or chat sequence. It does not mention side effects or auth requirements, but the tool is read-only in nature and the description aligns with that.

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 concisely convey the tool's purpose and the two possible booking flows. No redundant or vague language. Front-loaded with key function.

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, description explains return values (cities, names, links). It also outlines the booking workflow (web vs. chat). However, it omits explanation of the form_type parameter, which could leave the agent unsure when to use different enum values. Overall, mostly complete given tool complexity.

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% with detailed enum descriptions, so baseline is 3. Description does not add any additional meaning about the form_type parameter; the parameter is not mentioned at all. Thus no added 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?

Description clearly states it returns partner cities, names, and direct reservation links for battery replacement. Distinguishes from siblings like get_partner_reviews (reviews) and request_booking (booking action) by specifying the output and completion paths.

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?

Provides context on when to retrieve partners and how to proceed with booking (web link or chat flow). Does not explicitly list alternatives, but the mention of two completion paths offers some guidance. Missing explicit when-not-to-use compared to siblings.

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 provided; description describes a read operation but does not disclose behavioral traits like idempotency, rate limits, or error handling. Adequate for a simple read 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?

Single sentence, front-loaded with purpose, no unnecessary words. Efficient and clear.

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, but description adequately lists returned fields (description, parameters, EAN, offers). For a simple product detail tool, this is 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?

Schema coverage is 100% with a clear description. The description adds value by clarifying the slug originates from search_batteries, which is not explicit in the schema description.

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 clearly states it returns product detail by slug, listing returned fields (popis, parametre, EAN, partner offers with prices). It references the source (search_batteries), distinguishing from sibling tools like get_collection.

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 usage after search_batteries to get detail for a specific slug. Does not explicitly state when not to use or alternatives, but sibling tools fill the gap.

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 provided; description lacks details on authentication requirements, rate limits, or whether the list includes all collections. Adequate for a basic read operation but not fully 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?

Single sentence in Slovak, front-loaded with purpose, no redundant 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?

Simple tool with no input parameters; description explains output (list with description and product count). Lacks mention of pagination or limit, but sufficient for basic use.

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 has zero parameters with 100% coverage, so baseline is 4. No parameter documentation needed.

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 lists product collections with description and product count, distinguishing it from siblings like get_collection which likely retrieves a single collection.

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 tool versus alternatives such as get_collection. The description merely states functionality without usage context.

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 burden. It discloses the reservation is pending, requires consent, and involves an email-based confirmation and partner approval. It doesn't mention idempotency or side effects, but for a creation tool, the pending state and required follow-up actions are adequately described.

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 dense and front-loaded, conveying purpose, prerequisites, and flow in a few sentences without redundancy. Every sentence adds value.

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 complexity (10 params, no output schema, no annotations), the description covers purpose, prerequisites, partner selection, time suggestion, and the confirmation flow. It misses error handling or return value info, but the main workflow is well-described.

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 50%, and the description adds context for key parameters: token (from verify_code), customer_email (must be verified), customer_consent (must be true), partner_code (from get_partners), scheduled_at (during working hours). However, it does not cover vehicle_make, vehicle_model, vehicle_year, customer_name, customer_phone beyond schema, so it only partially compensates for the missing schema descriptions.

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 explicitly states it creates a PENDING reservation for battery exchange at a partner, which is a specific verb+resource. It distinguishes itself from siblings like verify_code and get_partners by being the step that creates the actual booking after verification and partner selection.

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

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

The description clearly states prerequisites: token from verify_code, verified email, explicit consent (customer_consent=true). It advises selecting partner via get_partners and suggesting time during working hours. It also explains the post-call flow (customer confirms via email, partner approves). It lacks explicit when-not-to-use but provides sufficient context.

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 fully disclose behavior. It adds that the code has limited validity and a daily limit, which are important constraints. However, it does not explain what happens on invalid email or whether the action is idempotent. The agent instructions are more procedural than behavioral.

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 relatively concise at two sentences. It front-loads the core action ('KROK 1 rezervácie: pošle 6-miestny overovací kód...'). The inclusion of step-by-step agent instructions adds some verbosity but is still acceptable given the tool's role in a multi-step process.

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?

The tool is simple (one param, no output schema) and the description covers the core action and constraints. However, it lacks details on the return value or success confirmation, which is notable given the absence of an output schema. The sibling tool 'verify_code' suggests a flow, but the agent might need more on what to expect after calling this 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 baseline is 3. The description does not add new semantic details about the 'email' parameter beyond what the schema already states ('E-mail zákazníka'). It merely contextualizes the email as the customer's for verification.

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 sends a 6-digit verification code to the customer's email, using a specific verb ('posle') and resource ('overovací kód'). It explicitly identifies this as step 1 of a reservation, distinguishing it from sibling tools like 'verify_code' which handle the subsequent verification step.

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 contextual usage guidance by labeling this as 'KROK 1 rezervácie', implying it should be used first in a reservation flow. However, it does not explicitly state when to use this tool versus alternatives like 'verify_code', nor does it specify conditions to avoid use (e.g., existing verified customer).

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 provided, so description carries full burden. Implies read-only search behavior and describes what happens: returns names, prices, partners, link. Adequately covers the expected outcome without misleading.

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: first defines purpose and scope, second lists return fields and a recommendation. No redundant text, front-loaded with key information, efficient and clear.

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 purpose, scope, return values, and usage recommendation. No output schema, but description sufficiently addresses common use cases. Lacks pagination or error details, but acceptable for a search 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% with descriptions for both parameters (limit, query). Description adds no additional meaning beyond schema; the return type context is helpful but does not enhance parameter understanding.

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 clearly states it searches batteries and products in the S.O.S BATTERY e-shop, specifies types (car, motorcycle, instrument), and lists return fields. Unambiguously distinguishes from sibling tools like get_product or get_collection.

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 recommends using only products from these results (web link), indicating when to trust the tool's output. Lacks explicit when-not-to-use or alternative tool guidance, but context is clear.

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 are provided, so the description carries full burden. It explains the success outcome (returns token, unlocks request_booking), but does not mention error behavior, rate limits, or side effects. The behavior is partially described.

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 front-loaded with context ('KROK 2 rezervácie') and efficiently covers purpose, action, and outcome without unnecessary words.

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 no output schema and two required parameters, the description explains the core purpose and success output, but omits details like error handling, input validation, or exact sequence with sibling tools. It is adequate but not fully 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 50% (only code has description). The description adds meaning by linking the code to the email and stating the token is for that email, but does not elaborate on email format or validation. It partially compensates for the missing schema description.

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 is step 2 of reservation, verifies a 6-digit code, and returns a token that unlocks request_booking for a specific email. This distinguishes it from siblings like request_booking and request_verification.

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 explicitly says it's step 2 and instructs to ask the customer for the code, providing clear context for when to use. It does not mention when not to use or list alternatives, but the intended use case is well-defined.

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