Zacatrus

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

Annotations already mark this as a non-readonly, non-idempotent, non-destructive write. The description adds real behavioral context beyond them: Zacatrus emails the confirmation with a QR, and the client must be authenticated. It stops short of saying what happens if a slot is already taken or whether a retry duplicates 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?

Five short sentences, each carrying distinct actionable content: prerequisite lookup, confirmation ask, phone rule, post-booking notification, auth requirement. No filler and the key prerequisite is front-loaded.

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

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

For a mutation tool with no output schema, the description covers the outcome (confirmation email with QR), the auth requirement, and the ordering of operations. It leaves unstated what a failed or conflicting reservation looks like, but an agent has everything needed to 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 description coverage is 100%, so the baseline is 3, but the description adds cross-tool semantics: slot values must come from ludoteca_slots and the phone must be collected fresh for this reservation rather than reused. That is meaning beyond the schema's field-level prose.

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+scope: reserving a ludoteca table at a Zacatrus store for a customer. This clearly separates it from ludoteca_slots (which only lists availability), my_bookings, and cancel_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?

Explicitly prescribes the prerequisite step (search free slots with ludoteca_slots first), the confirmation flow (client must confirm store, day and slots), and the gating condition (client must be logged in). It also gives an exclusion-style rule: never assume or reuse a phone number from another 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?

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description still adds real value: the ownership constraint, the 'only future reservations' restriction, the login requirement, and the side effect that Zacatrus sends the cancellation email.

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

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

Front-loaded with the action and scope, followed by the booking_id source, confirmation requirement, side effect, and auth precondition. Every sentence carries distinct operational information with no 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?

With no output schema needed and annotations covering the safety profile, the description supplies everything else an agent needs: prerequisites (login), the id source, the confirmation step, and the outcome (cancellation email). Nothing material is missing for a 2-parameter mutation 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 both parameters (booking_id and country) are already documented in the schema, including the booking_id source and the country enum semantics. The description only restates that booking_id comes from my_bookings, adding no syntax or format detail 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?

States a specific verb and resource ('Cancela una reserva de mesa en la ludoteca') and narrows the scope to the client's own, not-yet-passed reservations. This cleanly distinguishes it from siblings such as my_bookings (which reads) and ludoteca_slots (which lists 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?

Explicitly tells the agent where to get booking_id ('Obtén el booking_id con my_bookings') and mandates asking the customer for confirmation before cancelling. It leaves no ambiguity about the workflow or the prerequisite login state.

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

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

The "solo lectura" claim merely restates readOnlyHint=true, but the description genuinely adds the login/authentication requirement and the constraint that new addresses can only be created via the web, neither of which appears in the annotations. It does not disclose caching, rate limits, or whether last-order data can be stale.

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 with the payload enumeration front-loaded, followed by two short constraint sentences. Everything earns its place, though the payload list is packed into one long clause that could be broken up for scannability.

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

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

With no output schema, the description usefully enumerates the returned data shape (addresses as id + city/postal label, stores, shipping methods, reusable last order), and it covers read-only status, auth prerequisite and address-creation limitation. It omits how the country parameter changes results and gives no guidance on calling order relative to prepare_order.

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 sole 'country' parameter already documents site selection, language, prices and links. The description does not reference the country parameter at all, so it adds nothing beyond the schema – baseline 3 applies.

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

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

States precisely what the tool returns – saved addresses (id + short label), pickup stores, shipping methods and last-order defaults – and ties it to its consumer, prepare_order, which distinguishes it from prepare_order and prepared_order_status. However, it never states the action verb itself ("returns/retrieves"), so the function is inferred from the enumerated payload rather than declared.

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 framing "lo que hace falta para preparar un pedido con prepare_order" clearly positions this as the step preceding prepare_order, and it adds a real exclusion/limitation ("una dirección nueva solo se añade desde la web") plus a prerequisite (logged-in customer). It stops short of explicitly naming siblings to use instead in other situations (my_orders, list_stores).

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

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

