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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuine behavioral value by warning that live boards can be unavailable independently of schedules, but says nothing about how failure is surfaced, rate limits, or freshness of the 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 short sentences, zero filler, with the core action and its scope front-loaded. Every clause carries information the agent cannot get from the structured fields.

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 described, and the availability caveat is useful. But for a tool with four required parameters at 0% schema coverage and no explanation of the stationId/stationName pairing, the description leaves a real invocation 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?

Schema description coverage is 0% and the description names none of the four required parameters. The unusual requirement of both stationId and stationName — and where to obtain them (e.g. search_train_locations) — is undocumented, so an agent gets no help resolving these inputs.

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 an operator station board') plus a scope nuance (observation timestamp). It is distinguishable from get_train_status and search_train_journeys by being station-level rather than train- or journey-level, though it never says so 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?

The sentence 'Live boards may be unavailable independently of schedules' implies this tool covers live station boards and is separate from schedule queries, which hints at usage. However, no sibling is named and there is no explicit when-to-use/when-not-to-use guidance despite six related tools.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so safety is covered; the description adds a genuinely useful behavioral caveat that live status data may be missing regardless of schedule availability — important for an agent deciding whether to retry or fall back. It does not mention auth, rate limits, or refresh 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 short sentences, front-loaded with the action and inputs, with no filler. The second sentence earns its place as a real caveat rather than padding.

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-value explanation is not required, and annotations cover the safety profile. What remains missing is input format guidance (date and origin identifier conventions) and the expected behavior/response when live status is unavailable — a notable gap for a 4-parameter, zero-coverage 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 0% across four required parameters. The description only restates the parameter names in prose ("operator, train number, service date, and origin identity") and adds no format guidance for serviceDate, trainNumber, or origin, and does not mention the trenitalia/italo enum restriction. "Origin identity" vaguely implies an identifier but leaves the code-vs-name question open.

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 ("Get live status") and enumerates the identifying inputs, which clearly separates it from the search_* siblings that return schedules rather than live state. It stops short of naming an alternative tool outright, but the retrieved artifact 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?

Usage is only implied: the phrase "Live status may be unavailable independently of schedules" hints that schedules are a separate concern, but the description never says when to prefer this over search_train_journeys or get_station_board, nor what to do when status is unavailable. No exclusions or prerequisites are given.

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=true, so the safety profile is fully covered by structured data. The description adds only the modal exclusivity rule, which is really routing guidance, and says nothing about what "status" entails or any auth/config prerequisites. Adequate against the lower bar set by annotations, but no extra behavioral value.

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, zero filler, with the most important constraint ("BUS ONLY") front-loaded in capitals. Nothing could be removed without losing routing 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 parameters, full annotation coverage and an output schema covering return values, the description supplies nearly everything an agent needs. The only small gap is that "status" is never characterized, though the output schema plausibly covers it.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The description correctly implies a no-argument enumeration by saying "list configured ... providers".

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 configured bus/coach providers and their status") and immediately constrains domain with "BUS ONLY". It explicitly separates itself from list_train_providers, so an agent can distinguish it from siblings without reading any 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 an explicit prohibition ("Never use this tool for trains or rail") and names the correct alternative (list_train_providers). Both the when and the when-not are stated with no inference required.

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, non-destructive and openWorld, so the safety profile is covered. The description adds value by disclosing that results are operators annotated with capability flags rather than raw schedule data — useful framing that keeps the agent from expecting journey results.

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 the domain restriction front-loaded, which is the right ordering. There is mild redundancy between "TRAINS ONLY" and "requests involving trains or rail", but nothing that wastes real reading effort.

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 zero parameters, rich annotations, and an output schema handling return values, the description is nearly complete. The only substantive gap is that it never distinguishes this provider-listing call from search_train_journeys or get_train_status, which matters given seven siblings.

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 tool takes zero parameters, which is the baseline-4 case; there is nothing the description could clarify about inputs. Schema description coverage is 100% and there are no required or enum parameters to disambiguate.

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 ("Lists train operators") plus the payload content (capability enablement for schedule, price, live-status, station-board). The "TRAINS ONLY" qualifier separates it from the sibling list_providers, which presumably spans other transport modes.

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 for requests involving trains or rail" gives a domain-level routing cue but no when-not and no alternatives. An agent asking for an actual itinerary could still plausibly land here instead of search_train_journeys or get_train_status, since neither sibling is named or excluded.

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, openWorld), so the bar is low, and the description still adds real context: results contain official provider links meaning the agent cannot complete a booking here and the user must continue manually on provider sites. It does not mention pagination truncation via limit (max 50) or provider-mixing behavior, which would have pushed this higher.

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 with the hard constraint ('BUS ONLY') front-loaded, then purpose, then the sibling redirect, then an output caveat. No filler and nothing buried.

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 described, and the safety profile is in annotations. The one meaningful gap for a 7-parameter search tool is that it never says origin/destination require exact shared location names that must first be obtained via search_locations or list_providers.

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 57%, so the baseline is around 3; the description only contributes the 'one-way' framing, which implicitly tells the agent no return date/round-trip parameter exists. It adds nothing about provider scoping, passenger counts, or limit truncation beyond what the schema already says.

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 one-way bus/coach journeys') and immediately bounds scope with 'BUS ONLY'. It names the sibling it is not (search_train_journeys), so an agent can route correctly without opening either 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 an explicit exclusion ('Never use for trains or rail') plus the concrete alternative to use instead, which is exactly the guidance that distinguishes it from the train siblings. It stops short of telling the agent how to resolve origin/destination names (search_locations / list_providers) before calling.

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, openWorld, non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: the bus-only domain boundary and the downstream convention that exact names are shared across providers for aggregation, though it says nothing about result-set size or the 50-item cap.

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, each earning its place: scope, exclusion with alternative, and a workflow tip. The most decision-critical constraint (BUS ONLY) 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?

