CGS IT Solutions GmbH — Claude Code Training · Modul 8 · MCP · v0.4.7

Modul 8

MCP im Detail

Vertiefung · Model Context Protocol

Inhalt

1Konzepte & Vokabular — was MCP ist, Client/Server/Tools, Transport 2Server verwenden — .mcp.json, Scopes, Freigabe, echtes Beispiel 3Eigenen Server bauen — einen Service als MCP-Server exponieren (Quarkus) 4Abgrenzung zur CLI — Token Overhead, Entscheidung, Vendor Lock-in Übung — einen eigenen Tool-Endpoint exponieren Glossar — Begriffe zum Nachschlagen

Konzepte & Vokabular

Was MCP ist

MCP (Model Context Protocol) ist ein offenes Protokoll, über das ein Client wie Claude Code strukturiert an fremde Werkzeuge und Daten andockt — einmal gebaut, an jedem Client nutzbar.

  1. Client und Server sprechen dieselbe Sprache — unabhängig davon, wer sie gebaut hat.
  2. Nicht proprietär: ein Server, den ihr einmal schreibt, funktioniert an jedem MCP-fähigen Client, nicht nur an Claude Code.
  3. Strukturiert statt Text: der Agent bekommt aufrufbare Funktionen mit Parametern, kein Freitext zum Parsen.
# Ohne MCP
Agent liest CLI-Textausgabe
und rät die Struktur.

# Mit MCP
Agent ruft Tool("freeSeats", id=7)
und bekommt { "free": 12 } zurück.
MCP ist der Anti-Lock-in-Teil des Stacks: ein Protokoll, kein Produkt.

Das Vokabular Glossar

Sechs Begriffe genügen, um jede MCP-Config zu lesen — in der Praxis begegnen euch fast nur die ersten drei.

Client

Die Anwendung, in der das Modell läuft — hier Claude Code. Verbindet sich zu Servern.

Server

Ein Prozess, der Fähigkeiten anbietet. Lokal gestartet oder remote erreichbar.

Tools

Aufrufbare Funktionen mit Parametern — das, was der Agent tatsächlich ausführt.

Resources

Lesbare Inhalte, die der Server bereitstellt — Dokumente, Datensätze, Zustände.

Prompts

Vom Server mitgelieferte Vorlagen, die der Nutzer auswählen kann.

Connectors

Fertige, gehostete Anbindungen an Dienste — MCP als Produkt statt Selbstbau.

checked am 2026-07-24 gegen code.claude.com

Transport: lokaler Prozess oder Remote-Dienst

Ein MCP-Server läuft entweder als lokaler Prozess (stdio) oder als Remote-Dienst (HTTP) — die Config verrät sofort, welcher.

  1. stdio (lokal): command + args starten einen Kindprozess; Claude Code redet über stdin/stdout — kein Netzwerk.
  2. HTTP (remote): type: "http" + url — Verbindung zu einem laufenden Dienst über das Netz.
  3. Faustregel: steht command drin, ist es lokal; steht url drin, ist es remote.
// stdio — lokaler Prozess
"angular": {
  "command": "npx",
  "args": ["-p", "@angular/cli", "ng", "mcp"]
}

// http — Remote-Dienst
"stripe": {
  "type": "http",
  "url": "https://mcp.stripe.com"
}
Der Unterschied ist sicherheitsrelevant: ein Remote-Server sieht, was ihr ihm schickt; ein stdio-Server läuft in eurer eigenen Umgebung.
checked am 2026-07-24 gegen code.claude.com

Server verwenden

.mcp.json: Scopes & Freigabe

Wo ein Server konfiguriert ist, entscheidet, wer ihn bekommt — und jeder Server wird beim ersten Start einzeln freigegeben.

  1. Project — .mcp.json im Repo-Root, per Versionskontrolle geteilt: das ganze Team bekommt dieselben Server.
  2. Local — nur für dich in diesem Projekt (in ~/.claude.json), z. B. für Server mit persönlichen Credentials.
  3. User — für dich über alle Projekte hinweg.
  4. Freigabe: ein Server aus dem Repo ist erst mal fremder Code — er läuft erst nach expliziter Zustimmung.
# Scope-Ablage
Project  .mcp.json (Repo-Root, geteilt)
Local    ~/.claude.json (privat)
User     ~/.claude.json (alle Projekte)

# Status prüfen
/mcp # zeigt Server + Tools + Freigabe
/mcp zeigt jederzeit, welche Server verbunden sind und welche Werkzeuge sie anbieten.
checked am 2026-07-24 gegen code.claude.com

Echtes Beispiel: der Angular-Server

