Get one parking entity

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description adds real value beyond them by disclosing return content and conditional behavior: operating hours are marked Free/Paid/Mixed, payment providers and links are included, and the parking quote appears only when start_time is supplied.

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?

A single dense sentence, but it is front-loaded with the primary identity of the tool and then layers on the returned facets in a readable order. Nothing is padding, though the compound structure is heavy for one sentence.

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?

There is no output schema, so the description must carry the return-shape burden, and it does: it enumerates the entity fields, the hours semantics, the payment info, and the optional quote. For a complex 12-parameter read-only tool, an agent has enough to call it correctly.

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%, so the schema already documents all 12 parameters, including the vehicle and permit fields the description never mentions. The description adds only light semantic framing (date drives hours, start_time triggers the quote), which is the expected baseline when the schema does the heavy lifting.

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?

States a specific verb ('get') and resource ('one on-street segment or car park by id') and enumerates the returned facets (name, address, bay types, capacity, zone, authority, hours, payment, quote). It clearly distinguishes a single-entity lookup from the sibling listing/rule tools like find_parking_rules_near and fetch_kerb_segments.

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 implied: call it when you already have an entity id, and start_time is the condition that adds a quote. However, the description never explicitly states when to prefer this over siblings such as get_zone_rules or find_parking_rules_near; that routing information lives only in the entity_id schema description.

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