Crosby, TX Weather

Server Details

Crosby, TX weather, air quality, tropics, floods, fishing, pollen, burn bans, radar, news & schools.

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
Last Tested: 2026-09-12 15:31
Transport: Streamable HTTP
URL
Repository: reloru/new-relo
GitHub Stars: 1

TDQS

A4.4/5.0

Scored 2026-09-10 22:59 across 14 tools

Disambiguation5/5

Each of the 14 tools targets a distinct aspect of weather or local information for Crosby, TX—air quality, alerts, burn bans, news, current conditions, emergency contacts, fishing conditions, forecast, pollen, radar, river levels, school events, traffic, and tropical outlook. There is no overlap that would cause an agent to select the wrong tool; even similar topics like fishing and river levels are clearly differentiated (water quality vs. flood stage).

Naming Consistency5/5

All tool names follow a uniform verb_noun pattern using snake_case: get_air_quality, get_alerts, get_burn_ban, etc. The prefix 'get_' is consistent, and the nouns are specific and descriptive, making the naming pattern predictable and easy to navigate.

Tool Count5/5

With 14 tools, the server is well-scoped for a comprehensive local weather and community information hub. Each tool provides a distinct, non-redundant capability, and the count falls within the ideal 3–15 range, avoiding both sparseness and bloat.

Completeness5/5

The set covers all major weather-related needs (current, forecast, radar, alerts, air quality, pollen, tropical), plus local essentials (traffic, river levels, burn ban, school events, emergency contacts, fishing, news). There are no obvious dead ends—every query type a user might have for this domain is addressed, and the read-only nature is consistent with a weather/information server.

Available Tools

14 tools

get_air_qualityAir quality (AQI)A

Read-onlyIdempotent

Inspect

Current U.S. Air Quality Index for the Houston metro area (the Houston-Galveston-Brazoria reporting area, which includes Crosby, TX). Measured by EPA/AirNow monitors when available (measured:true), with an Open-Meteo modeled fallback (measured:false). Regional, not a Crosby-pinpoint reading.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`updated`	No	ISO 8601 timestamp of the last data refresh.
`location`	Yes
`airQuality`	Yes

TDQS

A4.7/5.0

Behavior5/5

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

Discloses data source priority (EPA/AirNow with Open-Meteo fallback), measured flag behavior, and regional scope. Adds significant value beyond annotations which only indicate safety and idempotency.

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 short sentences, front-loaded with purpose, every word adds value. No redundancy.

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

Completeness5/5

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

With no parameters, comprehensive annotations, and an output schema present, the description fully covers the tool's purpose, data source, and scope.

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?

No parameters exist; schema coverage is 100%. Baseline score 4 applies as the description does not need to add parameter details.

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?

Clearly states it provides the current U.S. Air Quality Index for the Houston metro area, with specific geographic detail and data source explanation. Differentiates from siblings by specifying regional scope.

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?

Implicitly guides usage by stating it is regional and not a pinpoint reading, which helps an agent decide when to use it vs more localized tools. Lacks explicit when-not or alternative names.

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

get_alertsActive alertsA

Read-onlyIdempotent

Inspect

Active NWS weather alerts for Crosby, TX. Returns an empty list when none are active.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	Yes
`alerts`	Yes
`location`	Yes

TDQS

A4.3/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description's burden is lower. It adds context that the tool returns an empty list when no alerts are active, which is useful but not extensive. 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?

The description is two sentences, front-loaded with the core purpose. Every word is necessary and there is no redundancy or filler.

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 no parameters, a simple read operation, and an output schema present, the description covers all essential information: what the tool returns (active alerts) and the edge case (empty list when none active). No gaps remain.

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?

The tool has no parameters, and schema coverage is 100%. The description does not need to add parameter details. The baseline for no parameters is 4, and the description is adequate.

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 it retrieves active NWS weather alerts for a specific location (Crosby, TX). The verb 'get' and resource 'alerts' are specific, and the location scoping distinguishes it from sibling tools that retrieve other types of data (air quality, news, etc.).

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 does not explicitly state when to use this tool versus alternatives, but the purpose is self-evident from the name and sibling tool names. The description indicates it returns an empty list when no alerts are active, implying it should be used to check for active alerts in that area.

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

