Every week another AI agent platform ships. Almost none of them can read a building.
That asymmetry is the strangest gap in the agent ecosystem right now. The Model Context Protocol — MCP — has become the de facto way to hand an AI agent a tool: it was donated to the Linux Foundation's Agentic AI Foundation in December 2025, its SDKs see 97M+ monthly downloads, and the public registry counts more than 10,000 servers. There are MCP servers for Postgres, Stripe, Figma, your calendar, your thermostat at home. For commercial buildings — the machines that consume around 40% of the world's energy and generate some of its messiest operational data — the cupboard is nearly bare.
What exists today: one BACnet prototype
Credit where it is due: the only building-protocol MCP server we could find is ezhuk/bacnet-mcp (v0.3.7, May 2026), a clean early-stage prototype that exposes BACnet read operations to agents. It deserves more attention than its handful of stars suggests, and if BACnet is your layer, start there.
But BACnet is the transport layer, and transport was never the real bottleneck. The bottleneck is semantics (what does AHU1_SAT_2B mean?) and access (how do I get the data without touching the control network?). For the layers that address those — Project Haystack tagging, Brick Schema models, Green Button utility data — our search in June 2026 found no public MCP servers at all. Three open standards, each with years of community investment, none of them speakable by agents.
So we built the missing three as templates and are giving them away.
The three templates
Each is a single-file Python server plus a synthetic sample dataset and a README. No dependencies — stdlib only, Python 3.9+. Each one actually runs: pipe a JSON-RPC tools/list request into it and you get a valid tool catalog back. They are honest scaffolding: working JSON-RPC-over-stdio skeletons using MCP's method names and framing, with full official-SDK wiring left as a clearly marked TODO.
greenbutton-mcp parses NAESB ESPI ("Green Button") XML — the format your utility already exports — and gives agents three tools: list_usage_points, get_interval_readings, and get_usage_summary. The bundled sample is three days of hourly electricity data for a synthetic office, and the summary tool computes daily totals, peak/base hours, and load factor. Green Button matters because it is the zero-hardware path into building energy data: no gateway, no integrator, just a file from a portal covering roughly 60% of US electric customers. The full OAuth "Connect My Data" flow is documented as a TODO; file parsing comes first because that is what works everywhere today.
haystack-mcp serves a Project Haystack-tagged point model — the bundled sample is a 25-point office (two AHUs, three VAVs, a chiller, a meter) — through read_points with a documented subset of the Haystack filter grammar, hisRead over bundled trend data, and about. The tool names deliberately mirror Haystack's own REST ops, so pointing the template at a real SkySpark or Niagara endpoint later is a mechanical swap, and the README walks through exactly that path.
brick-mcp loads a Brick 1.3 building model from Turtle and answers query_equipment, query_points_by_class, and get_building_summary — equipment hierarchies, feeds-relationships, point classes — without requiring the agent to speak SPARQL. The TTL parser is regex-based and demo-grade by declaration; the README tells you precisely where to swap in rdflib for production. The sample model is ~33 triples: a chiller feeding an AHU feeding a VAV, with points attached both ways.
Read-only is the point, not a limitation
All three templates share one design decision we will not compromise: there are no write tools. Not disabled — absent. An agent connected to these servers cannot command equipment, override a setpoint, or write history, because the surface to do so does not exist.
This is deliberate philosophy, not caution theater. Facility managers' distrust of cloud-connected anything is rational; OT networks are kept isolated for good reasons (NIST 800-82 exists for a reason). So these servers consume exports — the CSV your BMS already emails, the XML your utility already serves, the TTL your modeling tool already produces — and never sit on the control network. The pitch to a building owner is simple: this cannot break your building, by construction. Advisory in, decisions stay human.
Honest caveats
Two things we want on the record. First, these are templates, not products — skeletons meant to be forked, with TODOs marked where production work begins (OAuth, SDK wiring, real RDF parsing). Second, the fact that nobody built these before us is evidence worth respecting: it may mean the demand is still small. We think the 97M-download MCP wave makes that gap temporary, but we sized this effort accordingly — a few weeks of work, released openly, not a company-defining bet. Watch the fork count with us.
One distinction worth keeping crisp: AISB is also designing a public MCP server that exposes our knowledge corpus — anchored CRE claims, benchmarks, compliance lookups. These templates are the other half: building-side, exposing your building's own data to your agents. Knowledge about buildings, versus data from a building. Agents will need both.
Get the code, break it, improve it
The public repository is being set up. Until it is live, email hello@ai-smart-buildings.com and we will send you the current version of all three templates — honest answer, no fake download button.
What we would love in return, from anyone working on this: real-world ESPI quirks from utilities outside the usual suspects; Haystack tag-soup examples where three contractors named the same point three ways; anonymized Brick models that break our demo parser. And if you maintain bacnet-mcp or want to build the BACnet/Modbus siblings into this same read-only pattern — let's talk. The building data layer should be open, agent-readable, and boring. Templates are how it starts.
AISB community templates v0.1, MIT licensed. Synthetic sample data only — no real building data ships with any template.
Research compiled by the AISB agent fleet from primary sources; every claim verified against the public record. Cost figures are labeled industry estimates. Full source list available on request — hello@ai-smart-buildings.com.