Tokyo Charter Bus

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

The annotations already declare that this is a non-read-only, open-world, non-idempotent, potentially destructive operation. The description adds useful behavioral context: the request is sent to staff, a request reference is returned, the user must explicitly confirm and consent, and the action does not book or reserve a vehicle.

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 three tight sentences with no wasted wording. The core action is front-loaded, followed immediately by the critical confirmation prerequisites and the non-booking clarification.

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 complex tool with 30 parameters, nested objects, low schema description coverage, and no output schema. The description covers the purpose and confirmation requirements well, but it does not provide enough detail about the many input fields for an agent to use the tool confidently without relying heavily on incomplete schema descriptions.

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 only explains the two consent/confirmation flags, while the schema has 30 parameters and just 40% description coverage. Many important parameters, including days, vehicle_type, add_ons, dates, prefectures, and idempotency_key, receive no additional semantic guidance in the description.

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

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

The description states a specific verb and resource: it sends a charter quote request to Tokyo Charter Bus staff and returns a request reference. It also distinguishes the action from booking or reserving a vehicle, so an agent can understand the tool's role 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?

It gives explicit preconditions: call only after the user has reviewed the details, explicitly confirmed sending them, and agreed to the privacy policy, with user_confirmed and privacy_consent set to true. It also clarifies that this does not book or reserve a vehicle, though it does not explicitly point to sibling tools such as estimate_charter_bus_price or get_quote_status.

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 annotations, the description discloses the fare model components (billable hours including roll-call, billable km including empty running, night hours, relief-driver flags). It also states the conditional return behavior and clearly warns that the result is never a confirmed price, which is important behavioral context not covered by the annotations.

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

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

The description is two dense but well-structured sentences, front-loading the calculation purpose and then the return conditions. Every phrase contributes useful information without unnecessary repetition.

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

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

For a fare-estimation tool with no output schema, the description sufficiently explains the calculation basis, output type, and conditional 'quote_required' status. The main remaining gap is that it does not explicitly route the agent to create_quote_request when a quote is required, though the status name strongly hints at that next step.

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 input schema already explains vehicle_id, days, vehicles, and locale. The description adds fare-system context around billable hours and kilometers, but does not add parameter-specific meaning beyond what the schema provides; baseline 3 is appropriate.

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

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

The description clearly states a specific verb and resource: it calculates charter bus fare structure under Japan's time + distance system. It distinguishes the output as a reference estimate rather than a confirmed price, but does not explicitly name or contrast with sibling tools such as create_quote_request.

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

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

The description implies when the tool is usable by saying it returns a yen estimate only when the rate table is verified and all routing inputs are present, otherwise 'quote_required'. It does not explicitly say when to use this tool versus create_quote_request or get_quote_status, leaving the alternative path 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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description only needs to add context beyond that. It does so usefully by disclosing that the e-mail acts as a verification credential paired with the reference and that contact details are omitted from the response, which is a privacy trait not present in the structured fields.

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 what the tool returns before the prerequisites and the privacy caveat. No redundant restatement of the title 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 bears some responsibility for describing the return value. It says only what is not returned (no contact details) and never indicates what the status actually looks like or what states are possible, which is a meaningful gap for a status-lookup 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 67% and the description fills the main gap: the 'email' property has no schema description, and the description clarifies it must be the address used for the original request, i.e., a matching credential rather than an arbitrary value. The optional 'locale' parameter is left to the schema, which documents it adequately.

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: returns the status of an existing quote request. The word 'existing' implicitly separates it from the create_quote_request sibling, though no sibling is named explicitly, so differentiation is left partly to inference.

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 context of use is clear: look up the state of a request that has already been submitted, and the description states the two prerequisites (reference plus the e-mail used for the request). It does not name alternative tools or say what to do when the caller lacks the reference, but no real alternative exists among the siblings.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds modestly useful context beyond that — that distances and drive times are approximate and that 'only areas actually served are listed' — but says nothing about freshness, pagination, or how locale affects the payload.

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 verb and subject are front-loaded before the long parenthetical destination list, which is dense but genuinely aids matching against user requests. The trailing sentence about only-served areas earns its place as a data-completeness caveat, though the enumeration could be trimmed.

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-parameter, read-only lookup with no output schema, the description adequately conveys the scope and shape of the return value (facts, approximate distance, drive time, page link). Only the when-to-call-it guidance is thin.

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 whose schema description coverage is 100% and which already enumerates the accepted locale values and the default. The description never mentions locale or its effect on returned names, so it adds no meaning 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?

The description gives a specific verb and resource ('Returns the areas served from Tokyo') and enumerates the actual content, so an agent knows exactly what data comes back. It does not explicitly contrast itself with siblings, but the sibling set (quote requests, price estimates, bus options) is functionally 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?

Use is only implied: the tool is a discovery/catalog lookup an agent would call to learn which destinations are available. There is no explicit when-to-use statement, no mention of when to prefer list_charter_bus_options or estimate_charter_bus_price instead, and no stated preconditions.

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 as a read-only, idempotent, non-destructive, closed-world operation, and the description earns credit beyond that: it discloses the 6-passenger cap and hire-car licence conditions for the Alphard, the rule that add-on cars require a coach booking, and the exact scope of the fixed_prices (JPY, tax included, 2 h in Tokyo, airport transfers, day trips). It stops short of covering availability, seasonality, or what "verification status" means operationally.

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 purpose is front-loaded, but the body is a single dense run-on paragraph with stacked parentheticals (licence terms, regional scope, pricing scope) that makes it harder to scan than a short bulleted breakdown. Most sentences carry real information, but the packaging is 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 carries the return-value burden and does so reasonably, naming passenger seats, auxiliary seats, luggage information, verification status, and the fixed_prices block. It is nearly complete for a zero-required-parameter catalogue call; the remaining gaps are the meaning of verification status and whether the catalogue can be empty.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds meaning by tying the passenger and suitcase counts together into a "recommended combination" use case, and by clarifying that returned seat counts exclude the driver and that auxiliary (fold-down) seats can be excluded from counts. This goes beyond restating the schema field descriptions.

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

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

The description uses a specific verb-plus-resource ("Lists bus and coach types available for chartered group transport") and enumerates the exact catalogue contents: charter coaches, minibuses, the 7-seat Alphard, and add-on cars. It does not explicitly route the reader away from the sibling estimate_charter_bus_price, even though it also returns prices, so the boundary between the two is left to inference.

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: the passengers/carry_on_bags/large_suitcases parameters are flagged as triggering an optional recommendation, and "quote these exactly" is an instruction on handling the returned fixed_prices. There is no explicit when-to-use/when-not guidance and no mention of when to prefer create_quote_request or estimate_charter_bus_price instead.

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