← Startseite
🤖

Vorlesung 7

KI, Agenten & MCP
LLMs, Tool-Use, Model Context Protocol — mit Code-Beispielen

Fortgeschrittene Algorithmen und Programmierung
Prof. Dr. Alexandra Mikityuk
HTW Berlin

LLMs Agenten MCP

Lernziele

  • Verstehen, wie LLMs intern funktionieren — Tokens, Transformer, Training
  • Die wichtigsten Entwickler-Konzepte kennen: Context Window, Temperature, Halluzinationen, RAG
  • Den Unterschied zwischen Chat und Agent erklären — Agentic Loop, Tool Use
  • Das Model Context Protocol (MCP) verstehen — Architektur, Request/Response, eigene Server bauen
  • Bestehende MCP-Server kennen (Filesystem, GitHub, DB, Web-Suche)
  • Verstehen, wo bei MCP+LLM die Daten landen — und welche Sicherheits-Regeln gelten

Warum diese Vorlesung — warum jetzt?

📈 Praktische Realität

2026 ist KI nicht mehr „nice to have" — sie sitzt in jeder Entwickler-Toolchain (Copilot, Claude Code, Cursor). Wer sie nicht versteht, wird produktivitätsmäßig abgehängt.

🎓 Hier & jetzt

Die Konzepte LLM/Agent/MCP sind nicht magisch — es sind Algorithmen + Protokolle. Heute zerlegen wir sie systematisch — mit Code, nicht nur mit Buzzwords.

Was diese VL nicht ist: kein „Wie schreibe ich Prompts"-Tutorial. Wir schauen unter die Haube: was ist ein Token, wie funktioniert Tool-Use, wie sieht ein MCP-Request aus.

Was ist ein Large Language Model (LLM)?

In einem Satz: ein neuronales Netz, das die nächste Worteinheit (Token) vorhersagt — gegeben den bisherigen Text.

🔤 Tokens

Ein Token ist eine Worteinheit — ca. 3-4 Zeichen oder ein kurzes Wort. Beispiel:

"Hallo Welt!"
→ ["Hallo", " Welt", "!"]
→ [15043, 4435, 0]   (Zahlen)

Das LLM sieht nur Zahlen, niemals Buchstaben direkt.

🎯 Vorhersage

Bei Input "Die Hauptstadt von Frankreich ist" gibt das LLM für jedes mögliche nächste Token eine Wahrscheinlichkeit aus:

"Paris"   → 92%
"Berlin"  →  2%
"Lyon"    →  1%
…
Wichtig: ein LLM generiert Token für Token — nach jedem neuen Token wird das Modell erneut aufgerufen, jetzt mit dem alten Text + dem neuen Token. Das nennt man autoregressive Generierung.

Transformer — die Schlüssel-Architektur

