Smarter Weather

Get time context

get_time_context

Read-onlyIdempotent

Complete temporal context for a location: local time, timezone, 14-day calendar with day names and Today/Tomorrow offsets, sunrise/sunset/solar times (from the weather pipeline's astro product), and moon phase. Use whenever you need to reason about dates, times, or daylight for a location -- including "what time is sunset?", "is it dark there now?", or "what day of the week is the 4th-day forecast?". If current_time.timezone_resolved is false, zone unknown: state times as UTC, never as local. Accepts a place name directly. Example: {"location": "Seattle, WA"}.

Input Schema

Name	Required	Description
`lat`	No	Latitude in decimal degrees (-90 to 90). Most tools also accept a `location` place-name string instead of lat/lon.
`lon`	No	Longitude in decimal degrees (-180 to 180). For continental US use negative values (west of the prime meridian).
`location`	No	Free-text place: "City, ST" (e.g. "Portland, OR"), US ZIP, venue/address where enabled, or "lat,lon". Use this OR lat+lon, not both.

Output Schema

Name	Required	Description	Default
`moon`	Yes
`calendar`	Yes
`daylight`	Yes
`location`	Yes
`current_time`	Yes

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#"

Changed5 schema fields changedOct 22, 2026
- removedInput schema / additionalProperties
```
Removed value: -false
```
- addedOutput schema / properties / calendar / items / properties
```
Added value: +{}
```
- addedOutput schema / properties / current_time / properties
```
Added value: +{}
```
- addedOutput schema / properties / daylight / properties
```
Added value: +{}
```
- addedOutput schema / properties / moon / properties
```
Added value: +{}
```

Changed1 schema field changedOct 16, 2026

changedInput schema / properties / location / description

Previous value: -"Free-text place: city (\"Denver\"), city+state (\"Portland, OR\"), US ZIP, venue/address where enabled, or \"lat,lon\". Use this OR lat+lon, not both."New value: +"Free-text place: \"City, ST\" (e.g. \"Portland, OR\"), US ZIP, venue/address where enabled, or \"lat,lon\". Use this OR lat+lon, not both."

Changed2 schema fields changedOct 14, 2026

changedInput schema / properties / location / description

Previous value: -"Free-text place: city (\"Denver\"), city+state (\"Portland, OR\"), US ZIP (\"50219\"), or \"lat,lon\" (\"39.74,-104.99\"). Provide either this OR explicit lat+lon, not both."New value: +"Free-text place: city (\"Denver\"), city+state (\"Portland, OR\"), US ZIP, venue/address where enabled, or \"lat,lon\". Use this OR lat+lon, not both."

addedOutput schema / properties / location / properties / matched_via

Added value: +{
+  "enum": [
+    "autosuggest",
+    "fuzzy"
+  ],
+  "type": "string"
+}

First observedJul 14, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds genuinely non-obvious behavior: the fallback rule when current_time.timezone_resolved is false (report as UTC, never local) and the provenance of solar data via the weather pipeline's astro product.

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 sentences are front-loaded with the returned content and then the usage triggers, so the key information lands early. It is dense but nearly every clause carries useful detail, with only slight redundancy in the example after the schema already explains the location parameter.

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, so return-value structure need not be explained. Given that, the description is complete for a 3-param, zero-required, open-world lookup tool: it covers contents, invocation triggers, the timezone-unknown edge case, and accepted input forms.

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 100%, so lat, lon, and location are already fully documented, including the 'use this OR lat+lon' rule. The description only restates that a place name is accepted and adds a small example payload, which is marginal value over the 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?

The description names a specific resource and enumerates its contents: local time, timezone, 14-day calendar with Today/Tomorrow offsets, sunrise/sunset/solar times, and moon phase. This clearly separates it from siblings like get_current_conditions or get_forecast, which cover weather rather than temporal context.

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?

It gives explicit triggering conditions ('Use whenever you need to reason about dates, times, or daylight') plus three concrete example questions that map to the tool. It lacks an explicit exclusion or named alternative for overlapping cases, but the usage context is strong.

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.