The design premise is that the chat does not decide. Anything with consequences is staged as an intent that a human confirms, the approve and escalate actions are deliberately not exposed at all, and the read path runs through the real gateway so a read-only token stays read-only. That is the right shape for a regulated domain, and it is also the thing to understand before evaluating it: this is built to produce dossiers, evidence packages and decision-readiness views, not to execute market communication or control devices.
An MCP server in front of a large energy-domain platform for Stadtwerke, distribution-system operators and energy-service teams. Rather than mapping one tool per endpoint, it exposes nine meta-tools and routes intent through a capability broker — so the model works with a curated path into the platform instead of its whole catalogue.
- Nine meta-tools rather than a tool per endpoint, reached over JSON-RPC on the streamable-HTTP transport
- Discovery in two steps: search across capabilities, operations, receipts, blueprints and the recipe cookbook, then describe one of them in full — `cernion_search`, `cernion_describe`
- Read-only execution against the platform's own API through an allowlist, which goes through the real gateway so role-based access control applies as it would over REST — `cernion_execute_read`
- The agentic path: ask the platform an energy-domain question and get a dossier-shaped answer back — `cernion_ask`
- Consequential work split into stage and commit rather than one call: prepare a process intent, then execute or reject it, with status readable at any point — `cernion_prepare_process`, `cernion_execute_process`, `cernion_process_status`
- Stored receipts that can be planned before they are run, so the chain is inspectable first — `cernion_run_receipt`
- Session context including the tenant's quotas — `cernion_get_context`
- Typed references shared across the surface, so search and describe emit an identifier that the write and status tools accept back instead of separate id and kind parameters
- MCP resources and prompts on top: browsable capabilities, receipts, blueprints and recipes for clients that support resources, and one prompt per cookbook recipe registered at session start
- An explicit exclusion list — backup and restore, tenant-quota writes, system admin operations, and the human-in-the-loop approve, reject and escalate actions are not reachable through this surface
An account on the platform and a bearer token — an API token, a session token, or the OAuth 2.1 flow for clients that can only authorize in a browser. The endpoint is the platform's MCP path, and the session is established with an initialize call whose response header must be echoed on every subsequent request. Write-shaped tools are gated separately: a read-only-scoped token cannot reach writes through MCP any more than it can through REST. Node.js if you are running the platform yourself — this repository is the backend runtime, installed from a clone. The package is `cernion-energy-tools` (0.99.21 in package.json).
Build from source — clone the repository and build it, then deploy it and point your client at the endpoint