The annotations already declare a safe, idempotent, closed-world read, so the bar is lower. The description nonetheless adds a real behavioral constraint the schema cannot express: the current month's box contents are only returned once they have been revealed, and may otherwise be unavailable. That is genuinely useful conditional-return context, though nothing is said about link validity or update cadence.

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: the first front-loads what both offerings contain, the second carries the reveal caveat. Nothing is redundant, though the parenthetical lists make the first sentence dense.

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, read-only informational tool with no output schema, so it does not need return-format detail. The description covers both offerings and the one non-obvious behavioral caveat. It would be complete if it also clarified that this is the public offering overview rather than the user's own membership or box status.

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

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

Schema description coverage is 100% and the single country enum fully documents its own effect on language, prices and links, so the schema carries the burden. The description's mention of 'precios y enlaces' loosely corroborates the country parameter but adds no format or default detail beyond the schema. Baseline 3 applies.

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

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

States a specific resource: the two Zaca+ offerings and exactly what each covers (member discounts, ludoteca priority, early promos vs. surprise game boxes), plus that it returns prices and subscription links. It is clear on its own, but it never distinguishes itself from siblings like my_club and my_box, 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?

The description says what the tool covers but gives no when-to-use guidance, no prerequisites, and no routing to or away from the obviously adjacent siblings (my_club, my_box). Usage has to be inferred from the content list alone.

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, so safety is covered. The description adds real context beyond that: output is strictly aggregated (client counts per game, never identifying who), which tells the agent it must not expect or request user-level data.

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

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

Three short sentences, front-loaded with the core definition before the aggregation caveat and the use case. Slight overlap between the naming of the two metrics and the closing recommendation sentence, but nothing is 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?

A 3-parameter, optional-only, read-only tool with no output schema. The description conveys the ranking nature, the two metrics, and the aggregate return content, which is sufficient for correct invocation; only the ordering/tie-breaking behavior of the ranking is left unspecified.

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% — limit, metric and country are all fully documented in the schema, including defaults and enum meanings. The description restates the wanted/favorite distinction but adds no syntax or constraint beyond what the schema already provides, so the baseline 3 applies.

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

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

States a specific resource and scope: a community ranking of games split by two metrics (los más deseados / favoritos de clientes). An agent can tell this is an aggregate-ranking tool rather than a catalog search, though it never names a sibling (e.g. search_games) to sharpen the boundary.

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

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

"Sirve para recomendar 'lo que más gusta' o 'lo que más se desea'" implies the use case (recommendation/queries about community preference), which is genuinely helpful. However it gives no when-not-to-use rule and never points to alternatives like search_games, leaving the routing implicit.

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 useful return-content context (texto, precio, disponibilidad, enlace) but discloses no further behavioral traits such as auth needs, rate limits, or caching. With annotations carrying the safety burden, a 3 is appropriate.

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 with no wasted words, and the core purpose is front-loaded before the get_game equivalence note. The equivalence sentence is short but slightly confusing, keeping it just short of a 5.

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 read-only detail tool with no output schema, the description enumerates the returned fields and ties the id to a prior search, which is enough for correct invocation. The equivalence to get_game is the only unresolved point and could mislead an agent about which sibling to call.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema. The description reinforces the id's provenance ('El id que devolvió search') but adds no syntax or format detail, and it never mentions the country/store parameter. Baseline 3 when the schema does the heavy lifting.

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: retrieve the full card of a search result by its id, listing the fields returned (texto, precio, disponibilidad, enlace). However, the closing note 'Equivale a get_game' blurs sibling differentiation by telling the agent this is essentially the same as an existing sibling rather than contrasting the two.

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

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

Usage is implied rather than stated: 'El id que devolvió search' ties the call to a prior search invocation, so the workflow context is inferable. But there is no explicit when-to-use/when-not guidance and no routing between this tool and get_game, which the description declares equivalent.

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 and closed-world behavior, so the bar is lower. The description nonetheless adds real context beyond them: comments are anonymous (no name or profile), they are returned exactly as on the web, and results may legitimately be empty or sparse and must not be fabricated.

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

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

