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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the mutation profile is covered. The description adds genuinely non-structured context: that paid tickets incur a cancel_charge and that user confirmation is expected. It does not state whether cancellation is reversible or what happens to ancillary items, keeping it from 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 short sentences, front-loaded with the action and its scope, followed by the cost caveat and the confirmation requirement. Nothing is wasted and no sentence repeats a structured field.

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 destructive mutation with an output schema present, the description covers the essential agent-facing concerns: cost of cancellation, where to check it, and the need to confirm. Irreversibility and post-cancellation state are left implicit, but the destructive hint partially covers that.

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 67%, so most parameters are already documented in the schema (lang and refund_to_original_source both carry descriptions). The description adds no meaning to ticket_id or to the refund routing choice, so it neither compensates for the gap nor adds value over 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?

States a specific verb ('Cancel') and resource ('a reservation or a paid ticket'), which clearly separates it from creation-oriented siblings like create_reservation and read-only ones like get_my_ticket. It does not explicitly name a sibling alternative, but the scope is unambiguous.

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

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

Gives a concrete operating instruction ('Confirm with the user first') and routes the agent to get_my_ticket to inspect cancel_charge before acting on paid tickets. It lacks an explicit 'do not use when...' exclusion, but the context for safe use 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?

Annotations already declare this is a non-read-only, non-destructive, open-world operation, so the safety profile is covered. The description adds genuinely non-obvious behavior the annotations cannot convey: the reservation is created UNPAID and auto-expires at expiration_date unless paid or cancelled, which is critical for an agent to act on. It omits failure modes such as sold-out seats or what errors look like, 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 short sentences with zero filler: the action and its state come first, followed by the expiry/payment consequence. Capitalized UNPAID properly emphasizes the condition an agent must not miss.

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 a full output schema and annotations present, the description does not need to explain return values, and it covers the lifecycle an agent must know. The main residual gap is behavior when the requested seats or class are unavailable, plus the absent link between expiration_date and how the agent should track it afterward.

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%, with each parameter already documenting its source (route_id from search_routes, sections from get_route_detail, seat_class from price_classes, etc.), so the baseline is 3. The description adds no parameter-level detail, and it references expiration_date, which is not an input parameter, so an agent gets no extra guidance on how to populate the four required fields.

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

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

The description opens with a specific verb and resource ('Reserve seats') scoped to the logged-in account, then states the resulting object's state (UNPAID) and lifecycle. No sibling tool creates reservations, so ambiguity with get_ticket, search_routes, or cancel_ticket is low.

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 situates the call in a workflow by naming the follow-up alternatives (pay_ticket_with_credit or the app/web, or cancel), which tells the agent what to do next after reserving. It stops short of explicit when-not-to-use guidance or prerequisites such as needing a route_id from search_routes first, which the schema handles 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 establish that this is a read-only, open-world lookup. The description adds meaningful behavioral context beyond that: results are location identifiers plus types, city IDs cover all stations, and station IDs matter for route detail and seat operations. It does not cover pagination or result limits, but the core downstream behavior is 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?

The description is short, front-loaded, and structured around one main action followed by a practical usage rule. Every sentence contributes either purpose, integration guidance, or ID-type selection advice.

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 that an output schema exists and annotations cover safety, the description provides enough context for an agent to call this lookup and use its results correctly. Minor gaps around limit behavior and language handling are acceptable because those are largely covered by the input schema.

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

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

Schema description coverage is 75%, with query, lang, and station_type documented while limit is not described in the schema. The description reinforces name-based lookup and the city/station distinction, but it does not add much parameter-level guidance beyond what the schema already provides.

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

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

The description states a specific verb and resource: find RegioJet cities and stations by name. It clearly distinguishes this lookup tool from route-search and ticket siblings by identifying its role as the source of from/to location IDs.

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

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