get_burn_banBurn ban statusA

Read-onlyIdempotent

Inspect

Current outdoor-burning ban status for Harris County, TX (which includes Crosby) from the Texas A&M Forest Service. Countywide only — TFS has no sub-county resolution, so this is never a Crosby-specific status.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`county`	Yes	Always "Harris".
`source`	Yes
`status`	No	"Yes" = ban in effect, "No" = no active ban, null = status unavailable from the last check.
`startDate`	No	ISO date-time the current ban took effect, as reported by TFS; null when there is no active ban.
`lastChecked`	No	ISO 8601 timestamp of the last data refresh.
`officialUrl`	No
`statusSince`	No	When the CURRENT status was first observed. Equal to trackingSince means no change has ever been witnessed — it is when observation began, NOT a transition date.
`trackingSince`	No	The first observation ever recorded for this feed.

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already cover readOnly and non-destructive behavior. The description adds value beyond those by revealing the external data source, the countywide granularity, and the fact that no sub-county resolution exists. This helps the agent calibrate expectations 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?

Two sentences: the first establishes resource, location, and source; the second adds an important scope caveat. Every clause contributes useful information with no filler.

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 zero-parameter, read-only tool with an output schema and annotations already enriching safety and behavioral hints, this description is complete. An agent can correctly select and invoke the tool, and understand its limitations.

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?

The tool has zero parameters, and the schema coverage is 100%, so there is nothing meaningful the description needs to add. This matches the 0-parameter baseline.

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

Purpose5/5

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

States a specific resource ('outdoor-burning ban status'), location (Harris County, TX), and data source (Texas A&M Forest Service), so an agent can clearly tell it apart from sibling tools like get_alerts or get_current_conditions. The note about Crosby and countywide scope makes the purpose even clearer.

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 explicitly indicates when this tool should be used: for current outdoor-burning ban status in Harris County, TX. It also clearly states the limitation that this is never a Crosby-specific status. It does not name alternative sibling tools, so it stops short of full 'use X instead' guidance.

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

get_crosby_newsLocal newsA

Read-onlyIdempotent

Inspect

Recent local news headlines for Crosby, TX and nearby northeast Harris County communities, aggregated from public sources and filtered for relevance. Empty when nothing recent.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`items`	Yes
`source`	No
`updated`	No	ISO 8601 timestamp of the last data refresh.
`location`	No

TDQS

A4.7/5.0

Behavior5/5

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

Description adds value beyond annotations: explains source (public sources, filtered) and behavior (empty when nothing recent). Annotations already indicate safety.

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 front-loaded with core purpose, no fluff.

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?

Fully covers purpose, scope, and edge case (empty result). Output schema exists, so return details are not required.

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?

No parameters defined; baseline 4 applies as description need not add parameter info.

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?

Description clearly states it provides recent local news headlines for a specific geographic area, distinguishing it from sibling tools like get_alerts or get_traffic.

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?

Description implies usage for latest local news with an empty result when none recent. No explicit when-not or alternatives, but sibling context provides clarity.

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

get_current_conditionsCurrent conditionsA

Read-onlyIdempotent

Inspect

Current weather for Crosby, TX: temperature, feels-like, sky, precip chance, humidity, dew point, UV index, measured air quality (EPA/AirNow, Houston metro area), and sunrise/sunset.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`uv`	No	EPA UV index; null at night or when the EPA feed is down.
`sun`	No
`current`	No	An NWS forecast period, passed through (startTime, temperature, shortForecast, windSpeed, probabilityOfPrecipitation, ...) plus computed feelsLike °F where applicable. Full schema: https://crosbynews.com/openapi.json Adds dewpointF and humidityPercent.
`updated`	No	ISO 8601 timestamp of the last data refresh.
`location`	Yes
`airQuality`	No	US AQI. measured:true = EPA/AirNow monitors (Houston metro reporting area incl. Crosby); measured:false = Open-Meteo modeled fallback. Regional, not Crosby-pinpoint either way.

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already indicate readOnlyHint, idempotentHint, etc. Description adds specific data sources (EPA/AirNow for Houston metro area) and includes sunrise/sunset, which are not obvious from annotations. No contradiction.

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?

Single sentence listing all key outputs. Every word adds value. Extremely concise and 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?