Three short sentences, front-loaded with what is returned, then anonymity, then the empty-result caveat. Each sentence carries distinct information; only phrases like 'tal como están en la web' border on redundancy, but they convey raw-fidelity intent.

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

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

With no output schema, the description does the work of characterizing the return (anonymous comments plus wishlist/favorite counts, possibly empty), and annotations cover the safety profile while the schema covers all three parameters. The main missing piece is how comments are ordered or paginated, which an agent may need for multi-page retrieval.

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 fully documents sku, limit and country (including the es/fr enum semantics). The description adds no parameter-level detail such as default limit or SKU-vs-URL acceptance, 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 states a specific resource and scope: public customer comments for a given game from Zacatrus, plus how many customers wishlist or favorite it. It clearly describes the returned data (raw web text, anonymous), but it never names or differentiates itself from related siblings such as community_top_games or get_game.

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 resource description rather than stated: an agent can infer it is for reading a specific game's comments, but there is no explicit when-to-use, when-not-to-use, or named alternative (e.g., community_top_games for aggregate rankings). The 'si no hay, no lo inventes' instruction is a result-handling hint, not usage routing.

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 cover read-only, idempotent and non-destructive behavior, so the description's added value is the disclosure of return semantics: availability states (in_stock/out_of_stock/preorder), the preorder date, and that country drives language, prices and links. It does not mention failure behavior for an invalid sku, but the behavioral profile is otherwise well disclosed.

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, front-loaded with the resource and its returned fields, followed by the identification rule. The long field enumeration is dense but every item earns its place by substituting for the absent output 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?

With no output schema, the description compensates by enumerating the returned fields and explaining availability and preorder semantics, and it covers both the identifier and the country parameter. An agent has everything needed to call 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 description coverage is 100%, so both parameters are already documented; the description mainly restates that sku is the search_games field or a ficha URL and that country sets language/prices/links. It adds a useful cross-tool link but no syntax or format detail beyond the schema, matching the baseline 3.

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 ('Ficha completa de un juego de Zacatrus') and enumerates the exact fields returned (precio, disponibilidad, jugadores, edad, duración, temáticas, autores, editorial). An agent can distinguish it from search_games, which only lists games and yields the sku this tool consumes.

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: 'Identifícalo con el sku que devuelve search_games, o con la URL de la ficha', which establishes the search_games -> get_game workflow and the two accepted identifiers. It gives no explicit when-not or alternative-lookup guidance (e.g. store_stock for per-store availability), so it falls short of a 5.

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

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

Annotations already cover read-only, idempotent and closed-world semantics, so the bar is lower. The description still adds real behavior: recurring events (weekly or every 15 days) are returned with only their next date, and enrollment requires a web account. Pagination/return format is not covered, but the recurring-event collapsing is valuable non-obvious context.

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

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

Three tight sentences, front-loaded with the resource and its scope, followed by the returned fields, the recurring-event rule, and the enrollment caveat. Every sentence carries information, though the field list and the enrollment note could be trimmed slightly.

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

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

With no output schema, the description compensates by naming the returned fields (tienda, fecha y hora, duración, plazas libres, descripción) and the store/country scoping. It omits pagination behavior and any indication of what an empty result means, leaving a small gap for a 4-parameter listing 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 days, limit, store and country are already documented in the schema. The description mentions store/date/description fields but does not add syntax or interaction detail for any parameter beyond what the schema states, 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 gives a specific verb+resource combination — upcoming published events at physical Zacatrus stores — and enumerates the entity types (ligas, torneos, encuentros) plus returned fields. This clearly separates it from list_stores (stores, not events) and from booking tools like book_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?