Vor 2017: RNNs/LSTMs verarbeiteten Text sequenziell — langsam, kurzer Kontext. Der Transformer („Attention is all you need", Vaswani et al. 2017) änderte alles.

🐢 RNN/LSTM (vor 2017)

  • Sequentielle Verarbeitung — Token nach Token
  • Vergisst frühere Tokens („vanishing gradient")
  • Schwer parallelisierbar

🚀 Transformer

  • Attention: jedes Token „schaut auf" alle anderen gleichzeitig
  • Beliebig lange Abhängigkeiten möglich
  • Massiv parallelisierbar → GPUs/TPUs ausnutzbar
Attention in einem Satz: für jedes Token wird berechnet, „wie wichtig" jedes andere Token im Kontext ist. Das gibt Bedeutungs-Verbindungen über beliebig große Distanzen — anders als bei RNNs.
Konsequenz: alle modernen LLMs (GPT, Claude, Gemini, Llama, …) sind Transformer-basiert. Unterschiede liegen in Größe (Parameter-Anzahl), Training-Daten, Feintuning.

Vor dem Transformer: RNNs und LSTMs

Wie hat man Text vor 2017 verarbeitet? Mit sequenziellen Netzen — und das war das Problem.

RNN (Recurrent Neural Network)

Verarbeitet Text Wort für Wort, sequenziell — wie Lesen von links nach rechts.

Jedes Wort wird verarbeitet, ein „Gedächtnis" (Hidden State) wird weitergegeben.

Problem: bei langen Texten „vergisst" das Netz die ersten Wörter — wie stille Post, am Ende kommt nur noch Rauschen an.

LSTM (Long Short-Term Memory)

Verbesserte RNN mit einem „Notizbuch": kann gezielt Informationen merken oder vergessen.

Hat „Gates" (Tore), die steuern, welche Infos behalten und welche verworfen werden.

Besser, aber: immer noch sequenziell (langsam). Bei sehr langen Texten (> 1000 Wörter) trotzdem Kontextverlust.
Gemeinsames Problem: beide Architekturen verarbeiten sequenziell — Wort 1, dann Wort 2, dann Wort 3 — nicht parallelisierbar, langsam auf GPUs, Kontext geht verloren. Genau das löst der Transformer auf der nächsten Slide.

Wie wird ein LLM trainiert? — in 3 Phasen

1️⃣ Pretraining

Gigantische Text-Mengen (Internet, Bücher) → das Modell lernt Sprache vorherzusagen. Statistisch nächstes Token bei beliebigem Input.

Dauer: Wochen bis Monate · Kosten: 10 Mio. € aufwärts

2️⃣ Supervised Finetuning

Kleinere Datensätze mit Q&A-Paaren: „Frage X → gute Antwort Y". Das Modell lernt, hilfreich zu antworten — nicht nur Text fortzusetzen.

3️⃣ RLHF

Reinforcement Learning from Human Feedback: Menschen bewerten Antworten, das Modell wird auf „präferierte" Antworten getrimmt. Macht es höflich, sicher, hilfreich.

Konsequenz: wenn jemand sagt „das Modell weiß X" — eigentlich heißt das, das Modell hat in den Trainingsdaten genug Hinweise auf X gesehen, dass es plausibel davon redet. Es gibt kein „Wissen", nur statistische Korrelation.

Die KI-Landschaft 2026 — die wichtigsten Modelle

ModellAnbieterStärkenContext
Claude 4.x (Opus, Sonnet, Haiku)AnthropicCode, Reasoning, Tool-Usebis 1 Mio. Tokens
GPT-5OpenAIGeneralist, Multimodal~ 400k Tokens
Gemini 2.xGoogleMultimodal, große Context-Fenster2+ Mio. Tokens
Llama 4MetaOpen-Weight, lokal lauffähig~ 128k Tokens
Mistral / DeepSeekEU / ChinaEffizient, Open-Weight32k-200k Tokens
Praxis-Auswahl: in diesem Kurs nutzen wir Claude — gute Code-Performance, einfache API, MCP-First-Class-Support. Konzepte sind aber 1:1 auf andere Modelle übertragbar.

Was kann ein LLM? Was nicht?

Realistische Erwartungen — was ein LLM standalone kann, und wo es scheitert.

Das kann ein LLM

  • Code schreiben und erklären
  • Text zusammenfassen
  • Übersetzen (auch zwischen Programmiersprachen)
  • Konzepte erklären, Analogien finden
  • Muster in Daten erkennen
  • Bugs finden, Refactoring vorschlagen
  • Brainstorming, Ideenfindung

Das kann ein LLM NICHT

  • Zuverlässig rechnen (Mathe-Fehler möglich!)
  • Aktuelle Infos kennen (Wissens-Cutoff!)
  • Wirklich verstehen (statistische Muster)
  • Im Internet suchen (ohne Tools)
  • Dateien lesen/schreiben (ohne Tools)
  • Programme ausführen (ohne Sandbox)
  • Garantiert korrekt sein (Halluzinationen!)
Merke: ein LLM ist ein extrem guter Textgenerator — kein allwissendes Orakel. Die „NICHT"-Spalte wird teilweise durch Tools und Agenten gelöst — dazu gleich mehr.

Zwei zentrale Entwickler-Konzepte

📐 Context Window

Die maximale Anzahl Tokens, die das Modell in einem Request sehen kann — Input + Output zusammen.

Bei 1 Mio. Tokens (Claude Opus): ca. 750 000 Wörter — ein ganzes Buch passt rein.

Wichtig: Tokens kosten Geld. Längerer Context = teurer API-Aufruf.

🎲 Temperature

Ein Parameter (0.0 - 1.0) der die Zufälligkeit der Antwort steuert:

  • 0.0 — immer das wahrscheinlichste Token (deterministisch)
  • 1.0 — sehr variabel, kreativ

Code-Generierung: 0.0 - 0.3. Brainstorming: 0.7 - 1.0.

Gleicher Prompt, andere Temperature → andere Antwort. Bei Bug-Reproduktion: temperature=0 setzen, sonst lässt sich der Bug nicht reproduzieren.

Halluzinationen + die Lösung: RAG

🌀 Halluzination

Das Modell erfindet plausible, aber falsche Fakten — weil es nur statistisch vorhersagt, nicht „weiß".

Beispiel: Frage nach einem Paper-Titel → das Modell erfindet einen, der nie existierte, aber stilistisch passt.

🔍 RAG — Retrieval-Augmented Generation

Statt sich auf Modell-„Wissen" zu verlassen: relevante Dokumente aus einer Datenbank abrufen, in den Prompt einfügen, dann antworten lassen.

Ablauf: Frage → Dokumente suchen → an Prompt anhängen → Modell antwortet mit Kontext.

Praxis-Regel: für faktische Antworten (Doku, Code-Referenzen, eigene Daten) immer RAG nutzen. Halluzinationen sind unvermeidbar, aber durch Kontext stark reduzierbar.

Claude Code — Terminal & VS Code

Die KI-Engine für Entwickler, die wir hier nutzen. Läuft in zwei Modi.

🖥️ Modus 1: Im Terminal

# Claude Code starten
$ claude

# Beispiel-Prompts:
> Erkläre mir dieses Projekt
> Finde den Bug in server.py
> Schreibe Unit-Tests für api.py

📝 Modus 2: In VS Code

  • Extension „Claude Code" aus dem Marketplace
  • Gleiche Engine — bequemere Oberfläche
  • Inline-Hilfe, Code-Generierung, Refactoring
  • Terminal-Integration eingebaut
Was Claude Code kann: Dateien lesen, schreiben, erstellen + Git-Befehle ausführen + Tests schreiben & laufen lassen. Es versteht den gesamten Projekt-Kontext.
Wichtig: wer die VS Code Extension nutzt, nutzt bereits Claude Code — dieselbe Engine. Im Hintergrund läuft genau die Agent-Architektur, die wir gleich besprechen.

Prompt Engineering — Grundlagen

Vier Regeln, die 80% des Unterschieds zwischen brauchbaren und unbrauchbaren Antworten ausmachen.

  • Sei spezifisch: Sprache, Framework, Ziel benennen — nicht „mach mir was", sondern „in Python mit Flask"
  • Gib Kontext: Zielgruppe, Einschränkungen, Umgebung („für Embedded, kein malloc verfügbar")
  • Beispiele geben (Few-Shot): zeige, wie das Ergebnis aussehen soll — auch mit Input/Output-Paaren
  • Iteriere: Ergebnis → Feedback → Verbesserung. Selten ist der erste Prompt der beste.

😤 Schlecht

"Mach mir eine API"

✨ Gut

"Erstelle einen REST-Server in
Python mit Flask:
- GET /api/sensors → Liste (JSON)
- POST /api/sensors → Hinzufügen
- Verwende SQLite
- Füge Error-Handling hinzu"

Von Chat zu Agent — die Evolution

Bisher: ein Prompt → eine Antwort. Aber moderne KI-Anwendungen brauchen mehr: mehrere Schritte, externe Daten, Aktionen in der Welt.

StufeWas kann's?Beispiel
Chat-LLMantwortet auf FrageChatGPT-Tab
+ Tool-Usekann externe Tools aufrufen (Web-Suche, Rechner)ChatGPT mit Browser-Plugin
Agentplant, ruft Tools in Schleife, korrigiert sichClaude Code, Cursor, Auto-GPT
Multi-Agentspezialisierte Agenten arbeiten zusammenkomplexe Workflows
Der Sprung liegt zwischen „Chat" und „Agent" — ein Agent hat Autonomie über mehrere Schritte. Er entscheidet selbst, welches Tool wann aufgerufen wird.

Was ist ein KI-Agent?

Definition: ein Agent ist ein LLM, das in einer Schleife läuft, Tools aufrufen kann und autonom entscheidet, welcher Schritt als nächstes kommt.

🔁 Loop

Schritt 1 → beobachte Ergebnis → Schritt 2 → … bis Ziel erreicht oder Limit.

🛠️ Tools

Funktionen, die der Agent aufrufen kann: Datei lesen, HTTP-Request, Bash-Command, Datenbank-Query.

🧠 Autonomie

Der Agent entscheidet selbst, welches Tool wann — kein hartgekodeter Ablauf.

Beispiel — Claude Code: ihr schreibt „füg Dark-Mode ein" → Claude liest Dateien, schreibt neue Komponenten, läuft Tests, korrigiert Fehler, committed. Alles autonom in einer Loop. Das ist der Standard-Agent heute.

Der Agentic Loop visualisiert

Wiederholt sich, bis Modell kein Tool mehr aufruft (= „Aufgabe erledigt").

User-Prompt
Modell denkt
Tool aufrufen?
JA
Tool ausführen
Ergebnis ans Modell
zurück zu „Modell denkt"
Tool aufrufen?
NEIN
Antwort an User
In Code: eine simple while-Schleife in der Host-Anwendung — solange das Modell ein tool_use-Block zurückgibt, ausführen + Ergebnis anhängen + erneut fragen.

Tool Use — Code-Beispiel

Wir geben Claude ein Tool zum Wetter-Abfragen — und lassen es entscheiden, wann es dieses ruft.

# 1. Tool definieren — JSON-Schema
tools = [{
    "name": "get_weather",
    "description": "Aktuelles Wetter für eine Stadt",
    "input_schema": {
        "type": "object",
        "properties": {"city": {"type": "string"}},
        "required": ["city"]
    }
}]

# 2. Anfrage mit Tools
response = client.messages.create(
    model="claude-opus-4-7",
    max_tokens=1024,
    tools=tools,
    messages=[{"role": "user", "content": "Wie ist das Wetter in Berlin?"}]
)

# 3. Claude antwortet mit tool_use Block
if response.stop_reason == "tool_use":
    tool_call = response.content[0]
    # tool_call.name = "get_weather"
    # tool_call.input = {"city": "Berlin"}
    result = get_weather(tool_call.input["city"])    # unsere Funktion

    # 4. Ergebnis zurück an Claude, fragen weiter
    final = client.messages.create(
        model="claude-opus-4-7", max_tokens=1024, tools=tools,
        messages=[
            {"role": "user", "content": "Wie ist das Wetter in Berlin?"},
            {"role": "assistant", "content": response.content},
            {"role": "user", "content": [{"type": "tool_result",
                "tool_use_id": tool_call.id, "content": result}]}
        ]
    )
    print(final.content[0].text)   # "In Berlin ist es heute 18°C…"
Schlüssel-Punkt: Claude führt das Tool nicht selbst aus — es sagt nur „bitte ruf get_weather mit Berlin auf". Wir (die Host-App) führen die Funktion aus und schicken das Ergebnis zurück. Das ist der Sicherheits-Vorteil von Tool-Use.

Multi-Agent-Systeme

Statt einem großen Agent: mehrere spezialisierte Agenten, koordiniert von einem Orchestrator.

Orchestrator-Agent
↓ delegiert
Research-Agent
Coding-Agent
Test-Agent
↓ Ergebnisse zurück
Orchestrator fasst zusammen
Warum? Spezialisierte Agenten haben fokussiertere Prompts/Tools — bessere Ergebnisse. Plus: parallel ausführbar → schneller. Trade-off: mehr Komplexität, höhere Token-Kosten.

Model Context Protocol (MCP) — das Problem

Jede Host-App (Claude Desktop, Cursor, Claude Code) braucht Zugriff auf Tools und Daten. Bisher: jede App implementiert ihre Integration selbst → Code-Duplikation, inkompatibel.

😩 Vorher: M × N Problem

Bei M Hosts und N Datenquellen = M × N Integrationen. Jede Tool-Anbindung muss für jeden Host neu geschrieben werden.

MCP: M + N

Standardisiertes Protokoll (JSON-RPC). Tool-Anbieter implementieren einmal einen MCP-Server. Hosts implementieren einmal einen MCP-Client. Fertig.

Analogie: MCP ist für KI-Tools, was USB für Hardware war. Vorher: jeder Hersteller eigene Anschlüsse. Mit USB: jedes Gerät passt an jeden Computer.

MCP-Architektur

Drei Rollen, klar getrennt.

🏠 Host

Die App, in der das LLM läuft. Z.B. Claude Desktop, Claude Code, Cursor. Sie spricht mit dem LLM und mit den MCP-Servern.

🔌 Client

Im Host eingebaut: spricht das MCP-Protokoll (JSON-RPC), verbindet zu Servern, ruft deren Tools auf.

🛠️ Server

Stellt Tools/Resources/Prompts zur Verfügung — z.B. Filesystem-Zugriff, GitHub-API, Datenbank. Wird vom Host gestartet.

Datenfluss: User schreibt Prompt → Host an LLM → LLM will Tool nutzen → Host fragt MCP-Server → Server liefert Ergebnis → zurück an LLM → LLM antwortet User.

MCP unter der Haube — JSON-RPC

MCP nutzt JSON-RPC 2.0 — ein einfaches Request/Response-Format.

📤 Request (Host → Server)

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "read_file",
    "arguments": {
      "path": "/etc/hosts"
    }
  }
}

📥 Response (Server → Host)

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "content": [{
      "type": "text",
      "text": "127.0.0.1 localhost..."
    }]
  }
}
Transport-Schichten: der gleiche JSON-RPC läuft über stdio (lokale Subprozesse), SSE (Server-Sent Events über HTTP) oder WebSocket. Host wählt, der Server bedient alle drei.

