APIbase

Bright Sky — Hourly Weather Observations / Forecast for Germany

brightsky.weather.observations

Read-onlyIdempotent

Retrieve hourly historical weather observations or DWD forecasts for any location in Germany by latitude, longitude, and date, with no API key required.

Instructions

Get hourly weather observations or forecast for any location in Germany from DWD (Deutscher Wetterdienst). Pass a past date to retrieve historical observations; pass a future date to retrieve the DWD numerical forecast. Each hour includes: temperature, dew point, humidity, pressure, cloud cover, visibility, precipitation, sunshine, wind speed/direction, wind gusts, precipitation probability, solar irradiance, and condition icon. Returns up to 10 days of data (240 hourly records). No API key required — open DWD data via Bright Sky (MIT licence).

Input Schema

Name	Required	Description
`date`	Yes	Start date/time for observations in ISO 8601 format (e.g. "2026-07-01" or "2026-07-01T08:00:00"). Returns historical data when date is in the past; returns DWD forecast when date is in the future.
`units`	No	Unit system: "dwd" (default) uses km/h wind and °C temperature; "si" uses m/s wind
`latitude`	Yes	Latitude of the location in Germany (e.g. 52.52 for Berlin, range 47–56)
`last_date`	No	End date/time for observations in ISO 8601 format. When omitted, returns data for the 24-hour period starting at "date". Maximum range is 10 days.
`longitude`	Yes	Longitude of the location in Germany (e.g. 13.40 for Berlin, range 5–16)

Output Schema

Name	Required	Description	Default
`error`	No	Present only when the call failed. Includes error code, message, request_id, and any provider-specific extras.
`result`	No	Tool response payload. Shape varies per tool — consult the tool description and inputSchema. May be an object, array, string, or number depending on the upstream provider response.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv2.2.0Oct 29, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds that no API key is required, data is open via Bright Sky (MIT licence), and details the data fields per hour and the 10-day/240-record limit. This goes beyond the annotations to set expectations about data scope and availability.

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 a single, well-structured paragraph. It front-loads the primary action, then explains the conditional behavior, followed by data fields and limits. Every sentence provides essential information without redundancy or fluff, though it is slightly long.

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?

With an output schema present, the description does not need to detail return formats. It covers the core usage (past/future dates), geographic scope (Germany), data content (per-hour fields), maximum range (10 days/240 hours), and access requirements (no API key). An agent can call this tool correctly with the given information. Minor lack of explicit examples or error conditions prevents a 5.

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%—all five parameters have descriptions, including the date field's past/future behavior and unit options. The description adds contextual details like the 10-day range and hourly record count, but these relate to overall behavior rather than clarifying individual parameters. Since the schema already carries the parameter semantics, a baseline of 3 is appropriate.

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 gets hourly weather observations or forecasts for any location in Germany, sourced from DWD. It explicitly explains that past dates yield historical observations and future dates yield forecasts, distinguishing it from siblings like brightsky.weather.current which provides current conditions.

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 is clearly specified: pass a past date for history, future date for forecast, and the tool returns up to 10 days of data (240 hourly records). It doesn't explicitly name alternatives like brightsky.weather.current, but the past/future distinction and hourly focus make when to use this tool clear. A more explicit 'when not to use' would elevate it to 5.

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

Deploy Server