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

With no annotations, the description carries the full burden, and it does disclose one genuinely useful behavioral trait: untracked places are reported as 'not covered' rather than as zero, and absence of coverage is not evidence of absence of transit data. That is valuable output semantics beyond the schema, but nothing is said about read-only safety, permissions, or result shape.

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 sentences, both earning their place: the first front-loads scope, the second front-loads the interpretation caveat. No filler, no repetition of the schema.

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 two-parameter read tool with no output schema and no annotations, the description covers what is returned, the granularity options, and the crucial not-covered-vs-zero semantics. It stops short of saying whether the optional subdivision is required for subdivision-level output or what the totals are keyed on, but the gap is small.

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 both parameters (country as ISO 3166-1 alpha-2, subdivision as ISO 3166-2 code or name) are already fully documented. The description's 'one ISO country, or one subdivision inside it' only restates that relationship without adding format or edge-case detail, so the baseline 3 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?

States a specific resource ('Covered-set totals') and an explicit scope (one ISO country, or a subdivision inside it), which is concrete enough for an agent to know what comes back. It does not, however, contrast itself with the obviously related siblings coverage_stats or national_stats, so disambiguation must come from elsewhere.

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 scope phrasing implies the use case (single-country / single-subdivision lookups), but there is no explicit when-to-use statement and no named alternative such as coverage_stats or national_stats for aggregate or comparative queries. Usage is inferable rather than stated.

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?

No annotations are provided, so the description carries the full disclosure burden. It implies a read-only stats/aggregation operation but never confirms that, nor does it describe scope constraints, freshness, or the shape of results. 'Portable' is unexplained jargon rather than a behavioral trait.

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, which is appropriate for a zero-parameter tool. It is slightly dense with undefined terms ('portable', 'coverage-wide') but wastes no 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?

With no output schema, the description must convey what comes back, and it only gestures at 'quality totals' and 'country/subdivision rollups' without defining the metrics or structure. Combined with no differentiation from overlapping siblings, an agent lacks enough to call this correctly with confidence.

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 the schema-based baseline of 4 applies. There is nothing for the description to clarify on the input side.

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 the subject matter (coverage-wide quality totals plus country/subdivision rollups) but uses no clear verb and leans on undefined jargon like 'portable' and 'the feeds this scorecard tracks'. It does not distinguish itself from close siblings such as national_stats, get_rollup, or coverage_for, so an agent cannot confidently pick it over those.

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, no exclusions, and no mention of the sibling tools that clearly overlap (national_stats, get_rollup, coverage_for). The agent is left to guess which stats tool 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?

With no annotations, the description carries the full behavioral burden and does disclose the important edge case: a code with no written recipe returns only the rule link and signals that fact, and nothing is invented beyond the written content. It omits auth, rate-limit, and pagination behavior, but the degradation contract is the disclosure an agent most needs here.

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 sentences, front-loaded with what the tool returns before the empty-recipe caveat. Dense but each clause adds information; the closing hedge 'nothing is described beyond what is written' slightly repeats the no-recipe clause but usefully bounds expectations.

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 and no annotations, so the description must describe the return shape itself, and it does: recipe, rule link, optional tool fix path, and the partial-result case. Given a simple two-parameter lookup, this is complete enough 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 100%, so both the 'code' example and the enumerated producing-tool keys are already documented in the schema. The description adds only marginal meaning by tying the 'tool' parameter to the returned fix path, which is the baseline expectation 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?

The description names the resource precisely — the fix recipe, rule link, and optional producing-tool fix path for a notice code — so an agent knows it is a lookup keyed on a validator/scorecard code. It distinguishes itself somewhat from retrieval siblings like get_scorecard and get_evidence_packet by specifying the fix-recipe payload, though it never states the action verb outright.

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: you supply a notice code to learn how to fix it, and optionally a producing tool to get that tool's fix path. There is no explicit when-to-use vs. when-not, and no sibling is named as the alternative, so an agent must infer the trigger condition from the code parameter alone.

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?