Tool has output schema, and description covers all listed data fields. Scope (Crosby, TX) is clear. No further details needed.

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?

No parameters, so schema coverage is 100% by default. Description does not need to add parameter info. Baseline 4 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?

Description clearly states it provides current weather conditions for Crosby, TX, listing specific metrics (temperature, feels-like, sky, etc.). This distinguishes it from sibling tools like get_forecast (future) and get_air_quality (air quality only).

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?

No explicit when to use or alternatives are given. However, the listed data points imply it's for a comprehensive current snapshot. An agent can infer usage from sibling tool names but description lacks direct guidance.

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

get_emergency_contactsEmergency contactsA

Read-onlyIdempotent

Inspect

Emergency resource directory for Crosby, TX (unincorporated Harris County): 911 guidance, sheriff non-emergency, power-outage and gas-leak reporting, the CAER industrial-incident line, flood and road tools, shelters, and disaster assistance. Static verified directory — in a life-threatening emergency, call 911.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`note`	No
`location`	No
`sections`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that it is 'static verified directory', providing extra behavioral context 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?

Two sentences that are front-loaded with location and purpose. No wasted words; every sentence provides essential 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?

For a simple no-parameter tool with an output schema (presumably listing contacts), the description is complete enough. It specifies the geographic scope and types of resources.

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?

No parameters exist, so schema covers 100%. The description adds meaning by detailing the contents of the directory, which compensates for the lack of 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 it is an 'Emergency resource directory' for Crosby, TX, listing specific resources like 911 guidance, sheriff, power outage, etc. It distinguishes itself from sibling tools (weather, news, traffic, etc.) by being focused on emergency contacts.

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 explicitly says 'in a life-threatening emergency, call 911', guiding when to use this tool versus not. It implies usage for non-emergency directory lookup, though it doesn't explicitly compare to siblings, the context is clear.

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

get_fishingFishing conditionsA

Read-onlyIdempotent

Inspect

Live water conditions for the waters people fish near Crosby, TX — Lake Houston, the San Jacinto River forks, the Trinity River, and nearby bayous — from USGS real-time monitoring. Full stations report temperature, dissolved oxygen, pH, and turbidity; some fished bayous report water level only. A nearby-station reading, not the exact fishing spot, and conditions rather than a guaranteed bite.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`note`	No
`source`	No
`updated`	No	ISO 8601 timestamp of the last data refresh.
`location`	No
`stations`	Yes

TDQS

A4.5/5.0

Behavior5/5

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

The description adds significant context beyond annotations: it notes data is from nearby stations (not exact spots), varies by station (full vs. limited parameters), and does not guarantee a bite. This clarifies limitations and behavioral expectations.

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 sentences with no unnecessary words. The first sentence covers the core purpose and scope; the second adds critical qualifiers. Information is front-loaded and easy to parse.

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 no parameters and an output schema exists, the description provides all necessary context: what data is included, sources, variability, and limitations. No gaps remain.

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?

No parameters exist; baseline for 0 parameters is 4. The description adds no parameter info because none are needed.

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 specifies exactly what the tool does (live water conditions for fishing near Crosby, TX), lists specific water bodies, and mentions data sources (USGS). It clearly distinguishes itself from siblings like get_air_quality or get_forecast by focusing on fishing-related water conditions.

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?

The description implies usage for fishing but does not explicitly state when to use this tool versus alternatives like get_river_levels. No exclusion criteria or alternative tool comparisons are provided.

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

get_forecastForecastA

Read-onlyIdempotent

Inspect

Forecast for Crosby, TX from the U.S. National Weather Service. Returns the 7-day day/night forecast, or upcoming hourly periods if hours is given (up to 48 — through about two days out).

ParametersJSON Schema

Name	Required	Description	Default
`hours`	No	Return this many upcoming hourly periods instead of the daily forecast.

Output Schema

ParametersJSON Schema

Name	Required	Description
`hourly`	No	Upcoming hourly periods (only when `hours` was given).
`forecast`	No	7-day day/night periods (daily mode).
`location`	Yes

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 and idempotent behavior. Description adds value by specifying the data source (U.S. NWS) and output format (7-day day/night or hourly up to 48 periods). 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?

Two sentences efficiently convey core purpose, source, location, output options, and parameter effect. No 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 tool's simplicity (one optional parameter, clear output schema), the description fully covers what the agent needs: source, location, output options, and parameter usage. Annotations handle behavioral transparency.

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?

The single parameter `hours` is already well-described in the schema (limit 1-48). The description reinforces its purpose and adds context ('through about two days out'), providing marginal additional clarity 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?

Clearly states the tool returns a forecast from the U.S. National Weather Service for Crosby, TX. Differentiates from sibling tools like get_current_conditions by specifying it's a forecast, either daily or hourly.

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?

Explains when to use daily vs hourly forecast via the `hours` parameter. While it doesn't explicitly exclude alternatives, the context is clear enough that the tool is for forecasts, not current conditions or other weather data.

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

get_pollenPollen & mold countA

Read-onlyIdempotent

Inspect

The Houston Health Department's measured daily pollen and mold count (National Allergy Bureau scale) — tree, weed, and grass pollen plus mold spores, with the species actually counted. A real measurement, not a model; counts publish weekday mornings and apply regionally to Crosby, TX.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`groups`	Yes	tree / weed / grass / mold — each null when that reading was missing from the day's report.
`source`	Yes
`species`	No	Per-group list of the types counted above zero, as the lab names them.
`updated`	No	ISO 8601 timestamp of the last data refresh.
`location`	No
`measured`	No
`countDate`	No	Calendar date (Central time) the count is for; weekends carry Friday's count.
`officialUrl`	No

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint. The description adds valuable behavioral context: it is a real measurement published weekday mornings, regionally applied to Crosby, TX. This goes beyond annotations without contradiction.

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 two sentences with comprehensive detail, but slightly verbose. All information is necessary for understanding the tool's purpose and behavior.

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 zero parameters and an output schema (not shown), the description is fully complete. It explains the source, scale, types, region, and publication schedule, leaving no ambiguity about what the tool returns.

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

Parameters5/5

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

There are no parameters, so schema coverage is 100%. The description adds meaning by detailing what the output contains (types of pollen and mold spores), which compensates for the lack of 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 retrieves measured daily pollen and mold counts from the Houston Health Department, specifying types (tree, weed, grass, mold spores) and that it includes species counted. It distinguishes itself from siblings like get_air_quality by emphasizing it is a real measurement, not a model.

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 clear context for when to use this tool (for real pollen/mold counts in the Houston/Crosby, TX region) but does not explicitly exclude alternatives or mention when not to use it. The context is sufficient for an agent to infer appropriate usage.

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

get_radarWeather radar imageA

Read-onlyIdempotent

Inspect

Latest NWS KHGX (Houston/Galveston) radar still image covering Crosby, TX, returned inline as a GIF. For the animated loop, see https://crosbynews.com/radar.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds minimal extra: format (GIF) and source (NWS KHGX). Acceptable but not rich.

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 sentences, no fluff. Front-loaded with purpose, second sentence provides alternative. Highly efficient.

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

Completeness4/5

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

Adequate for a no-parameter, read-only tool. Missing potential details like image size or update frequency, but overall sufficient given simplicity.

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?

No parameters exist, baseline is 4. Description adds no parameter info because unnecessary.

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?

Clearly states it returns the latest NWS KHGX radar still image as a GIF covering Crosby, TX. Distinguishes from siblings like get_forecast or get_current_conditions by specifying location and format.

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?

Provides explicit alternative for animated loop via URL. Does not compare to sibling tools but gives clear context that this is for still images only.

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

get_river_levelsRiver & bayou levelsA

Read-onlyIdempotent

Inspect

Current water levels and NWS flood stages for the rivers and bayous that flood Crosby, TX and northeast Harris County (Cedar Bayou, San Jacinto River, Luce Bayou, and more). Each gauge reports its stage, flow, flood category, and thresholds.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`gauges`	Yes
`source`	No
`updated`	No	ISO 8601 timestamp of the last data refresh.
`location`	No

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds value by specifying the data reported (stage, flow, flood category, thresholds) and the geographic scope, providing behavioral context 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?