It clarifies the reading use case and explicitly notes that registration happens on the website with an account (link in url), steering the agent away from trying to register through this tool. It does not name sibling tools as alternatives, so it falls short of explicit when/when-not routing.

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 this a safe, idempotent, closed-world read, so the bar is lower. The description nevertheless adds a genuinely useful behavioral caveat: the hours are as declared on the web and do not guarantee the store is currently open, which prevents an agent from over-claiming real-time status.

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 front-loads the resource and its payload fields, followed by a short disclaimer sentence. Both earn their place, though the parentheticals make it slightly heavier than necessary.

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

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

With no output schema, the description compensates by enumerating the returned fields (address, hours, closures, ludoteca), and annotations cover the safety profile. An agent has enough to call it correctly, though the optional country parameter's practical effect on results is left entirely to the schema.

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

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

Schema description coverage is 100% and the single country parameter is fully documented in the schema, including its effect on language, prices and links. The description adds nothing about the parameter, so the baseline of 3 applies.

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

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

The description names a specific resource (Zacatrus physical stores) and enumerates exactly what each entry contains: address, declared hours, upcoming closure days, and ludoteca availability. It is a list operation and implicitly distinguishable from store_stock and ludoteca_slots by virtue of being store-index data rather than stock or slot data, though it never names 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?

Usage context is only implied via the note that the hours match those shown when selecting in-store pickup, which hints at the pickup-selection workflow. There is no explicit when-to-use guidance, no exclusions, and no routing to alternatives such as store_stock for inventory questions.

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, so safety is covered. The description adds real behavioral context beyond them: no reservation is made here, and days outside the Zaca+ Club advance window are surfaced as club_only, which is a data-semantics detail an agent could not infer from annotations or schema.

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 compact sentences, front-loaded on what the tool returns, with the booking/club_only caveats following. The inline definition of ludoteca is worth its length; there is minor redundancy between the title and opening phrase.

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

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

For a zero-required-param, read-only listing tool with full schema coverage and complete annotations, the description covers purpose, scope, booking boundary and the club_only caveat. Return-value shape is not described and no output schema exists, but this is a minor gap for an availability listing.

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

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

Schema description coverage is 100%, so date format, days range, store code/name and country enum are all already documented in the schema. The description's 'por tienda y día' is consistent with but not additive to those field definitions, so the baseline 3 applies.

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

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

States a specific resource and scope: free table slots at Zacatrus store game libraries, broken down by store and day. The parenthetical explaining what the ludoteca is removes ambiguity, and the explicit 'Sin reservar nada' separates this read-only listing from the booking flow (the book_table sibling).

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

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

Gives clear context: use this to see availability, and to book you must enter the website with an account (link in url) rather than use a tool. It also explains the club_only advance-booking window, which tells the agent how to interpret results for non-club customers. It does not name the book_table sibling directly for contrast, so it stops short of a 5.

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

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

Annotations already declare idempotent=false, destructive=false, readOnly=false, but the description adds real behavioral context beyond them: it is purely additive (never removes a mark, never changes anything else) and requires the customer to be logged in. The login/auth prerequisite is exactly the kind of disclosure annotations cannot carry.

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?

Five short sentences, each carrying distinct information (purpose, add-only constraint, confirmation, identifier source, auth). Front-loaded with the action; no filler. Slightly long but nothing redundant enough to cut.

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 and a simple 3-param mutation, the description covers what matters: what it does, what it does not do, the auth requirement, and how to obtain the identifier. It never states what a successful call returns, but for a flag-setting operation with rich annotations that gap is minor.

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

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

Schema description coverage is 100%, so both enum params and country are already fully documented in the schema. The description only adds where to source the sku (search_games or the ficha URL), which is marginal over the schema's own 'campo sku de search_games' text. Baseline 3 for high coverage 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 and resource ('Añade un juego a la colección del cliente') plus the two possible values (owned/wanted), which is exactly the distinction that separates it from sibling tools like my_collection or search_games. An agent can tell what the tool does without opening the schema.

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

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