With no annotations, the description carries the full behavioral burden. It usefully discloses that the packet is "deterministic" and tied to the "latest" scorecard (a current-snapshot rather than historical read), but says nothing about permissions, size, cost, or whether the packet is cached/stable across calls.

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 packet contents are listed compactly after the colon. Dense but every clause carries information; it reads as a noun phrase rather than an instruction, which is a minor structural weakness.

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, so the description must convey the return value, and it does list the packet's components reasonably well. However, it omits any guidance on invocation context or what the agent should do with the packet, leaving gaps for a tool whose output it must describe.

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 parameter is documented with a concrete example ('unitrans'), so the schema already does the work. The description adds only the implicit scoping of 'one agency' and 'latest', which the schema does not restate.

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 artifact and enumerates its three components (producer contract, work items with acceptance tests, feed identity), so an agent can tell it apart from get_scorecard or explain_finding. It never states a verb like "return" and does not explicitly contrast itself with those siblings, 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?

There is no when-to-use guidance and no named alternative among the eight siblings. The phrase "one agency's latest scorecard" hints that it is scoped to the current scorecard snapshot, but the agent is left to infer when this is preferable to get_scorecard, explain_finding, or coverage_for.

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?

With no annotations, the description carries the full burden and does substantial work: it defines the comparable_with_previous flag, enumerates the five causes that make a point non-comparable (rubric, scoring profile, validator, reader archive profile, measured-category set), and warns that differences across such a boundary are not real feed changes. It also conditions the findings delta on comparability of the two most recent snapshots. Missing only operational details like pagination, auth, or rate limits.

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?

