The MCP server

csy-mcp is a thin stdio MCP server that wraps the operator’s installed csy CLI, so any MCP-capable AI agent — a desktop assistant, an IDE agent, a chat client — can ask the plant questions without being able to touch it. The tool inventory is read + propose only, and the boundary is structural: write-capable verbs are absent from the tool registry, not suppressed by a policy prompt. This is the same advisory-only stance as the rest of the platform’s AI architecture — an agent wired to csy-mcp can observe and explain, and a human stays in the execution path for anything that could reach equipment.

Tool inventory

The inventory is closed — five tools, four of them read-only wrappers over the CLI’s live read verbs:

Tool	What it does	Wraps
read_tags	Current tag values, with quality, for a device instance	csy instance tags
read_trend	A bounded historian window for an instance’s tags (--last or --from/--to, --max-points)	csy instance trend
read_alarms	Active alarms for a site, optionally filtered to one instance	csy site alarms
read_command_audit	The command-audit ledger, instance- or site-scoped	csy instance commands / csy site commands
propose_command	Formats the exact operator command line (csy ui device/<instance>, then the REPL action <id>) for a human to review and run — it never executes anything	—

Propose means propose

propose_command produces text, not action. Executing a device command remains the operator’s UI-session flow — preconditions evaluated fail-closed on good-quality values, confirmation prompts, expiry, and the audit trail (alarms & commands). There is no path from an MCP tool call to a tag write.

The boundary is conformance-tested: the exact tool inventory is pinned, mutating CLI verbs are deny-listed, and every wrapped invocation is re-parsed against the real CLI command tree. Adding a read tool requires establishing the wrapped verb is non-mutating; a write-capable tool cannot be added without changing the platform’s advisory-only architecture.

Authentication and tenancy

Each read launches csy, which uses the operator’s current context from ~/.consystence/config.json — the same credentials and the same tenancy scoping as an interactive invocation. To point the server at a different endpoint or org, run csy context use <name> and restart the MCP session.

csy-mcp stores no credentials of its own, strips CONSYSTENCE_TOKEN from the child environment, and never calls auth verbs. On an authentication failure it returns reauthentication_required naming the exact csy auth login --context <name> line — the operator re-authenticates in their own terminal, never through the agent.

Running

csy-mcp builds from the same source tree as csy (its version is kept in lockstep). During the beta, build it from the monorepo alongside the CLI; packaged distribution will accompany the CLI’s release channels. Configure it in any MCP client as a stdio server:

{
  "command": "csy-mcp",
  "args": []            // optional: ["--csy-path", "/path/to/csy"]
}

The csy binary is resolved from --csy-path, then the directory containing csy-mcp, then PATH; startup fails fast if csy --version doesn’t run. Protocol stdout carries only MCP messages — all diagnostics go to stderr.