It explicitly says to use the returned id and type as from/to in search_routes, and gives a concrete decision rule: prefer CITY ids for searching, STATION ids for route detail/seats. This tells the agent when to choose each location type and how the result feeds a specific sibling tool.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description contributes the 'logged-in' scoping detail, implying auth comes from the session rather than parameters, but adds nothing about caching, freshness or error behavior for an unauthenticated call.

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

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

A single front-loaded sentence with the resource first and the returned fields after the colon. No filler, no 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?

For a simple, argument-free read with an output schema and read-only annotations, the description covers purpose and payload adequately. The only minor omission is any mention of the optional language parameter or behavior when not logged in.

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 optional parameter at 100% schema description coverage, the schema already documents 'lang' and its default fully. The description adds no further parameter meaning, 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 ('Get the logged-in RegioJet account') and enumerates the key fields returned (name, default tariff, credit balance), so the agent knows exactly what comes back. It does not explicitly distinguish itself from siblings, though no sibling overlaps in scope since the others deal with tickets, routes and seats.

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

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

Use is implied by the content (fetch name, tariff, credit balance), and the 'logged-in' framing signals it applies to the current session only. There is no explicit when-to-use or when-not guidance and no reference to any alternative tool.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds real, non-obvious domain behavior beyond that: results are grouped per vehicle (carriage/bus) and per route section, and double-decker buses are treated as one vehicle with seats listed per deck — a detail an agent could easily misinterpret as separate vehicles.

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 core operation, followed by one sentence that resolves a specific modeling ambiguity. 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?

Return values are covered by the output schema and all five parameters are documented, so the description only needs to frame the operation and result grouping, which it does. A minor gap remains: it does not clarify that this is an availability read with no hold placed, which matters before an agent calls create_reservation.

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%, with every parameter documented in the schema, including cross-references to get_route_detail and list_tariffs. The description adds no parameter-level meaning, 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?

Uses a specific verb (get) and resource (free seats) with an explicit scope: per vehicle offering the given seat class, per route section. This is clearly distinguishable from siblings like get_route_detail (which supplies the inputs) and list_seat_classes (which enumerates class keys).

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 itself never says when to call this versus alternatives or what prerequisite flow applies. The ordering hint exists only implicitly via the schema note that sections come from get_route_detail and seat_class comes from price_classes, so usage is inferred rather than stated.

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?

Beyond the readOnlyHint annotation, the description provides rich behavioral context by listing the specific data fields returned ('state, seats, price, unpaid amount, cancel conditions'). This informs the agent about the successful response structure.

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 definition is highly concise and front-loads the core function and scope in a single, powerful sentence with no unnecessary fluff.

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

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

For a lookup tool, the definition is reasonably complete as it specifies the key information returned (price, state, etc.). It is adequate for the task but doesn't specify how optional parameters like `lang` influence the data beyond existence.

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

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

The schema coverage is moderate (67%), meaning there is room for improvement. However, since the description adds no specific meaning or constraints to the parameters (`ticket_id`, `lang`, `currency`), it receives the baseline score.

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 action ('Get one ticket') and the scope ('of the logged-in account'). While it doesn't explicitly state it requires a specific ID, the combination of the name and description is specific and distinct from listing tickets.

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 usage by focusing on the retrieved data, but it does not explicitly guide the agent on when to choose this over similar sibling tools like `list_my_tickets` or `get_ticket`.

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 and openWorldHint=true, so the safety profile is covered. The description adds the shape of what comes back (sections with platforms/transfers plus per-seat-class pricing), which is useful context, but it omits that prices depend on the tariffs/currency parameters and says nothing about failures when a route has no through-fare.

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 resource front-loaded and no filler; every clause (sections, vehicle types, platforms, transfers, per-seat-class pricing) contributes 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?

