Retrieve every stop, operating days, and current location for a specific bus trip by passing a trip_id from bus departures or live vehicle results.
Every stop one bus journey calls at, the days it runs, and where the bus is
now if it is running. Take trip_id from bus_departures or live_buses.
| Name | Required | Description | Default |
|---|---|---|---|
| trip_id | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v0.1.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds genuine behavioral detail beyond that: the current location is only returned 'if it is running,' which tells the agent to expect a nullable/conditional field. It does not mention rate limits, auth, or pagination.
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 with no filler. The payload description (what you get back) is front-loaded, and the sourcing instruction for the parameter follows immediately.
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 enumerated. Given the single-parameter, read-only nature of the tool, the description covers what is returned and where to get the input; only identifier formatting and the not-running edge case are left implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and there is one parameter, so the description carries the burden of explaining trip_id. It does add real value by telling the agent where to obtain the ID, but gives no format, example, or constraint on the identifier itself.
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 the returned resource concretely: every stop on a bus journey, its running days, and the current vehicle position. It implicitly distinguishes itself from siblings by naming bus_departures and live_buses as the sources of the trip_id rather than as competing lookups, though it never states the retrieval verb directly (e.g. 'get the full service for a trip').
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 a clear actionable context: 'Take trip_id from bus_departures or live_buses,' which routes the agent to the prerequisite tools and therefore implies when this tool is appropriate. It does not state exclusions or what to do if the trip is not running beyond the conditional phrasing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.