Gives actionable context: ask the customer for confirmation before marking, and identify the game via the sku from search_games or the game's URL. It also implicitly excludes un-marking ('no quita ninguna'), but never explicitly names when to prefer a sibling over this tool, so it stops short of a 5.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new context: the auth requirement (client must be logged in) and the data-minimization scope (only the first name is returned), which the agent needs to reason about failures and privacy.

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: capability first, then usage, then prerequisite. Every sentence earns its place with zero padding or repetition of the title.

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

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

For a zero-required-param read tool with no output schema, the description supplies the missing return-shape information ('nombre de pila' and 'desde cuándo') and the login prerequisite. Only the country/store dimension is left unexplained, which is minor since the schema documents 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 description coverage is 100% and the single 'country' enum parameter is fully documented in the schema, so the description carries no burden here. However, the description never mentions that store selection (es/fr) affects language, prices and links, adding nothing beyond the schema. Baseline 3 applies.

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

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

States a specific verb and resource ('comprueba qué cuenta de Zacatrus tiene conectada') plus the exact payload scope ('solo el nombre de pila') and 'desde cuándo'. This clearly separates it from account-adjacent siblings like my_orders, my_box, or my_club, which return different data.

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 names two use cases ('saludar al cliente', 'comprobar que la conexión funciona') and states the prerequisite that the client must be logged in. It does not name alternatives or when-not-to-use, but the sibling set is disjoint enough that this is a minor 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuine extra context beyond that: the authentication requirement ('Necesita que el cliente haya iniciado sesión') and the fact that the result feeds cancel_booking. It does not, however, discuss pagination or result limits.

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 dense, front-loaded sentence that wastes no words and puts the resource and scope first. It is slightly run-on, packing returned fields, the cancel_booking link, and the auth requirement into one clause stack, but every element 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?

With no output schema, the description usefully enumerates the returned fields (store, day, time slots, tables, booking_id) and the auth prerequisite, which is enough to call a simple one-param read tool correctly. It omits any notion of pagination or result volume, a minor gap for a list-style 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 single 'country' enum parameter is already fully documented in the schema, including the es/fr store mapping and its effect on language and prices. The description adds no parameter-level meaning beyond that, 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 names a specific resource (table reservations at the ludoteca) and scope (those the customer holds from today onwards), plus the fields returned (tienda, día, franjas, mesas, booking_id). It also implicitly distinguishes itself from cancel_booking by referencing the booking_id that sibling consumes, so an agent can tell it apart from book_table and cancel_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?

It gives clear context: only reservations 'a partir de hoy' (upcoming, not historical) and a stated prerequisite that the client must be logged in. It also points to cancel_booking as the consumer of the returned booking_id. What it lacks is an explicit when-not or a named alternative to choose 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: an authentication prerequisite (the customer must be logged in) and a data-freshness rule (game contents only surface once revealed, otherwise only the reveal date is shown). That is real added value, though it does not address error/empty states.

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 front-loaded with the precondition, then the returned fields, then the read-only/where-to-change note, then the auth requirement — a logical order. It is a dense 3-sentence block with a UI cross-reference ("Tu cuenta > BOX") that earns its place by anchoring expectations, though a little is spent restating read-only status already covered by annotations.

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 and a read-only, 1-param ancillary tool, the description carries the return-value burden and does so: it enumerates modalities, per-box fields and the reveal-timing caveat. Combined with the auth requirement, an agent has enough to call it correctly; only edge cases (not subscribed, FR vs ES differences) are left implicit.

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% for the single 'country' parameter (enum es/fr, with its effect on language, prices and links already documented in the schema). The description never mentions country or any parameter behavior, so the baseline of 3 applies — nothing added, nothing lost.

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?

It states a specific resource (Zaca+ Box subscription) and exactly what is returned: active modalities (Familiar, Para 2, Outlet) plus, for each, the next box's name, ship date and max price. That is far more than a restatement of the name/title. It does not explicitly differentiate itself from the nearby sibling 'club_and_box', so it falls short of a 5.

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

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