Six parameters, three required, with an output schema and annotations already supplied, so return values and safety needn't be in the description. Still, for a pricing/segment tool the description should note that tariffs and currency alter the price output and that station-level (not city-level) ids are mandatory, both of which it leaves 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%, including enum values for lang, currency, the tariffs list format, and the explicit 'station, not city' warnings on the station ids. The description adds nothing about parameters, so the schema carries the whole burden and 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 ('Get') and resource ('route's sections') plus the content returned: trains/buses, lines, platforms, transfers, and price per seat class. This is clearly distinct from search_routes (which finds routes) and get_ticket (which returns a purchased ticket), 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?

No when-to-use or when-not-to-use guidance, and no stated prerequisite that route_id/from_station_id/to_station_id must first come from search_routes. Only the input schema hints at that dependency; the description itself gives the agent nothing about choosing between this and get_ticket or search_routes.

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 establish a non-mutating, open-world read. The description adds that the ticket must already exist and is retrieved by two keys, but provides no further context about access requirements, missing tickets, or other runtime behavior.

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

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

The single sentence is direct, front-loaded, and free of filler. Its brevity is appropriate for a simple keyed retrieval operation.

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 input schema, annotations, and output schema supply most of the details needed to invoke this simple read correctly. The principal gap is sibling-selection guidance, especially differentiation from get_my_ticket and list_my_tickets.

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

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

The description reinforces that account_code and ticket_id jointly identify the ticket, offering modest context for the otherwise undescribed ticket_id. The schema already documents account_code, lang, and currency, and the description adds no identifier sourcing or formatting details.

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 and identifies the two lookup keys: account code and ticket id. It does not explicitly distinguish this operation from the closely related get_my_ticket or list_my_tickets siblings.

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?

Mentioning an existing ticket and both identifiers implies the intended lookup situation, but there is no explicit when-to-use guidance. In particular, it does not explain when get_my_ticket or list_my_tickets would be preferable.

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 and openWorldHint: true, so the safety profile is covered, but the description adds nothing beyond them. It does not mention that results default to active-only filtering, whether results are paginated, or that the tool reaches an external/remote source — all behavior an agent would benefit from knowing.

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 certainly concise and front-loaded, but at seven words it is under-specified rather than efficient; the terseness is the problem, not verbosity.

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

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

An output schema exists, so return values need not be explained, but for an open-world, default-filtered listing tool the description leaves out the filtering behavior and the language behavior. Given a 2-parameter schema with one undocumented parameter, the definition is too thin to support confident invocation.

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

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

Schema coverage is only 50%: lang is documented in the schema, but active_only has no description anywhere. The description does not compensate — neither parameter is mentioned, and the default-true active-only filter, which materially changes results, goes completely unexplained.

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 verb ("List") and a resource ("marketing actions / promo prices"), so the general intent is inferable. However, "action prices" is ambiguous and the slash-separated phrasing leaves unclear whether this returns marketing campaigns, promotional fares, or price records. It also does nothing to distinguish itself from the sibling list_tariffs.

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

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

There is no guidance on when to use this tool, no exclusions, and no mention of the obvious alternative list_tariffs, which an agent would plausibly confuse it with given the overlapping price/tariff vocabulary. The agent must guess from the name alone.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that: no indication of whether the list is static reference data, whether it is paginated or filtered, or how carriers relate to the connections mentioned. For a simple read this is tolerable but it is pure restatement.

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 short sentence with the resource front-loaded and no wasted wording. It is efficient, though its brevity borders on under-specification rather than disciplined concision.

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

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

An output schema exists, so return values need not be explained, and annotations cover the safety profile. However, for a discovery tool the description leaves open whether carriers are a fixed reference set and how they map onto routes, which is the main thing an agent would want before calling 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?

There is a single optional 'lang' parameter with 100% schema description coverage and an inline enum, so the schema fully documents it. The description mentions no parameter behavior at all, which is acceptable given the high coverage but adds no meaning beyond the schema baseline.

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

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

The description gives a specific verb and resource ('List carriers') plus a scope qualifier ('operating RegioJet connections'), so an agent knows exactly what is returned. It does not explicitly differentiate itself from the sibling list_* tools, but the resource noun is distinct enough that confusion is unlikely.

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

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

