decibel-shield

Server Details

Noise data tools: city noise rankings, decibel levels of common sounds, NIOSH safe-exposure math.

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 100.0% over 38 days
Last Tested: 2026-09-24 03:34
Transport: Streamable HTTP · MCP 2025-06-18
URL

TDQS

A4.3/5.0

Scored 2026-09-19 13:26 across 10 tools

Disambiguation3/5

Most tools are clearly scoped by geography and query type (address, US city, neighborhood, Europe, ordinance, sound level, exposure time). The main ambiguity is between get_city_noise and list_loudest_cities, which both cover the same 50 world cities and estimated rankings; the descriptions help but don't fully eliminate the overlap.

Naming Consistency3/5

Seven of ten tools follow a clear get_<scope>_<topic> pattern, but lookup_sound_level, list_loudest_cities, and safe_exposure_time break it with different verbs or no verb at all. The naming is readable and consistently snake_case, but the set feels less predictable than it could be.

Tool Count5/5

Ten tools is a well-scoped size for a noise-data server. Each subdomain—geographic noise, sound levels, ordinances, and the app itself—has representation without excessive granularity.

Completeness4/5

The server covers address-level noise, US/Europe/world city rankings, neighborhood rankings, ordinances, sound-level lookup, and safe-exposure guidance, so most user intents are addressed. Minor gaps exist, such as ordinances for only eight cities and limited measured detail outside Europe/US, but these don't create dead ends.

Available Tools

10 tools

get_address_noiseModeled transportation noise at a US addressA

Read-onlyIdempotent

Inspect

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) 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.

ParametersJSON 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
`address`	No	US street address, e.g. "1600 Pennsylvania Ave NW, Washington DC"

Output Schema

