MCP-Server erklärt — Claude Code mit eigenen Tools erweitern

Claude Code ist von Haus aus leistungsfähig. Aber was es wirklich erweiterbar macht, ist das Model Context Protocol — MCP. Wenn man sich je gewünscht hat, dass Claude Code die eigene Datenbank abfragen, die Staging-Umgebung durchsuchen oder mit internen APIs interagieren kann — MCP macht genau das möglich.

Dieser Beitrag ist ein Deep Dive: Was ist MCP, wie funktioniert die Architektur, und wie baut man einen eigenen MCP-Server in TypeScript?

Was ist MCP?

Das Model Context Protocol ist ein offener Standard, der definiert, wie KI-Assistenten mit externen Tools kommunizieren. Man kann es sich wie einen USB-C-Port für KI vorstellen: eine standardisierte Schnittstelle, über die jedes kompatible Tool an jeden kompatiblen KI-Assistenten andocken kann.

Vor MCP war Tool-Integration ad hoc. Jedes KI-Produkt hatte sein eigenes Plugin-Format, seine eigenen API-Konventionen. MCP ändert das durch ein universelles Protokoll mit drei Kernkonzepten:

• Tools: Funktionen, die die KI aufrufen kann (z.B. „Datenbank abfragen", „Jira-Ticket erstellen")
• Resources: Daten, die die KI lesen kann (z.B. Dateiinhalte, API-Responses, Datenbank-Schemas)
• Prompts: Wiederverwendbare Prompt-Templates, die der Server dem Client anbieten kann

Die Client-Server-Architektur

MCP folgt einem Client-Server-Modell:

Der Client (Claude Code) erfragt verfügbare Tools über den tools/list-Endpoint des Servers. Wenn Claude ein Tool verwenden will, sendet er eine tools/call-Anfrage mit Toolname und Argumenten. Der Server führt das Tool aus und gibt das Ergebnis zurück.

Die Kommunikation läuft über stdio (für lokale Server) oder HTTP mit Server-Sent Events (für Remote-Server). Das Drahtformat ist JSON-RPC 2.0 — simpel, bewährt, einfach zu debuggen.

Wie Claude Code MCP-Server nutzt

Wenn man einen MCP-Server in Claude Code konfiguriert, steht er als Tool während der Session zur Verfügung. Claude sieht den Namen, die Beschreibung und das Parameter-Schema des Tools und entscheidet kontextabhängig, wann er es aufruft.

Die Konfiguration lebt in der .mcp.json des Projekts oder in ~/.claude/settings.json für globale Server:

{
  "mcpServers": {
    "meine-datenbank": {
      "command": "npx",
      "args": ["-y", "@my-org/db-mcp-server"],
      "env": {
        "DATABASE_URL": "postgresql://localhost:5432/mydb"
      }
    }
  }
}

Claude Code startet den Server-Prozess automatisch und kommuniziert per stdio. Die Verbindung lässt sich mit dem /mcp-Befehl in Claude Code verifizieren.

Verfügbare Community-Server

Das MCP-Ökosystem wächst schnell. Server, die ich regelmäßig nutze:

Filesystem Server: Dateien lesen und schreiben mit konfigurierbaren Zugriffskontrollen. Nützlich, wenn Claude Zugriff auf Verzeichnisse außerhalb des Projekt-Roots braucht.

PostgreSQL Server: Datenbank direkt abfragen. Claude kann Schemas inspizieren, SELECT-Queries ausführen und Ergebnisse analysieren. Ich nutze das für Debugging von Datenproblemen ohne Kontextwechsel.

Browser/Playwright Server: Browser programmatisch steuern. Seiten navigieren, Screenshots machen, Formulare ausfüllen. Unverzichtbar für Frontend-Debugging im Kontext.

GitHub Server: Issues erstellen, PRs lesen, Repositories verwalten. Integriert den GitHub-Workflow direkt in Claude Code.

Einen eigenen MCP-Server bauen