Eigener MCP-Server — in 20 Zeilen Python

Mit pip install mcp ist das offizielle SDK installiert.

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("htw-tools")

@mcp.tool()
def grade_lookup(student_id: str) -> str:
    """Liefert die Note eines Studierenden anhand seiner Matrikelnummer."""
    # Hier würdest du eine DB abfragen — vereinfacht hardcoded:
    grades = {"12345": "1.7", "67890": "2.3"}
    return grades.get(student_id, "keine Note gefunden")

@mcp.tool()
def average(numbers: list[float]) -> float:
    """Berechnet den Durchschnitt einer Liste von Zahlen."""
    return sum(numbers) / len(numbers)

if __name__ == "__main__":
    mcp.run()   # startet stdio-Server
Das war's wirklich. Die @mcp.tool()-Decorator-Magie macht JSON-Schema-Generierung + Routing automatisch. Funktions-Signatur + Docstring → fertiges Tool.

End-to-End: Claude + MCP-Server

Wir verbinden den MCP-Server von eben mit Claude Desktop / Claude Code.

🔧 Konfigurations-Datei

In Claude Desktop / Claude Code legt man eine Config-Datei an. Beispiel ~/.claude/mcp.json:

{
  "mcpServers": {
    "htw-tools": {
      "command": "python",
      "args": ["/Users/htw/server.py"]
    }
  }
}
Was passiert beim Start:
  1. Claude Code startet als Subprozess python server.py
  2. Kommunikation über stdin/stdout (stdio-Transport)
  3. Claude fragt initial: „welche Tools gibt's?" → Server antwortet mit JSON-Schema von grade_lookup + average
  4. Claude weiß ab jetzt: ich kann diese Tools nutzen. Ruft sie autonom auf, wenn passend.

