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

The annotations already establish that the tool is read-only, idempotent, and open-world. The description adds behavior the annotations do not cover: the data is unverified and unofficial, it must be attributed with a time stamp, and it must never replace official information or timetables. One minor gap remains: the description does not state whether results are paginated, ordered, or empty when no reports match.

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 front-loaded with the purpose and then lists the arguments clearly. The closing instruction about not adding routes, hours, or phone numbers from memory repeats the earlier caveat about unofficial information, so it takes up space that could be trimmed, but the repetition does reinforce an important constraint.

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?

No output schema exists, yet the description lists the kinds of content returned (delays, crowding, broken elevators, tips) and the freshness dimensions, which is nearly sufficient for a three-parameter tool with no required arguments. It could still say more about result ordering or volume.

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 has to carry the full burden of explaining the parameters, and it does: station is 'matched loosely', line examples are given ('Red Line', 'D80', 'MARC'), and days is described with a default of 2 and a maximum of 30. These details go beyond the bare types in the schema, though the matching syntax for station is still vague.

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 both the action and the resource, and it also describes the data source as 'crowdsourced on this site'. It clearly signals that this tool covers unofficial rider observations rather than agency alerts, so an agent can distinguish it from siblings such as get_service_alerts or get_station_info.

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 gives strong context: it says to present results as 'riders reported ...', to include how long ago each report came in, and never to let these reports replace the timetable or official alerts. It does not name which sibling tool to use for official alerts, but the restriction it states clearly points an agent to the official tool for authoritative information.

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