DMV Transit

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

Annotations already declare readOnly, idempotent, open-world, non-destructive, so the safety profile is covered. Beyond that the description adds genuinely useful behavior: the result is itemized per leg, payment is typically per-leg rather than a single transaction, and it carries an unofficial/not-affiliated disclaimer warning the agent about authority of the data.

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?

Front-loaded with the core purpose, then input formats, then grounding constraints — every sentence carries information. The awkward mid-sentence line breaks slightly hurt readability but no content 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?

No output schema exists, and the description compensates by describing the result structure (per-leg fares, payment instructions, total). With annotations covering side effects, the only real omission is the meaning of the two optional parameters.

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%, so the description must compensate, and it does well for the two required params by listing accepted formats (addresses, places, stations, "lat,lon"). But the optional "when" and "rider_category" params are never explained, even though they plausibly change fare pricing (time-of-day, discount category) — a meaningful gap in a fare tool.

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 opens with a specific verb and resource: "Estimate the total fare for a cross-system trip," and enumerates the return shape (per-leg fares, payment method per leg, total). The multi-leg/total scope implicitly but clearly separates it from single-fare siblings like get_fare and how_to_pay.

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?

It supplies a grounding rule ("Answer only from this tool's results: never add routes, hours, phone numbers...") and clarifies that each leg is usually a separate payment, which sets expectations. However, it never states when to prefer this tool over get_fare, plan_trip, or how_to_pay, so sibling selection is left to inference.

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 readOnly, idempotent, openWorld and non-destructive, so the safety burden is covered. The description adds real value beyond that: the 400 m default radius, the accepted feed-slug pattern for agency ("dash", "vre", "wmata"), accepted place formats, and an explicit grounding constraint against supplementing results from memory. It omits return shape and any behavior on empty results.

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 sentence is front-loaded and the Args block is compact and scannable, and the grounding sentence earns its place as a hard constraint. Minor redundancy: the Args block restates defaults that also appear in the schema, though that is justified given zero schema descriptions.

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 output schema and a search tool, the description never says what a result looks like (stop names, IDs, distances, agency attribution) or how many results to expect, which leaves the agent guessing about response shape. Inputs and safety profile are complete, so the gap is confined to return-value expectations.

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 coverage is 0%, so the description must carry all parameter meaning, and it does: place accepts a station name, a stop name, or "lat,lon"; radius_m is in meters with a default of 400; agency is an optional feed slug with concrete examples. That is meaningfully more than the bare schema titles provide.

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?

"Stops and stations within walking distance of a place, across all agencies" gives a specific verb-equivalent (proximity search) and resource (stops/stations), plus a scope note that separates it from agency-scoped or station-detail tools. It does not name a sibling explicitly (e.g. get_station_info, transfers_at), so it stops short of a 5.

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 by the purpose: it is the tool for finding nearby stops, and the agency arg hints at narrowing scope. There is no explicit when-to-use / when-not-to-use guidance, no statement of when to prefer get_station_info or transfers_at instead, and no note on what to do if the place string fails to resolve (e.g. fall back to geocode_address).

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 read-only, idempotent and open-world behavior, and the description adds real context on top: geographic coverage limits, multiple-match ambiguity handling, the `point` field as the pass-through value for planning tools, and a grounding rule against supplying addresses or hours from memory. The unofficial/not-affiliated disclaimer is also disclosed.

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 and trigger condition are front-loaded and the sentences are mostly load-bearing. The Args block restates what the schema already declares structurally and the closing grounding/disclaimer sentence is somewhat tacked on, but neither is wasteful enough to hurt scanning.

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 output schema, the description does the necessary work of describing the return shape at a high level — multiple candidate results, a `point` value to feed into planners, and the need to confirm which match is intended. It leaves the remaining result fields (name, formatted address, confidence) unspecified, which an agent must discover at call time.

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%, so the description carries the full burden, and it does explain both parameters: query is "what the rider said" with two concrete examples, and limit is bounded to 1–5, tighter than the schema's default of 5. It stops short of saying what limit controls in practice (candidate matches for disambiguation) or what happens at the boundaries.

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 gives a specific verb and resource ("Find where a street address, hotel, attraction or other place is") and bounds it geographically to DC, Maryland and Northern Virginia. It also implicitly separates itself from station lookups by noting the query is for places that are "not plainly a station," which distances it from siblings like get_station_info and find_stops_near.

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?

