MCP-Server

Ein **MCP-Server** ist ein technisches Kernbauteil im Umfeld moderner KI-Systeme und steht für **Model Context Protocol Server**. Er dient dazu, **große Sprachmodelle (LLMs)** wie GPT strukturiert, sicher und reproduzierbar mit **externem Kontext, Daten und Funktionen** zu verbinden.

Im Kern ist ein MCP-Server eine **standardisierte Vermittlungsschicht** zwischen einem KI-Modell und der „realen Welt“ eines Unternehmens oder einer Anwendung.

---

## 1. Grundidee des MCP (Model Context Protocol)

Große Sprachmodelle sind von sich aus:

* zustandslos

* ohne direkten Datenbank- oder API-Zugriff

* nicht sicher mit internen Systemen verbunden

Das **MCP** definiert einen **einheitlichen, maschinenlesbaren Standard**, über den ein Modell:

* Daten abfragen

* Aktionen auslösen

* Werkzeuge verwenden

* Kontext erhalten

Ein **MCP-Server** implementiert diesen Standard.

---

## 2. Was macht ein MCP-Server konkret?

Ein MCP-Server stellt dem Modell kontrolliert zur Verfügung:

### a) Ressourcen (Resources)

Lesender Zugriff auf strukturierte oder unstrukturierte Daten, z. B.:

* Dateien

* Datenbankabfragen

* interne Dokumentation

* Tickets, CRM-Einträge, Logs

### b) Werkzeuge (Tools)

Ausführbare Funktionen, z. B.:

* API-Calls

* Berechnungen

* Suchabfragen

* Geschäftslogik (z. B. „Bestellung anlegen“)

### c) Kontext-Management

* Versionierung von Kontext

* Zugriffsbeschränkungen

* Mandantenfähigkeit

* Auditierbarkeit

### d) Sicherheits- und Kontrollschicht

* Authentifizierung & Autorisierung

* Rate-Limiting

* Eingabe- und Ausgabefilter

* Trennung von Prompt und Daten

---

## 3. Warum braucht man einen MCP-Server?

Ohne MCP:

* direkte Prompt-Injection-Risiken

* harte Kopplung an APIs

* keine saubere Rechteverwaltung

* schwer wartbar und nicht skalierbar

Mit MCP:

* **standardisierte Integration**

* **austauschbare Modelle**

* **zentrale Governance**

* **produktionsreife KI-Architektur**

Kurz:

> MCP macht aus einem Chatbot ein **Enterprise-fähiges KI-System**.

---

## 4. Für welche Art von Anwendungen ist ein MCP-Server relevant?

### Typische Anwendungsfälle

**1. Unternehmensinterne KI-Assistenten**

* Wissensassistent für Mitarbeiter

* Zugriff auf interne Dokumente, Richtlinien, Tickets

**2. Entwickler-Tools**

* Code-Analyse mit Projektkontext

* Zugriff auf Repositories, CI-Daten, Logs

**3. Fachanwendungen mit KI-Logik**

* Vertragsprüfung

* Risiko- und Compliance-Checks

* Angebots- und Berichtserstellung

**4. Agenten-basierte Systeme**

* Mehrschrittige Workflows

* Automatisierte Entscheidungen

* Tool-Ketten und Orchestrierung

**5. Regulatorisch sensible Systeme**

* Finanzwesen

* Gesundheitswesen

* Öffentliche Verwaltung

---

## 5. Für wen ist ein MCP-Server relevant?

### Direkt relevant für:

**Software-Architekten**

* saubere Trennung von Modell und Systemlogik

* Governance und Skalierbarkeit

**Backend- & Plattform-Entwickler**

* standardisierte Tool- und Datenanbindung

* Wiederverwendbarkeit

**Unternehmen / IT-Abteilungen**

* Kontrolle über Datenzugriff

* Modell-Austausch ohne Neuentwicklung

**KI-Produktteams**

* schnellere Iteration

* geringeres Sicherheitsrisiko

---

### Weniger relevant für:

* Endanwender

* einfache Ein-Prompt-Chatbots

* Proof-of-Concepts ohne Produktionsanspruch

---

## 6. Abgrenzung zu ähnlichen Konzepten

| Konzept | Unterschied |

| -------------------- | --------------------------------------------------- |

| **Plugins** | meist an ein Modell gebunden |

