Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@brick-bacnet-mcp List all the air-handling units across the building."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A read-only BACnet/IP gateway that exposes building automation point databases to LLM agents via MCP, with Brick + Project Haystack semantic tagging at ingest time.
The research note this implementation came out of is at https://habchy.dev/research/bacnet-msi-semantic-gap. A version of the same article is also published at AutomatedBuildings.com (link will be added when the AB.com edition goes live).
Short version: vendor agentic platforms (JCI OpenBlue, Honeywell Forge, Siemens Building X, Tridium Niagara 5) keep their semantic AI layer inside their own controls portfolios. Independent MSIs running mixed-vendor 5-50 building portfolios have BACnet point databases but no clean way to expose them in semantic-tagged form to external LLM agents. This gateway is one answer to that gap.
ezhuk/bacnet-mcp does read and write at the BACnet protocol layer with no semantic normalization. This project sits beside it: it adds the Brick + Haystack tagging step at ingest and restricts the v0.1 surface to read-only for a tighter compliance footprint.
Related MCP server: BACnet MCP Server
Discovers BACnet/IP devices on the local broadcast domain (Who-Is, I-Am)
Enumerates objects per device (AI, AO, AV, BI, BO, BV, MSI, MSO, MSV, Schedule, Calendar)
Reads present-value, units, and description per object
Tags each object with a Brick class and a Haystack tag set using rule-based mapping (rules are extensible via YAML)
Exposes the tagged topology to any MCP host via four tools: list_devices, list_objects, get_object_value, get_tagged_topology
Not a write path. WriteProperty is intentionally out of v0.1 for the compliance-surface reasons noted in the research article.
Not a Niagara station integration. Fox protocol / Niagara module wrapping is a separate design.
Not an FDD or analytics platform. The tagged topology is meant to be consumed by downstream FDD or LLM-agent workflows. This gateway is the ingest layer only.
Not a UI. Output is MCP only. Pair it with Claude Desktop, Cursor, or any other MCP host.
Not BACnet/SC. v0.1 is BACnet/IP only. Secure Connect is a v0.2 consideration.
Not 223P full schema parity. v0.1 uses the simplified Brick + Haystack mapping. Full 223P entity model is a v0.2 candidate.
Not multi-site federated. v0.1 handles one broadcast domain at a time.
Not authenticated. v0.1 runs in a trusted local network environment.
pip install brick-bacnet-mcpOr from source:
git clone https://github.com/Yveshby27/brick-bacnet-mcp
cd brick-bacnet-mcp
pip install -e .Python 3.11 or later required.
Create a config file config.yaml:
bacnet:
local_device_instance: 555001
broadcast_address: 192.168.1.255
polling_interval_seconds: 30
rules:
brick: src/brick_bacnet_mcp/rules/brick_rules.yaml
haystack: src/brick_bacnet_mcp/rules/haystack_rules.yaml
mcp:
transport: stdio # or "http" for a hosted MCP host
http_port: 8080 # only if transport == http
log_level: INFORun the MCP server:
brick-bacnet-mcp --config config.yamlOr wire it into Claude Desktop:
{
"mcpServers": {
"brick-bacnet": {
"command": "brick-bacnet-mcp",
"args": ["--config", "/path/to/config.yaml"]
}
}
}With the server running and the simulator active (or a real BACnet/IP network reachable), an MCP-capable LLM can run:
User: List all the air-handling units across the building.
Agent (via MCP tool): calls
get_tagged_topology(filter="brick:AHU")Agent response: Found 3 AHUs. AHU-1 has 5 child points (discharge_air_temp, return_air_temp, supply_fan_status, mixed_air_damper_position, outside_air_temp). AHU-2 ... AHU-3 ...
See examples/ for full runnable scripts.
The starter rule library targets common US-style object-name conventions (OAT, DAT, ZNT, CHWS, AHU-1, etc.). Real-world mixed-vendor portfolios use wildly different naming. Before assuming the tool is broken or working, run:
brick-bacnet-mcp --coverage-report --config config.yamlThis does one discover + enumerate + tag cycle against your network and prints:
Total objects discovered
Brick / Haystack match percentages
Top 20 most-common object names that no rule matched (use --top-unmatched N for a different count)
Top 10 hottest rules
Use the unmatched list to extend the YAML rule files for your naming convention. A first-run match rate of 30-50% is normal for a portfolio that hasn't been calibrated yet; 70%+ is what you'd want before relying on the tagged topology for LLM queries.
The tagger applies YAML-defined rules to map BACnet object names and units to Brick classes and Haystack tag sets. The default rule set covers about 50 common HVAC, lighting, and metering object-name patterns. Users override or extend by editing src/brick_bacnet_mcp/rules/brick_rules.yaml and haystack_rules.yaml locally.
Example rule (Brick):
- pattern: '(?i)^(oat|outside_air_temp|outsideair)$'
units: ['degF', 'degC', '°F', '°C']
brick_class: 'Outside_Air_Temperature_Sensor'See docs/RULES.md for the rule grammar and override conventions.
See docs/ARCHITECTURE.md. Short version:
discovery.py runs Who-Is broadcast, captures I-Am responses, caches device metadata
reader.py enumerates the object list per device and polls present-value at the configured interval
tagger.py applies Brick + Haystack rules to each enumerated object
topology.py assembles the tagged objects into a queryable graph
server.py exposes four MCP tools over stdio or streamable HTTP
v0.1 is a research instrument. The roadmap below is what the research article flagged as worth doing next IF v0.1 gets enough sustained-use signal to justify extending. None of it is committed pre-signal.
v0.2: COV subscription support, BACnet/SC, 223P full schema parity, SkySpark / FIN Haystack-store passthrough
v0.3+: Optional write path behind explicit opt-in, multi-site federation, authentication layer for non-local deployment
ezhuk/bacnet-mcp for the prior-art MCP + BACnet integration that this project builds beside
bacpypes3 for the BACnet protocol library
Project Haystack for the Haystack tagging vocabulary and community
Brick consortium for the Brick schema
The named MSI voices whose published positioning this research builds on: Brian Turner (Adaptive Buildings), Marc Petock (Lynxspring), Tom Shircliff and Rob Murchison (Intelligent Buildings LLC), Jim Meacham (Altura Associates), Therese Sullivan (BuildingContext), Alper Üzmezler (BASSG)
MIT. See LICENSE.
See CONTRIBUTING.md. PRs welcome for rule library extensions, documentation, examples, and test coverage. Larger changes (write path, non-BACnet protocol support, UI, FDD logic) are out of v0.1 scope. Open an issue first to discuss before submitting a PR.
Read the current present-value and tags of a single BACnet object.
| Name | Required | Description | Default |
|---|---|---|---|
| object_type | Yes | ||
| device_instance | Yes | ||
| object_instance | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the only source of behavioral info. It says 'current present-value,' implying time-sensitivity, but doesn't disclose whether tags are optional, what happens if the object doesn't exist, or authentication requirements. Significant gaps for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, directly stating the action and resource. No filler; appropriately concise for a simple evaluation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values need not be explained, but with 3 undocumented parameters, no annotations, and no behavioral details (e.g., error handling, tag semantics), the description is too sparse for an agent to call correctly without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain each parameter. It only mentions 'present-value and tags' but doesn't clarify what object_type, device_instance, or object_instance mean in the BACnet context, or their formats. The description adds minimal meaning beyond the raw names in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads present-value and tags of a single BACnet object, which distinguishes it from list-oriented siblings like list_devices and list_objects. However, it lacks explicit comparison to siblings, so it doesn't earn a 5 for sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: to read a single object's value/tags. It does not explicitly state when to use this versus list_objects (e.g., for a single object) or list_tagged_topology. Acceptable but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the full or filtered tagged-topology graph.
filter_brick: keep only objects matching this Brick class fragment filter_haystack: keep only objects whose Haystack tags include all of these
| Name | Required | Description | Default |
|---|---|---|---|
| filter_brick | No | ||
| filter_haystack | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the behavioral burden. It indicates a read-only 'Return' operation and describes filtering semantics, but it does not disclose traversal behavior, size limits, errors, or other edge cases. It is not misleading, but it is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded with the main operation, and every line provides useful parameter-level information. There is no filler or repetition, making it efficient to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with two optional parameters and an output schema, this is close to sufficient. However, it never explains what 'tagged-topology graph' means, and it lacks clarifying context about when the filters should be used or what the returned graph contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides types and defaults, while the description adds meaning for both parameters. It explains that filter_brick matches a Brick class fragment and that filter_haystack keeps objects whose tags include all specified values, which goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool: it returns the tagged-topology graph, with optional filtering. It does not explicitly distinguish itself from sibling tools like list_devices or list_objects, but the resource name and domain are concrete enough that the purpose is not vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not say when to prefer this tool over siblings, nor does it provide when-not-to-use conditions. It mentions full or filtered results, but leaves the actual selection context to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all BACnet devices discovered on the local broadcast domain.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states the operator and scope, implying a read-only list operation, but doesn't explicitly disclose non-destructiveness, potential empty results, or any discovery limitations beyond the local broadcast domain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One clean sentence, front-loaded with the action, no filler. Every word is aye essential to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless, output-schema-bearing listing tool, the description is nearly complete. The only minor gap is the lack of explicit statement that it's read-only, which is otherwise reasonably inferred from the verb.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema fully reflects that (empty properties, 100% coverage). Baseline for a parameterless tool is 4; description need not add anything beyond what the schema already shows.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States the specific verb (list) and resource (BACnet devices) with scope (local broadcast domain). It clearly distinguishes itself from siblings like list_objects and get_object_value by indicating it returns devices, not objects or values.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you need to see all discovered BACnet devices. However, it doesn't explicitly mention when not to use it or contrast it with list_objects or get_tagged_topology, leaving the routing decision to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all tagged objects for a given BACnet device.
| Name | Required | Description | Default |
|---|---|---|---|
| device_instance | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the primary behavior (listing all tagged objects) and the scoping by device_instance, but does not mention potential errors (e.g., invalid device instance), pagination behavior, or whether the operation is read-only (though listing implies it). This is adequate for a simple read operation but not particularly rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence that front-loads the action and scope. Every word earns its place—no filler, no repetition of the tool name, and no unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and an output schema, the description is nearly complete. It does not need to explain return values because the output schema exists. It could mention error conditions or prerequisites (e.g., device must exist) but these are not critical for a basic list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only a type (integer) for device_instance, and schema description coverage is 0%. The description adds valuable meaning by clarifying that this integer represents a BACnet device. This extra context helps the agent understand what to supply, though it doesn't specify any format constraints beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action (list), the resource (tagged objects), and the scope (for a given BACnet device). This unambiguously distinguishes it from sibling tools like list_devices (which lists devices) and get_object_value (which retrieves a value), without needing to inspect schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need all tagged objects for a specific device) but does not mention alternatives or any when-not conditions. There is no explicit guidance on choosing between this and get_tagged_topology or get_object_value, so the agent must infer the appropriate context from the tool names and descriptions alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0get_object_valueget_tagged_topologylist_deviceslist_objectsScored across 4 tools
Each tool targets a distinct action: enumerating devices, listing objects per device, reading a single object's value, and retrieving the topology graph. There is no overlap in purpose, and descriptions clearly differentiate between collection-level and instance-level operations.
All tools follow the verb_noun pattern with a clear convention: 'list_' for enumeration and 'get_' for specific retrieval. This consistency makes the tool purpose predictable and reduces cognitive load for agents.
With exactly 4 tools, the server is well-scoped for a BACnet/Brick read-only exploration use case. Each tool serves an essential, non-redundant function, and the count is neither sparse nor overwhelming.
The tool set covers the core read workflows: discovering devices, listing their objects, reading values, and exploring the tagged topology. Minor gaps exist (e.g., no direct device detail or object write capability), but these are acceptable if the server is intended for querying rather than modification.
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
Data-ontology maps of your business systems, served to AI agents over MCP.
Zero-setup MCP gateway securely connecting AI to your tools with authentication and workflows
The HubSpot MCP Server acts as a bridge that enables AI assistants and Large Language Models to securely interact with HubSpot CRM data through natural conversation, without requiring users to understand complex API structures. It provides read-only access to standard CRM objects (contacts, companies, deals, tickets, products, invoices, and more) and their associations, secured via OAuth 2.0, allowing AI agents to perform tasks like summarizing deals, fetching company updates, and looking up record changes.