Aus cgsit-finance — genau ein Server, ein lokaler stdio-Prozess, und der aus gutem Grund.

  1. Was er kann: u. a. get_best_practices, list_projects, search_documentation, run_target — Wissen nach dem Trainings-Cutoff, das keine CLI so ausliefert. Doku: angular.dev/ai/mcp.
  2. Lokal, kein Netz: command: npx startet ng mcp als Kindprozess; Internet berührt nur der einmalige Paket-Download.
  3. Die Disziplin: ein Server, nicht fünf — jeder legt seine Tool-Beschreibungen in jeden Kontext.
// .mcp.json — Repo-Wurzelverzeichnis
{
  "mcpServers": {
    "angular": {
      "command": "npx",
      "args": ["-p", "@angular/cli", "ng", "mcp"],
      "cwd": "…/cgsit-finance-web"
    }
  }
}
Tipp: Jeder Server muss sich gegen eine Frage rechtfertigen: Was kann er, das ein vorhandenes CLI nicht kann?
checked am 2026-07-24 gegen cgsit-finance + angular.dev

Tool-Namen & wie der Agent sie ruft

Jedes Tool eines Servers trägt einen eindeutigen Namen nach festem Schema — so weiß der Agent, welchen Server er anspricht.

  1. Namensschema: mcp__<server>__<tool> — der Präfix macht sichtbar, woher ein Werkzeug kommt.
  2. Freigabe pro Tool: in settings.local.json stehen die erlaubten Tools namentlich — nicht der ganze Server pauschal.
  3. Kosten im Blick: jeder aktive Server lädt seine Tool-Definitionen in jede Runde (Modul 1: alles wird neu geschickt).
// .claude/settings.local.json
"enabledMcpjsonServers": [ "angular" ],
"permissions": {
  "allow": [
    "mcp__angular__list_projects",
    "mcp__angular__get_best_practices"
  ]
}
checked am 2026-07-24 gegen cgsit-finance

Eigenen Server bauen

Zusatzthema — über das Kern-Curriculum hinaus

Wann ein eigener Server — und wann nicht

Ein eigener MCP-Server lohnt sich erst, wenn ein vorhandenes CLI oder Skill die Aufgabe nicht sauber löst.

Eigener Server lohnt sich

  • strukturierter Zugriff auf einen eigenen Dienst (DB, interne API), den kein Standard-CLI kennt
  • der Agent soll wiederholt und in jeder Session darauf zugreifen
  • die Antwort ist strukturiert und lässt sich schlecht aus Text parsen

Lieber CLI oder Skill

  • ein Shell-Kommando tut es einmalig genauso — kein Server-Betrieb nötig
  • es geht um ein Verfahren, nicht um Datenzugriff (dann Skill)
  • der Nutzen rechtfertigt die dauerhafte Kontext-Miete nicht (Block 4)

Anatomie: ein Server ist eine Menge Tools

Einen MCP-Server bauen heißt: Methoden als Tools deklarieren — Name, Beschreibung, typisierte Parameter, Rückgabewert.

  1. Ein Tool = eine Methode mit einer klaren Beschreibung, die dem Modell sagt, wann es sie nutzt.
  2. Parameter sind typisiert und beschrieben — daraus baut der Client das Aufruf-Schema.
  3. Transport ist Konfiguration, nicht Code: dieselbe Klasse läuft als stdio- oder als HTTP-Server.
Server
  - Tool freeSeats(seminarId)
  - Tool bookSeat(seminarId, user)
  - Tool cancelBooking(id)

# der Client sieht Namen,
# Beschreibung, Parameter-Schema

Code: ein eigener Server in Quarkus

Mit der Quarkus-MCP-Extension wird aus einer annotierten Methode ein Tool — die Fachlogik bleibt euer bestehender Service.

// pom.xml — stdio-Transport
io.quarkiverse.mcp:quarkus-mcp-server-stdio:2.0.0.Beta3

// SeminarTools.java
import io.quarkiverse.mcp.server.Tool;
import io.quarkiverse.mcp.server.ToolArg;

public class SeminarTools {
  @Inject SeminarService seminars;

  @Tool(description = "Freie Plätze eines Seminars abfragen")
  int freeSeats(@ToolArg(description = "Seminar-ID") long seminarId) {
    return seminars.freeSeats(seminarId);
  }
}
@Tool macht die Methode aufrufbar, @ToolArg beschreibt die Parameter — mehr braucht ein erstes Tool nicht. Der Service dahinter ist unverändert.
checked am 2026-07-24 gegen docs.quarkiverse.io

Registrieren & testen