| **RAG** | nur Datenabruf, keine Aktionen |

| **Function Calling** | modellabhängig, kein Standard |

| **MCP** | modellneutraler, vollständiger Integrationsstandard |

---

## 7. Zusammenfassung

Ein **MCP-Server** ist:

* eine **Integrations- und Kontrollschicht**

* für **produktive, sichere KI-Systeme**

* mit Fokus auf **Standardisierung, Governance und Skalierbarkeit**

Er ist besonders relevant für Organisationen, die KI **nicht experimentell**, sondern **dauerhaft und kontrolliert** einsetzen wollen.

## 1. Konkrete Architektur-Skizze (MCP in der Praxis)

### Ziel

Ein KI-System, das:

* austauschbare LLMs nutzt

* kontrollierten Zugriff auf interne Systeme erlaubt

* revisionssicher und skalierbar ist

### Architektur (logische Sicht)

```

┌──────────────────────────┐

│ Frontend │

│ (Web, App, Chat UI) │

└─────────────┬────────────┘

│ User Request

▼

┌──────────────────────────┐

│ Application Backend │

│ (Auth, Session, Roles) │

└─────────────┬────────────┘

│

▼

┌──────────────────────────┐

│ MCP Server │

│ ────────────────────── │

│ • Context Provider │

│ • Resource Registry │

│ • Tool Registry │

│ • Policy Engine │

│ • Audit / Logging │

└─────────────┬────────────┘

│ MCP Protocol

▼

┌──────────────────────────┐

│ LLM (austauschbar) │

│ GPT / Claude / Llama │

└──────────────────────────┘

│

▼

┌──────────────────────────┐

│ Interne Systeme / APIs │

│ DB • CRM • ERP • Files │

└──────────────────────────┘

```

### Kernaussage

**Das Modell spricht niemals direkt mit internen Systemen.**

Der MCP-Server ist die **einzige kontrollierte Schnittstelle**.

---

## 2. Beispiel: MCP-Server in einer realen Anwendung

### Szenario

**Interner Vertragsassistent für ein Unternehmen**

#### Anforderungen

* Zugriff auf Vertragsdatenbank

* Berechnung von Risiken

* Erstellung von Zusammenfassungen

* Protokollierung aller Aktionen

---

### MCP-Server: Ressourcen & Tools

#### Ressourcen (read-only)

```json

{

"resources": [

{

"name": "contracts",

"type": "database",

"description": "Vertragsdaten (Lesen)",

"access": "role:legal"

}

]

}

```

#### Tools (aktionen)

```json

{

"tools": [

{

"name": "calculate_risk_score",

"input_schema": {

"contract_id": "string"

},

"description": "Berechnet Risikokennzahl"

}

]

}

```

---

### Ablauf eines Requests

1. User fragt:

> „Bewerte den Risiko-Level von Vertrag X“

2. MCP-Server:

* prüft Benutzerrolle

* stellt Vertragsdaten als Kontext bereit

* erlaubt Tool-Call

3. Modell:

* analysiert Text

* ruft `calculate_risk_score`

4. MCP-Server:

* führt Business-Logik aus

* loggt Aktion

* gibt Ergebnis zurück

5. Modell:

* formuliert Antwort für User

---

### Warum MCP hier entscheidend ist

* Keine direkten DB-Credentials im Prompt

* Tool-Zugriff ist explizit freigegeben

* Audit-Trail für Compliance

* Modell kann gewechselt werden

---

## 3. Einordnung: MCP vs. OpenAI-Tools vs. LangChain vs. LlamaIndex

### Vergleichstabelle

| ---------------- | ----------- | -------------- | -------------- | ------------ |

---

### Einordnung nach Rolle

#### MCP

**Plattform- und Architekturstandard**

* vergleichbar mit REST oder OAuth

* langfristige Infrastruktur

#### OpenAI Tools / Function Calling

**Modell-Feature**

* gut für einfache Workflows

* nicht governance-fähig

#### LangChain

**Entwickler-Framework**

* schnelle Prototypen

* komplexe Chains

* schwer kontrollierbar im Betrieb

#### LlamaIndex

**RAG-Spezialist**

* Dokumentenabfragen

* kein Aktions- oder Policy-Layer

---

### Best Practice in der Realität

