Skip to main content
Glama

World Monitor

by app.worldmonitor

get_climate_data

Read-onlyIdempotent

Climate intelligence: temperature/precipitation anomalies (vs 30-year WMO normals), climate-relevant disaster alerts (Re

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoCap each list dataset (anomalies, disasters, stations, news, alerts) to at most this many items (default 30, pass 0 for no cap).
countryNoFilter the country-tagged datasets (climate disasters, air-quality stations) to one ISO 3166-1 alpha-2 code.
datasetNoRestrict the response to one or more climate sub-datasets. Omit for the full bundle.
summaryNoReturn counts + 3-item samples instead of full lists. Useful when you only need shape/size or want to budget context before drilling in.
jmespathNoOptional JMESPath projection applied to the response. See initialize.instructions for grammar and examples.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataYes
staleYesTrue when any contributing cache key fails its freshness contract: fetched longer ago than its per-key maxStaleMin budget, below a declared minRecordCount, or — for keys that declare a content-age contract — carrying upstream observations older than maxContentAgeMin even though the fetch itself is recent. A recent cached_at with stale:true means the fetch is current but the underlying data has stopped advancing, so refetching will not help.
cached_atYesISO-8601 timestamp of the OLDEST contributing cache key, or null when no valid seed-meta is present.
activationUnknownNoOptional. True when an activation marker this tool consults could not be read, so `stale` was computed without knowing whether the producer has ever published. Distinguishes an unreadable marker from a producer that genuinely never ran — the same signal /api/health and /api/seed-health publish under this name.
contentFreshnessPendingUntilNoOptional ISO-8601 deadline while a cleanly absent content-freshness block is temporarily covered by deployment-order grace.

TDQS

B3.1/5.0
Behavior3/5

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

Annotations already declare read-only, idempotent, non-destructive, so the description only needs to add behavioral context. It adds useful detail about 30-year WMO baselines and climate-relevant disaster alerts, but is truncated and does not describe bundle behavior or data freshness. It does not contradict the 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 existing text is brief and front-loaded, but it is an incomplete fragment ending in '(Re' rather than a finished sentence. It contains no wasted words, yet the truncation is a structural defect.

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

Completeness3/5

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

The rich input schema, output schema, and annotations cover parameter semantics and safety. However, the description under-represents the full dataset bundle: the schema lists seven datasets while the description mentions only two. It also offers no routing guidance, leaving the overall picture incomplete for an agent choosing among many siblings.

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% and all five parameters have descriptions, so the baseline is 3. The tool description adds no parameter-level details beyond mentioning anomaly and alert content, but none are needed because the schema already documents limit, country, dataset, summary, and jmespath.

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 identifies concrete resources — temperature/precipitation anomalies benchmarked against 30-year WMO normals and climate-relevant disaster alerts — so an agent can tell this is a climate-data retrieval tool. It lacks an explicit verb and does not differentiate from overlapping siblings like get_natural_disasters or get_temporal_anomalies, and the text appears truncated after 'disaster alerts (Re'.

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?

No guidance is given for when to call this tool instead of the many climate-adjacent siblings, such as get_natural_disasters or get_alert_digest. The description states content but no conditional selection criteria or exclusions.

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

All World Monitor toolsInspect
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.

TDQS

C2.7/5.0
Disambiguation2/5

Tool purposes overlap in several clusters: generate_forecasts vs get_forecast_predictions, get_airspace vs get_aviation_status, and get_focal_points/get_hotpot_escalation/get_signal_convergence are all threshold/crossing detectors. While most get_* tools name a distinct source or domain, these blurred boundaries will lead agents to incorrectly select among similar-sounding tools, especially across 69 options.

Naming Consistency4/5

The dominant get_<domain>_<noun> convention is clear and readable, and most country/EU/data tools follow it consistently. Exceptions like analyze_situation, generate_forecasts, search_flight_prices_by_date, and list_x_feed break the pattern but remain understandable rather than chaotic.

Tool Count1/5

Sixty-nine tools is an extreme surface for any MCP server; even a global intelligence monitor should be split into focused sub-servers. The count is inflated by one-off datasets (Toronto police, flight price search) and overlapping predictive/alert tools, making selection costly and coherence hard to maintain.

Completeness3/5

The server covers an unusually broad range of domains—conflict, macro, energy, climate, health, cyber, aviation, maritime, and trade—so core data retrieval is extensive. However, there are noticeable gaps: no direct event/article detail retrieval by ID, no country-list enumeration, and several orphaned datasets lack surrounding operations or context.

Resources