Model Context Protocol

The battery passport, operated through an AI assistant

Our passport engine speaks MCP — the open standard AI assistants like Claude use to call tools. Your data owners ask in plain language instead of reading API docs: Which mandatory fields are missing? What would this SAP delivery produce?

Request API access What is the battery passport?

What this looks like in practice

Which mandatory fields is our home-storage model still missing before publication?

The passport stands at 41 of 95 mandatory fields (category industrial). 54 are open — the biggest blocks:

Use phase (BMS/telematics): 21 fields · test bench: 7 · dismantling: 7 · waste texts: 7 · CO₂: 5

Shall I turn that into a follow-up list per responsibility?

Real response structure from the engine — pass_status tool, sample passport of 27 Aug 2026

How it works

Three steps, no integration project.

Get an API key

You receive a tenant-bound key carrying exactly the rights you need — read, validate or deliver.

One entry in your assistant’s MCP configuration (Claude Desktop, Claude Code and others). The key decides which tools appear.

Ask instead of clicking

Look up the catalogue, pull the gap list, map a customer file, dry-run a delivery — in conversation, against the real engine.

The tools

Every tool calls the engine’s public HTTP API. There is no second path around validation and tenant isolation.

Tool	Requires	What it does
`katalog_lesen`	public	Read the Annex XIII catalogue: every field with its obligation flag per category (lv, industrial, ev)
`feld_info`	public	Look up a single catalogue field: legal basis, data type, unit, plausibility bounds
`pass_status`	dpp:ingest or dpp:publish	Passport status: completeness, missing mandatory fields, publishability, blocking reason
`links_lesen`	public	Read a passport’s use-phase links (SoH, telematics, certificates)
`gs1_link_pruefen`	public	Take a GS1 Digital Link apart and check it against the resolver
`lieferung_validieren`	dpp:ingest	Dry-run a delivery — same rules, nothing is written
`lieferung_einreichen`	dpp:ingest	Submit a delivery for real — logged, values keep their provenance label
`link_hinzufuegen`	dpp:write	Attach an external reference to a passport (e.g. a BMS data source)

On top: readable resources (the catalogue per category, your tenant permissions) and two guided workflows — preparing customer data into a canonical delivery, and following up open mandatory fields per responsibility.

Security and limits

The AI gets tools, not privileges.

One front door

The MCP server calls the public HTTP API only. No database access, no second validation logic — checks, publication gate and tenant isolation stay in one place.

The gate stays deterministic

Whether a passport may be published is decided by the same rule-based check as always — never by a language model.

AI values carry a label

Every value a model extracts from documents carries the status ai_extracted — until a human confirms it. It can never pose as a verified measurement.

Publishing stays human

A publish tool does not exist. Release is the economic operator’s declaration of conformity — a signature, not a machine call.

The key decides visibility

Which tools an assistant even sees is decided by the API key. A read-only key never learns that write tools exist. Write calls are logged.

Configuration

One entry, done. The key comes from the environment — never into the config file.

{
  "mcpServers": {
    "dpp": {
      "command": "npx",
      "args": ["tsx", "packages/mcp/src/index.ts"],
      "env": { "DPP_API_URL": "https://elektro-beta.vercel.app" }
    }
  }
}

Without a key the server starts in public mode: catalogue and GS1 checks work; passport and delivery tools appear once a key is present.

Become a pilot customer

We set up your tenant, issue the key and accompany the first delivery — from SAP export to a publication-ready passport.

Get in touch