Three sentences, front-loaded with what the tool returns and then progressively detailing the comparability semantics. The middle sentence is dense but every clause adds necessary meaning. No filler or restatement of the name.

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 and no annotations, so the description must explain return semantics itself, and it does so well for the key field (comparable_with_previous) and for the conditional findings delta. It is only lightly incomplete in not sketching the overall response shape or pagination behavior for a 120-point feed history.

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 limit, since, and agency_id are already fully documented in the schema (including the 120 default/ceiling and the YYYY-MM-DD format). The description adds no parameter-level meaning beyond that, 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 resource and scope ('One feed's dated grade and score history') plus the extra artifacts it returns (measurement-contract boundaries, appeared/cleared findings). An agent can tell it is a historical time-series tool. It does not, however, name or distinguish itself from any of the many sibling analytics tools (national_stats, get_rollup, get_scorecard), so it falls short of the top mark.

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 rather than stated: the description makes clear this is the tool for dated trend/comparability analysis, and the 'only when those two are comparable' clause signals a precondition on interpreting the findings output. But there is no explicit when-to-use, when-not-to-use, or named alternative among the eight siblings.

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?

No annotations are provided, so the description carries the full burden. It does add a genuinely useful interpretive guard — shared fixes are not a ranking of agencies — which prevents a likely misreading of the output, but it says nothing about permissions, whether results are cached/live, or the shape of the response.

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 sentences, front-loaded with the resource and its contents, followed by one clarifying caveat. Nothing is redundant and the second sentence earns its place by heading off misinterpretation.

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 annotations, the description does the needed work by previewing the three returned sections. It is adequate for a simple single-record read, though a hint about what 'rollup_id' scopes (which cohort/program) would make it airtight.

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 rollup_id parameter is fully documented in the schema with an example ('california'), so the description cannot add much. It correctly conveys that the tool operates on one rollup, matching the parameter's intent, which is the expected baseline.

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 resource (a single program rollup) and enumerates its payload: shared fixes, grade distribution, and members needing attention. This distinguishes it from aggregate siblings like national_stats or coverage_stats, though it never names an alternative to sharpen the contrast.

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 phrasing 'One program rollup' implies singular retrieval keyed by rollup_id, but there is no explicit when-to-use, no exclusions, and no routing versus get_scorecard, national_stats, or coverage_stats. The agent must infer selection from the name alone.

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?

No annotations are provided, so the description carries the full burden. 'Latest' hints at freshness, but nothing states that this is a read-only operation, whether results are cached, what happens for an unknown agency_id, or any auth requirement. Enumerating the payload partially compensates, but the core behavioral profile is absent.

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 efficient sentence with no filler; content is front-loaded. It is a content list rather than a purpose statement, so it is concise but not optimally structured for tool selection.

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 tool with no output schema, listing the returned sections (grades, findings, fixes, NTD GTFS readiness) is genuinely useful. However, the description leaves out what the tool actually does, when to invoke it instead of siblings, and any read-only/freshness behavior — substantial gaps given no annotations.

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?

There is a single parameter (agency_id) and the schema documents it at 100% coverage, including an example slug, so the baseline is 3. The description adds no meaning about the parameter at all — it never references the agency argument.

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 resource (an agency's latest scorecard) but supplies no verb — it is a noun-phrase inventory of contents rather than a statement of what the tool does. An agent can infer retrieval, and 'scorecard' distinguishes it somewhat from siblings like get_history and get_rollup, but it never explicitly says 'fetch/retrieve a scorecard for an agency'.

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 guidance on when to use this tool versus the eight siblings (get_history, get_rollup, get_evidence_packet, explain_finding, etc.). No prerequisites, no exclusions, no indication of how it relates to rollup/history views.

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?

With no annotations, the description carries the full behavioral burden and does disclose meaningful traits: it is a legacy/backwards-compatible view and contains a 'covered-corpus stats member' alongside the national/by-state data. For a zero-parameter read-only stats tool the risk surface is small, though the return shape (beyond a single phrase) and any error/deprecation behavior are not described.

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 sentences, no filler, with the scope statement front-loaded and the alternative-plus-condition in the second sentence. The phrase 'backwards-compatible covered-corpus stats member' is jargon-heavy and slightly opaque, costing a point.

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-param, no-output-schema stats tool, the description supplies what an agent needs: what data is returned, its geographic granularity, its legacy status, and the preferred alternative. Nothing critical is missing, though the return structure is only loosely characterized.

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 per the rubric the baseline is 4. The description adds no parameter information because none exists to explain, and the empty schema is self-evident.

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 resource and scope: 'NTD GTFS readiness nationally and by state,' which tells an agent exactly what data this tool surfaces. It also flags the tool as legacy and names the sibling it is not (coverage_stats), aiding differentiation. The framing phrase 'United States policy view' is vague, but the substantive clause carries the meaning.

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?

'Prefer coverage_stats for geography-neutral totals' gives an explicit alternative plus the condition that selects it, implying national_stats is for US-specific / by-state needs. It stops short of stating outright when this tool is the right choice or whether it is deprecated, but the routing guidance is clear and actionable.

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?

With no annotations, the description carries the full burden. It partially does so by disclosing the returned fields (portable location, grade, score, expiry, readiness), which is valuable given there is no output schema. But it says nothing about read-only nature, ordering, pagination beyond the schema's limit default, or auth requirements.

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 sentences, zero filler, and the search scope is front-loaded before the return-value sentence. Every clause (filter dimensions, returned fields) carries distinct information.

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 no output schema, the description usefully enumerates the return payload, which is the main completeness risk. It falls slightly short on pagination/ordering and filter-combination behavior for a six-parameter search tool, but nothing critical for a correct call 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 100%, so the schema already documents all six parameters including the 'prefer subdivision' hint. The description groups and names the same dimensions but adds no syntax, format, or interaction semantics (e.g., AND vs OR across filters) beyond what the schema provides; baseline 3 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?

States a specific verb (Search) and resource (tracked transit agencies), then enumerates the searchable dimensions (name, id, ISO country, subdivision, legacy state, grade). This clearly separates it from stats/aggregation siblings such as national_stats, get_rollup, and get_scorecard, which return computed values rather than agency 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?

Usage is implied by the enumeration of filter dimensions, so an agent can infer this is the lookup tool for individual agencies. However, there is no explicit when-to-use versus alternatives (e.g., coverage_for or get_scorecard for aggregate views) and no guidance on combining filters or when results are exhaustive.

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