Der fertige stdio-Server wird wie jeder andere in .mcp.json eingetragen — als command, der euren Prozess startet.

  1. Bauen: das Quarkus-App-Artefakt erzeugen (./mvnw package).
  2. Registrieren: als command-Server eintragen, der die App über stdio startet.
  3. Freigeben: beim ersten Start den Server bestätigen (Workspace-Trust).
  4. Prüfen: /mcp zeigt den Server und sein Tool freeSeats.
// .mcp.json
"seminar": {
  "command": "java",
  "args": ["-jar",
    "target/quarkus-app/quarkus-run.jar"]
}

/mcp # seminar: freeSeats [ok]
Ab jetzt kann der Agent mcp__seminar__freeSeats aufrufen — strukturiert, ohne euren Service als Text zu parsen.
checked am 2026-07-24 gegen docs.quarkiverse.io

Abgrenzung zur CLI

MCP vs. CLI: Token Overhead

Jeder aktive MCP-Server lädt seine Tool-Definitionen in den Kontext — das kostet, bevor irgendetwas passiert, und in jeder Runde erneut.

MCP-Server

  • dauerhafte Kontext-Miete für alle Tools, auch die nie benutzten
  • lohnt sich bei Wissen/Zugriff, den der Agent sonst nicht hat

CLI

  • kostet Kontext nur, wenn es aufgerufen wird
  • ideal für einmalige oder seltene Operationen
Context Hygiene: ein Server, der selten hilft, kostet trotzdem in jeder Runde. Nur andocken, was sich rechnet.

Entscheidung: MCP, CLI oder Skill?

Drei Werkzeuge, drei Fragen — die Antwort ergibt sich fast immer aus Ort und Häufigkeit.

Wenn ich will…dannweil
ein Shell-Kommando einmalig ausführenCLIkostet Kontext nur beim Aufruf
ein wiederkehrendes Verfahren abrufbar machenSkillAnleitung, kein externer Zugriff
strukturiert auf ein System außerhalb zugreifenMCPstrukturierte Schnittstelle statt Textparsen
einen eigenen Dienst wiederholt anbindenMCP (eigener Server)kein Standard-CLI kennt ihn
Im Zweifel die günstigere Stufe wählen: erst CLI, dann Skill, dann MCP — ein Server ist die teuerste Bindung.

Open Source & Vendor Lock-in

Weil MCP ein offenes Protokoll ist, bindet euch ein selbst gebauter Server an keinen Anbieter — er läuft an jedem MCP-fähigen Client.

  1. Ein Server, viele Clients: dieselbe Anbindung funktioniert über Werkzeuggrenzen hinweg.
  2. Eigener Code, eure Kontrolle: ein stdio-Server läuft in eurer Umgebung, nicht bei einem Dritten.
  3. Abwägung Connectors: gehostete Fertig-Anbindungen sind bequem, aber genau der Lock-in, den das Protokoll vermeidet.
Ein Server
  läuft an Claude Code,
  läuft an anderen MCP-Clients,
  läuft morgen an dem,
  den es noch nicht gibt.
Das ist der strategische Wert von MCP: Investition in eine Anbindung, nicht in einen Anbieter.

Übung — einen eigenen Tool-Endpoint exponieren

Aufgabe

1. Nehmt eine bestehende Service-Methode (z. B. freeSeats) und macht sie mit @Tool zu einem MCP-Tool.
2. Registriert den stdio-Server in einer lokalen .mcp.json und gebt ihn frei.
3. Lasst Claude Code die Frage „wie viele freie Plätze hat Seminar 7?" beantworten — ohne dass ihr den Endpoint im Prompt nennt.

Verifizierbares Ergebnis: /mcp listet euren Server samt Tool, und Claude Code ruft nachweislich mcp__<server>__freeSeats auf, statt zu raten oder Text zu parsen.

Dauer ca. 30–40 Minuten · Zusatzthema, optional

Glossar Glossar

MCP (Model Context Protocol) Offenes Protokoll, über das ein Client wie Claude Code strukturiert an externe Werkzeuge und Datenquellen andockt.
Tool (MCP) Aufrufbare Funktion mit benannten Parametern, die ein MCP-Server anbietet und der Agent ausführt.
stdio (MCP-Transport) Betrieb eines MCP-Servers als lokaler Kindprozess; Kommunikation über stdin/stdout statt Netzwerk.
Scope (MCP) Ablageort einer Server-Config, der bestimmt, wer sie bekommt: Project (geteilt via .mcp.json), Local und User (privat).

© 2026 CGS IT Solutions GmbH

Alle Rechte vorbehalten

Diese Schulungsunterlagen sind urheberrechtlich geschützt. Vervielfältigung, Weitergabe oder kommerzielle Nutzung — auch in Auszügen — nur mit ausdrücklicher schriftlicher Genehmigung der CGS IT Solutions GmbH.

cgsit-claude-training · Modul 8 · MCP · v0.4.7