MCP-Server auf Deutsch — was es ist und warum du es brauchst

Das Problem das MCP löst

Du baust einen LLM-Workflow. Du willst dass dein Modell auf deine Datenbank zugreift, GitHub-Issues schreibt, Slack-Nachrichten schickt. Ohne MCP heißt das: für jede Integration eigenen Code, eigene Authentifizierung, eigenes Error-Handling, eigene Function-Calling-Beschreibung pro Provider.

Ich habe das erlebt. Eine OpenAI-Function-Calling-Implementierung mit zehn Tools zu warten ist wie ein fragiles Kartenhaus. Du änderst ein Tool, etwas anderes bricht. Du wechselst zu Claude, alles muss umgeschrieben werden. Du willst einen lokalen Llama dazunehmen — Pech, Function-Calling-Spec ist anders.

MCP ändert das. Es ist ein standardisiertes Protokoll, über das ein LLM mit jedem Tool sprechen kann, das dieses Protokoll spricht.

Das ist langweilig gesagt. Praktisch ist es revolutionär. Und ich benutze das Wort sonst nicht.

Wie MCP aufgebaut ist

Drei Konzepte. Nicht mehr.

• Tools sind Funktionen die das Modell aufrufen kann. query_database, create_github_issue, send_slack_message.
• Resources sind Daten die das Modell lesen kann. Eine Datei, eine Tabelle, eine API-Antwort.
• Prompts sind vorgefertigte Prompt-Templates die der Server ausliefert.

Ein MCP-Server liefert eine oder mehrere dieser drei Sachen über eine simple JSON-RPC-Schnittstelle. Stdio oder HTTP — egal.

Der Aufruf sieht so aus:

{
  "method": "tools/call",
  "params": {
    "name": "query_database",
    "arguments": { "sql": "SELECT * FROM users LIMIT 10" }
  }
}

Das Modell ruft auf. Der Server antwortet. Das ist der gesamte Mechanismus.

Wie sich das von Function-Calling unterscheidet

Function-Calling kennt jedes moderne LLM. Was MCP anders macht.

Standardisierung. Dein MCP-Server läuft mit Claude, mit GPT, mit lokalem Llama. Solange der Client MCP versteht, musst du nichts umschreiben. Das ist nicht klein. Das ist der Punkt.

Discovery. Der Server beschreibt seine Tools selbst. Das Modell sieht beim Start eine Liste verfügbarer Tools mit Parametern und Beschreibungen. Du musst sie nicht händisch in jeden Prompt einfügen.

Lifecycle. Initialize, Resources, Tools, Prompts, Sampling — ein durchdachtes Modell. Das mag wie Overhead klingen, aber es löst konkrete Probleme bei komplexen Agents.

State. Der Server kann Kontext halten zwischen Aufrufen. Eine Datenbankverbindung bleibt offen. Ein eingeloggter User bleibt eingeloggt. Kein ewiges Auth-Handshake.

Was es heute schon gibt

Stand Mitte April 2026 sind über 800 öffentliche MCP-Server in verschiedenen Registries gelistet. Keine Ahnung wie viele nicht-öffentliche dazukommen — die wirklich spannenden sind intern in Firmen.

Die Kategorien die ich regelmäßig nutze:

• Datenbanken: Postgres, MySQL, MongoDB, Supabase — alle haben Reference-Implementationen
• Code-Hosting: GitHub, GitLab — produktionsreif
• Cloud-APIs: AWS, GCP, Cloudflare, Vercel
• Browser-Automation: Playwright, Puppeteer — das ist ein Game-Changer für Web-Scraping-Aufgaben
• Spezialisten: Filesystem, Memory, Bash, Git

Nicht alles ist gut. Manche Server sind grob zusammengeschustert. Aber die Qualität steigt schnell, weil jeder der einen braucht einen bauen kann.

Wann du selbst einen bauen willst

Drei klare Fälle.

Dein Unternehmen hat eine interne API, und du willst dass dein Team mit Claude Code damit arbeiten kann, ohne dass jeder eigene Wrapper schreibt. Bau einen MCP-Server. Zwei Stunden Arbeit, alle im Team haben Zugriff.

Du baust ein eigenes Produkt das KI-Agents im Workflow hat. Dein Backend braucht eine saubere Schnittstelle dorthin. Bau einen MCP-Server als Adapter.

Du willst etwas wiederverwendbares für die Community veröffentlichen. Bau einen MCP-Server und mach es Open Source. Das ist heute deutlich wirkungsvoller als ein Blogartikel oder ein Twitter-Post.

Dein erster MCP-Server in 30 Minuten

Das TypeScript-SDK von Anthropic ist gut dokumentiert und der Einstieg ist überraschend einfach.

import { Server } from "@modelcontextprotocol/sdk/server";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio";

const server = new Server({ name: "mein-erster-mcp", version: "1.0.0" }, {
  capabilities: { tools: {} },
});

server.setRequestHandler(ListToolsRequestSchema, async () => ({
  tools: [{
    name: "hallo",
    description: "Sagt Hallo auf Deutsch",
    inputSchema: {
      type: "object",
      properties: { name: { type: "string" } },
      required: ["name"],
    },
  }],
}));

server.setRequestHandler(CallToolRequestSchema, async (request) => {
  if (request.params.name === "hallo") {
    const n = request.params.arguments?.name ?? "Welt";
    return { content: [{ type: "text", text: `Hallo, ${n}!` }] };
  }
  throw new Error("Unbekanntes Tool");
});

await server.connect(new StdioServerTransport());

Das ist ein vollständiger MCP-Server. Claude Code kann den direkt laden, sieht das hallo-Tool in der Tool-Liste, ruft es auf, zeigt die Antwort.

Was du danach machst — echte Datenbank statt Hallo — ist genau das gleiche Muster. Nur mit mehr Logik in der Tool-Implementation.

Was nicht läuft

Zwei Dinge die mich gestört haben.

Authentication ist noch unscharf. Die Spec hat OAuth drin, aber viele Server implementieren das nicht sauber. Wenn du einen MCP-Server über HTTP anbietest, musst du dir das Auth selbst zurechtbasteln. Für interne Tools okay. Für Public-APIs riskant.

Error-Handling ist uneinheitlich. Manche Server werfen JSON-RPC-Errors, manche Text, manche beides. Das zu parsen kostet Nerven. Wird sich hoffentlich in der nächsten Spec-Version klären.

Weiterlesen

Wenn du Claude Code noch nicht nutzt, fang beim Claude-Code-Artikel an — das Zusammenspiel mit MCP ist der eigentliche Hebel. Für konkrete Automation mit lokalen LLMs plus MCP schau den Ollama-vs-MLX-Artikel.

Eigene Server im Aufbau oder Fragen zu Setup? Zone "KI Agents & MCPs" im Discord.