Skip to main content
Glama

BusCalc — Business & Trade Calculations

NOAA and NWS observations, forecast and data quality

buscalc_weather_data_lookup
Read-only

Fetch nationwide US NWS hourly forecasts, nearby station observations and active official alerts, or NOAA CO-OPS coastal water level. Checks up to three nearby NWS stations, with official Aviation Weather Center METAR observation fallback when primary readings are missing or delayed. Fallback readings are at most 90 minutes old and within 80 miles; source, station, distance and observation time are explicit. Supplemental gust, precipitation/snow/ice accumulation and visibility forecasts retain native valid intervals where available. Missing observation fields can have separately attributed recent station supplements; original station records remain intact. Compatible grid periods may fill missing hourly forecast fields with per-field provenance. Independent product failures remain explicit; no invented probabilities. Coordinates rounded to 0.01 degree before provider lookup. Five-minute cache; source timestamps, missing values, quality flags and errors retained. Full future hours only, up to 168 returned. Not a calculation success, safety assurance or executable market price. No user job data sent upstream. Put tool fields inside inputs. Supply units or modelVersion only when listed in inputSchema. Follow its required fields and exact choices. Do not pass the REST calculator field inside MCP arguments.

Example tool call

This call uses example arguments supplied in the tool’s input schema.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "inputs": {
        "kind": "location",
        "latitude": 34.17,
        "longitude": -86.84
      }
    },
    "name": "buscalc_weather_data_lookup"
  }
}

Input Schema

NameRequiredDescriptionDefault
unitsNo
inputsYes
modelVersionNo

Output Schema

NameRequiredDescriptionDefault
kindYes
notesYes
sourceYes
coastalNo
qualityYes
forecastNo
sourceURLYes
calculatorYes
observationNo
retrievedAtYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior5/5

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

Annotations only declare readOnly/openWorld/non-idempotent/non-destructive; the description goes far beyond them with fallback chain behavior (Aviation Weather Center METAR), staleness and radius bounds (90 minutes, 80 miles), cache TTL, 168-hour return cap, coordinate rounding, per-field provenance, and explicit 'no invented probabilities'. These are exactly the operational traits an agent cannot get from annotations.

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

Conciseness3/5

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

The purpose is front-loaded, but the remainder is a dense run-on stream mixing provenance rules, disclaimers and invocation mechanics without any grouping. Most sentences carry real information, though the disclaimer sentence about calculation success and market prices is padding for a weather lookup.

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?

An output schema exists, so return values need not be explained here, and the description still covers fallback, provenance, caching, staleness and invocation wrapping. The chief omission is guidance on the nested 'inputs' object's alternate forms beyond what the oneOf already shows.

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

Parameters3/5

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

Schema description coverage is 0%, so the description must carry parameter meaning and only partly does. It clarifies the 'inputs' wrapper, warns against the REST calculator field, and constrains units/modelVersion to what appears in inputSchema, but never explains the latitude/longitude semantics or what the effectively-empty 'units' object accepts.

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?

Opens with a specific verb and resource set: 'Fetch nationwide US NWS hourly forecasts, nearby station observations and active official alerts, or NOAA CO-OPS coastal water level.' This maps cleanly onto the two oneOf branches (location vs coastal) and distinguishes it from the calculation siblings, which the description explicitly says this is not.

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?

Usage context is clear: nationwide US weather observations/forecasts, with an explicit negative boundary ('Not a calculation success, safety assurance or executable market price') that steers calculation intent elsewhere. It stops short of naming a concrete alternative sibling or stating when to prefer buscalc_weather_operational_calculations.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources