A
licenseA
qualityD
maintenanceReal-time weather, forecasts, astronomy, marine data for 200+ countries
2
11
9 npm
1
MIT
Vertical Weather
Server Details
Wind, temperature, pressure, humidity and air density at chosen heights, from NOAA GFS.
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
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
A4.2/5.0
Scored across 3 tools
Disambiguation5/5
Each tool serves a clearly distinct purpose: retrieving atmospheric data, checking capabilities, and monitoring usage. There is no overlap or chance of confusing one tool with another.
Naming Consistency5/5
All tool names follow a consistent 'get_' plus noun pattern, making the set predictable and easy to navigate. The naming style is uniform and descriptive.
Tool Count5/5
Three tools is well-scoped for a focused vertical weather data server. Each tool earns its place—one for the core data, two for essential metadata and quota management.
Completeness5/5
The server covers the essential operations for its domain: fetching atmospheric profiles, understanding what data is available, and tracking usage. There are no obvious gaps for its stated purpose.
Available Tools
3 toolsget_atmospheric_profileGet an atmospheric profileARead-onlyInspect
Wind, temperature, pressure, humidity and air density at chosen heights above a point.
Each level has wind_u_ms (towards east), wind_v_ms (towards north), wind_speed_ms,
wind_direction_deg (where the wind comes FROM, clockwise from north; 0 at zero speed
means calm), temperature_k, pressure_pa, specific_humidity_kg_kg, relative_humidity_pct
and density_kg_m3. valid_time is the model time actually used; provenance names the
GFS run and grid point. Heights outside the model column are refused with the range
that is available.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| time | Yes | ISO 8601 timestamp with a timezone, e.g. 2026-10-03T18:00:00Z. Up to 14 days ahead or about ten days back. | |
| latitude | Yes | Decimal degrees, north positive. | |
| longitude | Yes | Decimal degrees, east positive. | |
| altitudes_m | Yes | 1 to 32 different heights in metres. | |
| altitude_reference | Yes | agl: heights above ground level. msl: heights above mean sea level. | |
| ground_elevation_m_msl | No | Optional site elevation in metres above sea level, used for agl heights instead of the model's terrain. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A3.9/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the description adds value by detailing output fields, error behavior (heights outside the model column are refused with the available range), and provenance info (GFS run and grid point). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear summary sentence followed by a detailed field explanation. It is appropriately sized for the complexity, though the field list is slightly verbose, it remains front-loaded and informative.
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?
Given the output schema exists and the schema covers parameters, the description adds necessary context about output fields and error handling. It is complete enough for an agent to call correctly, with no missing critical information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does not add significant parameter semantics beyond the schema; it focuses on output fields rather than input parameters, and the schema already thoroughly documents each parameter.
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 returns atmospheric variables (wind, temperature, pressure, humidity, density) at specified heights above a point. It is specific and distinguishes from sibling tools (get_capabilities, get_usage) by its focus on vertical profiles, leaving no ambiguity about what it does.
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 explains what the tool does but does not explicitly state when to use it versus alternatives or any prerequisites. It implies usage for obtaining atmospheric profiles but lacks exclusions or alternative routing, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_capabilitiesGet capabilitiesARead-onlyInspect
Current coverage (time range, heights, fields) and usage limits. No API key needed.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A3.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the description adds value by noting that no API key is required and that the data represents current coverage. This is useful behavioral context beyond the structured annotations, with 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?
The description is a single well-structured sentence, front-loaded with the most important scope information ('Current coverage') and ending with a concise auth note. No filler or redundant wording.
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?
For a zero-parameter read-only tool with an output schema, the description conveys the essential purpose and auth requirement. It does not mention how to select it over get_usage, but that gap is already captured under usage guidelines.
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, so the schema is inherently complete and the description does not need to document inputs. The baseline of 4 applies; there is nothing semantically missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies what the tool reports: current coverage (time range, heights, fields) and usage limits. It names the resource and scope specifically, though it does not explicitly differentiate it from the sibling tool get_usage, which likely overlaps on usage limits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus get_usage or get_atmospheric_profile. The only usage-related statement is 'No API key needed,' which is a useful prerequisite but does not help an agent choose among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_usageGet usageARead-onlyInspect
Today's data-fetch count and remaining daily allowance for the caller's account (UTC day).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A3.7/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so this is a safe, non-mutating, open-world read. The description adds the UTC day context, which clarifies the timezone of the allowance, but does not explain nuances like whether count/reset are per-account or per-day specifics beyond UTC. Since annotations cover the safety profile, a 3 is appropriate.
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, clear sentence that immediately states what is counted and the time frame (UTC day). No wasted words, and the key information (data-fetch count and remaining allowance) is front-loaded.
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?
Given the lack of parameters and the output schema's existence (which likely details return structure), the description is sufficient for an agent to understand the tool's purpose and call it. It could benefit from noting that no arguments are needed, but the schema already conveys that. Overall, complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the schema provides no property descriptions. With 0 parameters, the baseline is 4 because there is nothing to document. The description does not need to add parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: it retrieves the caller's daily data-fetch count and remaining allowance. It specifies the resource ('caller's account') and the metric (usage), and it is distinct from siblings that deal with atmospheric profiles or capabilities. However, it could be more explicit that it is a read-only usage report.
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 that this tool is used to check data-fetch usage, which is useful for avoiding rate limits, but it does not explicitly state when to use it vs. alternatives or any exclusions. Sibling tools have different purposes, so the context is clear for this singleton tool, but no explicit guidance is given.
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.
3 tool updates
- First observed
get_atmospheric_profile - First observed
get_capabilities - First observed
get_usage
Related MCP Connectors
Weather data, forecast API, climate data, historical weather, alerts, agricultural & travel weather.
Weather forecasts from MET Norway (Yr): geocoding plus hourly forecasts worldwide.
MET Norway (api.met.no) MCP — global weather, Nordics specials.
Global weather API: forecasts, historical data, marine, ski, astronomy and timezone.
Related MCP Servers
- AlicenseAqualityDmaintenanceWindAI MCP Server — AI-powered wind resource assessment for any location on Earth.53 npm1MIT
- AlicenseNot gradedqualityAmaintenanceGeocode places, fetch global weather forecasts, ERA5 historical climate, marine conditions, air quality, and terrain elevation via MCP. Provides 11 tools over STDIO or Streamable HTTP.476 npm8Apache 2.0
- AlicenseNot gradedqualityDmaintenanceGlobal weather intelligence for AI assistants providing 10 weather tools — forecasts, historical data, air quality, marine, geocoding, elevation, and climate projections at 1km resolution with 80+ years of archive.1MIT
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd
Glama MCP Gateway
Add one secure layer between your agents and this server.