cernion_askLABSCO SUMMARY
Consequential steps stop at prepare.
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.
What it is
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.
What you get
- 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
Requirements
- 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 22 or later if you are running the platform yourself — this repository is the backend runtime, installed from a clone. The package is
cernion-energy-tools.
Setup effort
Add the hosted endpoint plus a key — paste it into your client, then supply credentials
USE CASES
01
Finding out what the platform can actually do for a question
Search the capability and operation catalogue, then describe the one that fits before committing to a path.
02
Answering an energy-domain question with evidence attached
Ask the agent layer and get a dossier-shaped result — objective, data, chain, gaps — rather than a free-text answer.
03
Pulling read-only status without opening the platform
Run an allowlisted read through the gateway, so access control is enforced exactly as it would be over the REST API.
04
Staging something consequential for a human to confirm
Prepare the process intent, review it, then execute or reject — and read the status while it waits.
05
Checking a stored chain before running it
Plan the receipt first to see what it would do, and only then run it.
9 tools
Listed in project docs. Your client may show a different list.
cernion_searchcernion_describecernion_execute_readcernion_run_receiptcernion_prepare_processcernion_execute_processcernion_process_statuscernion_get_contextBEFORE YOU INSTALL
What to know first
Tools you get
9 tools named in the project's documentation.
Requires
A Cernion API token (ck_…)
INSTALLATION
Connect your client
Server setup
Setup
TERMINAL
git clone https://github.com/energychain/cernion-energy-tools.git
cd cernion-energy-tools
npm install
cp .env.example .env
npm startHosted endpoint
ENDPOINT URL
https://api.cernion.de/api/mcpConnect a client to this instead of installing anything. Send your Cernion API token (ck_…) as an Authorization: Bearer header. In Claude.ai, use the Claude.ai setup under MCP Clients instead. Taken from this project's own documentation.
MCP Clients
Claude.ai — OAuth
Get a personal Cernion API token (ck_…); the project's OAuth guide says where to request one.
In Claude.ai, add a custom connector with the URL https://api.cernion.de/api/mcp. Enter the Client ID and Client Secret that https://api.cernion.de/oauth/client-info returns.
When the Cernion consent page opens, paste your ck_… token to authorize the connector.
The hosted endpoint takes the ck_… token as a Bearer token; Claude.ai cannot send one directly, so it passes through this OAuth consent page instead.
HTTP request (curl)
Opens a session on an instance you run yourself (port 3000). The response carries an mcp-session-id header that every later request must send back.
HTTP REQUEST (CURL) · TERMINAL
curl -sX POST http://localhost:3000/api/mcp \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer <YOUR_TOKEN>' \
-H 'Accept: application/json, text/event-stream' \
-d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"test","version":"0.0.1"}}}'