Usage is only implied: the description makes clear this is a reference enumeration of carriers, which an agent can infer is for discovering available carriers. There is no explicit when-to-use, no prerequisites, and no mention of alternatives such as search_routes when the real goal is route planning.

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?

Beyond readOnlyHint and openWorldHint, the description discloses account-scoped results and newest-first ordering, while "logged-in account" also implies an authentication prerequisite. It adds no detail about pagination behavior, empty results, or authentication failures, so the additional behavioral context is useful but limited.

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

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

One compact sentence front-loads the operation and account scope, then adds the useful ordering guarantee. There is no filler or redundant wording.

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 read-only tool with no required parameters and an output schema, the account scope, ordering, and schema-defined filters are nearly sufficient for correct selection and invocation. Explicit single-ticket alternatives and a brief explanation of limit/offset pagination would address the main remaining 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?

The description provides no parameter-specific guidance; lang, states, and currency are documented in the schema, while limit and offset rely on their intuitive names, defaults, and bounds. With 60% schema coverage and simple optional parameters, this is adequate but does not compensate for the undocumented pagination fields.

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 verb "List," the resources "tickets and reservations," the logged-in account scope, and the newest-first ordering make the operation clear. It does not explicitly distinguish this collection listing from get_my_ticket or get_ticket for retrieving a single ticket or its details.

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 wording implies use when retrieving the current user's tickets and reservations rather than searching routes, locations, or other catalog data. There is no explicit when-not guidance or direction to get_my_ticket/get_ticket when the agent already has a ticket identifier or needs full details.

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 and openWorldHint=true, so the safety profile is covered. The description adds the useful detail that results include human-readable descriptions of each class, but says nothing about ordering, scoping (global vs per route/carrier), or localization behavior.

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

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

A single tight sentence with the resource front-loaded and no filler. It could be marginally sharper by noting the scope of the list, but nothing is wasted.

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 enumeration tool with an output schema and complete parameter documentation, the description covers what the tool returns and its examples. The main residual gap is whether seat classes are global or contextual to a route/carrier.

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

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

Schema coverage is 100% and the single optional 'lang' parameter is fully documented in the schema itself. The description adds no meaning beyond that, 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?

States a specific verb and resource ('List seat classes') and enumerates concrete examples ('Low cost, Standard, Relax, Business, ...') plus the fact that descriptions are returned. This clearly separates it from siblings like list_tariffs or list_carriers, though it never names those alternatives 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?

There is no when-to-use guidance, no mention of prerequisites, and no reference to alternatives such as list_tariffs or get_free_seats. An agent must infer that this is a reference-data lookup used before browsing fares or 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 readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds only that entries carry a `key`, without mentioning whether the tariff catalog is static or remote, how large it is, or whether the language setting affects keys. With annotations and an output schema present, this modest addition is adequate but thin.

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 short and front-loaded, which is good, but the second sentence is ambiguous: `key` is not a parameter here, so the instruction reads as a dangling reference. Two sentences is the right size, but one of them is not earning its place as written.

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

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

An output schema exists, so return values need no explanation, and the single parameter is fully documented in the schema. However, for a catalog-listing tool in a large sibling set, the definition never clarifies how the returned keys feed into other tools or whether the list is exhaustive/stable across calls.

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

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

There is a single optional parameter with 100% schema description coverage, so the schema already explains `lang` and its default. The description adds nothing about the parameter and instead introduces a `key` reference that is not an input of this tool, which is mildly confusing rather than informative.

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 and resource ("List passenger tariffs") and enumerates the categories returned (adult, child, student, senior), which separates it from siblings such as list_action_prices and list_seat_classes. It is clear what the tool returns, though it does not explicitly name the siblings it is distinct from.

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

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

