Sedona MCP Server

Multi-Protocol Unified Access to Sedona, Sandstar, and SkySpark

One MCP server, four building-automation protocols, zero glue code.

Sedona MCP Server speaks Sedona Sox over binary TCP on port 1876, Sedona Weblet over HTTP on 8085, Sandstar's Project Haystack bridge, and SkySpark over HTTPS -- all behind a unified MCP tool surface. Ask it to search Sedona classes, generate component code, or execute live Axon against a running SkySpark project, and the protocol-routing layer figures out which transport to dial.

Offline, it indexes 27+ tools of Sedona examples, kits, classes, patterns, and templates with FlexSearch. Online, it reaches into real buildings.

Why It Exists

A modern controls stack is not one protocol -- it is four, sometimes five. Engineers juggle separate tools for each, losing context every time they switch. Sedona MCP Server collapses that into one conversation: the assistant asks executeAxonCode and the server handles the HTTPS plus SCRAM handshake to SkySpark; it asks searchSedonaClasses and the server hits the local index; it asks getActiveConnection and the server reports which device is currently bound.

Who It's For

  • Controls engineers working across Sedona devices and SkySpark projects on the same job
  • Sandstar developers bridging Haystack tags to Sedona hardware
  • AI-assisted integrators who want one MCP server, not four

Protocol Switchboard

Four protocols, one MCP tool call

One config file defines your Sox devices, Weblet servers, Sandstar bridges, and SkySpark instances. Any tool call routes to the right transport -- binary TCP, HTTP, HTTPS -- without a single line of glue code.

Protocol Routing
connections.json: 4 defined
MCP Tool Call
executeAxonCode({...})
searchSedonaClasses queryHaystack executeAxonCode getActiveConnection
Sedona Sox Binary
tcp:1876
Raw Sox protocol over TCP
Sedona Weblet HTTP
http:8085
Weblet HTTP endpoints
Sandstar Haystack
http:8085
Project Haystack bridge
SkySpark HTTPS + SCRAM
https:443
Authenticated Axon execution
4 protocols -- 27+ tools -- 1 config file v2.0.0

Tool Surface

Six domains, one interface

Search, generate, validate, analyze, execute, connect. Twenty-seven-plus tools organized by the operation you are performing -- not the protocol you are hitting.

The assistant does not need to know the wire format. It picks the tool for the task. The router dials the right destination.

MCP Tools (27+) tools/list
Sedona Search
5 tools
searchSedonaExamples searchSedonaClasses listSedonaKits searchSedonaRegex listSedonaCategories
Code Gen
3 tools
generateSedonaCode validateSedonaCode listSedonaTemplates
Function Analysis
3 tools
findFunctionUsage getFunctionCallGraph getFunctionUsageStats
SkySpark / Axon
4 tools
executeAxonCode listSkySparkProjects switchSkySparkProject discoverProjectFunctions
Device / Connection
3 tools
getActiveConnection discoverInstanceProjects clearProjectCache
Haystack
1 tool
queryHaystack
Active Connections 4 wired
Sox 192.168.1.100:1876
4ms getActiveConnection 3s ago 3s ago
Weblet 192.168.1.100:8085
12ms searchSedonaClasses 12s ago 12s ago
Sandstar sandstar.internal:8085
retrying -- queryHaystack 2m ago 2m ago
SkySpark skyspark.internal:443
127ms executeAxonCode 38s ago 38s ago
config/connections.json
{ "sox": { "host": "192.168.1.100", "port": 1876 }, "weblet": { "host": "192.168.1.100", "port": 8085 }, "sandstar": { "host": "sandstar.internal" }, "skyspark": { "host": "skyspark.internal", "auth": "scram" } }

Live Connections

Four rails, one dashboard

Every connection is tracked independently. getActiveConnection reports which protocol was last used. discoverInstanceProjects walks whatever is reachable. clearProjectCache resets when something drifts.

The config file is the single source of truth. Add a new SkySpark instance, add a new Sedona device, change a port -- the router re-reads on next tool call.

SkySpark Execution

From the catalog to the building

executeAxonCode runs arbitrary Axon against the currently-bound SkySpark project. listSkySparkProjects and switchSkySparkProject let you roam across instances. discoverProjectFunctions introspects; getProjectSchema returns the data model.

Project state persists. Switch once, and the next 50 tool calls go to the same building. Switch back, and the cache was ready.

SkySpark Bridge live
executeAxonCode({ code: "read(point and zone and temp).hisRead(today)" })
Result (5 rows, 4 cols)
dis zone val ts
Zone 101core-172.3°F10:12
Zone 102core-174.1°F10:12
Zone 103core-171.8°F10:12
Zone 201core-273.4°F10:12
Zone 202core-272.9°F10:12
Active Project
campus-main 42 points · last sync 3m ago
lab 12 points · last sync 18m ago
qa 8 points · last sync 1h ago
switchSkySparkProject
Sedona Device Sox Binary
Active Device
Host192.168.1.100:1876
Protocolsox (binary)
Firmware1.2.28
Kits loaded12
Points47
Stateok
Kits loaded (12)
sys42 classes
control23 classes
logic18 classes
timing11 classes
sensor9 classes
datetimeStd7 classes
inet6 classes
types5 classes
basicSchedule4 classes
sox3 classes

Sedona Devices

First-class introspection on the binary rail

listSedonaKits walks the device manifest. getActiveConnection reports the bound host. discoverInstanceProjects auto-pairs discovered devices with their project context. Sox is treated as a peer of HTTP, not a legacy transport.

Binary does not mean opaque. Every class, every kit, every firmware version is visible to the assistant -- and searchable.

Interested in this project?

Explore the source code, contribute, or get in touch.