MyStreetData USA

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

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds genuine behavioral context beyond that: it warns there is no aggregate score or ranking and that period, scale and missing values must be interpreted per source. That is meaningful for correctly reading the result.

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 short, front-loaded sentences with no filler. The scope constraint leads, followed by the two interpretation caveats, so the most decision-relevant information comes first.

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 profile. Still, for a comparison tool with an undocumented `dimensions` enum and no routing to the single-street sibling, the description leaves gaps an agent must resolve elsewhere.

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 parameter meaning. It documents the street_ids constraint ('2–5 distinct IDs') matching minItems/maxItems, but says nothing about the `dimensions` parameter or its enum values (walkability.nwi, food.snap_retailers, transport.ev_stations), leaving half the inputs opaque.

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 operation and scope: 'Side-by-side contextual measurements for 2–5 distinct IDs.' This clearly conveys a multi-street comparison, distinguishing it from the single-street sibling get_street_context by implication. It stops short of naming that sibling, so differentiation is inferred rather than explicit.

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 statement 'No overall score, ranking or recommendation' sets output expectations, and 'Interpret each source period, scale and missing value separately' offers interpretation guidance. However, it never states when to choose this over get_street_context or when comparison is inappropriate, leaving usage 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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower; the description still adds genuine context by defining what 'publication verification' means and explicitly warning that it is not a claim of indexing or current freshness. That caveat about data provenance is exactly the kind of behavioral detail structured fields cannot carry.

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 tight sentences with no filler, led by the returned payload and followed by the scope and provenance caveats. The front-loading is reasonable, though the final sentence about publication verification is dense enough to need a second read.

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 description covers the payload, its scope limits, and provenance caveats. The one meaningful gap is the undocumented area_id parameter, which is partially excused by the low-complexity, read-only nature of the 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?

The single area_id parameter has 0% schema description coverage and only a regex pattern, and the description never mentions it or explains how it scopes the returned coverage. With one undocumented optional parameter and no compensating prose, the description leaves the parameter's meaning to inference.

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 resource returned - dataset version, included states, and site-area coverage - which is a specific metadata payload rather than a search, and it distinguishes itself from the search siblings by declaring 'This is the site catalogue, not all United States streets.' It stops short of a crisp verb-first statement of what invoking it does, 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?

Usage is only implied: by framing itself as the catalogue rather than a street search, it hints you consult it to learn what the dataset covers before searching. There is no explicit 'use this when / don't use this when' and no named alternative among search_areas, search_streets, get_street_context, or compare_streets.

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, closed-world), so the bar is lower. The description still adds genuine value by disclosing data vintage/quality traits: 'period, scale and missing-data status', and by clarifying the data is observational, not live.

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 dense sentences, front-loaded with the data payload and ending with the scope disclaimer; nothing is wasted. The opening is a noun-phrase fragment rather than a verb-led statement, which slightly weakens front-loading.

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 surfaces the key interpretive fields (period, scale, missing-data status). For a read-only, two-parameter tool with clear scope exclusions, only the missing street_id acquisition path leaves a 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%, so the description must carry the parameter burden. It effectively names the three dimensions (walkability, SNAP retailers, EV stations) matching the enum values, but says nothing about street_id format (the us:#### pattern) or how the dimensions array is selected/combined.

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 specific resource and its content: EPA block-group walkability plus observed SNAP retailer and EV station counts near the street centroid. That is concrete enough to distinguish it from the search/compare siblings, though it never names an alternative tool 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?

Usage is implied by the data scoping, and the closing clause 'Not a home, safety or live availability assessment' usefully bounds what the tool should not be used for. However it gives no positive routing guidance, e.g. that search_streets should be used first to obtain a street_id, so an agent must infer the workflow.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower; the description still adds real signal: matching is prefix-based, and the returned areas 'are not guaranteed municipal boundaries.' That caveat about data semantics is non-obvious and valuable.

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 statements with the core action front-loaded and no filler. Slightly dense with semicolons, but every clause (area types, area_id selection, boundary caveat, prefix search) earns its place.

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. The description covers what is searched, the matching mode, and a data-quality caveat; the only gap is the unaddressed limit/cursor pagination behavior for a 4-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 parameter burden. It clarifies that query matches by name, state is used to qualify the area_id, and prefix matching applies to the query, but limit and cursor pagination parameters are left completely unexplained.

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 (find) and a precisely scoped resource (city, county, or metro grouping), plus the output to select (state-qualified area_id). This is clearly distinguishable from the sibling mystreetdata_search_streets, which operates on a different resource.

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 implies the lookup role by telling the agent to 'select the state-qualified area_id,' suggesting this feeds a downstream call, but it never states when to use this over search_streets or whether a street search also requires an area first. Usage is implied rather than explained.

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, closed-world), so the bar is lower. The description still adds non-obvious behavior: prefix matching semantics, that results distinguish ZIPs from persistent IDs, and the notable security constraint that a supplied URL is never treated as a fetch target.

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?

Four short, front-loaded sentences with no filler; the core purpose leads and the prerequisite/safety caveats follow. Sentence fragments are dense but each 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?

An output schema exists, so return values need not be described, and annotations carry the safety profile. The description adds purpose, the search_areas prerequisite, matching semantics, and the URL-injection guard — enough for an agent to call this correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry the full burden of the four parameters. It partially compensates by revealing that query is prefix-based and that area_id is state-qualified, but limit (default 5, max 10) and cursor (pagination) get no explanation anywhere in the description or schema.

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 ("Find streets") plus the matching mode ("by name prefix") and scope ("one state-qualified site area"), which an agent can act on. It references the sibling search_areas but does not distinguish itself from compare_streets or get_street_context, so sibling differentiation is only partial.

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 search_areas first" gives an explicit prerequisite ordering, and "one state-qualified site area" implies the single-area scope constraint. It stops short of stating when to prefer this over compare_streets or get_street_context, so there are no real exclusions beyond the one prerequisite.

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