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

Annotations already declare readOnly, idempotent, non-destructive, and openWorld=false, so the safety profile is covered. The description adds genuine value by clarifying data provenance — the evidence is locally supplied and no rail API call occurs — which implies possible staleness and a closed data set. It stops short of describing result shape, ordering, or what an empty result means.

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 front-loaded sentence with no filler; the scope qualifier and the negative constraint are both packed in without waste. It is arguably under-specified rather than over-written, but there is nothing to trim.

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 no explanation, and annotations cover safety. What remains missing for a per-journey lookup tool is any tie between the required journey_id and the returned evidence, plus minimal usage context relative to its siblings — without that, an agent knows what the tool reads but not precisely how to feed or choose it.

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% and the singular required parameter journey_id is never mentioned in the description, so nothing is added about what a journey ID refers to, where to obtain it, or whether evidence is returned only for that journey. With one obviously-named parameter the cost is limited, but the description does not compensate for the coverage gap.

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 uses a specific verb ('List') and a specific resource ('final-arrival evidence') and scopes it with 'locally supplied', which distinguishes it from anything that would pull live data from a rail API. It does not explicitly contrast itself with siblings like dsb_status or dsb_prepare_claim_form, and 'final-arrival evidence' is domain jargon an agent must infer means per-journey arrival records.

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 when-to-use guidance and no alternatives named. The phrase 'nothing is fetched from a rail API' hints at a use case (reading cached/held evidence rather than querying a live source), but the agent is not told which sibling to prefer when it needs live status versus stored evidence.

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

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

The annotations already establish that the operation is read-only, idempotent, and non-destructive. The description usefully adds that it stops before any form is filled, but otherwise provides little behavioral context about preparation dependencies, workflow effects, or failure conditions.

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?

Two short, front-loaded sentences communicate the returned artifacts and the key limitation without filler. The brevity leaves documentation gaps that are scored elsewhere, but the wording itself is efficient and well structured.

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?

The output schema and annotations cover return structure and safety, but the description is not complete enough for this multi-input workflow tool. It leaves the form's domain, its relationship to form preparation and evidence collection, and the roles of the optional inputs unclear.

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?

With 0% schema description coverage, the description needed to compensate but explains none of ticket_id, journey_id, evidence_id, or journey_details. It particularly misses when the optional evidence or passenger-supplied journey details should be provided and how they affect the prepared handoff.

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 uses a clear verb and identifies three concrete handoff artifacts: the form link, prepared fields, and user-review checklist. It does not identify the specific claim form or distinguish this retrieval/handoff operation from dsb_prepare_claim_form.

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?

Prepared fields and user review imply a late-stage handoff, while 'No form is filled yet' signals that this is not a completion step. However, there are no explicit prerequisites or guidance on when to use this instead of dsb_prepare_claim_form or the evidence and journey sibling tools.

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

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

The description adds crucial conceptual context by stating journeys are 'known' and cannot be inferred from a purchase. This behavioral constraint goes beyond standard operational hints like 'readOnlyHint' and helps manage agent expectations regarding data completeness.

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 highly concise, using only two sentences to convey the tool's function, constraints, and usage boundaries without any filler. The key pieces of information are immediately front-loaded in the first clause.

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?

Given the low complexity (one optional parameter) and the comprehensive nature of the provided annotations, the description is robust. It successfully frames the tool's scope and limitations, which is the most important context for an AI agent.

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?

With 0% schema description coverage, the description provides necessary semantic value by explicitly defining the parameter's role as optional and tied to an identifier ('optionally for a ticket'). This clarifies that 'ticket_id' acts as a lookup mechanism for known data.

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 clearly states the action (List), the resource (known journeys), and the optional constraint (optionally for a ticket). This distinction helps the AI understand that the tool retrieves existing data rather than creating or updating it.

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 tool includes a vital negative constraint: 'Never infer travel from a purchase alone.' This provides strong guidance on when the tool should and should not be used, preventing logical misuse by the agent.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile needs no restating. The description adds useful context that the data comes from a configured local source, but it does not disclose ordering, result limits, or what happens when dates exclude everything. An output schema exists, so omitting return-value detail is acceptable.

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 front-loaded clause with no filler; the source and the date-filter qualifier come in the right order. It is efficient, though its terseness edges toward under-specification rather than crispness.

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?

