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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description's main added value is the note that the upstream JSON needs no API key and that fresh calls are limited in the hub store. That is real context beyond the annotations, but it is phrased vaguely (how limited? cached how long?) and one sentence ("The MIT file covers the software") is licensing trivia with no operational value. Return shape and staleness behavior remain undisclosed.

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 purpose is front-loaded in the first sentence, which is good. But the remaining sentences include cryptic or low-value material — "The project README, read on 2026-11-08, offers that JSON with no key" and "The MIT file covers the software" — that dilute the useful limits and safety notes.

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?

For a zero-parameter, read-only tool with no output schema and annotation coverage, the description covers safety and auth adequately. It does not describe what a returned "capacity route" contains or how many/which three are chosen, which an agent would want to interpret results.

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 the baseline is 4. The description reinforces this by stating it does not accept a URL, which usefully rules out a URL argument an agent might otherwise try to pass.

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 a specific verb and resource: read up to three current BC Ferries capacity routes from bcferriesapi.ca. The resource (ferry capacity) is distinct enough from siblings like hub_airport, hub_rail-board and hub_transit that an agent can route correctly without opening the schema. It does not explicitly contrast itself with those siblings, which keeps it out of 5 territory.

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 supplies exclusions ("does not sell a ticket", "does not spend points", "does not accept a URL") that help rule out booking or points-based siblings. However, it never states a positive when-to-use condition or names an alternative tool, so the agent must infer the trigger scenario itself.

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