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

readOnlyHint=true and openWorldHint=true already carry the safety and openness profile, so the description's burden is lighter. It adds the useful nuance of a 'stored' record and the exact id formalism, but discloses nothing about permissions, freshness, or source coverage.

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?

One front-loaded sentence that carries the verb, the resource scope, the parameter format, and a concrete example with zero wasted words.

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?

With an output schema present, return values needn't be explained, and the sole parameter is thoroughly documented. The only missing piece is workflow routing to the search tool that produces the id, a minor gap for such a simple lookup.

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% and the single id parameter is fully documented with the same <source>:<source_listing_id> format and example. The description effectively restates the schema, so baseline 3 is appropriate.

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 a specific verb ('Fetch') and a precisely scoped resource ('one stored vehicle-listing record by composite id'), which cleanly separates it from the sibling search/facets/price_history tools that return sets or aggregates. An agent can identify this as a by-id detail lookup without opening any schema.

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?

Usage is only implied: a by-id lookup naturally follows a search, but the description never names datasets_vehicle_listings_search as the source of the id or states when-not to use it. No alternative or prerequisite is given, so the agent must infer the workflow.

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