It names the triggering condition ("Si el cliente está suscrito a Zaca+ Box") and states what the tool does NOT handle (sign-up, cancellation, modality changes happen in the customer's account via manage_url), which effectively routes those actions elsewhere. It does not explicitly say when to pick this over my_club or club_and_box, so it is clear context without explicit alternatives.

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?

Adds meaningful behavior beyond the annotations: explains that mutations (signup, cancellation, renewal changes) are out of scope and happen via manage_url, and that the customer must be logged in. readOnlyHint is reinforced with explicit scope statements, not just stated.

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 compact sentences, each carrying a distinct fact (scope, read-only, manage_url pointer, auth prerequisite). No 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 single-parameter read tool with strong annotations and full schema coverage, the description covers scope, safety and auth. It lacks any note on what happens when the customer is not a member (empty result vs. error), a minor gap given no output schema.

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

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

Only one parameter exists and schema coverage is 100%, so baseline is 3; the description additionally implies the country choice affects language and links, marginally strengthening the schema's own explanation.

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: reads the customer's Zaca+ Club membership, returning plan, start date, paid-until date and auto-renewal. Siblings like my_account, my_orders and my_box cover other account facets, and the description limits itself to the club membership 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?

The conditional at the start ('Si el cliente es socio de Zaca+ Club') and the login requirement give clear when-to-use context, and it points to manage_url for changes. It does not explicitly name a sibling alternative, but the scope 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?

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds a genuinely useful behavioral fact not in the annotations: the client must be logged in, and results carry a summarized record per game rather than full detail.

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

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

Three dense sentences, front-loaded with what the tool returns before moving to usage and the login prerequisite. No filler or repetition of the name/title.

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

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

No output schema exists, so the description carries return-shape duty and does partially discharge it by noting each game comes with a summarized record. Combined with the login prerequisite and full schema coverage, only the pagination/limit behavior nuance is left implicit.

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 enum meanings for 'list' and 'country', the default (both lists) and the limit bounds are fully documented in the schema. The description adds no parameter-level detail beyond what is already structured, so 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?

Names a specific resource — the client's Zacatrus collection split into 'owned' and 'wanted' entries, each with a summarized record — which an agent can immediately separate from unrelated siblings like my_orders, my_bookings or my_fichas. The verb (retrieve/recommend from) and the two-list scope are both explicit.

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

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

Gives concrete when-to-use conditions: recommend from what the client already owns (with an example query) and avoid recommending games already owned. It does not name an alternative sibling or state an exclusion (e.g. when to prefer search_games instead), so it stops short of a full when/when-not/alternatives statement.

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, so 'Solo lectura' is consistent but partly redundant. The description adds genuine value by disclosing the authentication requirement and, usefully, the content of the result (balance plus euro equivalent) in the absence of an output schema. No error behavior or rate limits are mentioned.

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

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

Three short sentences, front-loaded with what the tool returns, followed by the read-only note and the auth prerequisite. No wasted 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?

For a single-optional-parameter read tool with no output schema, the description covers purpose, output content, and the login requirement, which is close to sufficient. It stops short of describing behavior when the customer is not logged in, leaving a minor gap.

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

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

With one parameter at 100% schema description coverage, the schema fully documents the country enum and its effect on language, pricing and links. The description adds nothing about the country selector, so the baseline of 3 applies.

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

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

The description names a specific resource — the customer's fichas balance (identified as Zacatrus's points program) plus its euro equivalent — and anchors it to 'Tu cuenta', which implicitly distinguishes it from the broader my_account sibling. An agent can tell exactly what is being retrieved.

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

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

It states a prerequisite ('Necesita que el cliente haya iniciado sesión'), which is useful context, but gives no explicit when-to-use vs. alternatives (e.g., my_account) and no when-not guidance. Usage is implied by the resource itself rather than spelled out.

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

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

Annotations already cover read-only, idempotent, non-destructive and closed-world traits, so the bar is lower. The description still adds real value beyond them: it discloses the login requirement, that addresses and payment data are deliberately excluded, and that tracking info only appears once the order has shipped.

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 paragraph where each clause carries new information: returned fields, the 'order' filter, the read-only scope, and the auth prerequisite. Nothing is repeated or padded, and the most decision-relevant facts come first.

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

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

