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

Annotations already provide readOnlyHint, openWorldHint, and idempotentHint, covering safety and idempotency. The description adds behavioral context beyond annotations: it discloses that includeComments returns all comments unpaged and can produce a large response, explicitly warning about payload size and recommending the paginated alternative. This extra disclosure of a non-obvious behavior (unpaged, potentially huge) goes beyond the annotations and is valuable for the agent's decision-making. No contradiction with annotations detected.

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 its purpose, then lists the returned fields concisely, and ends with the optional parameter note. It's informational without redundancy, though the enumeration of field groups is somewhat lengthy. Every sentence contributes to understanding what the tool returns or how to use it. It's structured well, not verbose to the point of distraction, so a 4 is appropriate.

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 single-station retrieval tool with a rich output schema (has output schema: true), the description sufficiently explains what is returned (full record fields) and the optional comment inclusion behavior, including the warning about payload size and the alternative. It covers all key aspects a caller needs: identifier, optional flag, and behavioral nuance. The presence of an output schema means return structure details are not the description's job. No significant missing pieces for this moderate-complexity 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 100% — both 'id' and 'includeComments' have clear descriptions in the input schema. The description text itself reiterates the includeComments behavior ('Set includeComments to also return community check-ins inline') but adds no new semantics beyond the schema, which already explains the unpaged nature and suggests the sibling tool. Since the schema fully covers parameter meaning, the baseline of 3 applies; the description provides no additional value over schema.

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?

Description uses the specific verb 'get' with a clear resource ('full record for one Open Charge Map station') and a precise identifier ('numeric OCM ID'). It enumerates exactly what is returned (connections, operator, access restrictions, cost, etc.), distinguishing it from siblings like openchargemap_get_station_comments (which focuses on comments) and openchargemap_find_stations (search). The purpose is unambiguous and fully differentiated.

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 and includeComments parameter explicitly state when to use the alternative tool: 'prefer openchargemap_get_station_comments, which returns them a page at a time.' It effectively tells the agent that for a full station record, this tool is appropriate, and for paginated comments, use the sibling. However, it does not explicitly contrast with find_stations (search vs single-record) beyond the obvious purpose, which is implicitly clear from the purpose statement. Still, the guidance for the main alternative is explicit, earning a high score but not perfect.

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