decibel-shield

Modeled transportation noise at a US address

get_address_noise

Read-onlyIdempotent

Answers "how loud is my neighborhood", "noise map by address", "how noisy is this address", "noise level in ZIP 78701". Modeled transportation noise (road + rail + aircraft, 24-hour average LAeq dBA) at a US street address, a 5-digit ZIP (sampled at the ZIP Code area center, approximate), a town or city name (sampled at the town center, approximate) or lat/lng, sampled block-by-block from the federal BTS 2020 National Transportation Noise Map. Returns a modeled dBA band, NOT a measurement; "below 45 dBA" means no modeled freeway/rail/flight path nearby (model floor, not silence). Continental US only.

Input Schema

Name	Required	Description
`lat`	No	Latitude (use with lng instead of an address)
`lng`	No	Longitude (use with lat)
`zip`	No	5-digit US ZIP Code; sampled at the center of the ZIP Code area (Census 2023 ZCTA), so approximate
`place`	No	US town or city name, ideally with the state, e.g. "Boulder, CO"; sampled at the center of the town (Census 2023 places), so approximate
`address`	No	US street address, e.g. "1600 Pennsylvania Ave NW, Washington DC"

Output Schema

Name	Required	Description
`lat`	No
`lng`	No
`band`	Yes	Modeled dBA band, e.g. "60–70 dBA", or "below 45 dBA"
`note`	No
`query`	No
`db_low`	No
`db_high`	No
`modeled`	Yes
`approximate`	No	"zip" or "place" when sampled at an area center rather than a street
`attribution`	No
`resolved_by`	No	street, street_unit, zip, place, zip_from_street, place_from_street or point
`street_matched`	No	false when a street address did not match and its ZIP or town was used instead
`matched_address`	No	Geocoder’s normalized address (when an address was given)
`nearby_max_band`	No	Loudest modeled band within ~90 m, if higher than the point

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 11, 2026

addedInput schema / properties / place

Added value: +{
+  "description": "US town or city name, ideally with the state, e.g. \"Boulder, CO\"; sampled at the center of the town (Census 2023 places), so approximate",
+  "type": "string"
+}

addedOutput schema / properties / approximate

Added value: +{
+  "description": "\"zip\" or \"place\" when sampled at an area center rather than a street",
+  "type": "string"
+}

addedOutput schema / properties / resolved_by

Added value: +{
+  "description": "street, street_unit, zip, place, zip_from_street, place_from_street or point",
+  "type": "string"
+}

addedOutput schema / properties / street_matched

Added value: +{
+  "description": "false when a street address did not match and its ZIP or town was used instead",
+  "type": "boolean"
+}

Changed1 schema field changedSep 19, 2026

addedInput schema / properties / zip

Added value: +{
+  "description": "5-digit US ZIP Code; sampled at the center of the ZIP Code area (Census 2023 ZCTA), so approximate",
+  "type": "string"
+}

AddedJul 11, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, so the bar is low, yet the description adds substantial behavioral context: results are modeled, not measured; ZIP and town inputs are sampled at area centers and therefore approximate; and 'below 45 dBA' means the model floor rather than silence. These caveats materially change how an 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core purpose and packs coverage limits and model caveats efficiently. The leading list of user-phrase variants ('how loud is my neighborhood', etc.) is slightly padded but useful for retrieval matching, so it mostly earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return format need not be explained, and the description covers everything else an agent needs: data source, metric, sampling granularity, geographic coverage, and the interpretation trap of the model floor. Nothing material is missing.

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

Parameters3/5

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 five parameters including the ZIP/town-center approximation. The description restates the accepted input types but adds no syntax, precedence, or fallback rules beyond what the schema provides, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (modeled transportation noise at a location) and names the exact data source and metric (road+rail+aircraft, 24-hour LAeq dBA from BTS 2020). The 'Continental US only' scope plus the address/ZIP/place/lat-lng input envelope distinguishes it from the European and city-level siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear context for when it applies (US street address, ZIP, town, or lat/lng) and explicitly excludes non-continental-US queries, which routes the agent away from get_europe_city_noise. It does not, however, explicitly tell the agent when to prefer it over get_city_noise or get_neighborhood_noise, which overlap with the place/ZIP inputs.

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

All decibel-shield tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?