With no output schema, the description must describe returns, and it does so concretely (fields plus conditional shipping tracking). It also covers the auth prerequisite and the data-exclusion boundary, so an agent has everything needed to call 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 description coverage is 100%, so all three parameters (limit, order, country) are already documented in the schema, including the 'order' semantics the description restates. The description adds no format or syntax detail beyond the schema, which is the expected baseline of 3.

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 ('Los últimos pedidos del cliente') and enumerates exactly what is returned: número, fecha, estado, juegos, total y seguimiento del envío. The conditional behavior with the 'order' parameter is spelled out, distinguishing it from siblings like prepared_order_status and my_account 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?

Gives clear operating context: it explains that passing 'order' returns just that one order, and that the customer must be logged in. It does not explicitly name an alternative tool for related needs (e.g., prepared_order_status for in-prep orders), so sibling routing is left partly to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so 'Es solo lectura' is largely redundant. However, the description adds genuinely non-structured context: the auth prerequisite that the customer must be logged in, and the enumerated outcome states (pending confirmation, expired, cancelled, converted to an order with its number).

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

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

Three short sentences, front-loaded with the state outcomes, then the identification method, then the read-only and auth notes. No filler and every sentence carries distinct information.

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

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

With no output schema, the description compensates by enumerating the possible return states and noting the order number is returned. Combined with the auth requirement and lookup keys, an agent has everything needed to call and interpret the tool.

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

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

Schema description coverage is 100%, so the baseline is 3 and the schema already documents all three parameters. The description adds an either/or identification rule (prepared_id OR the idempotency_key you used) that clarifies the intended alternative use of the two lookup parameters, though it does not mention the country parameter.

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

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

It names the specific resource (a prepared order made by prepare_order) and a precise verb-like function: reporting which of several lifecycle states it is in. It is clearly distinguished from the sibling prepare_order, which creates the resource rather than querying its state.

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 places the tool in a workflow: use it after prepare_order, and identify the order via prepared_id or the idempotency_key you used. It does not spell out explicit exclusions or when to prefer one identifier over the other, so it stops short of full when/when-not guidance.

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

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

Adds substantial context beyond annotations: nothing is charged here, the order is not final until confirmed on zacatrus.es, login is required, droppoint_droppoint must be chosen by the client on the map, and the idempotency mechanic (same key returns the same prepared order) is spelled out rather than left to the idempotentHint flag. Annotations (readOnly=false, destructive=false, idempotent=true) are consistent with all of this.

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

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

Front-loads the purpose and output, then layers prerequisites, constraints and the idempotency rule. Dense but every sentence carries operational value; the repeated emphasis on showing the summary/link is slightly redundant but justified by the tool's risk profile.

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 is needed because the description states what is returned (resumen con líneas, envío, total, destino, caducidad y enlace). Combined with login, no-charge, stock and idempotency disclosures, an agent has everything required to call this correctly.

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

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

Schema coverage is 100% so the baseline is 3, but the description adds genuine meaning: it explains the droppoint_droppoint + address_id interaction for shipping_method, the country store implications, and how idempotency_key should be generated per distinct order. It doesn't cover country or pickup_store semantics in the prose, keeping it short of a 5.

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 ('Prepara un pedido de Zacatrus') and enumerates exactly what the order contains (productos, dirección o tienda, forma de envío). It is easily distinguished from siblings like checkout_options, prepared_order_status and my_orders, and it also states the output (resumen + enlace de pago).

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 directs the agent to call checkout_options first and confirm with the client, names the sibling tools that supply skus (search_games, get_game, store_stock), and states a clear exclusion set (no preventas, tarjetas regalo ni suscripciones, solo con stock). This is textbook when/when-not/alternatives guidance.

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

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

Annotations already declare readOnly/idempotent/non-destructive/false openWorld, so the safety profile is covered. The description adds genuinely useful context beyond them: what is returned (id, título, enlace) and the intended search-then-fetch workflow. No limits or pagination are mentioned, keeping it below a 5.

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

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