ParametersJSON 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
`attribution`	No
`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

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description discloses important behavioral traits: results are modeled bands, not measurements; ZIP sampling is approximate at the ZCTA center; 'below 45 dBA' is a model floor, not silence; and coverage is continental US only. This significantly helps the agent interpret outputs correctly.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

The description is tightly written, front-loaded with user-intent examples, and every sentence adds value: purpose, data source, output semantics, and limitations. No filler or repetition of schema details.

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?

The description is complete for a read-only lookup tool: it specifies inputs, data source, output band, what the floor value means, and geographic coverage. The output schema covers return structure, so the description does not need to repeat it.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics by explaining how each input is sampled (e.g., ZIP center approximation, lat/lng as an alternative to address) and clarifying the model's resolution. This goes beyond the schema's basic parameter descriptions.

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?

The description states exactly what the tool computes: modeled transportation noise (road, rail, aircraft) as a dBA band at a US address, ZIP, or lat/lng. It includes natural-language query examples and clearly distinguishes itself from city-level siblings by emphasizing address/point granularity.

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

Usage Guidelines3/5

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

It clearly communicates valid input types (address, ZIP, lat/lng) and a key limitation (continental US only, modeled not measured). However, it does not explicitly compare itself to siblings like get_city_noise or get_neighborhood_noise, leaving the when-to-use-vs-alternatives decision mostly to inference.

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

get_city_noiseGet estimated noise levels for a cityA

Read-onlyIdempotent

Inspect

Answers "how loud is Tokyo", "noise level in Mumbai", "is Delhi louder than London". Estimated day/night noise ranges (dB), rank among 50 major world cities, dominant noise sources and a confidence label, with WHO guideline context (53 dB Lden / 45 dB Lnight). Estimates synthesized from published sources, not measurements. For US cities computed from federal data use get_us_city_noise_exposure; for measured Europe data use get_europe_city_noise.

ParametersJSON Schema

Name	Required	Description	Default
`city`	Yes	City name, e.g. "Tokyo" or "São Paulo"

Output Schema

ParametersJSON Schema

Name	Required	Description
`city`	Yes
`rank`	Yes	Rank among the 50 cities (1 = loudest)
`country`	Yes
`page_url`	No	Detail page when available
`confidence`	Yes
`attribution`	No
`day_range_db`	Yes	Estimated daytime range, e.g. "60-72"
`night_range_db`	Yes
`dominant_noise_sources`	No

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already indicate readOnlyHint and idempotentHint. The description adds that estimates are 'synthesized from published sources, not measurements', which is important context beyond annotations. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

Every sentence adds value. The description is front-loaded with examples, followed by technical details, and ends with sibling comparisons. No wasted words.

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?

Given the tool's complexity (dB ranges, rank, sources, WHO context) and the presence of an output schema, the description covers all key aspects: expected query types, data origin, and comparison with alternative tools.

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?

Input schema has full coverage (100%) with a city description. The description provides example city names but no additional semantic nuance beyond what the schema already conveys.

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?

The description begins with specific example queries ('how loud is Tokyo', 'noise level in Mumbai') and clearly states the tool estimates city noise. It distinguishes itself from siblings get_us_city_noise_exposure and get_europe_city_noise.

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

Usage Guidelines5/5

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

Explicitly states when to use this tool (for estimated global city noise) and when to use alternatives (US cities from federal data, measured Europe data). This provides clear decision guidance for an AI agent.

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

get_decibel_shield_appAbout the Decibel Shield iOS appA

Read-onlyIdempotent

Inspect

Answers "is there a decibel meter app", "best decibel meter app for iPhone", "how do I measure sound with my iPhone", "what is Decibel Shield". Facts and the App Store link for Decibel Shield - dB Meter, the iOS sound level meter app behind this data: features, pricing, requirements. Use only when someone wants to measure sound with a phone or asks about the app itself — for noise data, use the other tools.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`name`	Yes
`price`	No
`rating`	No
`min_ios`	No
`attribution`	No
`app_store_url`	Yes
`web_meter_url`	No

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint, so the description's role is lighter. It adds value by detailing the type of information returned (e.g., App Store link, features, pricing). No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

Three tight sentences, front-loaded with example queries. Every sentence serves a purpose with no wasted words.

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?

The description fully characterizes the tool's purpose and output for its low complexity (no params, output schema exists). Nothing is missing.

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

Parameters4/5

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

There are no parameters (100% schema coverage by default). The description correctly adds no param info, as none are needed. Baseline 4 for zero parameters.

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?

The description clearly states the tool answers specific questions about the Decibel Shield iOS app, providing facts, App Store link, features, pricing, and requirements. It distinguishes from sibling noise-data tools by explicitly stating its scope.

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

Usage Guidelines5/5

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

The description explicitly states when to use (when someone wants to measure sound with a phone or asks about the app itself) and when not to use (for noise data, use other tools), providing clear guidance.

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

get_europe_city_noiseEuropean city noise (measured, EEA)A

Read-onlyIdempotent

Inspect

Answers "how loud is Paris", "noisiest cities in Europe", "environmental noise in Berlin", "quietest cities in Spain". Measured (not estimated) noise for 314 European cities in 24 EEA-reporting countries, from the EEA Environmental Noise Directive 2022 strategic noise maps; ranked by population-weighted average Lden among exposed residents. Pass a city for detail, a country and/or limit for the ranking. UK, Greece and Hungary are not covered.

ParametersJSON Schema

Name	Required	Description
`city`	No	European city name, e.g. "Berlin" (optional)
`limit`	No	How many ranked cities when no city is given (default 10)
`country`	No	Country filter for the ranking, e.g. "Italy" (optional)

Output Schema

ParametersJSON Schema

Name	Required	Description
`cities`	Yes
`attribution`	No

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already provide readOnlyHint and idempotentHint, but the description adds valuable context: data source (EEA 2022), ranking method (population-weighted average Lden), and explicit coverage gaps. This goes beyond what annotations offer.

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?

The description is a single paragraph of 4 sentences, efficiently packing essential details. It front-loads the most common queries and then provides data context and usage. Slightly longer than minimal but still concise.

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?

Given the tool's complexity (3 optional parameters, no required, output schema present), the description covers all needed context: data source, coverage, usage patterns, and ranking methodology. The output schema presence reduces the need to explain return values, and the description is sufficient for selection and invocation.

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

Parameters4/5

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

Although schema coverage is 100% with descriptions, the additional text explains that 'city' provides detail, while 'country' and 'limit' are for ranking, and clarifies the default limit (10). This adds meaning beyond the raw schema.

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?

The description clearly states the tool answers specific queries like 'how loud is Paris' and 'noisiest cities in Europe', and distinguishes itself by specifying 'Measured (not estimated) noise for 314 European cities' from the EEA. This differentiates it from sibling tools like get_us_city_noise_exposure or get_address_noise.

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?

The description gives explicit usage: 'Pass a city for detail, a country and/or limit for the ranking.' It also clarifies coverage exclusions (UK, Greece, Hungary). However, it does not explicitly state when not to use this tool versus alternatives, such as for US cities or estimated noise.

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

get_neighborhood_noiseUS neighborhood noise ranking (measured)A

Read-onlyIdempotent

Inspect

Answers "loudest neighborhoods in Los Angeles", "quietest neighborhood in Chicago", "which NYC neighborhood has the most noise". 384 neighborhoods in Los Angeles, New York and Chicago, ranked within their city by share of residents ≥60 dB transportation noise, computed from the federal BTS 2020 National Transportation Noise Map (same source as the US city tool). Pass the city name; optional limit. For a single address use get_address_noise.

ParametersJSON Schema

Name	Required	Description	Default
`city`	Yes	US city with neighborhood data: "Los Angeles", "New York" or "Chicago"
`limit`	No	How many neighborhoods (default 10)

Output Schema

ParametersJSON Schema

Name	Required	Description
`city`	Yes
`attribution`	No
`neighborhoods`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already indicate readOnlyHint=true and idempotentHint=true, so the description need not repeat that. It adds valuable context about the data source (BTS 2020 National Transportation Noise Map) and the metric (share of residents ≥60 dB), which goes beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

The description is concise with two sentences, front-loading the purpose with examples and including all necessary details without superfluous information.

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?

Given the presence of multiple sibling tools, the description effectively contextualizes usage by directing to get_address_noise for addresses. It explains the data source and scope (3 cities), and with an output schema available, it covers return values adequately.

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

Parameters4/5

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

With 100% schema coverage, baseline is 3. The description adds the default value for limit (10) not present in the schema, and clarifies the allowed cities for the city parameter, providing additional utility.

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?

The description uses specific examples like 'loudest neighborhoods in Los Angeles' to clearly state the tool's purpose of providing neighborhood noise rankings. It distinguishes itself from the sibling tool get_address_noise by explicitly directing users to that tool for single address queries.

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?

The description instructs users to 'Pass the city name; optional limit' and points to get_address_noise for single addresses. However, it does not mention when to use this tool versus other siblings like get_city_noise, leaving some ambiguity.

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

get_noise_ordinanceCity noise ordinance (official code summary)A

Read-onlyIdempotent

Inspect

Answers "what are quiet hours in Boston", " noise ordinance", "how do I file a noise complaint". Verbatim-verified summary of the city's official noise ordinance: quiet hours, decibel limits (or their explicit absence — audibility/nuisance standards), complaint channel, code citation + official URL, verified date. Covers Boston, Worcester, Huntsville, Chesapeake, Madison, Inglewood, Rockford, Columbus. Plain language, not legal advice.

ParametersJSON Schema

Name	Required	Description	Default
`city`	Yes	US city name, e.g. "Boston" or "Columbus, OH"

Output Schema

ParametersJSON Schema

Name	Required	Description
`city`	Yes
`note`	No
`state`	Yes
`code_url`	Yes
`page_url`	No
`verified`	No	Date the summary was verified against the live code
`db_limits`	Yes
`attribution`	No
`quiet_hours`	Yes
`code_citation`	No
`standard_type`	No
`complaint_channel`	No

TDQS

A4.4/5.0

Behavior5/5

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

Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds valuable context: it is a 'verbatim-verified summary' with a verified date, plain language, and not legal advice. There are no contradictions with annotations.

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?

The description is moderately concise (4 sentences), front-loaded with query examples. It covers purpose, scope, and disclaimer. The list of cities could be slightly more compact, but overall effective.

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?

Given the single-parameter schema and presence of an output schema, the description fully explains what the tool returns (quiet hours, decibel limits, complaint channel, etc.) and which cities it covers. No gaps remain.

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 coverage is 100% (one required parameter 'city' with example 'Boston' or 'Columbus, OH'). The description reiterates these examples but does not add new semantic details beyond what the schema provides.

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?

The description clearly states the tool answers questions about noise ordinances, quiet hours, decibel limits, and complaint channels. It specifies cities covered and distinguishes from siblings like get_city_noise and get_us_city_noise_exposure by focusing on ordinance text rather than exposure data.

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?

The description provides explicit use cases (e.g., 'what are quiet hours in Boston', '<city> noise ordinance') and notes it is a summary of official code. It does not explicitly mention when not to use it or point to alternatives, but sibling tool names imply separate purposes.

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

get_us_city_noise_exposureUS city transportation-noise exposure (measured)A

Read-onlyIdempotent

Inspect

Answers "loudest cities in the US", "quietest cities in the US", "how noisy is Boston", "what share of Miami hears highway noise". Share of residents exposed to ≥60 dB / ≥70 dB transportation noise for all 297 US cities of 100,000+ residents, computed from the federal BTS 2020 National Transportation Noise Map, not estimated. Pass a city for detail, omit for the ranking. Street address → get_address_noise; neighborhoods → get_neighborhood_noise.

ParametersJSON Schema

Name	Required	Description	Default
`city`	No	US city name, e.g. "Boston" (optional)
`limit`	No	How many ranked cities when no city is given (default 10)

Output Schema

ParametersJSON Schema

Name	Required	Description
`cities`	Yes
`attribution`	No

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already indicate read-only, idempotent behavior. The description adds valuable context: data source (federal BTS map), measured not estimated, specific dB thresholds, and city coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

Two concise sentences, no waste. First sentence gives purpose and examples, second provides technical details and alternatives. Information is front-loaded.

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?

Given two optional parameters and an existing output schema, the description covers purpose, usage, data source, and sibling differentiation completely.

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

Parameters4/5

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

Schema coverage is 100% with descriptions; the description complements by explaining usage patterns ('pass a city for detail, omit for ranking') and providing examples, adding value beyond schema.

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?

The description clearly states the tool answers specific questions about US city noise exposure using measured data, and explicitly distinguishes from sibling tools (get_address_noise, get_neighborhood_noise).

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?

The description explains when to pass a city vs omit for ranking, and mentions alternative tools for address or neighborhood queries, providing clear usage context.

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

list_loudest_citiesList the loudest cities rankingA

Read-onlyIdempotent

Inspect

Answers "loudest cities in the world", "noisiest cities ranking", "which city has the worst noise pollution". 50 major world cities ordered by estimated daytime noise, loudest first — estimates synthesized from published sources, not measurements. For "loudest cities in the US" or "quietest cities in the US" use get_us_city_noise_exposure (computed from federal BTS data); for Europe use get_europe_city_noise (measured).

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	How many cities to return (default 10)

Output Schema

ParametersJSON Schema

Name	Required	Description
`cities`	Yes
`attribution`	No

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, and non-destructive. The description adds that data is estimated from published sources, not measurements, alerting the agent to potential inaccuracy. This context is valuable beyond annotations, though no further behavioral details are needed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

The description is two sentences, front-loading the purpose and then providing data source and ordering details. Every sentence adds value with no redundancy, demonstrating excellent conciseness.

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?

For a simple 1-parameter tool with an output schema, the description sufficiently covers purpose, scope, limitations, and alternatives. No gaps remain for effective tool selection and invocation.

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 coverage is 100% with a single 'limit' parameter already described. The description does not add extra meaning about the parameter beyond what's in the schema, so baseline score of 3 is appropriate.

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?

The description explicitly states it answers queries like 'loudest cities in the world' and 'noisiest cities ranking', specifying 50 major world cities ordered by estimated daytime noise. It clearly distinguishes from sibling tools by naming alternatives for US and Europe.

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

Usage Guidelines5/5

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

The description provides explicit when-to-use guidance (for global loudest cities) and when-not-to-use (for US or Europe), naming alternative tools (get_us_city_noise_exposure, get_europe_city_noise). This helps the agent select the correct tool.

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

lookup_sound_levelLook up how loud a common sound isA

Read-onlyIdempotent

Inspect

Answers "how loud is a hair dryer", "how many decibels is a chainsaw", "is 85 decibels loud", "how loud is 80 decibels". Decibel level and hearing-risk guidance for everyday sounds (whisper, conversation, traffic, lawn mower, concert, jet engine...), every figure sourced to CDC/NIOSH/NIDCD/ASHA published tables. Input is a sound name; if you already have a dB number and want safe listening time, use safe_exposure_time.

ParametersJSON Schema

Name	Required	Description	Default
`sound`	Yes	Sound to look up, e.g. "lawn mower" or "subway"

Output Schema

ParametersJSON Schema

Name	Required	Description
`matches`	Yes
`attribution`	No

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint. The description adds value by stating the tool provides decibel level and hearing-risk guidance, and that figures are sourced from authoritative organizations (CDC, NIOSH, NIDCD, ASHA), offering behavioral context beyond what annotations provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

The description is concise, using a short paragraph that front-loads examples, states the tool's output, and provides an alternative. Every sentence serves a purpose with no waste.

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?

Given one fully-documented parameter, existing annotations, an output schema, and sibling tools that provide context, the description is complete. It covers purpose, usage, and alternative, making it sufficient for agent understanding.

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 coverage is 100% with a description for the 'sound' parameter. The description repeats that input is a sound name but adds no new semantic meaning beyond the schema. Baseline 3 is appropriate.

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?

The description clearly states that the tool answers questions about how loud common sounds are, providing decibel levels and hearing-risk guidance. It gives concrete examples like 'hair dryer' and 'chainsaw', and distinguishes itself from sibling tools by mentioning an alternative for dB numbers.

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

Usage Guidelines5/5

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

Explicitly tells when to use this tool (when you have a sound name and want decibel information) and when to use the alternative (safe_exposure_time for dB numbers wanting safe listening time). This provides clear guidance on tool selection.

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

safe_exposure_timeSafe exposure time for a decibel levelA

Read-onlyIdempotent

Inspect

Answers "how long can I listen to 100 dB", "is 85 dB dangerous for 8 hours", "how long at a concert before hearing damage". Maximum daily safe exposure time for a sound level per NIOSH's recommended exposure limit: 85 dB(A) for 8 h, 3 dB exchange rate (88 dB → 4 h, 100 dB → 15 min). Input is a dB number; to get the dB of a named sound first, use lookup_sound_level.

ParametersJSON Schema

Name	Required	Description	Default
`db`	Yes	Sound level in dB(A), e.g. 95

Output Schema

ParametersJSON Schema

Name	Required	Description
`db`	Yes
`summary`	Yes
`attribution`	No
`safe_duration_hours`	No	NIOSH max daily exposure in hours; null when not applicable

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already indicate the tool is read-only and non-destructive. The description adds behavioral detail: it calculates maximum daily safe exposure time using NIOSH's 3 dB exchange rate. This is sufficient, though it could mention any output format or precision limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

The description is concise (three sentences) and well-structured: it opens with example queries, then provides technical details, and ends with a usage hint. Every sentence is informative and 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?

Given the tool's simplicity (one parameter, straightforward logic), the description covers input, calculation method, and refers to the sibling tool. With an output schema present, return values are likely documented elsewhere, so the description is complete.

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?

The input schema has 100% coverage, so the parameter (db) is already described. The description reinforces its meaning with examples like '85 dB(A)' and '100 dB → 15 min', but adds minimal extra value beyond the schema.

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?

The description explicitly states it answers questions like 'how long can I listen to 100 dB', clearly indicating its function. It also explains the NIOSH recommended exposure limit and exchange rate, making the tool's purpose unmistakable.

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

Usage Guidelines5/5

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

The description provides concrete usage scenarios ('how long at a concert before hearing damage') and directs users to a sibling tool (lookup_sound_level) if they need the dB of a named sound first, offering clear alternatives.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateSep 19, 2026

Changedget_address_noise1 field changed

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"
+}

3 tool updatesJul 11, 2026
- Addedget_europe_city_noise
- Addedget_neighborhood_noise
- Addedget_noise_ordinance
2 tool updatesJul 11, 2026
- Addedget_address_noise
- Changedget_us_city_noise_exposure1 field changed
  - changedInput schema / properties / limit / maximum
```
Previous value: -100New value: +297
```

6 tool updatesJun 10, 2026

Changedget_city_noise1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "attribution": {
+      "type": "string"
+    },
+    "city": {
+      "type": "string"
+    },
+    "confidence": {
+      "enum": [
+        "high",
+        "med",
+        "low"
+      ],
+      "type": "string"
+    },
+    "country": {
+      "type": "string"
+    },
+    "day_range_db": {
+      "description": "Estimated daytime range, e.g. \"60-72\"",
+      "type": "string"
+    },
+    "dominant_noise_sources": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "night_range_db": {
+      "type": "string"
+    },
+    "page_url": {
+      "description": "Detail page when available",
+      "type": "string"
+    },
+    "rank": {
+      "description": "Rank among the 50 cities (1 = loudest)",
+      "type": "integer"
+    }
+  },
+  "required": [
+    "rank",
+    "city",
+    "country",
+    "day_range_db",
+    "night_range_db",
+    "confidence"
+  ],
+  "type": "object"
+}

Changedget_decibel_shield_app1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "app_store_url": {
+      "type": "string"
+    },
+    "attribution": {
+      "type": "string"
+    },
+    "min_ios": {
+      "type": "string"
+    },
+    "name": {
+      "type": "string"
+    },
+    "price": {
+      "type": "string"
+    },
+    "rating": {
+      "type": "number"
+    },
+    "web_meter_url": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "name",
+    "app_store_url"
+  ],
+  "type": "object"
+}

Changedget_us_city_noise_exposure1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "attribution": {
+      "type": "string"
+    },
+    "cities": {
+      "items": {
+        "properties": {
+          "city": {
+            "type": "string"
+          },
+          "pct_ge60_db": {
+            "description": "Share of residents exposed to >=60 dB (%)",
+            "type": "number"
+          },
+          "pct_ge70_db": {
+            "type": "number"
+          },
+          "population": {
+            "type": "integer"
+          },
+          "rank": {
+            "type": "integer"
+          },
+          "state": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "rank",
+          "city",
+          "state",
+          "pct_ge60_db"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "cities"
+  ],
+  "type": "object"
+}

Changedlist_loudest_cities1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "attribution": {
+      "type": "string"
+    },
+    "cities": {
+      "items": {
+        "properties": {
+          "city": {
+            "type": "string"
+          },
+          "confidence": {
+            "enum": [
+              "high",
+              "med",
+              "low"
+            ],
+            "type": "string"
+          },
+          "country": {
+            "type": "string"
+          },
+          "day_range_db": {
+            "description": "Estimated daytime range, e.g. \"60-72\"",
+            "type": "string"
+          },
+          "dominant_noise_sources": {
+            "items": {
+              "type": "string"
+            },
+            "type": "array"
+          },
+          "night_range_db": {
+            "type": "string"
+          },
+          "page_url": {
+            "description": "Detail page when available",
+            "type": "string"
+          },
+          "rank": {
+            "description": "Rank among the 50 cities (1 = loudest)",
+            "type": "integer"
+          }
+        },
+        "required": [
+          "rank",
+          "city",
+          "country",
+          "day_range_db",
+          "night_range_db",
+          "confidence"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "cities"
+  ],
+  "type": "object"
+}

Changedlookup_sound_level1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "attribution": {
+      "type": "string"
+    },
+    "matches": {
+      "items": {
+        "properties": {
+          "db_high": {
+            "type": "number"
+          },
+          "db_low": {
+            "type": "number"
+          },
+          "risk": {
+            "type": "string"
+          },
+          "risk_note": {
+            "type": "string"
+          },
+          "sound": {
+            "type": "string"
+          },
+          "source": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "sound",
+          "db_low",
+          "db_high",
+          "risk",
+          "source"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "matches"
+  ],
+  "type": "object"
+}

Changedsafe_exposure_time1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "attribution": {
+      "type": "string"
+    },
+    "db": {
+      "type": "number"
+    },
+    "safe_duration_hours": {
+      "description": "NIOSH max daily exposure in hours; null when not applicable",
+      "type": "number"
+    },
+    "summary": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "db",
+    "summary"
+  ],
+  "type": "object"
+}

1 tool updateJun 10, 2026
- Addedget_us_city_noise_exposure
5 tool updatesJun 10, 2026
- First observedget_city_noise
- First observedget_decibel_shield_app
- First observedlist_loudest_cities
- First observedlookup_sound_level
- First observedsafe_exposure_time

Related MCP Connectors

Stupidly Clever
com.stupidlyclever.www
140+ calculators and data tools — finance, health, science, global comparisons and more.
Finance Health & Wellness
1
Global Metro Power Rankings A
org.citizenofnowhere.rankings
Query 4,300+ ranked metros across sixteen dimensions: profiles, search, and head-to-head comparisons
Open Data Search
511
Environmental Compliance
io.github.martc03
EPA air quality monitoring and HUD foreclosure data. 3 MCP tools for environmental and housing data.
Government Data Open Data Research & Data
25
GroundTruth - Environmental Records A
ai.agentlookups
Federal environmental records near any US location, with dates and provenance; never a safety score.
Real Estate Government Data Open Data
31

Related MCP Servers

EPA Air Quality System (AQS)
Government Data Open Data Search
tyson-swetnam
A
license
A
quality
D
maintenance
Provides access to EPA's Air Quality System API with 31 tools for querying air quality data, monitoring sites, and pollution measurements across the United States through natural language.
Updated 10 months ago (2025-12-02 17:56 UTC)
31
MIT
Backup Power Finder
E-commerce & Retail
sholts2026
F
license
Not graded
quality
B
maintenance
Enables comparing and ranking portable battery power stations and solar generator bundles by load, runtime, use case, solar charging, portability, battery chemistry, and budget, with modeled estimates and shopping guidance.
Updated 3 days ago (2026-09-21 07:45 UTC)
-
EcoBack Raumklima MCP
Energy Weather Services
f-tiger
F
license
Not graded
quality
D
maintenance
Nine tools for indoor climate and household energy in Germany/EU: BTU sizing for a room, portable-AC window-seal length, live heatwave outlook, appliance running costs, heating watts, dew point for safe ventilation, and balcony-storage subsidy rules. Also searches and reads 133 guides on getecoback.com; no auth, no personal data, and every answer returns its source URL.
Updated a month ago (2026-08-29 11:41 UTC)
-
osha-recordkeeping-mcp
Legal & Compliance
srhtdmrkl
A
license
A
quality
C
maintenance
Enables deterministic evaluation of workplace injury recordability under 29 CFR Part 1904, using 11 typed triage tools to return cited determinations for OSHA log entries.
Updated 6 days ago (2026-09-18 07:14 UTC)
11
MIT

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?