Your Air Is a Service
#kairair#api#mcp#developers#open-data#building-in-public
David Olsson
A weather network that ends at its own map is a museum. Nice to look at, closed on the important question: then what?
The whole reason to gather air data from many backyards is so someone can do something with the aggregate — a researcher correlating a neighbourhood's microclimate, a developer building a frost alarm, a student asking whether the valley really does trap cold air the way everyone says. None of that happens if the data is trapped behind a pretty interface. The map is where the network shows off. The API is where it becomes useful.
So KAIRair treats its data as a service from the start, not as an export you beg for later.
the research API
The front door for builders is a key-authenticated developer API — a clean, versioned surface (/api/v1) that returns the network's data as JSON you can build against.
Two design choices in there matter more than they look.
The first is that it's key-authenticated and rate-limited. You provision an API key — a single active key you manage yourself, shown to you once and yours to rotate — and every request carries it. That's not gatekeeping for its own sake; it's what lets the network stay open and accountable. Open data doesn't have to mean anonymous scraping. A key means access can be generous and still fair — the rate limits keep one enthusiastic script from starving everyone else, and the network can tell its users apart without making them jump through hoops.
The second is that it's versioned. The v1 in the path is a promise: build against this and I won't move it under you. A research API that silently changes shape is worse than no API, because it breaks the very projects that trusted it. Versioning is how you tell developers you mean it.
The point of the whole thing is to make the network's air yours to compute on. Pull the readings, join them to your own data, ask questions the map can't answer. The network gathers; you get to reason.
a live stream, not just a poll
Reading the past is one mode. Watching the present is another.
Under the hood, telemetry flows in from stations and fans out live — the public map updates in real time because it's fed by a live channel, not by refreshing a page. That same real-time posture is what makes a station's experience feel alive rather than periodically stale, and it's the shape a genuine air network wants: not "here's a snapshot from whenever you last asked," but "here's what the air is doing right now, as it changes."
Messaging like this is also the honest bridge to the network's next stage. A backyard fleet talking over lightweight messaging is exactly the architecture that scales past ten stations to hundreds — many small devices, publishing to one place, with subscribers (a map, a logger, a research pipeline) listening in. Some of that is live today and some of it is the road ahead, and I'll keep being clear in this series about which is which. But the direction is set: the network is built to be subscribed to, not just visited.
the part that surprises people: an MCP
Here's the interface I didn't expect to be building for a weather network, and now can't imagine it without.
KAIRair has an MCP server — a way for an AI assistant, like Claude, to talk to the network directly. MCP (the Model Context Protocol) is the plumbing that lets an assistant call real tools instead of guessing. Point an assistant at KAIRair's MCP and you can just ask: what's the warmest station right now, how has the pressure moved across the network today, which stations went quiet. The assistant queries the live network and answers from real data.
Think about what that does to the audience for the data. The research API is for people who write code. The MCP is for everyone else — anyone who can ask a question in a sentence. It collapses the distance between "I wonder" and "here's the answer from live sensors," with no query language in between. The person curious about their valley's cold air doesn't have to become a developer to interrogate the network. They can converse with it.
That's not a gimmick bolted onto a data product. It's a recognition that the most valuable interface to a pile of readings, for most people, is a conversation — and that an air network worth building should be answerable in plain language, not just in JSON.
own your data, and let others build on it
Pull these together — a keyed research API, a live stream, an MCP — and you get the thesis of this post.
On most connected-sensor platforms, your data is the platform's asset, and you're renting a view of it. KAIRair runs the other way. The hosts own their stations. The network's data is meant to be reached — queried, subscribed to, conversed with — by the people it belongs to and the people who'd build something good on top of it. Self-hostable, key-fair, versioned, and answerable in a sentence.
A weather network that only shows you a map answers one question: what's the weather. A weather network that's also a service answers a much better one: what could you learn from everyone's air at once?
That question is the whole reason to gather it in the first place.
Part nine of the KAIRair build series. Previous: What a Host Does, What a Host Gets. Next: weather you can feel — the experience platform that turns a station's live readings into an installable, ambient scene.