Noise data tools: city noise rankings, decibel levels of common sounds, NIOSH safe-exposure math.
Scored across 10 tools
Most tools are clearly distinct by resource and granularity (address, neighborhood, city, ordinance, sound level, exposure). The city-noise tools overlap somewhat: get_city_noise, list_loudest_cities, get_us_city_noise_exposure, and get_europe_city_noise all deal with city rankings across different regions/datasets, but the descriptions explicitly cross-reference each other to guide selection. Only the boundary between get_city_noise and list_loudest_cities for world-city rankings is slightly fuzzy.
All names use consistent snake_case, and most follow an action_noun pattern (get_*, list_*, lookup_*). The only notable deviation is safe_exposure_time, which lacks a verb prefix and breaks the otherwise predictable pattern. Verb choice varies slightly (get_ vs list_ vs lookup_), but remains readable and semantically meaningful.
Ten tools is well-scoped for a noise-data and hearing-safety server. Each tool targets a distinct data source or granularity (US address, US neighborhood, US city, Europe city, world city, ordinance, sound lookup, safe exposure, app info). No tool feels redundant or out of place.
The surface covers modeled noise data at multiple geographic scales, hearing-risk reference data, safe-listening guidance, and an app reference. Minor gaps exist: noise ordinances cover only 8 cities, world city coverage is limited to 50, and non-US address/neighborhood noise is not available. These are manageable limitations rather than dead ends.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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" |
| 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 |
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.
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City name, e.g. "Tokyo" or "São Paulo" |
| 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 |
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.
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| price | No | |
| rating | No | |
| min_ios | No | |
| attribution | No | |
| app_store_url | Yes | |
| web_meter_url | No |
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.
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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) |
| Name | Required | Description |
|---|---|---|
| cities | Yes | |
| attribution | No |
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.
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | US city with neighborhood data: "Los Angeles", "New York" or "Chicago" | |
| limit | No | How many neighborhoods (default 10) |
| Name | Required | Description |
|---|---|---|
| city | Yes | |
| attribution | No | |
| neighborhoods | Yes |
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.
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | US city name, e.g. "Boston" or "Columbus, OH" |
| 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 |
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.
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.
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.
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.
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.
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.
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.
| 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) |
| Name | Required | Description |
|---|---|---|
| cities | Yes | |
| attribution | No |
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.
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.
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.
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.
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.
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.
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).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many cities to return (default 10) |
| Name | Required | Description |
|---|---|---|
| cities | Yes | |
| attribution | No |
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.
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| sound | Yes | Sound to look up, e.g. "lawn mower" or "subway" |
| Name | Required | Description |
|---|---|---|
| matches | Yes | |
| attribution | No |
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.
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| db | Yes | Sound level in dB(A), e.g. 95 |
| Name | Required | Description |
|---|---|---|
| db | Yes | |
| summary | Yes | |
| attribution | No | |
| safe_duration_hours | No | NIOSH max daily exposure in hours; null when not applicable |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_address_noise4 fields changedInput schema / properties / placeAdded 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"
+}Output schema / properties / approximateAdded value: +{
+ "description": "\"zip\" or \"place\" when sampled at an area center rather than a street",
+ "type": "string"
+}Output schema / properties / resolved_byAdded value: +{
+ "description": "street, street_unit, zip, place, zip_from_street, place_from_street or point",
+ "type": "string"
+}Output schema / properties / street_matchedAdded value: +{
+ "description": "false when a street address did not match and its ZIP or town was used instead",
+ "type": "boolean"
+}get_address_noise1 field changedInput schema / properties / zipAdded value: +{
+ "description": "5-digit US ZIP Code; sampled at the center of the ZIP Code area (Census 2023 ZCTA), so approximate",
+ "type": "string"
+}get_europe_city_noiseget_neighborhood_noiseget_noise_ordinanceget_address_noiseget_us_city_noise_exposure1 field changedInput schema / properties / limit / maximumPrevious value: -100New value: +297get_city_noise1 field 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"
+}get_decibel_shield_app1 field 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"
+}get_us_city_noise_exposure1 field 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"
+}list_loudest_cities1 field 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"
+}lookup_sound_level1 field 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"
+}safe_exposure_time1 field 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"
+}get_us_city_noise_exposureget_city_noiseget_decibel_shield_applist_loudest_citieslookup_sound_levelsafe_exposure_time140+ calculators and data tools — finance, health, science, global comparisons and more.
Free, no-login construction safety tools: OSHA rule text, toolbox talks, 1904 recordability.
Waste codes, transfer notes filled in from chat, HAVS, noise and first-aid calculators.
Ocean acoustics: propagation models, bathymetry, sound speed, vessel noise, live AIS. Open.
Add one secure layer between your agents and this server.