Smarter Weather

Get platform status

get_platform_status

Read-onlyIdempotent

Current data-freshness status of the weather platform: overall state, per-source states (ok / degraded / outage / no_signal), open incidents with cause attribution (provider outage vs internal processing delay), and active provider advisories. Use this when a user asks whether data is current, when other tools return surprisingly stale data, or before presenting time-critical weather. If a source is degraded or in outage, tell the user their data may be stale rather than presenting it as live. No inputs. Refreshed about every 5 minutes.

Input Schema

Name	Required	Description	Default
`include_ok`	No	true: list every monitored source including healthy ones. false (default): only sources that are not ok, keeping the response compact.

Output Schema

Name	Required	Description
`note`	No
`overall`	Yes	Worst state across customer-facing data sources; "unknown" when status is unavailable.
`sources`	No
`advisories`	No
`generated_at`	No	When the status document was generated (UTC).

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 22, 2026

removedInput schema / $schema

Removed value: -"http://json-schema.org/draft-07/schema#"

removedOutput schema / $schema

Removed value: -"http://json-schema.org/draft-07/schema#"

Changed3 schema fields changedOct 22, 2026
- changedOutput schema / properties / advisories / items / additionalProperties
```
Previous value: -trueNew value: +{}
```
- changedOutput schema / properties / sources / items / additionalProperties
```
Previous value: -trueNew value: +{}
```
- changedOutput schema / properties / sources / items / properties / incident / additionalProperties
```
Previous value: -trueNew value: +{}
```
Changed3 schema fields changedSep 1, 2026
- changedOutput schema / properties / advisories / items / additionalProperties
```
Previous value: -falseNew value: +true
```
- changedOutput schema / properties / sources / items / additionalProperties
```
Previous value: -falseNew value: +true
```
- changedOutput schema / properties / sources / items / properties / incident / additionalProperties
```
Previous value: -falseNew value: +true
```
Changed1 schema field changedJul 28, 2026
- changedOutput schema / properties / sources / items / properties / incident / properties / since / type
```
Previous value: -"string"New value: +[
+  "string",
+  "number"
+]
```

Changed1 schema field changedJul 16, 2026

addedOutput schema / properties / sources / items / properties / warming

Added value: +{
+  "description": "true when no_signal only means monitoring is still warming up (not an outage).",
+  "type": "boolean"
+}

AddedJul 15, 2026

TDQS

A4.3/5.0

Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive, so the safety profile is covered. The description adds genuinely useful context the annotations cannot carry: the ~5-minute refresh cadence and the meaning of the four source states. However, it doesn't state whether incidents/advisories are always present, how far back incidents are reported, or the response's size/shape despite the include_ok toggle doing exactly that.

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 payload is front-loaded (what it returns, then when to call it, then how to interpret it, then cadence), and each sentence adds a distinct fact. No filler or restatement of the tool name.

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?

An output schema exists and annotations cover the safety profile, so the description doesn't need to explain return values. What remains — the freshness semantics, the state vocabulary, the degradation message, and the refresh interval — is all present, which is exactly enough for an agent to call and interpret this correctly.

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 the single include_ok parameter is fully documented in the schema, so the baseline applies. The description's 'No inputs' is slightly at odds with the existence of an optional parameter and could cause an agent to overlook the include_ok toggle when it wants a full source list, which is a minor loss of value rather than a gain.

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 names the specific resource and enumerates the four things it returns: overall state, per-source states, incidents with cause attribution, and provider advisories. That distinguishes it clearly from the data-fetching siblings (get_forecast, get_current_conditions), which return weather rather than platform health.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives three explicit triggers (user asks whether data is current, other tools return surprisingly stale data, before presenting time-critical weather) and adds a behavioral instruction for the degraded case: tell the user data may be stale rather than presenting it as live. That is when-to-use plus how-to-act, not just context.

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

All Smarter Weather tools Inspect

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.