Es gibt schon viele MCP-Server

Anthropic + Community pflegen einen großen Pool — meistens reicht: installieren, konfigurieren, fertig.

💾 Filesystem

Dateien lesen/schreiben in einem Sandbox-Verzeichnis. Der Standard für IDE-Integration.

🐙 GitHub / GitLab

Issues, PRs, Code-Suche. Claude kann Issues triagieren, PRs reviewen, Releases erstellen.

🗄️ PostgreSQL / SQLite

SQL-Queries gegen eure DB ausführen lassen. Vorsicht: nur read-only empfehlen!

🌐 Web-Suche / Browser

Brave Search, Fetch, Puppeteer. Live-Recherche zur Laufzeit.

💬 Slack / Linear / Jira

Nachrichten posten, Tickets erstellen — Anbindung an Team-Workflow.

🔧 Eigene

Wir bauen unseren eigenen für die Klausur-DB im Lab.

Sicherheit — Wo gehen die Daten wirklich hin?

Falsche Intuition: „Wenn der MCP-Server lokal läuft, bleiben meine Daten lokal." — Stimmt nicht.

Beispiel: lokale Excel-Datei mit Claude Code

📊 Excel-Datei auf deinem Mac (lokal)
🛠️ Lokaler MCP-Server liest sie (lokal)
🏠 Claude Code empfängt den Inhalt (lokal)
↓ HIER verlässt es deinen Rechner
☁️ Claude Code schickt den Inhalt an die Anthropic-API (damit das LLM ihn sehen kann)
🧠 Claude (Cloud) liest den Inhalt, antwortet

