MCP vs. Custom-API-Integration: Wann was wirklich gewinnt

Jedes Team, mit dem ich spreche und das eine Claude-Integration ausgeliefert hat, stellt innerhalb eines Monats dieselbe Frage: Sollte dieses Tool ein MCP-Server sein, oder sollte es als Tool-Definition in unserer App bleiben? Die Antwort wird als Technologie-Debatte gerahmt, ist aber in Wahrheit eine Frage danach, an wie vielen Stellen Sie dieselbe Faehigkeit einsetzen wollen.

Hier die Kurzfassung. Fuer rund 90 % der Teams ist eine Custom-API-Integration, die direkt in Ihren Claude-Code geschrieben wird, die richtige Wahl. Das Model Context Protocol ist die richtige Wahl, wenn Sie dieselbe Tool-Oberflaeche ueber mehrere LLM-Clients hinweg benoetigen, wenn Sie eine wiederverwendbare interne Plattform bauen oder wenn Sie Tools ausliefern, die andere aus ihren eigenen Assistenten heraus aufrufen sollen. Der Rest dieser Anleitung erklaert das Warum, mit Kostenmodell und einem Entscheidungsbaum am Ende.

Ich betreibe beide Muster in Produktion. Mein Telegram-Bot war monatelang eine Custom-Integration, bevor ich die Task-Schicht in einen vollwertigen MCP-Server umgebaut habe, sobald ich Claude Code gegen dieselben Tasks einsetzte. Diese beiden Systeme dienen als laufende Beispiele.

Verdikt vorab

Waehlen Sie eine Custom-API-Integration, wenn Sie eine App, eine Oberflaeche und Tools haben, die eng an den Zustand dieser App gekoppelt sind. Sie liefern schneller aus, debuggen schneller und tragen weniger Betriebslast.

Waehlen Sie einen MCP-Server, wenn mindestens eines der folgenden Punkte zutrifft:

• Sie wollen, dass zwei oder mehr LLM-Clients (Claude Desktop, Claude Code, Cursor, ein Custom Agent) dieselben Tools nutzen
• Sie stellen Faehigkeiten fuer Teammitglieder oder Kunden bereit, damit diese sie aus ihrem eigenen LLM-Client aufrufen koennen
• Sie bauen eine wiederverwendbare interne Plattform, in der die Tool-Entwicklung von App-Deploys entkoppelt sein muss
• Sie verkaufen ein SaaS-Produkt und wollen, dass Kunden es aus jedem MCP-faehigen Client aufrufen koennen

Alles andere ist eine Grauzone, und die Grauzone startet fast immer als Custom und wird spaeter zu MCP extrahiert.

Was MCP Ihnen tatsaechlich bringt

Das Model Context Protocol ist eine JSON-RPC-basierte Spezifikation dafuer, wie ein LLM-Client (Host) mit einem Tool-Anbieter (Server) spricht. Das Protokoll definiert, wie der Client verfuegbare Tools entdeckt, wie er sie aufruft, wie der Server strukturierte Ergebnisse zurueckgibt und wie Ressourcen und Prompts dargestellt werden. Ein Server kann als lokaler stdio-Prozess laufen, den der Client startet, oder als Remote-SSE/HTTP-Endpunkt.

Der Wert liegt nicht im Wire-Format. Der Wert liegt darin, dass jeder MCP-faehige Client Ihre Faehigkeit nutzen kann, sobald sie ein MCP-Server ist, ohne dass Sie eine neue Integration ausliefern muessen. Claude Desktop, Claude Code, Cursor und eine wachsende Liste von Drittanbieter-Clients sprechen alle dasselbe Protokoll, also bedient derselbe Server sie alle. Wenn Sie eine ausfuehrlichere Erlaeuterung des Protokolls und der tatsaechlichen Tool-Discovery wollen, habe ich eine in MCP servers explained geschrieben. Fuer die Implementierungsseite deckt build an MCP server in TypeScript das minimale Geruest ab.

Was eine Custom-Integration Ihnen bringt

