Gale — the agent inside the platform, now an API your product can embed — alongside the MCP server and Custom Vector Events.
Most weather decisions never happen on a weather screen. They happen inside the systems an operation already runs — the dispatch software deciding which trucks roll, the claims system triaging what a storm left behind, the AI agent a team is building this quarter. This release moves three doors into that world forward at once, and the clean way to tell them apart is one question: whose agent does the thinking — and what lands in your app? Embed our agent and get back an answer. Point your own agent at our data with a request. Or take delivery of the weather itself — a payload your systems and agents work natively.
The Gale API — our agent, embedded in your product
Gale is the agent inside the Tomorrow.io platform — it has been doing the weather reasoning for our own users for some time. This release exposes that agent as an API, which means your product can embed it and hand the weather thinking over entirely.
Two new endpoints do the work. GALE-AI/Chat takes a plain-language weather question and returns an answer — aware of your account’s context, able to continue a conversation across a session, in your language, your units, your timezone. GALE-AI/Summary returns forecast summaries as plain text your application can place wherever a person needs them. For chat responses, customers with platform access also get a link that opens the answer on the map, so a conversation that starts in your tool can finish in ours when someone wants to look deeper.
The mechanism matters more than the novelty here: a customer-facing app can answer “will the storm reach the venue before the gates open?” without anyone on your team translating that into parameters first — and without your team building weather reasoning at all. The thinking is delegated. What crosses the wire is an answer.
The MCP server — your agent, our data
For teams building their own agents, the interface is the tool call — and the MCP server is how Tomorrow.io makes itself callable. It’s an MCP layer on top of our API: this release adds three tools (AI chat, AI summaries, and data feeds), bringing the set to ten, alongside real-time conditions, forecast timelines, historical weather, climate normals, weather events, and weather along a route.
The division of labor is the point. Your agent keeps the reasoning; we make the data trivial to reach — public URL, an API key, and the tools are available. No integration project, no custom wrapper, no waiting on a sprint. An agent that plans deliveries, schedules crews, or drafts an operations briefing can spin up a forecast request the same way it uses any of its other tools. What crosses the wire is a request.
Custom Vector Events — your app, our payload
Custom Vector Events is how customers have been bringing weather-triggered events into their own systems — and this release changes what an event carries when it arrives.
A CVE event now has a persistent identity: an event ID that stays with it through its lifecycle, from new, to updated, to cancelled. It carries the values behind the trigger — the minimum, maximum, and average of the parameters that fired it. And its resolution is yours to choose, configured to match your operational tempo: fewer, larger events that span wider areas and longer durations for teams that want broad coverage; many small, frequently updated events that closely track the model for teams that need precision; or a balance between the two.
Together, those three properties change what kind of thing a weather event is to your software. A response you parse once and discard is a lookup. An object with identity, state, and a lifecycle is something your systems can hold — track through your operation the way you already track a shipment or a claim, from the moment it appears to the moment it closes.
And because what arrives is vector geometry with its context attached — not a reading, a payload — it’s a shape your own agents can work natively, inside your own stack: spatial joins against your assets and territories, intersections with your network, the analysis agents are genuinely good at once the data lives where they do. The context carries forward instead of evaporating after a response.
That’s not a hypothetical pattern. A railroad joining weather events against its network, an insurer treating a storm footprint as a claim-triggering event, a drone-logistics operator deciding whether a flight window is open — operations like these are already consuming weather this way: not as a question asked at one moment, but as a thing held, and computed on, over time.
Whose agent does the thinking?
An answer, a request, a payload. Embed our agent and delegate the weather reasoning. Point your agent at our data and keep the reasoning. Take delivery of the weather itself and let your systems work it natively. Each fits a different place in a stack, and most operations will end up using more than one: an application that asks Gale on a user’s behalf, an agent that calls for a route forecast, a downstream system that joins event geometry against everything it already knows. What this release completes is the set — wherever the weather thinking should live in your stack, there’s now a door built the shape of that choice.
Two doors in
Build with APIs
The Gale API and the MCP server are self-serve. Get an API key, read the docs, and both are available today.
Evaluating CVE
That’s a conversation with our team — feeds are configured to your parameters, your geography, your resolution — and now how events aggregate, from a few consolidated events that span wide areas to many granular ones that closely follow the model — which is exactly why they’re worth setting up deliberately.
← Back to the July 2026 Release overview
▽