Two tightly packed sentences: purpose first, then return contract, then workflow and alternative. No filler and nothing duplicated from 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?

With no output schema, the description sensibly documents the return fields, and the annotations carry the safety profile while the schema fully covers both params. Only minor gaps (result limits, pagination) remain.

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%: both 'query' (natural-language, with examples) and 'country' (enum es/fr with effect on language, prices, links) are fully documented in the schema. The description adds no parameter syntax or format detail beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource ('Búsqueda de texto libre en el catálogo de Zacatrus (juegos de mesa)') and precisely distinguishes itself from the sibling search_games by noting it is the no-filter equivalent. It also names the concrete return fields (id, título, enlace), so an agent knows exactly what it produces.

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 names the alternative (search_games), explains the relationship ('sin filtros'), and gives the intended audience ('clientes que solo conocen search y fetch'), plus a follow-up step ('usa fetch con el id'). It stops short of an explicit exclusion rule ('use search_games when you need filters'), which is only implied.

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 the safety profile is covered. The description adds real value beyond that by naming the returned fields and the availability states (in_stock, out_of_stock, preorder), which is important since no output schema exists. It does not mention auth or rate limiting, so it stops short of a 5.

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

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

Three sentences, front-loaded with the core purpose followed by filter categories, then returns, then the retry tip. Efficient overall, though 'con el mismo buscador que la web' is decorative filler that does not help an agent invoke the tool.

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 12 optional parameters and no output schema, the description usefully compensates by listing the searchable facets and the shape of the response. It omits result-count behavior already present in the schema and does not cover error/empty-result semantics beyond the retry hint, leaving minor gaps.

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

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

Schema description coverage is 100%, so every parameter (age, players, price ranges, minutes, country, sort, limit) is already documented, and the description only restates the filter categories. It adds no syntax or interaction detail beyond the schema's own normalization notes, so the baseline 3 applies.

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

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

States a specific verb and resource ('Busca en el catálogo de Zacatrus') and enumerates the catalog scope (juegos de mesa, rol, cartas y accesorios). It is clear what the tool does, but it does not distinguish itself from close siblings like 'search', 'get_game' or 'community_top_games', so an agent must infer the boundary.

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

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

Indicates that free text can be combined with filters and adds a practical fallback ('Si no hay resultados, prueba con menos filtros'), which is genuine guidance. However, it never says when to prefer this over 'get_game' (single game lookup) or 'community_top_games', so usage vs alternatives is only implied.

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 beyond the readOnly/idempotent/non-destructive annotations by disclosing two behavioral traits an agent cannot infer: unit counts are capped at 10 and can change within minutes (staleness), and a reservation needs store confirmation. It does not discuss caching or refresh semantics, but for a read-only tool this is meaningful added context.

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

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

Three short sentences, front-loaded with what is returned, followed by when to use it and the key caveat. Every sentence carries information an agent needs; nothing is redundant with the schema or annotations.

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

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

There is no output schema, so the description correctly compensates by naming the returned classification values and web availability. Combined with the volatility caveat and reservation note, an agent has enough to call and interpret the tool; only finer return-shape detail (e.g., per-store ordering) is missing.

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

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

Schema description coverage is 100%, so the sku, store code, and country enum are already fully documented in the schema. The description's mention of web availability loosely relates to the country parameter but adds no syntax or format detail beyond what the schema provides. Baseline 3 applies.

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

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

States a specific resource (units of a game per physical Zacatrus store plus web availability) and enumerates the returned stock states (in_stock, low_stock, out_of_stock). This clearly separates it from list_stores (store directory) and get_game (catalog data) without needing to open the schema.

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

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

Explicitly says when to use it: 'cuando alguien quiera comprar en tienda o recoger hoy.' It also sets expectations that a secure reservation requires confirming with the store. It stops short of naming a sibling alternative for edge cases (e.g., online-only stock), so it is clear context rather than full when/when-not routing.

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