Eine Custom-API-Integration bedeutet, dass Sie Ihre Tools direkt in Ihrem Claude-SDK-Aufruf definieren, die Handler in derselben Codebasis implementieren und die Anthropic-API selbst aufrufen. Kein separater Prozess, keine Protokollschicht, kein Discovery-Handshake. Das Tool-Schema ist ein JSON-Schema in Ihrer App, der Handler ist eine Funktion in Ihrer App, und die Ergebnisse gehen im selben Request-/Response-Zyklus zurueck.

import Anthropic from "@anthropic-ai/sdk";

const client = new Anthropic();

const tools = [
  {
    name: "get_task",
    description: "Fetch a task by ID",
    input_schema: {
      type: "object",
      properties: { id: { type: "string" } },
      required: ["id"],
    },
  },
];

const response = await client.messages.create({
  model: "claude-sonnet-4-6",
  max_tokens: 1024,
  tools,
  tool_choice: { type: "auto" },
  messages: [{ role: "user", content: "What's on task 42?" }],
});

Das ist die gesamte Integration. Der Handler fuer get_task ist eine ganz normale Funktion in derselben Codebasis. Wenn Sie den vollstaendigen Tool-Use-Flow inklusive Mehrrunden-Handling brauchen, habe ich ihn im Claude API tool use guide behandelt.

Das ist das Muster, das ich fuer die Geschaeftslogik meines Telegram-Bots und fuer den Graffiti-Customer-Profiling-Agent verwende. Ein Prozess, ein Deploy, normale Logs.

Direkter Vergleich

Die in der Praxis wichtigsten Zeilen sind die ersten drei. Alles andere folgt daraus.

Wann MCP den Overhead wert ist

Eine Frage entscheidet das: Wie viele unterschiedliche LLM-Clients werden diese Tools aufrufen? Wenn die Antwort eins lautet, bleiben Sie bei Custom. Wenn die Antwort jetzt zwei oder mehr lautet, oder es klar innerhalb von sechs Monaten dazu kommt, starten Sie mit MCP.

Konkrete Situationen, in denen ich zu MCP greifen wuerde:

Sie haben zwei oder mehr Claude-Oberflaechen. Wenn Ihr Team Claude Desktop fuer Recherche, Claude Code fuer Engineering und einen Custom-Slack-Bot fuer Ops nutzt und alle drei dieselben internen Tools brauchen (Ihr Task-Tracker durchsuchen, Ihre Analytics abfragen, in Notion posten), zahlt sich MCP schnell aus. Jeder neue Client ist ein Config-Eintrag, kein neues Integrationsprojekt.

Sie wollen, dass andere Ihre Tools ueber ihren eigenen Client aufrufen. Eine Senior-Engineer will Ihre internen Tools aus Cursor heraus nutzen. Ein PM will sie aus Claude Desktop heraus nutzen. Ein MCP-Server bedeutet, dass Ihnen egal ist, welchen Client sie verwenden. Sie veroeffentlichen den Server, sie tragen ihn in ihre Config ein.

Sie bauen ein wiederverwendbares SDK fuer eine externe Plattform. Wenn Sie ein SaaS verkaufen und wollen, dass Kunden es aus jedem LLM heraus aufrufen, ist ein MCP-Server die richtige Form. Ein Server, viele Kunden-Clients, versioniert wie eine API.

Langlebige Integration, in der Entkopplung zaehlt. Wenn sich die Tools in einem anderen Rhythmus aendern als die App oder mehrere Teams sie unabhaengig weiterentwickeln muessen, ist die Prozessgrenze nuetzlich. Server separat deployen, separat versionieren, separat zuruecksetzen.

Wann eine Custom-Integration gewinnt

Custom-Integration gewinnt in jeder Dimension, die nicht Portabilitaet ist. Wenn Portabilitaet keine Anforderung ist, addieren sich die anderen Vorteile schnell.

Bleiben Sie bei Custom, wenn:

• Sie eine App und eine Claude-Nutzungsoberflaeche haben, und das wird sich nicht aendern
• Tool-Latenz wichtig ist und Sie einen zusaetzlichen IPC-Hop pro Aufruf vermeiden wollen
• Ihre Tools stateful und eng an den App-Zustand gekoppelt sind (Mid-Request-Session-Daten, In-Memory-Caches, offene DB-Transaktionen)
• Sie bereits eine ausgereifte RPC-Schicht und Auth-Story in Ihrer App haben und MCP bedeuten wuerde, diesen Perimeter neu zu bauen
• Sie frueh im Produkt sind und noch nicht wissen, welche Tools sich lohnen zu behalten