Description is two sentences, front-loaded with the key purpose and geographic context. Every word earns its place—no redundancy or fluff.

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 has no parameters, an output schema, and simple behavior, the description fully covers what the tool does and what data it returns. The geographic scope and listed waterways provide sufficient context for a user to decide if this tool meets their needs.

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 zero parameters, the tool has no input schema burden. The description compensates by detailing the output information (stage, flow, flood category, thresholds) for the listed waterways, aligning with the high schema description coverage (100%).

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?

Description clearly states the tool provides current water levels and NWS flood stages for specific rivers and bayous in Crosby, TX and northeast Harris County, listing examples. This specific verb-resource pair and geographic scope distinguish it well from sibling tools like get_air_quality or get_traffic.

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?

No explicit guidance on when to use this tool versus alternatives. The context of flood monitoring is implied by the description, but it lacks clear 'when not to use' or references to sibling tools for comparison.

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

get_school_eventsSchool calendarA

Read-onlyIdempotent

Inspect

Upcoming Crosby ISD school-calendar events: first/last day of school, holidays, no-school and early-release days, testing windows, and campus activities.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum events to return (default 15).

Output Schema

ParametersJSON Schema

Name	Required	Description
`events`	Yes
`source`	No
`updated`	No	ISO 8601 timestamp of the last data refresh.
`district`	No
`timezone`	No

TDQS

A3.7/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, which fully cover the safety profile. The description adds no behavioral context beyond what annotations provide, such as caching behavior or limit effects.

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 a single, front-loaded sentence that efficiently conveys the tool's purpose without any wasted words. Every element is justified.

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 simple parameter set (one optional integer), an output schema exists (not shown but present), and the description lists typical event types, the definition is complete for a straightforward read-only tool.

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?

There is one parameter (limit) with 100% schema description coverage, so the schema already fully documents it. The description does not add any additional semantic meaning beyond the schema's existing explanation.

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?

Description clearly specifies what the tool does: return upcoming Crosby ISD school calendar events. It lists specific event types (first/last day, holidays, early-release days, testing windows, campus activities) and distinguishes itself from sibling tools like get_crosby_news or get_alerts by focusing solely on school calendar data.

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?

The description implies usage for school calendar events but provides no explicit guidance on when to use this tool versus alternatives. Sibling tools exist for other informational purposes, but no when-not-to-use or alternative recommendations are given.

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

get_trafficRoads & trafficA

Read-onlyIdempotent

Inspect

Live traffic incidents and scheduled lane closures on the roads Crosby, TX drives — US-90, FM-2100, FM-1942, and the Crosby stretch of IH-10 East — from Houston TranStar, plus links to the corridor traffic cameras. High-water road reports appear here during floods. Empty lists mean quiet roads.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`area`	Yes
`source`	Yes
`cameras`	No	Corridor cameras — pageUrl links TranStar's own camera pages (images are not embedded).
`updated`	No	ISO 8601 timestamp of the last data refresh.
`incidents`	No	Empty = no monitored incidents (the normal state); null = the incidents feed was unreachable at the last refresh.
`liveMapUrl`	No
`laneClosures`	No	Scheduled closures; empty = none, null = feed unreachable at the last refresh.

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, etc. Description adds data source, camera links, and behavior for empty lists ('Empty lists mean quiet roads') and flood reporting. 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?

Single sentence plus a brief note on empty lists. Every part adds value; no fluff. Front-loaded with key action and scope.

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 zero parameters and an output schema, the description fully covers purpose, behavior, and data sources. Complete for this tool's capabilities.

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?

No parameters; baseline for 0 params is 4. Description adds meaning about what the tool returns (e.g., incident types, camera links, flood reports), which is helpful beyond the empty 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?

Clearly states the tool returns live traffic incidents, scheduled lane closures, and high-water reports on specific roads (US-90, FM-2100, etc.) with source (Houston TranStar) and camera links. Distinct from siblings like get_air_quality or get_alerts.

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?

Implies usage for traffic info on specific roads, but no explicit when-to-use or when-not-to-use compared to siblings. No alternative tools mentioned.

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

get_tropical_outlookAtlantic tropical outlookA

Read-onlyIdempotent

Inspect