"Use `key` in tariffs arguments" implies a workflow — call this first to obtain keys consumed by other tools — but the guidance is cryptic and never states when this tool should be preferred over the other list_* siblings. Usage is implied 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 declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe read against an open dataset. The description adds the useful detail that each entry comes with a description, but says nothing about whether the list is paginated, how it relates to vehicles/routes, or whether the labels are locale-dependent.

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

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

A single front-loaded sentence with no filler, and the inline examples are the most valuable part of it. It is arguably under-specified rather than verbose, but nothing is wasted.

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?

Because an output schema exists, return values need not be described, and the annotations cover the safety profile. Still, the domain role of 'vehicle standards' — whether these are ticket types, fare categories, or vehicle attributes — is left unexplained, which is the main gap for a tool this simple.

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

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

There is a single optional parameter (lang) with 100% schema description coverage, so the schema already carries its meaning. The description contributes nothing about language behavior, which is the baseline-3 case when the schema does the work.

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

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

The description names a specific verb and resource ('List vehicle standards') and anchors it with concrete example values (YELLOW, FUN_AND_RELAX), so an agent knows exactly what it enumerates. It doesn't differentiate itself from the sibling list_* tools, but since those cover different resources (tariffs, seat classes, carriers) the resource name already distinguishes it.

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

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

There is no explicit when-to-use statement and no mention of alternatives, so usage is only implied: call this to resolve standard codes into their descriptions. An agent can infer it is the lookup for values seen elsewhere, but the description never says so.

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 flag destructiveHint=true and openWorldHint=true, but the description adds the material consequence — "Spends real money" — plus a mandatory user-confirmation step, which is behavior an agent cannot read off the hints. It does not cover partial-batch failure or insufficient-balance handling.

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: the action and its funding source first, then the safety warning. Nothing is wasted and the most important risk is front-loaded within the second clause.

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

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

An output schema exists, so return values need no explanation, and the description covers the essentials for a money-spending mutation: funding source, eligibility, and confirmation. It omits failure modes (insufficient credit, partially paid batches) that matter for a destructive batch operation.

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, including the create_reservation provenance of ticket_ids. The description only reinforces that ids must be UNPAID; baseline 3 applies where 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?

"Pay UNPAID tickets from the account's RegioJet credit" gives a specific verb (pay), resource (tickets) and funding source (account credit), which separates it from create_reservation and cancel_ticket. It does not name any sibling explicitly, so an agent must infer the boundary itself.

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 the entry condition (tickets must be UNPAID) and a procedural requirement (confirm with the user first), and the schema pins ticket ids to create_reservation output. It stops short of explicit exclusions, e.g. what to do for already-paid tickets or when credit is insufficient.

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 and openWorldHint=true, so safety and external-data traits are covered. The description adds that results are route ids rather than full route objects, which meaningfully shapes agent behavior, but it says nothing about pagination, result volume, or that tariffs/currency affect returned price 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?

Two sentences, front-loaded with the operation and immediately followed by the return-value/chaining hint; nothing is redundant. It is efficient but leans terse given the tool's 10 parameters.

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

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

With an output schema present, return-shape detail is not required, and the annotations cover the read-only profile. Still, for a 10-parameter search with cursor pagination, tariff lists and currency options, the description omits enough that an agent must fall back entirely on the schema to call it well.

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 80%, so the schema already documents lang, page, cursor, tariffs, currency and departure_date defaults. The description only restates that two locations and a date are involved, adding no new semantics such as how from_type/to_type interact or how cursor paging is used.

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 ('Search RegioJet connections between two locations on a date') and names the follow-up sibling get_route_detail, so an agent knows this is the entry point to a route lookup. It stops short of distinguishing itself from find_locations or get_free_seats, but the core purpose is unambiguous.

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

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

The clause 'Returns route ids for get_route_detail' implies the intended workflow and sequencing, which is useful guidance. However, there is no explicit statement of when to prefer this over alternatives, no prerequisites (e.g. ids must come from find_locations), and no exclusions.

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