Der letzte Punkt ist die haeufigste Falle. Teams greifen in der Phase “Lasst es uns richtig machen” zu MCP, bevor sie wissen, welche Tools die ersten drei Iterationen ueberleben. Die meisten Tools nicht. Bauen Sie sie zuerst in der App, schauen Sie, welche sich tatsaechlich behaupten, und befoerdern Sie dann die Ueberlebenden.

Das Hybrid-Muster

Das Muster, das fuer mich immer wieder funktioniert: Bauen Sie Kern-Tools zuerst als Custom-Integration, extrahieren Sie sie dann zu MCP, sobald Sie auf den zweiten Client treffen. Die Extraktion ist meist kleiner als erwartet, wenn Sie die Handler gut strukturiert haben.

Der Trick ist, Ihre Custom-Tool-Handler vom ersten Tag an als reine Funktionen von Input zu Output zu schreiben. Vergraben Sie sie nicht in Route-Handlern, lassen Sie sie keinen Zustand von this greifen. Jeder Handler nimmt einen typisierten Input, gibt einen typisierten Output zurueck und haelt Seiteneffekte in einem injizierbaren Service. Wenn Sie zur Extraktion bereit sind, wird der MCP-Server zu einem duennen Adapter ueber dieselben Funktionen.

Die Schritt-fuer-Schritt-Variante auf der TypeScript-Seite zeigt building an MCP server in TypeScript, inklusive der minimalen Adapterschicht, die Sie brauchen, sobald Ihre Handler so faktorisiert sind.

Reale Szenarien aus meinem Stack

Szenario 1: interner Task-Manager. Ich betreibe ein Task-System ueber TickTick mit Custom-Scoring, semantischer Suche ueber meine Historie und Projekt-Sync. Lange Zeit lief das in einem Telegram-Bot als Custom-Claude-Integration. Ein Prozess, Tools in derselben Datei definiert, die messages.create aufruft. Fein fuer eine Oberflaeche.

Als ich anfing, Claude Code auf denselben Tasks zu nutzen (Morning Planning, Aufraeumen veralteter Eintraege, Erstellung von Wochenberichten), hatte ich zwei Optionen: die Tool-Definitionen innerhalb eines Claude-Code-Agents nachbauen oder einmal extrahieren und teilen. Ich habe extrahiert. Der TickTick-MCP-Server laeuft jetzt als systemd-Service auf demselben VPS, und sowohl der Telegram-Bot als auch Claude Code sprechen denselben Server an. Der gesamte Refactor kostete rund zwei Tage, und der Wert hat sich beim ersten Mal ausgezahlt, als ich einen dritten Client hinzufuegte (ein Cron-Job, der claude -p mit derselben Tool-Oberflaeche ausfuehrt).

Wenn Sie die Agent-Seite dieser Geschichte wollen: Claude Code SDK agents deckt ab, wie ein Claude-Code-Client MCP-Tools konsumiert.

Szenario 2: kundenseitiger Support-Agent. Ein einzelnes Produkt, eine einzelne Oberflaeche, ein einzelner Client. Latenz zaehlt (der Nutzer wartet), die Tools sind an den Sitzungszustand des Produkts gekoppelt, und niemand sonst wird diese Tools je aufrufen. Der bleibt fuer immer Custom. MCP wuerde nichts bringen und einen Deploy, eine Auth-Schicht und einen extra Hop pro Aufruf kosten.

Das Muster lautet: Wenn die Tool-Oberflaeche intern und multi-client ist, neigen Sie zu MCP. Wenn die Tool-Oberflaeche extern und single-client ist, neigen Sie zu Custom.

MCP-Server-Hosting: stdio vs. Remote

Zwei Deployment-Modi, sehr unterschiedliche Betriebsgeschichten.

Stdio. Der Client startet den Server als Kindprozess und spricht ueber stdin/stdout. Konfiguration ist ein JSON-Eintrag im Client, kein Netzwerk, keine Auth-Schicht. Das ist der Default fuer lokale Dev-Tools wie Claude Desktop und Claude Code. Es ist das einfachste moegliche Deployment: ein Binary oder Node-Skript ausliefern, in der Client-Config referenzieren, fertig.