> **MCP ersetzt LangChain oder LlamaIndex nicht – es kapselt sie.**

Typische Kombination:

* MCP als Kontrollschicht

* LangChain intern für Logik

* LlamaIndex für Retrieval

* LLM beliebig austauschbar

---

## 4. Kurzfazit

Ein MCP-Server ist:

* kein Framework

* kein SDK

* kein Chatbot

Sondern:

> **die fehlende Infrastruktur-Schicht für produktive KI-Systeme**

---

Unter Einsatz von:

* **Node.js** für den MCP-Server (klar, weit verbreitet)

* **JSON-basierte Policies** (RBAC + ABAC)

* **ein Agenten-Beispiel**, das MCP korrekt nutzt

---

# 1. Konkrete MCP-Server-Implementierung (Node.js)

## Ziel

Ein MCP-Server, der:

* Ressourcen bereitstellt

* Tools ausführt

* Policies erzwingt

* modellneutral bleibt

---

## 1.1 Projektstruktur

```

mcp-server/

├── server.js

├── registry/

│ ├── resources.js

│ └── tools.js

├── policy/

│ └── policy-engine.js

├── services/

│ └── contracts.service.js

└── package.json

```

---

## 1.2 Minimaler MCP-Server (`server.js`)

```js

import express from "express";

import bodyParser from "body-parser";

import { resources } from "./registry/resources.js";

import { tools } from "./registry/tools.js";

import { checkPolicy } from "./policy/policy-engine.js";

const app = express();

app.use(bodyParser.json());

/**

* MCP: Context Endpoint

*/

app.post("/mcp/context", async (req, res) => {

const { user, resource } = req.body;

if (!checkPolicy(user, resource, "read")) {

return res.status(403).json({ error: "Access denied" });

}

const data = await resources[resource].get();

res.json({ context: data });

});

/**

* MCP: Tool Execution Endpoint

*/

app.post("/mcp/tool", async (req, res) => {

const { user, tool, input } = req.body;

if (!checkPolicy(user, tool, "execute")) {

return res.status(403).json({ error: "Access denied" });

}

const result = await tools[tool].execute(input);

res.json({ result });

});

app.listen(3000, () => {

console.log("MCP Server running on port 3000");

});

```

---

## 1.3 Resource-Registry (`registry/resources.js`)

```js

export const resources = {

contracts: {

description: "Vertragsdaten (read-only)",

async get() {

return [

{ id: "C-1001", value: 50000, country: "DE" },

{ id: "C-1002", value: 200000, country: "US" }

];

}

};

```

---

## 1.4 Tool-Registry (`registry/tools.js`)

```js

import { calculateRisk } from "../services/contracts.service.js";

export const tools = {

calculate_risk_score: {

description: "Berechnet Risiko-Score",

async execute({ contract }) {

return calculateRisk(contract);

}

};

```

---

## 1.5 Business-Logik (`services/contracts.service.js`)

```js

export function calculateRisk(contract) {

let score = 0;

if (contract.value > 100000) score += 50;

if (contract.country !== "DE") score += 30;

return {

contractId: contract.id,

riskScore: score

};

}

```

---

# 2. Policy-Definition (RBAC + ABAC)

## 2.1 Rollen (RBAC)

```json

{

"roles": {

"legal": ["contracts:read", "calculate_risk_score:execute"],

"sales": ["contracts:read"],

"guest": []

}

```

---

## 2.2 Attributbasierte Regeln (ABAC)

```json

{

"rules": [

{

"if": {

"resource": "contracts",

"action": "read",

"user.department": "legal"

},

"allow": true

},

{

"if": {

"tool": "calculate_risk_score",

"action": "execute",

"user.seniority": "senior"

},

"allow": true

}

]

}

```

---

## 2.3 Policy Engine (`policy/policy-engine.js`)

```js

const roles = {

legal: ["contracts:read", "calculate_risk_score:execute"],

sales: ["contracts:read"]

};

export function checkPolicy(user, target, action) {

const permissions = roles[user.role] || [];

return permissions.includes(`${target}:${action}`);

}

```

> In der Praxis würde hier zusätzlich:

>

> * ABAC ausgewertet

> * Mandanten-IDs geprüft

> * Logging erfolgen

---

# 3. Beispiel: Agenten mit MCP

## 3.1 Agenten-Konzept

Der Agent:

* analysiert eine Aufgabe

* entscheidet, welche Ressourcen benötigt werden

* ruft Tools über MCP auf

* bleibt zustandsarm

---

## 3.2 Agenten-Ablauf (logisch)

```

User → Agent → MCP(Context) → LLM

↓

MCP(Tool)

↓

Ergebnis → LLM → User

```

---

## 3.3 Agent (Pseudo-Code)

```js

async function riskAgent(user, question) {

// 1. Kontext laden

const context = await fetch("http://mcp:3000/mcp/context", {

method: "POST",

body: JSON.stringify({

user,

resource: "contracts"

})

}).then(r => r.json());

// 2. Modell entscheidet, welches Tool nötig ist

const contract = context.context.find(c => c.id === "C-1002");

// 3. Tool-Aufruf

const result = await fetch("http://mcp:3000/mcp/tool", {

method: "POST",

body: JSON.stringify({

user,

tool: "calculate_risk_score",

input: { contract }

})

}).then(r => r.json());

return `Risiko-Score für Vertrag ${contract.id}: ${result.result.riskScore}`;

}

```

---

## 3.4 Warum das ein „echter“ MCP-Agent ist

* Kein direkter DB-Zugriff

* Keine Credentials im Prompt

* Jede Aktion policy-gesichert

* Modell austauschbar

* Agent bleibt leichtgewichtig

---

# Gesamtfazit

Mit dieser Struktur erhältst du:

* **MCP als Infrastruktur-Layer**

* **klare Trennung von Modell, Logik und Daten**

* **Enterprise-taugliche Kontrolle**

* **Agenten ohne Sicherheitsrisiken**

---

Der Fokus liegt auf **klarer Trennung von Verantwortlichkeiten**, **Governance** und **Realbetrieb**.

---

# 1. Python-Variante eines MCP-Servers

## Technologie-Stack

* Python 3.11

* FastAPI (klar, schnell, OpenAPI-native)

* Pydantic

* explizite Policy-Prüfung

---

## 1.1 Projektstruktur

```

mcp_server/

├── main.py

├── registry/

│ ├── resources.py

│ └── tools.py

├── policy/

│ └── engine.py

├── services/

│ └── contracts.py

├── models.py

└── requirements.txt

```

---

## 1.2 `main.py` – MCP API

```python

from fastapi import FastAPI, HTTPException

from models import ContextRequest, ToolRequest

from registry.resources import RESOURCES

from registry.tools import TOOLS

from policy.engine import check_policy

app = FastAPI(title="MCP Server")

@app.post("/mcp/context")

def get_context(req: ContextRequest):

if not check_policy(req.user, req.resource, "read"):

raise HTTPException(status_code=403)

resource = RESOURCES.get(req.resource)

if not resource:

raise HTTPException(status_code=404)

return {"context": resource()}

@app.post("/mcp/tool")

def execute_tool(req: ToolRequest):

if not check_policy(req.user, req.tool, "execute"):

raise HTTPException(status_code=403)

tool = TOOLS.get(req.tool)

if not tool:

raise HTTPException(status_code=404)

return {"result": tool(req.input)}

```

---

## 1.3 Datenmodelle (`models.py`)

```python

from pydantic import BaseModel

from typing import Dict, Any

class User(BaseModel):

id: str

role: str

department: str

class ContextRequest(BaseModel):

user: User

resource: str

class ToolRequest(BaseModel):

user: User

tool: str

input: Dict[str, Any]

```

---

## 1.4 Resource-Registry

```python

# registry/resources.py

def contracts():

return [

{"id": "C-1", "value": 150000, "country": "US"},

{"id": "C-2", "value": 20000, "country": "DE"}

]

RESOURCES = {

"contracts": contracts

}

```

---

## 1.5 Tool-Registry

```python

# registry/tools.py

from services.contracts import calculate_risk

TOOLS = {

"calculate_risk_score": calculate_risk

}

```

---

## 1.6 Policy Engine (RBAC + ABAC)

```python

# policy/engine.py

ROLE_PERMISSIONS = {

"legal": ["contracts:read", "calculate_risk_score:execute"],

"sales": ["contracts:read"]

}

def check_policy(user, target, action):

perms = ROLE_PERMISSIONS.get(user.role, [])

return f"{target}:{action}" in perms

```

---