Active Atlantic tropical cyclones from the NOAA National Hurricane Center, AND the areas it is watching for development that do not have names yet, with their formation chances. Covers hurricane season (June–November) for Crosby, TX. Returns an explicit all-clear only when there are neither — a quiet CurrentStorms list does not by itself mean a quiet basin.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`basin`	Yes
`source`	No
`storms`	Yes	Named/numbered cyclones only. Empty is common and does NOT imply nothing is brewing — check `disturbances` too.
`updated`	No	ISO 8601 timestamp of the last data refresh.
`disturbances`	No	Areas the NHC is watching for development but has NOT named — the shaded areas on its graphical outlook. `null` means the outlook could not be read; `[]` means the NHC is watching nothing. Do not conflate the two, and do not report a formation chance as a storm or as a forecast track.
`outlookIssued`	No	ISO 8601 timestamp of the last data refresh.

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds critical behavior beyond annotations: it explains that an empty CurrentStorms list does NOT mean a quiet basin — you must check the 'areas watching' section and the explicit all-clear condition. This prevents agent misinterpretation of the output schema.

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 sentences, each earning its place: scope, source, and an important edge-case clarification about the all-clear. Front-loaded with the key resource (Atlantic tropical cyclones). Zero filler, highly efficient.

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?

No parameters, output schema exists, and annotations cover the safety profile. The description addresses the most plausible pitfall (misinterpreting an empty CurrentStorms list). Even though it doesn't describe the output format, the output schema fills that gap. Complete for an agent to call correctly.

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?

The schema has zero parameters, so the baseline is 4. The description correctly refrains from adding parameter info. It doesn't harm; the score is based on the absence of any need. No added value needed.

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

Purpose5/5

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

States a specific verb ('Get'), resource ('Atlantic tropical outlook'), and scope (active cyclones + unnamed development areas from NOAA NHC, with formation chances). Clearly distinguishes from sibling weather tools like get_forecast and get_current_conditions by narrowing to tropical cyclones and Atlantic basin coverage.

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?

Specifies the season (June–November) and location (Crosby, TX), which tells the agent when this tool is relevant. Doesn't explicitly name alternatives to exclude, but the specificity of 'Atlantic tropical cyclones' plus sibling names makes the use case clear. Slight deduction for not explicitly stating 'use only during hurricane season for tropical info vs. other weather tools'.

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 updateAug 25, 2026

Changedget_tropical_outlook3 fields changed

addedOutput schema / properties / disturbances