SSE/HTTP (remote). Der Server laeuft irgendwo erreichbar, und der Client verbindet sich ueber HTTP mit Server-Sent Events fuers Streaming. Sie brauchen jetzt Authentifizierung (Tokens, OAuth, was passt), TLS-Termination und eine Betriebsoberflaeche fuer den Server (Logging, Metriken, Restart-Policy). Das wollen Sie, wenn mehrere Nutzer denselben Server ansprechen muessen oder wenn der Server Ressourcen (GPU, proprietaere Daten) benoetigt, die nicht zu jedem Client ausgeliefert werden koennen.

Wenn Sie fuer ein Team bauen, lohnt sich Remote meist. Wenn Sie fuer sich selbst bauen, ist stdio in Ordnung, bis Sie nicht mehr der einzige Nutzer sind.

Kostenmodellierung

Grobe Zahlen aus dem, was ich ausgeliefert habe:

• Custom-Integration, pro Tool: 4 bis 8 Stunden initial, danach linear. Ein neues Tool ist Schema plus Handler plus ein paar Tests. Kein Protokoll-Overhead.
• MCP-Server, initialer Overhead: 1 bis 2 Tage. Protokoll-Plumbing, Transportwahl, Deploy-Story, Client-Config-Doku. Wird einmal bezahlt.
• MCP-Server, pro Tool: aehnlich wie Custom, sobald der initiale Overhead bezahlt ist. Die Schema-Form ist nah genug, dass Sie das meiste teilen koennen.
• Hinzufuegen des N-ten Clients: Custom ist ein neues Integrationsprojekt (Stunden bis Tage). MCP ist ein Config-Eintrag (Minuten).

Der Break-even liegt bei rund drei Clients oder sechs Monaten Wiederverwendung mit zwei Clients. Darunter gewinnt Custom. Darueber gewinnt MCP. Das passt zur allgemeinen Form des build vs buy tradeoff for AI agents, bei dem sich Infrastruktur-Investitionen nur dann auszahlen, wenn Sie sie tatsaechlich wiederverwenden.

Eine Einschraenkung: “Anzahl Clients” meint hier unterschiedliche LLM-Oberflaechen, nicht unterschiedliche Nutzer. Eine Claude-Code-Instanz, die von 50 Engineers genutzt wird, ist ein Client. Ein Claude Desktop plus ein Custom Agent sind zwei.

Was sollten Sie waehlen?

Gehen Sie diesen Baum von oben nach unten und stoppen Sie beim ersten Ja.

1. Haben Sie, oder werden Sie innerhalb von sechs Monaten haben, zwei oder mehr LLM-Clients, die dieselben Tools aufrufen? Ja > MCP. Nein > weiter.
2. Stellen Sie diese Tools Personen ausserhalb Ihrer Codebasis (Teammitglieder, Kunden) zur Verfuegung, die ihren eigenen LLM-Client nutzen werden? Ja > MCP. Nein > weiter.
3. Sind diese Tools ein Produkt fuer sich, verkauft oder geteilt als wiederverwendbare Plattform? Ja > MCP. Nein > weiter.
4. Sind Ihre Tools eng an In-Process-State gekoppelt, oder ist Latenz kritisch? Ja > Custom, ohne Rueckblick. Nein > weiter.
5. Default: Custom, mit Handlern, die als reine Funktionen faktorisiert sind, damit Sie spaeter extrahieren koennen.

Wenn Sie bei “Custom” landen und spaeter Fall 1 oder 2 eintritt, ist die Extraktion echte Arbeit, aber nicht dramatisch. Die Teams, die sich verbrennen, sind die, die am ersten Tag zu MCP greifen, weil es professioneller klingt, und dann eine Woche fuer Protokoll und Auth aufwenden, bevor sie ihr erstes Tool ausliefern.

Waehlen Sie danach, wie viele Oberflaechen die Tools nutzen werden, nicht danach, welche Option ernsthafter klingt. Die meisten Teams brauchen MCP noch nicht. Diejenigen, die es brauchen, wissen es meist, ohne fragen zu muessen.

Weiterfuehrende Artikel

• Build an MCP server in TypeScript
• MCP servers explained
• Claude API tool use guide
• AI agents: build vs buy