It states explicitly when to call ("whenever a rider names a place that isn't plainly a station, before planning a trip from or to it") and names the downstream tools that consume the output (plan_trip, plan_connection, find_stops_near). It also prescribes disambiguation behavior — verify the result matches and ask the rider when several fit — which no sibling tool covers.

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 openWorld. The description adds genuinely new behavior: results are limited to items 'currently out of service' rather than a full inventory, plus the answer-only constraint and the unofficial-source disclaimer. It still omits whether outage details include location, cause, or expected restoration, but that may be covered by the output schema.

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 scope statement is front-loaded in the first sentence, with the guardrails and disclaimer separated into a second short block. Both blocks are short and purposeful, though the disclaimer is more policy than tool documentation.

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-value shape need not be described, and the tool has a single optional parameter. The description supplies the one behavioral fact that matters (results are outages only) plus usage guardrails, which is sufficient for correct invocation.

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%, so the description must carry the param, and it does partially: it says the station filter is optional and limited to one station. It does not clarify whether the value is a station name, code, or free text, nor what happens for an unknown station, so the compensation is only partial.

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 first sentence names the exact resource (elevators and escalators) and the state being reported (currently out of service), which is far more specific than the title alone. It does not explicitly differentiate itself from get_service_alerts or get_station_info, so an agent must infer the boundary, but the resource is unambiguous.

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 only usage signal is 'optionally for one station', which hints at filtering but says nothing about when to choose this over get_service_alerts or get_station_info. There are no exclusions, prerequisites, or named alternatives, leaving the agent to guess which outage-related sibling to call.

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 read-only, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds genuinely new context: the rider_type alias groupings ("/peak" collapsing into regular) and the strong grounding instruction plus the unofficial/not-affiliated disclaimer, which affects how the agent should present results.

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 one-line purpose is front-loaded, followed by a compact Args block that is easy to scan. The grounding disclaimer is somewhat tangential for a fare lookup (routes, hours, phone numbers are outside this tool's domain), adding length without proportional value.

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, yet the description never indicates what a fare result looks like — currency, whether peak/off-peak is broken out, or what happens for an invalid station pair. For a three-parameter lookup with no return-value documentation, this is a meaningful gap in an otherwise adequate definition.

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%, so the description carries the full burden and largely does: it explains that origin/destination accept a station name or code, and it enumerates rider_type values that are absent from the schema (no enums present). It stops short of giving format examples or stating the default behavior beyond the schema's default 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?

"Station-to-station Metrorail fare" names a specific verb-equivalent (compute/look up a fare) and resource (Metrorail) with clear scope. It does not, however, differentiate itself from the close sibling estimate_trip_cost, so an agent must still guess which one answers a fare question.

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?

No when-to-use guidance is given, and the most relevant alternative (estimate_trip_cost) is never mentioned. The only constraint offered is an output-grounding rule ("answer only from this tool's results"), which governs answer composition rather than 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?

Beyond the read-only and idempotency annotations, the description adds a strict requirement to answer only from retrieved results and warns against supplementing them with remembered transit details. The unofficial, non-affiliation disclaimer also supplies useful provenance context, though source freshness and unknown-topic behavior remain unspecified.

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 compact and front-loads the resource, scope, and usable topic values. The grounding constraint and affiliation disclaimer each add distinct, relevant information without unnecessary wording.

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 simple one-parameter retrieval tool with an output schema and safety annotations, this provides nearly everything needed to select and invoke it. Explicit sibling differentiation and clarification of topic discovery or invalid-value handling would make it more complete.

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 and no enum, listing the exact topic tokens—new_rider, visitor, payment, fares, accessibility, safety, and maps—substantially improves invocability. It could be clearer about whether this list is exhaustive and what happens when another value is supplied.

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 that the tool returns the full text of a primary rider guide and enumerates its supported subjects. It does not explicitly distinguish the tool from overlapping siblings such as get_fare, how_to_pay, or search_transit_info.

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 topic list provides clear context for when a guide lookup is appropriate, and the grounding rule explains how its results should be used. However, there is no explicit routing to sibling tools for fare calculations, payment instructions, or broader transit searches.

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 read-only, idempotent, open-world lookup behavior, so the safety profile is covered. The description adds value beyond that by disclosing the shape of the answer (lines, transfer location, direction, stop count, fare) and by imposing a grounding constraint ('answer only from this tool's results'), which is real behavioral context for an agent composing a reply.

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?

Front-loaded with the purpose and return contents, followed by a compact Args block and a short grounding caveat. Every sentence serves a distinct function and there is no restatement of the tool name or annotations.

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 output schema, the description correctly covers the return contents, and it also states the accepted input formats, which the schema does not. The remaining gap is error/ambiguity behavior — what an agent should do if a station name does not resolve — but for a simple two-argument lookup this is close to complete.

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 coverage is 0% — the input schema gives only bare string titles — so the description must carry the load, and it does: each argument accepts a station name, a station code like 'C10', or an airport name/code such as 'DCA' or 'Dulles'. It stops short of covering case sensitivity, spacing, or what happens with an invalid or ambiguous station.

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 ('How to ride Metrorail between two stations') and enumerates exactly what the answer contains: line(s), transfer point, direction, stop count, and fare. That distinguishes it from generic siblings like get_route or plan_trip by scoping it to rail-only trips, though it never names those siblings explicitly.

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?

'Use this for EVERY Metrorail trip — never assume two stations share a line' gives a clear positive trigger and a caution against shortcutting. It lacks explicit when-not guidance and does not name which sibling to use instead for bus trips, multi-modal planning, or fare-only questions.

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 tool is read-only, idempotent, and open-world. The description adds behavior the annotations do not cover: the data is unverified and unofficial, it must be attributed with a time stamp, and it must never replace official information or timetables. One minor gap remains: the description does not state whether results are paginated, ordered, or empty when no reports match.

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 the purpose and then lists the arguments clearly. The closing instruction about not adding routes, hours, or phone numbers from memory repeats the earlier caveat about unofficial information, so it takes up space that could be trimmed, but the repetition does reinforce an important constraint.

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?

No output schema exists, yet the description lists the kinds of content returned (delays, crowding, broken elevators, tips) and the freshness dimensions, which is nearly sufficient for a three-parameter tool with no required arguments. It could still say more about result ordering or volume.

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%, so the description has to carry the full burden of explaining the parameters, and it does: station is 'matched loosely', line examples are given ('Red Line', 'D80', 'MARC'), and days is described with a default of 2 and a maximum of 30. These details go beyond the bare types in the schema, though the matching syntax for station is still vague.

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 both the action and the resource, and it also describes the data source as 'crowdsourced on this site'. It clearly signals that this tool covers unofficial rider observations rather than agency alerts, so an agent can distinguish it from siblings such as get_service_alerts or get_station_info.

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 gives strong context: it says to present results as 'riders reported ...', to include how long ago each report came in, and never to let these reports replace the timetable or official alerts. It does not name which sibling tool to use for official alerts, but the restriction it states clearly points an agent to the official tool for authoritative information.

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 cover read-only, open-world, idempotent, and non-destructive, so the safety profile is settled. The description adds real context beyond that: the data source (agency GTFS schedule), the presence of live disruption data, and a grounding constraint ('Answer only from this tool's results: never add routes, hours, phone numbers... from memory') that signals authority and completeness limits. The unofficial/non-affiliated disclaimer further sets expectations about data provenance.

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?

Front-loaded with the resource description, then a compact Args block with examples, then the grounding caveat. No sentence is filler, though the 'never add ... from memory' sentence is more an agent instruction than tool documentation and could be tightened.

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 two-parameter read tool with no output schema, the description does roughly summarize what comes back (hours, frequency, endpoints, fare, disruptions) and pins down both parameter formats. What is missing is edge-case behavior — unknown agency, no-match or multi-match queries — and any hint of output shape or pagination for a schedule payload that is likely large.

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 neither parameter has a description, so the description must carry the burden, and it does: agency is 'slug or name' with four concrete examples including the special 'wmata' Metrorail case, and query is 'route number or name' with examples spanning alphanumeric, named, numeric, and branded routes. It does not say what happens when a query is ambiguous or matches multiple routes, which is the one meaningful semantic 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?

Names a specific resource and scope: one route from a GTFS schedule, with an explicit field list (service days/hours, typical frequency, endpoints, fare, live disruptions). That is far more than a restatement of "Bus or train route". It does not, however, differentiate itself from sibling get_metro_route or get_fare, and its note that agency "wmata" covers Metrorail lines arguably overlaps with get_metro_route rather than clarifying 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 when-to-use guidance and no sibling is named as an alternative, even though get_metro_route, get_fare, and get_service_alerts all clearly overlap with the fields this tool returns. Usage is only implied by the returned-field list. The examples clarify invocation, not 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 declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuine value by naming the underlying data sources (WMATA incidents plus GTFS-realtime feeds) and the unofficial/non-affiliated disclaimer, but says nothing about freshness, latency, coverage limits, or the default behavior with zero filters on a fully optional 4-param tool.

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?

Front-loaded purpose sentence, then a compact per-argument list, then the grounding constraint. Every element is short and scannable. The 'Args:' block is slightly redundant with the schema titles, but it is the only place the accepted value formats live, so it earns its space.

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 described, and the remaining burden — accepted argument formats, data provenance, and output-grounding rules — is addressed. The gaps (filter combination semantics, behavior when no arguments are supplied, overlap with the dedicated elevator/escalator tool) are modest but real for a zero-required-parameter 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 0%, so the description carries the full burden and largely does: it defines line as a Metrorail line code with the actual codes (RD, BL, YL, OR, GR, SV) or a bus route number, mode with its three literal values, and agency with example slugs. What it omits is whether filters combine with AND or OR and what an empty filter set returns.

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 resource and scope: 'Live service disruptions' covering WMATA incidents (Metrorail, Metrobus, elevators) and agencies' GTFS-realtime alerts (detours, closed stops, missed trips). That is concrete enough to distinguish it from most siblings, though the elevator/escalator coverage overlaps with get_elevator_escalator_status and the description never draws that 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?

It gives a firm output-grounding rule ('Answer only from this tool's results: never add routes, hours, phone numbers...') and notes it is unofficial, which shapes how results are used. But it offers no when-to-use/when-not guidance against siblings like get_elevator_escalator_status, get_rider_reports or search_transit_info, and does not explain what happens when all optional filters are omitted.

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 readOnly, idempotent, non-destructive, and open-world, so the safety profile is covered. The description adds behavior beyond that: the accepted input forms (name or code) and a grounding rule forbidding supplementation from memory, plus an unofficial/not-affiliated disclaimer. It stops short of describing lookup failure or ambiguity handling.

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?

Front-loaded with the returned fields, then the input formats, then the grounding constraint and disclaimer. Each sentence does work, though the disclaimer is somewhat boilerplate and could be compressed.

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 structure need not be explained, and the description still previews the answer categories. For a single-parameter lookup, the input formats and grounding rule are the material gaps an agent would have, and both are covered; only ambiguity/error behavior is missing.

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%, so the description carries the full burden for the single 'station' parameter — and it does, giving two concrete accepted formats ("Gallery Place", "B01"). It does not state matching rules (case sensitivity, partial names, ambiguous matches), which keeps it short of a 5.

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 the concrete resource (a station) and enumerates exactly what it returns: lines served, address, parking, transfers, entrances. That is far more specific than a tautology, though it does not explicitly distinguish itself from adjacent siblings like transfers_at or get_route, which also touch station-level data.

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 by the returned-field list, and the note that a station can be given as a name or a code helps selection, but there is no explicit when-to-use or when-not-to-use guidance and no pointer to alternatives such as transfers_at for transfer-specific questions or find_stops_near for proximity.

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 readOnly/idempotent/non-destructive, yet the description still adds real value: it explains that fare_page_text is the agency's authoritative source for prices, discounts and transfer rules, and that the shorter hand-maintained fields are overridden by the fare page. That source-precedence detail materially affects how an agent should interpret and trust the result, though the overall return shape is only hinted at.

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 and the source-precedence rule are front-loaded in the first two sentences, the parameter block is compact, and the grounding/unaffiliated disclaimer is a single closing line. Nothing is padded.

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 one-parameter, read-only, open-world lookup with no output schema, the description supplies purpose, parameter format, and result-trust guidance. It stops short of describing what the response actually contains beyond naming fare_page_text and mentioning 'other fields', which would have fully closed the gap.

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 single agency parameter, so the description has to carry the load, and it does: it specifies slug-or-name and gives five concrete example values (vre, dash, omniride, wmata, metrobus). This meaningfully reduces call errors versus a bare string type.

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 guide-style resource (payment instructions for riding one named agency), which is more precise than the title 'How to pay'. It does not, however, distinguish itself from the sibling get_fare or estimate_trip_cost, so the agent must infer the boundary between payment mechanics and fare amounts.

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 by the wording 'how to pay to ride one agency', which suggests payment methods/discounts rather than price lookup, but no when-to-use or when-not-to-use rule is stated. The near-twin sibling get_fare is never mentioned, leaving the agent to guess which to call, and 'Answer only from this tool's results' is a grounding rule rather than a selection guideline.

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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. Beyond that the description adds genuinely new context: the results carry a 'data freshness' field and the source is unofficial and unaffiliated with WMATA or any agency, which affects how an agent should caveat answers. It does not describe result volume or whether the set is static.

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 blocks: the first front-loads what the tool yields, the second front-loads the grounding rule. The enumerated field list earns its place by telling the agent what it can cite. The affiliation disclaimer is borderline boilerplate but is short and relevant to answer framing.

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 enumerator with an output schema and full annotation coverage, this is close to sufficient: scope, contents, trust level and grounding rule are all stated, so return values need not be described. The remaining gap is freshness cadence and whether the agency set is exhaustive or region-limited to the ones named.

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 nothing for the description to disambiguate and the baseline of 4 applies. The description correctly spends no words on parameter explanation.

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 enumerates exactly what the tool returns — every transit system in the region with mode, role, strengths, service area, fare/payment summary and data freshness — and names the actual agencies, which makes it easy to tell apart from route-, fare- and station-level siblings like get_fare or get_route. It stops just short of an explicit verb phrase such as 'returns the list of agencies', leaving the action implied by the name.

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?

It gives a firm usage constraint — answer only from this tool's results and never supplement from memory — which tells the agent how far its authority extends. However, it names no alternatives and no exclusion condition, so an agent deciding between list_agencies, get_fare, how_to_pay or search_transit_info gets no routing guidance.

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 cover the safety profile (readOnly, idempotent, non-destructive, open-world), so the description adds context instead of repeating it: results carry document counts and a data-freshness indicator, and the tool is explicitly unofficial and unaffiliated with WMATA. What is missing is any note on ordering, pagination, or how topics relate to subsequent guide lookups.

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 sentences, front-loaded with the capability before the constraints. The disclaimer and grounding rule are doing real work (they prevent hallucinated transit facts), so they earn their place, though the second sentence packs three separate obligations together.

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 and no parameters, the description needn't explain return values, and it correctly summarizes what the list contains. The main gap is workflow context: it never states that listed topics are the inputs to get_guide, which is the obvious next step for an 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline for a parameterless tool applies.

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 first sentence gives a specific verb and resource ('List content categories') plus the payload ('document counts and data freshness'), which is enough to separate it from get_guide or get_rider_reports. It stops short of naming the sibling it feeds into, so the boundary is inferred rather than stated.

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 establishes a grounding rule ('Answer only from this tool's results') but never says when to choose this tool over get_guide, search_transit_info, or get_rider_reports. Usage as a browsing/discovery entry point is only implied by the word 'List'.

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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered; the description adds context the annotations cannot, namely that the tool is an unofficial, unaffiliated service and that answers must come only from its results rather than model memory. It still doesn't say how results are shaped or what happens when origin/destination are ambiguous or unroutable.

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?

Front-loaded with the outcome first, then an Args block, then a grounding constraint — each sentence earns its place. Slightly long for a three-parameter tool, but nothing is redundant enough to cut.

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 output schema and no annotation-level detail about results, the description still tells the agent what information the answer will contain (legs, hub, feasibility, fare, payment) and warns it is guidance rather than a booking. The main remaining gap is the response format and failure behavior for unroutable or ambiguous places.

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%, so the description carries the full burden, and it does: origin and destination accept address, place name, station, or "lat,lon", and `when` is a day value like "sunday" or "weekday" used to check feasibility. It adds real meaning beyond the bare string types, though it doesn't clarify what `when` values are actually accepted beyond those two examples.

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 and resource — advising on connections between two places "across systems" — and enumerates exactly what the answer contains: system per leg, transfer hub, days/times feasibility, fare and payment per leg. It implicitly separates itself from the single-agency sibling plan_trip via "across systems" and "Guidance, not a booked itinerary," but it never names plan_trip or any other sibling explicitly.

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?

Clears up the biggest ambiguity for a transit agent: this returns advice, not a booked itinerary, and the optional `when` exists to test day-level feasibility. There is no explicit when-not or named-alternative routing (e.g. use plan_trip for a single agency, estimate_trip_cost for pricing only), so an agent must infer when to prefer a sibling.

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 cover the safety profile (readOnly, idempotent, non-destructive, open-world), yet the description adds substantial behavior beyond them: up-to-a-mile walking radius, transfer count and 0.3 km transfer-distance limits, 10-minute wait preference, and the crucial freshness distinction that live updates apply only to 'leaving now' while future departures are pure timetable. It also flags special airport behavior at BWI/DCA/IAD and imposes an answer-only-from-results constraint.

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?

It is front-loaded with the core behavior and largely dense, but the intermediate paragraphs stack many routing-policy clauses that could be tightened, and the closing 'answer only from results / unofficial tool' boilerplate is a directive rather than tool semantics.

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 output schema, the description still tells the agent what an option contains (walking time, transfer waits, live-update status, airport step), so the agent knows what it will receive and how to present it. Nothing needed to call it correctly is missing.

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%, so the description must carry the burden and it does: origin/destination accept an address, landmark, station, or 'lat,lon' with a pointer to geocode_address output as the preferred form, and depart_at is specified as local Eastern time in 'YYYY-MM-DDTHH:MM' format with an explicit omit-to-leave-now default.

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 and resource — returning real trip options from agency timetables between an origin and destination — and explicitly contrasts itself with plan_connection, so an agent can route between them without opening either 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?

It gives an explicit trigger ('whenever a rider asks how to get somewhere at a particular time') and names the alternative with its own trigger ('use plan_connection for general "how would I get there" and which days it works'). No inference is required.

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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds value beyond that: it is a full-text web-page search (open-web content, not structured GTFS), it carries an unofficial/not-affiliated disclaimer, and it imposes a no-memory-of-facts grounding constraint. It does not describe result richness or coverage limits, which keeps it below 5.

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?

Front-loaded with the capability line, then the exclusion/alternative routing, then a compact Args block, then the grounding rule. Every sentence carries distinct information — scope, exclusions, parameter values, or an anti-hallucination constraint — with no repetition of the title or annotations.

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, and annotations cover the safety/idempotency profile. What remains for a search tool — content scope, exclusions, all three parameter semantics including the undocumented enum, and grounding expectations — is fully covered.

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 category parameter has no enum in the schema (plain anyOf string/null), so the description carries the full burden — and it does: it enumerates all 13 allowed category values, gives natural-language query examples ('pay with phone', 'bringing a bike'), and states the limit default. Minor gaps remain: no maximum for limit and no statement of how category matching works.

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 concrete verb+resource ('full-text search of the agencies' web pages') and immediately scopes the covered content (fares, payment, accessibility, safety, rules, guides, service changes). It then explicitly disclaims what it does NOT cover and names the sibling tools (get_metro_route, plan_connection, get_route, transfers_at) that handle routes/stops/schedules, so an agent can distinguish it from siblings 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?

Gives both the when (rider-page questions: fares, payment, accessibility, visitor guides) and the when-not (routes, stops, schedules, hours, service days), with named alternative tools for each excluded case. It also adds a grounding rule — answer only from this tool's results, never from memory — which is actionable usage guidance an agent would otherwise lack.

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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: results are grouped by agency, include walk time and GTFS service windows, and gain a feasibility check when day/time are supplied. It also flags that the tool is unofficial and unaffiliated with WMATA, which is meaningful provenance information an agent cannot get from annotations.

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 compact body sentences front-load the core behavior before the parameter note, with no filler. The closing grounding and disclaimer sentences are longer than strictly necessary but serve a real anti-hallucination and provenance purpose.

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 output schema, the description correctly describes the return shape: routes grouped by agency, each with walk time and service window, plus per-connection feasibility. Combined with annotations and the unofficial disclaimer, an agent has nearly everything needed; the only gap is how `place` should be formatted.

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 coverage is 0%, so the description carries the full burden, and it does most of the work: `day` is illustrated with 'saturday' and `time` with 'HH:MM', and their combined effect (per-connection feasibility check) is stated. `place` is only implied via 'a station or stop' in the opening sentence — no guidance on whether it takes a name, ID, or coordinates — which keeps this below a 5.

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 gives a specific verb-and-resource: routes from OTHER systems reachable on foot from a station/stop, grouped by agency with walk time and service window. The emphasis on 'OTHER systems' and 'reachable on foot' distinguishes it from single-agency route lookups like get_route or get_metro_route. It stops short of naming a sibling tool outright, so a 4 rather than a 5.

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?

It explains how to use the optional parameters ('Pass `day` and/or `time` to get a per-connection feasibility check'), which implies the base use case versus the enriched one. However, it never states when to choose this over plan_connection or plan_trip, nor any exclusions or prerequisites. Usage is inferable but not spelled out.

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