With an output schema present, return values need no explanation, and the annotations carry the safety profile. The routing guidance and aggregation tip make it nearly complete; only the limit/pagination behavior is left unaddressed.

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 documents query, provider, and limit reasonably. The description adds only an implicit note that omitting provider searches everything (via the aggregate-search hint) and emphasizes 'exact names', but never addresses the limit parameter or partial-match semantics beyond what the schema states.

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 ('Find bus/coach location IDs and exact names') and immediately scopes it with 'BUS ONLY', which separates it cleanly from the train siblings listed.

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 an explicit exclusion ('Never use for train stations') and names the correct alternative, search_train_locations, plus a positive hint about reusing exact names for aggregate bus searches, covering both when and when-not.

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, open-world, non-destructive. The description adds genuinely non-obvious behavior: prices are totals for the whole passenger set and must not be divided per person or discounted. It omits other traits (date format expectations, what truncation/empty results mean), 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?

Three short sentences; the hard constraint 'TRAINS ONLY' is front-loaded, followed by prerequisites and then the pricing rule. No filler and nothing is buried.

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 needn't be explained, and the price semantics are a good addition. But for an 8-parameter search tool the description leaves the provider enum and the date string format unaddressed, which are things an agent could get wrong when 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?

Schema description coverage is only 38% across 8 params, so the description should compensate more. It does clarify the three required params and reinforces the adults/children 'pass explicitly' semantics already in the schema, but says nothing about provider, limit, or date format, leaving several parameters undocumented anywhere.

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 combination of 'TRAINS ONLY' and the required origin/destination/date makes it clear this searches rail journeys between two points, and 'TRAINS ONLY' implicitly contrasts it with the broader search_journeys sibling. The verb 'search' itself is only implied (it comes from the title), so it sits just below a full 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 gives prerequisites (origin, destination, date) and a conditional rule for passenger counts, which is real usage guidance. However, it never names search_journeys or search_train_locations as alternatives, nor states when NOT to use this tool, so an agent must infer routing from the sibling 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 establish read-only, idempotent, open-world, non-destructive behavior. The description adds useful domain context that station IDs are operator-specific and names should be preferred across operators, but it says nothing about result ordering, pagination, or limit 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 description is very short and front-loaded, with the most important domain restriction first and operator-specific ID guidance last. No sentence 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?

An output schema and rich annotations reduce the need to explain returns and safety, but the description still leaves key parameter semantics unexplained and gives overbroad usage guidance. It is adequate for a simple search tool but not fully complete.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It gives partial query guidance (prefer names, IDs are operator-specific), but never explains the provider enum, limit default/max, or query syntax.

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?

"TRAINS ONLY" and "find operator-aware stations" identify a rail-specific station lookup, distinguishing it from generic location search and from journey/status siblings. The purpose is clear, though the verb is less explicit than an ideal "search train stations" statement.

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 for every request involving trains or rail" is overbroad and could misroute agents toward this tool for journey searches or train status. It provides no exclusion or explicit alternative routing, even though siblings like search_train_journeys and get_train_status exist.

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