The description covers the idealised core of the tool: it discovers tickets from a configured local source with optional inclusive date bounds. What remains unclear is whether the date filters apply to journey or ticket dates, which matters given the sibling journey tools.

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?

With 0% schema description coverage, the description carries the burden and it partially does: it clarifies that the dates are optional and that the bound is inclusive, which the schema does not state. However, it says nothing about format, whether start_date and end_date must be supplied as a pair, or what happens when only one is given.

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?

Names a verb ('Discover') and a resource ('ticket references') and adds scope ('from the configured local source'), but the verb is soft and the object ('ticket references') is ambiguous against the tool name dsb_list_tickets — it is unclear whether full tickets or only IDs are returned. It offers no differentiation from siblings such as dsb_list_journeys, so an agent must infer the boundary.

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 statement of when to use this tool, when not to, or which sibling (dsb_list_journeys, dsb_get_delay_evidence) to prefer for related lookups. The only implicit guidance is that journey dates are optional, which is about parameters, not tool selection.

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

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

Annotations already establish this is a safe, idempotent, closed-world read, so the safety profile is covered. The description adds genuinely new behavioral context the annotations cannot express: the agent is expected to prompt the passenger for missing times, and must not infer compensation. It stops short of saying whether anything is persisted or what the prepared output looks like.

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?

Two terse clauses plus a constraint — nothing is wasted, but the brevity crosses into under-specification rather than crispness. The most actionable constraint (no compensation inference) is buried as a trailing fragment.

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 explained. For a tool with four parameters, 0% schema coverage, and a nested journey object, however, the description leaves the agent without enough to know how to assemble the arguments or how this fits into the claim flow.

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% for the four top-level parameters, so the description carries the burden and largely fails. It never explains ticket_id vs journey_id vs evidence_id, nor when to supply the optional journey_details object; "ask the passenger for missing times" only faintly gestures at the optional actual_arrival field.

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?

"Prepare form fields" gives a verb and a loose resource, but which form (the claim form, per the tool name) and what preparing entails are left implicit. It does not distinguish this tool from the sibling dsb_get_form_handoff, which sounds like it occupies adjacent 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 hints at a workflow step (collect missing times from the passenger) but never says when to call this versus dsb_get_form_handoff or the listing tools. No preconditions, no exclusions, no mention of what to do if fields are already complete.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds the useful distinction between 'configured' versus 'actually implemented' capabilities and mentions privacy boundaries, but says nothing about freshness of the configuration snapshot or whether a round trip to a provider occurs.

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 front-loaded sentence with no filler, and the three reported aspects are enumerated in a logical order (provider, capabilities, privacy). It is arguably terse to a fault, but no sentence is wasted.

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 no parameters, a full annotation set, and an output schema that already documents return values, most of the burden is carried elsewhere. What the description lacks is orientation — what 'dsb' refers to and when a diagnostic call is warranted — leaving the agent to infer placement in a workflow.

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 there is no parameter meaning for the description to add; the baseline for a parameterless tool applies. Nothing is misleading or missing on this dimension.

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 verb 'Report' is paired with three specific resources — configured provider, implemented capabilities, and privacy boundaries — so the tool's scope is clear and distinct from the ticket/journey/claim siblings. It stops short of explicitly naming a sibling, so an agent must infer the separation from resource content alone.

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: checking what a provider is configured for and what is actually implemented suggests calling this before attempting other operations. There is no explicit when-to-use, when-not-to-use, or prerequisite statement, and no pointer to an alternative sibling.

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