> ## Documentation Index > Fetch the complete documentation index at: https://docs.energy.nlead.ch/llms.txt > Use this file to discover all available pages before exploring further. # Knowledge Skills and MCP > Market process knowledge as generated, versioned files the agents read; the process API as an MCP server for a partner's orchestrator Two things an agent needs that are neither checks nor tools: what a market process *is*, and a door through which an orchestrator outside the bridge can see the same cases and the same previews an internal agent does. This is PR 7 of the [agentic process support design](/setup/agentic-process-support.md). ## Knowledge skills A **knowledge skill** is one generated JSON file in `src/scheduling_bridge/agents/knowledge/`: a market process in the order a person would explain it - summary, goal, steps, deadlines with the rule they come from, message types, rejection codes with their meaning and what the bridge does about them, notes - and the **sources** it was generated from, pinned: a page of this documentation by its content hash, a document of the regulatory knowledge base by its id and version. Nothing in the files is edited by hand; the generator `scripts/generate_knowledge_skills.py` writes them, and the suite's drift test fails when a pinned source moved and the generator did not run again - what the model is told never silently falls behind the page or the regulation it came from. The first three, for the German market communication of the BKV: | Skill | Process | What it carries | | - | - | - | | `de-mako-aperak` | APERAK and CONTRL | The acknowledgment duty in both directions, the 45-minute and next-Werktag deadlines, what gets a CONTRL since 01.10.2025, the CONTRL codes (12, 23, 26, UCI/UCM), BGM+313, the Quittungs-Nachfass | | `de-mako-partin` | PARTIN and Erstkontakt | The datasheet 37003 and its format version, the first contact and its reminder, answering partner PARTINs, resending after a rejection, Korrektur mails, error 23 and Z29, Stammdaten-Anfrage and Nachversand | | `de-mako-zuordnung` | Zuordnungsermächtigung | UTILMD 55071 and 55072, the MaBiS deadlines, automatic granting and its widening, extending by missing types, withdrawal, Unterbilanzkreis, the GPKE answer when the permission is missing | A skill in the skill registry names the knowledge it carries (`knowledge` next to its checks and tools: `de-mako-aperak` for the APERAK routine and the MaKo check skills, and so on), and a round gets every knowledge skill of the agent's skills once, rendered compactly under *Market process knowledge* in its standing context, after the policy, the rules and the tools. Partner free text never enters a knowledge skill (D10): they describe the process, not the traffic. **Regenerating.** From the repository root: ```bash theme={null} .venv/bin/python scripts/generate_knowledge_skills.py # write the files .venv/bin/python scripts/generate_knowledge_skills.py --check # report drift, exit 1 if any ``` A page edit that changes the meaning is followed by an edit of the skill's content in the generator and a run; a page edit that does not (wording, a typo) is followed by a run alone, which re-pins the hash. A KB source is added as `kb("DE", "", "", [chunk ids])` by whoever read the knowledge base for it, and the snapshot of KB versions (`agents/knowledge/kb_versions.json`, document id to version) is refreshed in the same step; the drift test compares the pins against that snapshot. The regulatory KB is reachable over the Engrate internal MCP, not from the bridge itself, so the snapshot is a person's or an agent's read, dated by the skills' `generated_at`. ## The process API over MCP `POST /v1/process/mcp` is an **MCP server** (streamable HTTP in its plain JSON form: one JSON-RPC request in, one response out, no event stream; `GET` answers 405). It takes the process key like the console (`X-API-Key`) and is rate-limited and logged (`api_call`) like every other request. A client connects with ```json theme={null} {"url": "https:///v1/process/mcp", "headers": {"X-API-Key": ""}} ``` and gets what an internal agent gets, and no more: | Tool | Does | | - | - | | `list_cases`, `get_case`, `cases_summary` | The inbox, one case, the figures | | `list_tools` | The tool registry with policies and the approvals each takes now | | `preview_tool` | A tool's plan - its dry run; nothing sent, nothing stored | | `propose` | A proposal on a case (or a new case for it), previewed by the bridge, **waiting for the people the policy names** in the inbox; the caller's key name is the proposer | | `note_case` | A line on a case's timeline | | `list_agents`, `agents_analytics`, `get_policy` | The agents and their state, the analytics, the shared policy | | `list_knowledge`, `read_knowledge` | The knowledge skills, one rendered as the agents read it | Resources: `policy://shared` and `knowledge://` serve the same texts. Methods: `initialize` (protocol versions 2025-06-18, 2025-03-26 and 2024-11-05), `ping`, `tools/list`, `tools/call`, `resources/list`, `resources/read`, `prompts/list` (empty); notifications are accepted with 202. A tool's refusal (no such case, a refused plan) is the tool's result with `isError`, not a protocol error. What is **not** on the surface, by design: approving or rejecting a proposal, executing anything, the pipeline steps, the configuration, the agents' definitions. An external orchestrator - a partner's, a platform's - can propose exactly what an operator could propose and approve nothing: the people in the inbox stay the ones who decide (D2, D6). To give a partner a key of its own, add a named process key; its name is what the proposals carry. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.