Added value: +{
+  "description": "Areas the NHC is watching for development but has NOT named — the shaded areas on its graphical outlook. `null` means the outlook could not be read; `[]` means the NHC is watching nothing. Do not conflate the two, and do not report a formation chance as a storm or as a forecast track.",
+  "items": {
+    "properties": {
+      "area": {
+        "description": "NHC's own name for the area, in official English.",
+        "type": "string"
+      },
+      "chance48Category": {
+        "description": "low / medium / high, NHC's own wording.",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "chance48Percent": {
+        "type": [
+          "integer",
+          "null"
+        ]
+      },
+      "chance7DayCategory": {
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "chance7DayPercent": {
+        "type": [
+          "integer",
+          "null"
+        ]
+      },
+      "id": {
+        "description": "Invest number when assigned, e.g. \"AL95\".",
+        "type": [
+          "string",
+          "null"
+        ]
+      }
+    },
+    "type": "object"
+  },
+  "type": [
+    "array",
+    "null"
+  ]
+}

addedOutput schema / properties / outlookIssued

Added value: +{
+  "description": "ISO 8601 timestamp of the last data refresh.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

changedOutput schema / properties / storms / description

Previous value: -"Empty when the basin is quiet — the normal state most of the year."New value: +"Named/numbered cyclones only. Empty is common and does NOT imply nothing is brewing — check `disturbances` too."

1 tool updateAug 24, 2026

Changedget_burn_ban3 fields changed

changedOutput schema / properties / startDate / description

Previous value: -"ISO date-time the current ban took effect; null when there is no active ban."New value: +"ISO date-time the current ban took effect, as reported by TFS; null when there is no active ban."

addedOutput schema / properties / statusSince

Added value: +{
+  "description": "When the CURRENT status was first observed. Equal to trackingSince means no change has ever been witnessed — it is when observation began, NOT a transition date.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / trackingSince

Added value: +{
+  "description": "The first observation ever recorded for this feed.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

1 tool updateAug 23, 2026
- Addedget_burn_ban
1 tool updateJul 21, 2026
- Addedget_fishing

2 tool updatesJul 19, 2026

Addedget_air_quality

Changedget_current_conditions4 fields changed

changedOutput schema / properties / airQuality / description

Previous value: -"US AQI — MODELED (Open-Meteo), not a monitor reading; always labeled modeled:true."New value: +"US AQI. measured:true = EPA/AirNow monitors (Houston metro reporting area incl. Crosby); measured:false = Open-Meteo modeled fallback. Regional, not Crosby-pinpoint either way."

addedOutput schema / properties / airQuality / properties / measured
```
Added value: +{
+  "type": "boolean"
+}
```
removedOutput schema / properties / airQuality / properties / modeled
```
Removed value: -{
-  "type": "boolean"
-}
```
addedOutput schema / properties / airQuality / properties / reportingArea
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```

1 tool updateJul 17, 2026
- Addedget_pollen
1 tool updateJul 16, 2026
- Addedget_traffic

9 tool updatesJul 14, 2026

Changedget_alerts1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "alerts": {
+      "items": {
+        "properties": {
+          "event": {
+            "type": "string"
+          },
+          "expires": {
+            "type": "string"
+          },
+          "headline": {
+            "type": "string"
+          },
+          "severity": {
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "count": {
+      "type": "integer"
+    },
+    "location": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "location",
+    "count",
+    "alerts"
+  ],
+  "type": "object"
+}

Changedget_crosby_news1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "items": {
+      "items": {
+        "properties": {
+          "category": {
+            "description": "community or incident",
+            "type": "string"
+          },
+          "link": {
+            "type": "string"
+          },
+          "published": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "source": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "title": {
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "location": {
+      "type": "string"
+    },
+    "source": {
+      "type": "string"
+    },
+    "updated": {
+      "description": "ISO 8601 timestamp of the last data refresh.",
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "required": [
+    "items"
+  ],
+  "type": "object"
+}

Changedget_current_conditions1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "airQuality": {
+      "description": "US AQI — MODELED (Open-Meteo), not a monitor reading; always labeled modeled:true.",
+      "properties": {
+        "category": {
+          "type": "string"
+        },
+        "dominantPollutant": {
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "modeled": {
+          "type": "boolean"
+        },
+        "usAqi": {
+          "type": "integer"
+        }
+      },
+      "type": [
+        "object",
+        "null"
+      ]
+    },
+    "current": {
+      "description": "An NWS forecast period, passed through (startTime, temperature, shortForecast, windSpeed, probabilityOfPrecipitation, ...) plus computed feelsLike °F where applicable. Full schema: https://crosbynews.com/openapi.json Adds dewpointF and humidityPercent.",
+      "type": "object"
+    },
+    "location": {
+      "type": "string"
+    },
+    "sun": {
+      "properties": {
+        "sunrise": {
+          "type": "string"
+        },
+        "sunset": {
+          "type": "string"
+        }
+      },
+      "type": [
+        "object",
+        "null"
+      ]
+    },
+    "updated": {
+      "description": "ISO 8601 timestamp of the last data refresh.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "uv": {
+      "description": "EPA UV index; null at night or when the EPA feed is down.",
+      "properties": {
+        "current": {
+          "type": "integer"
+        },
+        "currentCategory": {
+          "type": "string"
+        },
+        "peakToday": {
+          "type": [
+            "integer",
+            "null"
+          ]
+        }
+      },
+      "type": [
+        "object",
+        "null"
+      ]
+    }
+  },
+  "required": [
+    "location"
+  ],
+  "type": "object"
+}

Addedget_emergency_contacts

Changedget_forecast2 fields changed

changedInput schema / properties / hours / maximum
```
Previous value: -12New value: +48
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "forecast": {
+      "description": "7-day day/night periods (daily mode).",
+      "items": {
+        "description": "An NWS forecast period, passed through (startTime, temperature, shortForecast, windSpeed, probabilityOfPrecipitation, ...) plus computed feelsLike °F where applicable. Full schema: https://crosbynews.com/openapi.json",
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "hourly": {
+      "description": "Upcoming hourly periods (only when `hours` was given).",
+      "items": {
+        "description": "An NWS forecast period, passed through (startTime, temperature, shortForecast, windSpeed, probabilityOfPrecipitation, ...) plus computed feelsLike °F where applicable. Full schema: https://crosbynews.com/openapi.json",
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "location": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "location"
+  ],
+  "type": "object"
+}

Addedget_radar

Changedget_river_levels1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "gauges": {
+      "items": {
+        "properties": {
+          "category": {
+            "description": "no_flooding/action/minor/moderate/major, or not_defined where NWS defines no flood stages.",
+            "type": "string"
+          },
+          "flow": {
+            "description": "Observed discharge in cfs.",
+            "type": [
+              "number",
+              "null"
+            ]
+          },
+          "id": {
+            "type": "string"
+          },
+          "name": {
+            "type": "string"
+          },
+          "officialUrl": {
+            "type": "string"
+          },
+          "stage": {
+            "description": "Observed gauge height in ft.",
+            "type": [
+              "number",
+              "null"
+            ]
+          },
+          "thresholds": {
+            "description": "NWS flood-stage thresholds in ft, keyed action/minor/moderate/major.",
+            "type": "object"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "location": {
+      "type": "string"
+    },
+    "source": {
+      "type": "string"
+    },
+    "updated": {
+      "description": "ISO 8601 timestamp of the last data refresh.",
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "required": [
+    "gauges"
+  ],
+  "type": "object"
+}

Changedget_school_events1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "district": {
+      "type": "string"
+    },
+    "events": {
+      "items": {
+        "properties": {
+          "allDay": {
+            "type": "boolean"
+          },
+          "end": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "location": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "start": {
+            "description": "All-day: YYYY-MM-DD. Timed: zone-less ISO local time (America/Chicago wall-clock).",
+            "type": "string"
+          },
+          "summary": {
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "source": {
+      "type": "string"
+    },
+    "timezone": {
+      "type": "string"
+    },
+    "updated": {
+      "description": "ISO 8601 timestamp of the last data refresh.",
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "required": [
+    "events"
+  ],
+  "type": "object"
+}

Addedget_tropical_outlook

6 tool updatesJul 13, 2026
- First observedget_alerts
- First observedget_crosby_news
- First observedget_current_conditions
- First observedget_forecast
- First observedget_river_levels
- First observedget_school_events

Related MCP Connectors

Weather & Climate Intelligence MCP A
io.github.FoundryNet
Weather data, forecast API, climate data, historical weather, alerts, agricultural & travel weather.
Weather Services Location Services
2
Smarter Weather A
io.github.smarterweather
Smarter Weather MCP: forecasts, alerts, outlooks, observations, AQI, grids, and map imagery.
Weather Services Location Services
3221
weathersight
io.weathersight
Historical weather and climate: 100+ years of station data, normals, extremes, and trends.
Weather Services Open Data
1
nws-weather-mcp-server A
io.github.cyanheads
Get US weather forecasts, active alerts, and current observations.
Weather Services Government Data Open Data
721

Related MCP Servers

WeatherAPI MCP Server
Weather Services Location Services Search
weatherapicom
A
license
A
quality
D
maintenance
Real-time weather, forecasts, astronomy, marine data for 200+ countries
Updated 6 months ago (2026-03-22 21:54 UTC)
2
11
11
1
MIT
MCP Weather Server
Weather Services Search Location Services
1broseidon
A
license
Not graded
quality
D
maintenance
Provides real-time weather information and multi-day forecasts for global locations using city names, coordinates, or ZIP codes. It includes tools for current conditions, forecasting, and weather summaries designed for activity planning.
Updated a year ago (2025-09-11 22:24 UTC)
7
MIT
NWS Weather MCP Sample
Weather Services Open Data
tumuml28
F
license
B
quality
C
maintenance
Provides weather forecast and alert tools using the National Weather Service API.
Updated 2 months ago (2026-07-25 01:31 UTC)
2
-
Weather MCP Server
Weather Services Open Data Government Data
andresilvase
A
license
Not graded
quality
B
maintenance
Retrieves weather alerts and forecasts from the National Weather Service API.
Updated 13 days ago (2026-08-30 22:23 UTC)
44
GPL 3.0

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Server Details

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Related MCP Connectors

Related MCP Servers

Glama MCP Gateway

Resources