← 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).

📚 Quellen & weiterführende Literatur

Was ihr lesen / ausprobieren solltet, wenn ihr tiefer einsteigen wollt:

📖 LLMs & Transformer

  • Vaswani et al. (2017): „Attention is All You Need" — das Transformer-Paper
  • 3Blue1Brown — Neural Networks (YouTube-Reihe, sehr visuell)
  • Karpathy: „Let's build GPT from scratch" (YouTube, hands-on)
  • Anthropic Research: anthropic.com/research

🤖 Agenten & Tool-Use

  • Anthropic: „Building Effective Agents" (Engineering-Blog)
  • Claude Docs: docs.claude.com (Tool Use, Messages API, Streaming)
  • Wei et al.: „ReAct: Reasoning + Acting in Language Models"

🔌 MCP — Model Context Protocol

🛠️ Zum Ausprobieren

  • Claude Code: docs.claude.com/claude-code
  • Anthropic Quickstart: 10 Zeilen Python, erster API-Call
  • HuggingFace Transformers — lokale Open-Weight-Modelle (Llama, Mistral)
  • Ollama: ollama.com — LLMs lokal laufen lassen
Praxis-Tipp: der schnellste Weg ist selbst bauen. Schreibt einen MCP-Server in 30 Zeilen Python, hängt ihn an Claude Code, schaut wie der Agent ihn nutzt. Eine Stunde Praxis schlägt zehn Stunden Theorie.

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 / …