Lokaler MCP + Cloud-LLM

Dateien werden lokal gelesen — aber der Inhalt geht ans LLM in der Cloud. Anthropic sieht ihn.

100% lokal — nur mit lokalem LLM

Z.B. Ollama als LLM + lokaler MCP-Server. Erst dann verlässt nichts den Rechner.

Faustregel: sensible Daten (Passwörter, API-Keys, Firmendaten) NIEMALS an MCP-Server geben, deren Output an ein Cloud-LLM weitergegeben wird.

Sicherheit — Best Practices

🔍 Code-Review

KI-generierten Code immer prüfen — Sicherheitslücken möglich! Vor allem Input-Validation, Auth-Checks, SQL-Strings.

🔑 API-Keys

Nie in Prompts oder Code einfügen. Immer .env-Dateien + Umgebungsvariablen nutzen.

🛠️ MCP-Server aus dem Internet

Nur vertrauenswürdige Quellen. Code vorher lesen! Ein fremder MCP-Server bekommt Tool-Use-Anweisungen vom LLM — er kann viel anstellen.

🏠 Lokale Modelle für Sensibles

Ollama, LM Studio — alles bleibt auf dem Rechner. Für vertrauliche Projekte (Firma, Forschung) ideal.

🔒 Verschlüsselung: wenn MCP über Netzwerk läuft (statt lokal als Subprozess), dann nur über verschlüsselte Kanäle (HTTPS, WSS).

Zusammenfassung

  • LLM = Next-Token-Vorhersage auf Basis eines Transformers. Tokens, Context Window, Temperature sind die zentralen Hebel.
  • Agent = LLM in Schleife + Tools + Autonomie. Standard-Anwendung: Claude Code & Co.
  • Tool-Use = LLM sagt „bitte ruf X auf", Host führt aus, Ergebnis zurück. LLM führt nie selbst aus.
  • MCP = standardisiertes Protokoll (JSON-RPC) für Host ↔ Tool-Server. Schreib einen Server einmal, jeder MCP-fähige Host kann ihn nutzen.
  • Viele fertige MCP-Server existieren bereits (Filesystem, GitHub, DB, Web-Suche) — der eigene ist meist nur eine Ergänzung.
  • Sicherheit: Daten gehen bei Cloud-LLM IMMER an den LLM-Anbieter — auch bei lokalem MCP-Server. Für vertrauliches: lokales LLM (Ollama, LM Studio).

Vielen Dank!

Fragen?

Prof. Dr. Alexandra Mikityuk

HTW Berlin · Büro Raum 308

Tel +49 30 5019-2664

Nächste Woche: Sicherheit I — Hashing & Passwörter

1 / …