Ein praktisches Beispiel: Ein MCP-Server, der das Error-Tracking-System des Projekts abfragt. In TypeScript mit dem offiziellen MCP SDK.

Schritt 1: Projekt aufsetzen

mkdir error-tracker-mcp && cd error-tracker-mcp
npm init -y
npm install @modelcontextprotocol/sdk zod
npm install -D typescript @types/node

Schritt 2: Server definieren

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({
  name: "error-tracker",
  version: "1.0.0",
});

server.tool(
  "get-recent-errors",
  "Aktuelle Fehler aus dem Error-Tracking-System abrufen",
  {
    project: z.string().describe("Projekt-Identifier"),
    limit: z.number().optional().default(10),
    severity: z.enum(["error", "warning", "info"]).optional(),
  },
  async ({ project, limit, severity }) => {
    const response = await fetch(
      `https://errors.internal.company/api/v1/projects/${project}/issues?limit=${limit}${severity ? `&severity=${severity}` : ""}`,
      { headers: { Authorization: `Bearer ${process.env.ERROR_TRACKER_TOKEN}` } }
    );
    const errors = await response.json();
    return {
      content: [{ type: "text", text: JSON.stringify(errors, null, 2) }],
    };
  }
);

const transport = new StdioServerTransport();
await server.connect(transport);

Schritt 3: In Claude Code konfigurieren

In die .mcp.json des Projekts eintragen:

{
  "mcpServers": {
    "error-tracker": {
      "command": "npx",
      "args": ["tsx", "./error-tracker-mcp/server.ts"],
      "env": {
        "ERROR_TRACKER_TOKEN": "dein-api-token"
      }
    }
  }
}

Jetzt kann Claude Code den Error-Tracker direkt abfragen: „Zeig mir die letzten kritischen Fehler im Frontend-Projekt" löst automatisch das get-recent-errors-Tool aus.

Praktische Einsatzszenarien

MCP-Server, die ich für meinen eigenen Workflow gebaut habe:

Deployment-Status-Server: Fragt Railway- und Vercel-APIs ab, um Deploy-Status zu prüfen, Logs zu lesen und Redeployments auszulösen. Beim Debugging eines Produktionsproblems kann Claude prüfen, ob ein Deploy läuft, ohne dass ich den Kontext wechsle.

Datenbank-Migrations-Server: Kapselt Supabase-Migrationsbefehle. Claude kann Migrations generieren, lokal anwenden und das Schema verifizieren — alles innerhalb der Konversation.

Dokumentations-Server: Indexiert interne Confluence-Seiten und macht sie durchsuchbar. Wenn Claude Kontext über eine Geschäftsregel braucht, kann er in der echten Dokumentation nachschlagen statt zu raten.

MCP-Server debuggen

Wenn etwas nicht funktioniert:

1. Verbindung prüfen: /mcp in Claude Code ausführen, um Status der verbundenen Server zu sehen.
2. Standalone testen: Server direkt starten und JSON-RPC-Requests per stdin senden.
3. stderr prüfen: MCP-Server sollten Fehler nach stderr loggen, das Claude Code erfasst.
4. Schemas validieren: Sicherstellen, dass Zod-Schemas mit dem übereinstimmen, was der Server tatsächlich akzeptiert. Schema-Mismatches sind die häufigste Fehlerquelle.

Fazit

MCP verwandelt Claude Code von einem Code-Assistenten in einen Integrations-Hub. Statt zwischen Editor, Datenbank-Client, Error-Tracker und Deployment-Dashboard hin und her zu wechseln, bringt man alle Tools in ein einziges Konversations-Interface.

Das Protokoll ist simpel genug, um es an einem Nachmittag zu implementieren. Am besten mit einem Tool starten, das einen echten Reibungspunkt im Workflow löst, und von dort aus erweitern. Das Community-Ökosystem deckt die häufigsten Fälle ab; eigene Server erledigen den Rest.