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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact beyond that, namely that a match does not imply public access or live availability, but it says nothing about result caps, pagination, or what an empty match means. The other sentences ('Put tool fields inside inputs', 'Do not pass the REST calculator field inside MCP arguments') are harness hygiene, not 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?

It is short and the purpose sentence is front-loaded, which is good. But four of the five sentences are reusable boilerplate about following inputSchema and not passing REST fields, so a large share of the text does not earn its place in a tool-selection decision.

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, but the input side is a nested object with enums and numeric bounds and gets no explanation at all. For a geographic station search that can be filtered by fuel type, connector, radius, hours and free-text query, the definition leaves the agent to reverse-engineer every meaningful choice from the raw 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% on a nested object with roughly ten properties, and the description compensates almost nothing: it never explains state (required), fuel codes like BD/CNG/E85/ELEC, connector enums, hours, radiusMiles, or limit. Worse, it tells the agent to 'supply units or modelVersion only when listed in inputSchema' while no 'units' field exists in the schema, which can send the agent looking for a nonexistent parameter. The only real contribution, that fields belong inside the nested 'inputs' object, is thin for this level of schema complexity.

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 first sentence gives a specific verb and resource: 'Search the BusCalc station reference index.' The title ('Alternative fuel and charging stops') supplies the domain, so the pairing is unambiguous, but the description itself never states what is being searched for (fuel/charging stations) nor names a sibling such as buscalc_map_marker_lookup or buscalc_map_nearby_landmarks to differentiate scope.

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?

There is no guidance on when to choose this tool over the map siblings or what inputs trigger a useful result. The closest thing to guidance, 'A match does not establish public access or live availability,' is a caveat about result meaning, not a when-to-use rule, and the remaining sentences are generic calling conventions rather than selection criteria.

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