# 2. OpenAPI- / MCP-Schema-Definition

## 2.1 MCP als Protokoll (logisch)

**MCP ist kein REST-Ersatz**, sondern ein **LLM-Integrationsprotokoll**.

OpenAPI beschreibt die **Transportform**.

---

## 2.2 OpenAPI-Auszug (YAML)

```yaml

openapi: 3.1.0

info:

title: MCP Server

version: 1.0.0

paths:

/mcp/context:

post:

summary: Retrieve context for model

requestBody:

required: true

content:

application/json:

schema:

$ref: "#/components/schemas/ContextRequest"

responses:

"200":

description: Context payload

/mcp/tool:

post:

summary: Execute MCP tool

requestBody:

required: true

content:

application/json:

schema:

$ref: "#/components/schemas/ToolRequest"

responses:

"200":

description: Tool result

components:

schemas:

User:

type: object

properties:

id:

type: string

role:

type: string

department:

type: string

ContextRequest:

type: object

properties:

user:

$ref: "#/components/schemas/User"

resource:

type: string

ToolRequest:

type: object

properties:

user:

$ref: "#/components/schemas/User"

tool:

type: string

input:

type: object

```

---

## 2.3 MCP-spezifische Erweiterungen (konzeptionell)

```json

{

"mcp": {

"resources": ["contracts"],

"tools": ["calculate_risk_score"],

"policies": ["rbac", "abac"],

"auditing": true

}

```

---

# 3. Multi-Agent-Orchestrierung mit MCP

## 3.1 Agentenrollen

| Agent | Aufgabe |

| ------------- | ------------------- |

| **Planner** | Zerlegt Aufgabe |

| **Retriever** | Holt Kontext |

| **Executor** | Führt Tools aus |

| **Writer** | Antwort formulieren |

---

## 3.2 Orchestrierung

```

User

↓

Planner Agent

↓

Retriever → MCP(Context)

↓

Executor → MCP(Tool)

↓

Writer Agent

↓

User

```

---

## 3.3 Orchestrator (Pseudo-Code)

```python

def orchestrate(user, task):

plan = planner_agent(task)

context = retriever_agent(

user=user,

resource=plan["resource"]

)

result = executor_agent(

user=user,

tool=plan["tool"],

input=context

)

return writer_agent(result)

```

**Wichtig:**

Kein Agent hat direkten Zugriff auf DB oder APIs – **nur MCP**.

---

# 4. Produktionsarchitektur (Docker, Auth, Secrets)

## 4.1 Zielbild

```

┌──────────┐ ┌──────────┐

│ Frontend │ → │ Backend │

└──────────┘ └────┬─────┘

│

┌─────▼─────┐

│ MCP Server │

└─────┬─────┘

│

┌──────▼──────┐

│ LLM Provider │

└─────────────┘

```

---

## 4.2 Dockerfile (MCP)

```dockerfile

FROM python:3.11-slim

WORKDIR /app

COPY requirements.txt .

RUN pip install -r requirements.txt

COPY . .

CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8080"]

```

---

## 4.3 Docker Compose

```yaml

version: "3.9"

services:

mcp:

build: .

ports:

- "8080:8080"

environment:

- MCP_ENV=prod

- POLICY_MODE=strict

secrets:

- jwt_public_key

secrets:

jwt_public_key:

file: ./secrets/jwt.pub

```

---

## 4.4 Auth & Secrets (Best Practice)

### Auth

* JWT (OIDC, z. B. Keycloak / Auth0)

* User-Claims → MCP Policy Engine

### Secrets

* **keine Secrets im Prompt**

* **keine Secrets im Container**

* Vault / Kubernetes Secrets / AWS Secrets Manager

---

## 4.5 Governance & Audit

* jeder MCP-Call:

* user_id

* resource / tool

* timestamp

* result_hash

* revisionssicher loggen (SIEM-fähig)

---

# Abschließendes Fazit

Du hast jetzt:

* einen **vollständigen MCP-Server (Python)**

* ein **formales OpenAPI/MCP-Schema**

* eine **echte Multi-Agent-Architektur**

* ein **produktives Deployment-Modell**

Das ist exakt die Architektur, die Unternehmen aktuell aufbauen, wenn KI **kein Experiment**, sondern **Kerninfrastruktur** ist.

Designed With ❤ Balbooa.com