Public hazard, water, weather and EPA data with source, age and licence on every reading.
Scored across 9 tools
The tools mostly target clearly distinct resources: catalogue sources, hubs, datasets, layers, places, readings, and dataset parts. The closest potential overlap is between get_readings and get_layer, since both return observed values, but their descriptions distinguish source-based current readings from map-layer GeoJSON output.
All tools follow a consistent verb_noun pattern: get_*, list_*, and search_*. The naming is predictable and readable throughout.
Nine tools is well within the expected range for a read-only public data catalogue and mapping server. Each tool appears to earn its place by covering a distinct object or operation.
The surface covers the core read-only lifecycle: discovering datasets, layers, places, hubs, and sources; fetching source details; and retrieving readings, layers, and dataset parts. Minor gaps remain, such as no dedicated get_hub or get_dataset detail operation, but the main workflows are supported.
The URL of one part of a dataset as GeoJSON, plus its description. Fetch the URL for the features; parts can be several megabytes.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| part | Yes | Two-letter state, or "all" for single-part datasets. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose non-obvious behavior: the tool returns a URL rather than inline data, the payload is GeoJSON, and parts can be several megabytes. It omits whether the URL is temporary/signed, whether authentication is required to fetch it, or any rate limits, leaving meaningful gaps.
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 short sentences, front-loaded with what is returned and followed by the operational instruction. No filler; every sentence carries information, though the second sentence could note the id's origin for equal efficiency.
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?
Since there is no output schema, the description correctly explains the return value (URL + description, GeoJSON, size). For a 2-param tool with no annotations it still leaves the `id` parameter and URL validity/auth details unaddressed, so it is adequate but not fully self-sufficient.
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 only 50%: `part` is documented ('two-letter state, or "all"'), but `id` has no description anywhere. The description adds nothing about what `id` refers to or where it comes from, so it fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource (one part of a dataset) and return shape (GeoJSON URL plus its description), which tells an agent what the tool produces. It does not explicitly contrast itself with siblings like get_layer or get_source, but the resource is unambiguous enough to distinguish them in practice.
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?
"Fetch the URL for the features" implies the follow-up workflow, which is useful usage context. However, there is no guidance on when to use this versus list_datasets, get_layer, or get_source, and no stated prerequisites (e.g., needing an id from list_datasets).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One map layer as a GeoJSON FeatureCollection: one point per place with the reading on the date (else the latest observed before it, never a guess), or one point per event for event layers.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| lat | No | Ad-hoc point latitude (with lng). For weather and WSI. | |
| lng | No | Ad-hoc point longitude (with lat). | |
| min | No | ||
| tag | No | Catalogue places with this tag, e.g. waterfowl, ice-fishing. | |
| bbox | No | ||
| date | No | YYYY-MM-DD; default today (US Eastern). | |
| fuel | No | power_plants: coal, oil/gas, nuclear, hydropower, wind, utility-scale solar, geothermal or bioenergy | |
| kind | No | weather_alerts: warning | watch | advisory | |
| type | No | ships_baltic: cargo | tanker | passenger | fishing | tug | other | |
| usgs | No | USGS monitoring location id(s), e.g. USGS-04193500. | |
| coops | No | NOAA CO-OPS station id(s), comma-separated, e.g. 9063085. | |
| ebird | No | eBird region code(s), e.g. US-OH-095. | |
| event | No | weather_alerts: an NWS event name, e.g. Red Flag Warning | |
| place | No | Comma-separated catalogue place ids (see list_places). | |
| state | No | ||
| marine | No | weather_alerts: include marine alerts | |
| min_mw | No | ||
| radius | No | aircraft, gps_interference: nautical miles around lat/lng, 1-250 | |
| region | No | reservoirs_west: a Reclamation region, e.g. Missouri Basin | |
| status | No | power_plants: operating | construction | |
| window | No | ||
| country | No | power_plants: ISO alpha-3, e.g. DEU | |
| elevated | No | ||
| operator | No | data_centers: operator, e.g. Microsoft | |
| indicator | No | ||
| continuing | No | volcanoes_world: only eruptions in progress | |
| erupted_since | No | volcanoes_world: year, default 1900 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does add meaningful behavior: the fallback to 'the latest observed before it, never a guess' and the point-per-place versus point-per-event distinction. However, it omits other important behavioral traits such as read-only nature, permissions, size limits, and pagination or error behavior.
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 dense but front-loaded sentence that leads with the output type and then explains the point semantics. It wastes little space, though the parenthetical fallback clause slightly interrupts readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 28 parameters, no annotations, and no output schema, the description is too thin. It explains the output shape but not how the many optional parameters interact, which ones apply to which layer ids, or what happens with invalid or missing data.
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 71%, so roughly a quarter of the 28 parameters are undocumented. The description itself adds no parameter semantics at all, leaving ambiguous optional filters like min, bbox, state, window, elevated, and indicator to the schema, where several are bare.
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 it returns one map layer as a GeoJSON FeatureCollection, with a specific point-per-place or point-per-event semantics. It distinguishes the shape of the output but does not explicitly differentiate itself from siblings such as get_readings or list_layers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It does not say when to use this tool instead of get_readings, get_dataset_part, or list_layers, nor does it explain when not to use it. Usage is only implied by the phrase 'One map layer.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch current readings from one source, each with value, unit, a one-line summary, place and provenance (source, URL, fetch time, licence). Sources this server will not republish (non-commercial, restricted or unreviewed licence) answer with an error naming the licence.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Ad-hoc point latitude (with lng). For weather and WSI. | |
| lng | No | Ad-hoc point longitude (with lat). | |
| min | No | usgs-earthquakes only: all | 1.0 | 2.5 | 4.5 | significant. | |
| tag | No | Catalogue places with this tag, e.g. waterfowl, ice-fishing. | |
| bbox | No | noaa-nwps only: xmin,ymin,xmax,ymax in degrees (≤400 sq deg); default the Great Lakes basin. | |
| usgs | No | USGS monitoring location id(s), e.g. USGS-04193500. | |
| coops | No | NOAA CO-OPS station id(s), comma-separated, e.g. 9063085. | |
| ebird | No | eBird region code(s), e.g. US-OH-095. | |
| limit | No | 1-1000, default 100. | |
| place | No | Comma-separated catalogue place ids (see list_places). | |
| since | No | ISO date or datetime; only readings at or after it. | |
| state | No | epa-echo only: two-letter US state, default OH. | |
| metric | No | Only readings of this metric. | |
| source | Yes | A source id with a fetcher (search_sources with fetchable=true). | |
| window | No | usgs-earthquakes only: hour | day | week. | |
| elevated | No | usgs-volcanoes only: true keeps volcanoes above normal. | |
| forecast | No | false drops modelled future values. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description carries the full burden and does real work: it discloses the returned fields, notes readings are 'current', and explains the failure mode for sources under non-commercial, restricted, or unreviewed licences (an error naming the licence). It still omits auth requirements, rate limits, and pagination behavior for the limit parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler, and the payoff (what you get back) is front-loaded ahead of the edge case (licence refusals). The provenance parenthetical is information-dense rather than redundant.
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 17-parameter tool with no annotations and no output schema, the description compensates well by describing the return shape in lieu of an output schema and flagging the licence-error path. Remaining gaps are the absence of auth/rate-limit guidance and any note on how narrow the parameter set is per source.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and every parameter (including source-specific ones like usgs, bbox, coops, elevated, window) is documented inline with source applicability and examples. The description adds only the vague hint that one source is selected, 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 and resource ('Fetch current readings') plus scope ('from one source'), and enumerates what each reading contains (value, unit, summary, place, provenance). That scope word cleanly separates it from the list_*/search_* siblings and from get_source/get_layer, which imply metadata or layered data rather than point readings.
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 never says when to reach for this tool versus get_source, get_dataset_part, or get_layer, nor does it state prerequisites such as needing a fetchable source id first. The only conditional text is about licence-error responses, which is error behavior, not usage routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One catalogue entry in full.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, yet it discloses nothing beyond a vague notion of completeness: no behavior on missing/invalid id, no permission or scope requirements, no error semantics, and no indication of what 'in full' actually includes.
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?
It is short, but this is under-specification rather than conciseness: a four-word fragment with no verb and no front-loaded actionable information. Brevity here does not earn a good score because nothing useful was compressed.
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 retrieval tool with no annotations, no output schema, and an undocumented parameter, the description is completely inadequate; an agent cannot know what it gets back, what the id must look like, or how it relates to the other source-related 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?
The single required parameter 'id' has 0% schema description coverage and the description adds no meaning whatsoever, not even that the id identifies a specific source or where it comes from. Compensation for the coverage gap is entirely absent.
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 fragment 'One catalogue entry in full' has no verb and does not use the tool's own resource name ('source'), instead calling it a 'catalogue entry', which leaves an agent inferring that get_source returns a single source record. It only weakly distinguishes itself from search_sources or the list_* siblings via the singular/full-record implication.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to call this versus search_sources or the list_* siblings, no prerequisite (e.g. needing an id from a prior search), and no exclusion conditions. Nothing in the description tells the agent how to choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Static public datasets this server holds as GeoJSON (wildfire burn perimeters, public-land share by county, federal campgrounds, fire-weather stations), with source, licence, feature count and parts (one per state, or "all").
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden. It does disclose the returned metadata (source, licence, feature count, parts) and marks the data as 'static public', implying read-only, non-mutating behavior. It says nothing about pagination, size, or that parts must be downloaded separately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that leads with the resource and then lists concrete examples and returned fields. The parenthetical enumerations are dense but each one aids disambiguation, so nothing is wasted despite the length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description partially compensates by naming the fields returned (source, licence, feature count, parts). For a zero-parameter listing tool this is nearly sufficient, though the exact shape of each dataset entry and how parts map to get_dataset_part is left implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4; there is nothing for the description to clarify about inputs, and it correctly spends its words on the output shape instead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource concretely (static public datasets served as GeoJSON) and enumerates the catalog contents — wildfire perimeters, public-land share, campgrounds, fire-weather stations — so an agent knows exactly what this returns. It does not explicitly name sibling alternatives, but the mention of 'parts (one per state, or "all")' gestures at the relationship with get_dataset_part.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the description reads like a catalog enumeration, so an agent can infer this is the discovery entry point before fetching a part. It never states when to prefer this over get_dataset_part or the other get_* siblings, and there are no prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Projects and catalogues that collect sources (God's Eye View, World Monitor, the MCP Registry, Source Cooperative, ...), with how each relates to this one.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden, and it does add one useful trait: results include 'how each [hub] relates to this one,' implying context-relative output. Beyond that it says nothing about read-only nature, result size, ordering, or pagination for what is presumably a complete enumeration.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that opens with the resource definition and appends the relationship clause. The parenthetical example list is slightly bulky but earns its place by disambiguating a coined term.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-annotation, no-output-schema list tool, the description defines the entity but leaves the return shape only half-specified: what a 'relationship to this one' looks like, ordering, and completeness are unstated. Adequate to call the tool, thin for interpreting its output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. The schema is empty, leaving nothing for the description to compensate for.
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 defines the unfamiliar resource 'hubs' concretely — projects and catalogues that collect sources — and grounds it with named examples (God's Eye View, World Monitor, MCP Registry, Source Cooperative). The listing verb is carried by the name rather than the text, and it never contrasts itself with siblings such as list_datasets or search_sources, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no when-not-to-use, and no mention of alternatives among the eight sibling tools. An agent must infer from the name alone that this is the entry point for browsing hub-level collections.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Map layers this server can draw as GeoJSON, with unit, source, licence, whether it is available here, and how to read it.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full disclosure burden. It helpfully enumerates the returned attributes (unit, source, licence, availability, how to read it), which compensates for the missing output schema, but says nothing about permissions, rate limits, or pagination behavior for a listing call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence that front-loads what is being returned and then lists the payload fields. Every clause carries information; there is no filler.
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 parameterless, non-mutating listing tool with no output schema, the description adequately covers what comes back by naming the returned fields. Only minor gaps remain (pagination, volume of results, ordering).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline of 4 applies. There are no arguments whose semantics the description would need to clarify.
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?
Names a specific verb (list) and resource (map layers) and further scopes it with the server's own drawing capability, so an agent can tell it apart from the singular get_layer. It does not explicitly contrast itself with list_datasets or list_hubs, so it stops short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the verb 'list' — enumerate the available map layers — but there is no statement of when to call this versus get_layer for a single layer, nor any preconditions or exclusions. The agent must infer the selection rule from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Named places the fetchers read for, with their upstream ids (CO-OPS station, USGS gauge, eBird region) and tags.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, yet it only discloses content (upstream id types, tags). It says nothing about read-only semantics, result size, pagination, sorting, or whether the fetcher relationship implies any auth or rate constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight fragment with no filler and the key content (upstream ids, tags) front-loaded. It is a noun phrase without a verb, but nothing is wasted.
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 one-param lister with no output schema, the description covers what the records contain, which is the main thing missing from structured fields. It still omits the filter semantics of 'tag' and any guidance on scope relative to the other list/search 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?
The single optional 'tag' parameter has 0% schema description coverage, and the description only obliquely references 'tags' as a returned attribute rather than explaining that tag filters the list (exact match? multiple? case sensitivity?). The one parameter that most needs explanation is left ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource ('named places the fetchers read for') and what comes back with each (upstream ids and tags), so an agent knows what this tool yields. It does not, however, distinguish itself from sibling listers like list_layers, list_hubs, or search_sources, which leaves some selection ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to call this versus list_layers/list_hubs or search_sources, and no mention that the optional tag parameter can filter results. Usage is only inferable from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the catalogue of public data sources (weather, water, hazards, flights, ships, energy, filings, trade, ...). Each entry gives the API, coverage, cadence, auth needed and licence. Use it to find where a kind of data comes from before writing a fetcher.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Words matched against name, id, coverage, topics and licence note. | |
| topic | No | One topic, e.g. weather, water, fires, flights, energy. | |
| license | No | ||
| fetchable | No | true: only sources this server can fetch now; false: only catalogued ones. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It usefully discloses that each entry includes API, coverage, cadence, auth and licence — which tells the agent what auth/access information it will get back — but says nothing about the search's own behavior (pagination, result limits, default ordering).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste, with the resource scope front-loaded and the usage cue attached to it. Every clause 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?
For a read-only search with no output schema, the description is adequately complete: it explains what the catalogue covers and what fields each entry returns, so the agent knows what it will get. Only the search-side behavior (limits, ordering) is left implicit.
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 75%, so the schema already documents query, topic and fetchable. The description adds no filter semantics beyond what the schema provides, and the enum-valued license parameter has no description in the schema that the prose compensates for. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (search) and resource (catalogue of public data sources), with the domain scope spelled out (weather, water, hazards, flights, ships, energy, filings, trade). It is distinguishable from get_source/list_datasets by the explicit 'search' framing, though it never names a sibling to sharpen that contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use it to find where a kind of data comes from before writing a fetcher' gives a concrete triggering situation and intent. No exclusions or named alternatives are offered, but the context is clear enough to select correctly.
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_layer2 fields changedInput schema / properties / id / enumPrevious value: -[
- "temperature",
- "wind",
- "pressure_change",
- "snow_depth",
- "wsi",
- "water_level",
- "river_flow",
- "ice",
- "sightings",
- "volcanoes",
- "flood_gauges",
- "epa_facilities",
- "recalls",
- "contract_awards",
- "wildlife",
- "natural_events",
- "world_bank",
- "earthquakes_emsc",
- "tropical_cyclones",
- "power_plants",
- "eu_industrial_production",
- "fema_declarations",
- "earthquakes",
- "lock_traffic",
- "border_crossings",
- "toxic_releases",
- "power_emissions",
- "river_discharge",
- "air_quality",
- "volcanoes_world",
- "lock_delays",
- "snowpack",
- "drought",
- "storm_reports",
- "wildfire_incidents",
- "aircraft",
- "military_aircraft",
- "gps_interference",
- "weather_alerts",
- "reservoirs_west",
- "ships_baltic",
- "quake_corroboration",
- "fire_corroboration",
- "fires",
- "persistent_heat",
- "steel_plant_heat"
-]New value: +[
+ "temperature",
+ "wind",
+ "pressure_change",
+ "snow_depth",
+ "wsi",
+ "water_level",
+ "river_flow",
+ "ice",
+ "sightings",
+ "volcanoes",
+ "flood_gauges",
+ "epa_facilities",
+ "recalls",
+ "contract_awards",
+ "wildlife",
+ "natural_events",
+ "world_bank",
+ "earthquakes_emsc",
+ "tropical_cyclones",
+ "power_plants",
+ "eu_industrial_production",
+ "fema_declarations",
+ "earthquakes",
+ "lock_traffic",
+ "border_crossings",
+ "toxic_releases",
+ "power_emissions",
+ "river_discharge",
+ "air_quality",
+ "volcanoes_world",
+ "lock_delays",
+ "snowpack",
+ "drought",
+ "storm_reports",
+ "wildfire_incidents",
+ "aircraft",
+ "military_aircraft",
+ "gps_interference",
+ "weather_alerts",
+ "reservoirs_west",
+ "ships_baltic",
+ "data_centers",
+ "quake_corroboration",
+ "fire_corroboration",
+ "fires",
+ "persistent_heat",
+ "steel_plant_heat",
+ "cement_plant_heat",
+ "chemical_plant_heat",
+ "oil_gas_field_heat"
+]Input schema / properties / operatorAdded value: +{
+ "description": "data_centers: operator, e.g. Microsoft",
+ "type": "string"
+}get_layer3 fields changedInput schema / properties / id / enumPrevious value: -[
- "temperature",
- "wind",
- "pressure_change",
- "snow_depth",
- "wsi",
- "water_level",
- "river_flow",
- "ice",
- "sightings",
- "volcanoes",
- "flood_gauges",
- "epa_facilities",
- "recalls",
- "contract_awards",
- "wildlife",
- "natural_events",
- "world_bank",
- "earthquakes_emsc",
- "tropical_cyclones",
- "power_plants",
- "eu_industrial_production",
- "fema_declarations",
- "earthquakes",
- "lock_traffic",
- "border_crossings",
- "toxic_releases",
- "power_emissions",
- "river_discharge",
- "air_quality",
- "volcanoes_world",
- "lock_delays",
- "snowpack",
- "drought",
- "storm_reports",
- "wildfire_incidents",
- "aircraft",
- "military_aircraft",
- "gps_interference",
- "weather_alerts",
- "fires",
- "persistent_heat",
- "steel_plant_heat"
-]New value: +[
+ "temperature",
+ "wind",
+ "pressure_change",
+ "snow_depth",
+ "wsi",
+ "water_level",
+ "river_flow",
+ "ice",
+ "sightings",
+ "volcanoes",
+ "flood_gauges",
+ "epa_facilities",
+ "recalls",
+ "contract_awards",
+ "wildlife",
+ "natural_events",
+ "world_bank",
+ "earthquakes_emsc",
+ "tropical_cyclones",
+ "power_plants",
+ "eu_industrial_production",
+ "fema_declarations",
+ "earthquakes",
+ "lock_traffic",
+ "border_crossings",
+ "toxic_releases",
+ "power_emissions",
+ "river_discharge",
+ "air_quality",
+ "volcanoes_world",
+ "lock_delays",
+ "snowpack",
+ "drought",
+ "storm_reports",
+ "wildfire_incidents",
+ "aircraft",
+ "military_aircraft",
+ "gps_interference",
+ "weather_alerts",
+ "reservoirs_west",
+ "ships_baltic",
+ "quake_corroboration",
+ "fire_corroboration",
+ "fires",
+ "persistent_heat",
+ "steel_plant_heat"
+]Input schema / properties / regionAdded value: +{
+ "description": "reservoirs_west: a Reclamation region, e.g. Missouri Basin",
+ "type": "string"
+}Input schema / properties / typeAdded value: +{
+ "description": "ships_baltic: cargo | tanker | passenger | fishing | tug | other",
+ "type": "string"
+}get_layer4 fields changedInput schema / properties / eventAdded value: +{
+ "description": "weather_alerts: an NWS event name, e.g. Red Flag Warning",
+ "type": "string"
+}Input schema / properties / id / enumPrevious value: -[
- "temperature",
- "wind",
- "pressure_change",
- "snow_depth",
- "wsi",
- "water_level",
- "river_flow",
- "ice",
- "sightings",
- "volcanoes",
- "flood_gauges",
- "epa_facilities",
- "recalls",
- "contract_awards",
- "wildlife",
- "natural_events",
- "world_bank",
- "earthquakes_emsc",
- "tropical_cyclones",
- "power_plants",
- "eu_industrial_production",
- "fema_declarations",
- "earthquakes",
- "lock_traffic",
- "border_crossings",
- "toxic_releases",
- "power_emissions",
- "river_discharge",
- "air_quality",
- "volcanoes_world",
- "lock_delays",
- "snowpack",
- "drought",
- "storm_reports",
- "wildfire_incidents",
- "aircraft",
- "military_aircraft",
- "gps_interference"
-]New value: +[
+ "temperature",
+ "wind",
+ "pressure_change",
+ "snow_depth",
+ "wsi",
+ "water_level",
+ "river_flow",
+ "ice",
+ "sightings",
+ "volcanoes",
+ "flood_gauges",
+ "epa_facilities",
+ "recalls",
+ "contract_awards",
+ "wildlife",
+ "natural_events",
+ "world_bank",
+ "earthquakes_emsc",
+ "tropical_cyclones",
+ "power_plants",
+ "eu_industrial_production",
+ "fema_declarations",
+ "earthquakes",
+ "lock_traffic",
+ "border_crossings",
+ "toxic_releases",
+ "power_emissions",
+ "river_discharge",
+ "air_quality",
+ "volcanoes_world",
+ "lock_delays",
+ "snowpack",
+ "drought",
+ "storm_reports",
+ "wildfire_incidents",
+ "aircraft",
+ "military_aircraft",
+ "gps_interference",
+ "weather_alerts",
+ "fires",
+ "persistent_heat",
+ "steel_plant_heat"
+]Input schema / properties / kindAdded value: +{
+ "description": "weather_alerts: warning | watch | advisory",
+ "type": "string"
+}Input schema / properties / marineAdded value: +{
+ "description": "weather_alerts: include marine alerts",
+ "type": "boolean"
+}get_layer2 fields changedInput schema / properties / id / enumPrevious value: -[
- "temperature",
- "wind",
- "pressure_change",
- "snow_depth",
- "wsi",
- "water_level",
- "river_flow",
- "ice",
- "sightings",
- "volcanoes",
- "flood_gauges",
- "epa_facilities",
- "recalls",
- "contract_awards",
- "wildlife",
- "natural_events",
- "world_bank",
- "earthquakes_emsc",
- "tropical_cyclones",
- "power_plants",
- "eu_industrial_production",
- "fema_declarations",
- "earthquakes",
- "lock_traffic",
- "border_crossings",
- "toxic_releases",
- "power_emissions",
- "river_discharge",
- "air_quality",
- "volcanoes_world",
- "lock_delays",
- "snowpack",
- "drought",
- "storm_reports",
- "wildfire_incidents"
-]New value: +[
+ "temperature",
+ "wind",
+ "pressure_change",
+ "snow_depth",
+ "wsi",
+ "water_level",
+ "river_flow",
+ "ice",
+ "sightings",
+ "volcanoes",
+ "flood_gauges",
+ "epa_facilities",
+ "recalls",
+ "contract_awards",
+ "wildlife",
+ "natural_events",
+ "world_bank",
+ "earthquakes_emsc",
+ "tropical_cyclones",
+ "power_plants",
+ "eu_industrial_production",
+ "fema_declarations",
+ "earthquakes",
+ "lock_traffic",
+ "border_crossings",
+ "toxic_releases",
+ "power_emissions",
+ "river_discharge",
+ "air_quality",
+ "volcanoes_world",
+ "lock_delays",
+ "snowpack",
+ "drought",
+ "storm_reports",
+ "wildfire_incidents",
+ "aircraft",
+ "military_aircraft",
+ "gps_interference"
+]Input schema / properties / radiusAdded value: +{
+ "description": "aircraft, gps_interference: nautical miles around lat/lng, 1-250",
+ "type": "number"
+}get_layer5 fields changedInput schema / properties / continuingAdded value: +{
+ "description": "volcanoes_world: only eruptions in progress",
+ "type": "boolean"
+}Input schema / properties / erupted_sinceAdded value: +{
+ "description": "volcanoes_world: year, default 1900",
+ "type": "number"
+}Input schema / properties / fuel / descriptionAdded value: +"power_plants: coal, oil/gas, nuclear, hydropower, wind, utility-scale solar, geothermal or bioenergy"Input schema / properties / id / enumPrevious value: -[
- "temperature",
- "wind",
- "pressure_change",
- "snow_depth",
- "wsi",
- "water_level",
- "river_flow",
- "ice",
- "sightings",
- "volcanoes",
- "flood_gauges",
- "epa_facilities",
- "recalls",
- "contract_awards",
- "wildlife",
- "natural_events",
- "world_bank",
- "earthquakes_emsc",
- "tropical_cyclones",
- "power_plants",
- "eu_industrial_production",
- "fema_declarations",
- "earthquakes"
-]New value: +[
+ "temperature",
+ "wind",
+ "pressure_change",
+ "snow_depth",
+ "wsi",
+ "water_level",
+ "river_flow",
+ "ice",
+ "sightings",
+ "volcanoes",
+ "flood_gauges",
+ "epa_facilities",
+ "recalls",
+ "contract_awards",
+ "wildlife",
+ "natural_events",
+ "world_bank",
+ "earthquakes_emsc",
+ "tropical_cyclones",
+ "power_plants",
+ "eu_industrial_production",
+ "fema_declarations",
+ "earthquakes",
+ "lock_traffic",
+ "border_crossings",
+ "toxic_releases",
+ "power_emissions",
+ "river_discharge",
+ "air_quality",
+ "volcanoes_world",
+ "lock_delays",
+ "snowpack",
+ "drought",
+ "storm_reports",
+ "wildfire_incidents"
+]Input schema / properties / statusAdded value: +{
+ "description": "power_plants: operating | construction",
+ "type": "string"
+}get_layer5 fields changedInput schema / properties / countryAdded value: +{
+ "description": "power_plants: ISO alpha-3, e.g. DEU",
+ "type": "string"
+}Input schema / properties / fuelAdded value: +{
+ "type": "string"
+}Input schema / properties / id / enumPrevious value: -[
- "temperature",
- "wind",
- "pressure_change",
- "snow_depth",
- "wsi",
- "water_level",
- "river_flow",
- "ice",
- "sightings",
- "volcanoes",
- "flood_gauges",
- "epa_facilities",
- "recalls",
- "contract_awards",
- "wildlife",
- "natural_events",
- "world_bank",
- "earthquakes"
-]New value: +[
+ "temperature",
+ "wind",
+ "pressure_change",
+ "snow_depth",
+ "wsi",
+ "water_level",
+ "river_flow",
+ "ice",
+ "sightings",
+ "volcanoes",
+ "flood_gauges",
+ "epa_facilities",
+ "recalls",
+ "contract_awards",
+ "wildlife",
+ "natural_events",
+ "world_bank",
+ "earthquakes_emsc",
+ "tropical_cyclones",
+ "power_plants",
+ "eu_industrial_production",
+ "fema_declarations",
+ "earthquakes"
+]Input schema / properties / indicatorAdded value: +{
+ "type": "string"
+}Input schema / properties / min_mwAdded value: +{
+ "type": "number"
+}get_dataset_partget_layerget_readingsget_sourcelist_datasetslist_hubslist_layerslist_placessearch_sourcesWeather, air quality and nearest live sensors anywhere, each with a signed receipt. Free, no key.
Sources in, feeds out: an open, ever-growing database of real-time public data, enriched.
Access UK flood warnings, river levels, water quality, Met Office forecasts, and carbon data
Weather, climate, terrain, fire and flood risk data for any point or polygon on Earth. Free tier.
Add one secure layer between your agents and this server.
