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 declare readOnly, idempotent, openWorld and non-destructive, so the safety bar is met without prose. The description adds genuine non-schema behavior: results carry official provider links for manual continuation, and snapshot:true is required for stable pagination. It does not mention rate limits or result ordering, which keeps 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?

Four short sentences, zero filler, with the mode restriction front-loaded and the alternative and pagination protocol following in priority order. Every clause carries operational 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 10 parameters, partial schema coverage and an output schema that already documents return values, the description supplies exactly the missing operational pieces: the snapshot/searchId pagination protocol and the manual-continuation nature of results. Passenger and date parameter handling is left implicit, a minor gap for a zero-required-parameter 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 only 50%, so the description must compensate—and it does for the trickiest fields: snapshot:true semantics and the constraint that continuation pages use only searchId, offset and limit (not the original search criteria). adults, children and the limit maximum are left to the schema, so not full marks.

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?

"BUS ONLY. Search one-way bus/coach journeys" gives a specific verb plus resource and an explicit transport-mode scope. It also names the sibling it must not be confused with (search_train_journeys), so an agent can discriminate it without opening 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?

Explicit negative guidance ("Never use for trains or rail; use search_train_journeys instead") plus a positive workflow rule for pagination (start with snapshot:true, then continue using only searchId, offset and limit). Both when-to-use and when-not-to-use are 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?

Annotations already declare readOnly, idempotent and openWorld, so the safety profile is covered; the description's real contribution is the hard domain boundary (bus only) and the cross-provider name-matching tip. It says nothing, however, about result volume, truncation behavior, or how provider scoping affects results — details an open-world search tool would benefit from.

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, zero filler, with the most decisive constraint ('BUS ONLY') front-loaded. The exclusion and the alternative arrive before any optional 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?

With an output schema present and rich annotations, the description only needs to convey scope and routing, which it does fully. It lacks only minor operational detail (e.g. what a returned location ID looks like, how provider filtering changes the result set) to be airtight for a 4-parameter search tool.

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

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

Schema coverage is 75% and the schema already describes query as a partial name and offset as truncation-driven pagination. The description does not explain the provider or limit parameters, 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?

States a specific verb and resource ('Find bus/coach location IDs and exact names') and immediately scopes it with 'BUS ONLY', making it distinguishable from the train siblings at a glance. The output artifact (location IDs and exact names) is named, not just the action.

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 the exclusion ('Never use for train stations') and routes the agent to the correct alternative (search_train_locations). It also adds a positive usage rule for the aggregate case ('reuse exact names shared across providers'), so both when-to-use and when-not-to-use are covered.

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, so the bar is lower, yet the description adds real domain behavior: each price is the total for the passenger set and must not be inferred as per-person or discounted. The snapshot/searchId continuation protocol is also a meaningful behavioral disclosure absent from 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?

Four tight sentences, front-loaded with the 'TRAINS ONLY' constraint and the required inputs, followed by the two highest-risk pitfalls (passenger counts and price interpretation) and the pagination recipe. 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?

An output schema exists, so return values needn't be described, and the pagination contract is fully specified. Remaining gaps are minor: no mention of provider selection (trenitalia vs italo) or expected date format, which an agent would need to guess for a 10-parameter open-world search.

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 only 30% schema coverage, the description carries weight and does so for the least obvious parameters: it explains adults/children semantics and how snapshot, searchId, offset, and limit interact for pagination. It adds nothing about provider (the one enum), date format, or origin/destination resolution, leaving some gaps.

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 'TRAINS ONLY' and names the required inputs (origin, destination, date), making it clear this is a rail-journey search rather than the generic sibling search_journeys. It stops short of explicitly naming that sibling, so the differentiation is implied rather than stated.

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 operative guidance: pass adults/children explicitly when the user states counts, and use snapshot:true first for stable pagination then continue with only searchId/offset/limit. It doesn't state when to prefer this tool over search_journeys or list_providers, so it falls short of full when/when-not coverage.

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), so the description earns credit for adding a real gotcha: station IDs are operator-specific while names span operators. That is a substantive behavioral fact an agent would otherwise learn only by failure. It does not mention result size or pagination behaviour.

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 scope constraint front-loaded in caps, so an agent reads the key discriminator first. Terse enough that the missing parameter guidance is an omission rather than clutter.

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 read-only nature removes mutation concerns. Against 4 parameters with 0% schema coverage, however, the description leaves pagination and provider filtering entirely to inference, which is a meaningful gap for a search tool.

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

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

Schema description coverage is 0%, so the description carries the full burden. It partially compensates for the query parameter by steering toward station names and warning that IDs are operator-specific, but limit, offset, and the provider enum receive no explanation at all, and the pagination parameters are never mentioned.

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 ('find operator-aware stations') with an emphasised scope marker ('TRAINS ONLY') that separates it from the generic search_locations sibling. It stops short of naming that sibling explicitly, so the differentiation is implied rather than spelled out.

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' gives a clear selection rule, and 'TRAINS ONLY' implicitly excludes non-rail lookups. The caveat about station IDs being operator-specific is actionable, but no alternative tool is named for the non-train case.

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