Braucht Ihr Produkt einen MCP-Server?

Bauen Sie einen MCP-Server nur dann, wenn externe KI-Agenten – Claude, ChatGPT, Cursor oder der interne Agenten-Stack eines Kunden – Ihr Produkt direkt aufrufen und echte Aktionen im Namen eines Nutzers ausführen sollen. Wenn Sie lediglich ein KI-Feature in Ihr eigenes Produkt integrieren möchten, brauchen Sie MCP überhaupt nicht; Sie brauchen eine normale Integration mit einem LLM API – ein anderes und in der Regel günstigeres Vorhaben.

Model Context Protocol (MCP) ist der offene Standard, den Anthropic für die Anbindung von KI-Agenten an externe Tools und Datenquellen veröffentlicht hat (Spezifikation und Dokumentation). Er hat sich schnell etabliert – OpenAI, Google und die meisten Agent-Frameworks unterstützen ihn inzwischen –, weshalb er in diesem Jahr in den Roadmaps von Gründern auftaucht. Aber „die Branche hat einen Standard übernommen" und „wir sollten einen bauen" sind zwei verschiedene Fragen, und wir beobachten, dass Teams die zweite schlicht überspringen.

Was ein MCP-Server tatsächlich tut

Ein MCP-Server ist ein schlanker Adapter. Er stellt eine festgelegte Menge an Aktionen und Daten Ihres Produkts bereit – „Rechnung erstellen", „Bestellstatus eines Kunden abfragen", „Lieferung planen" – als aufrufbare Tools, beschrieben in einem Schema, das ein Agent lesen und interpretieren kann. Der Agent (der in Claude, einer eigenen App oder anderem läuft) entdeckt Ihre Tools, entscheidet, welches er aufruft, und erhält strukturierte Ergebnisse zurück.

Im Hintergrund wird nach wie vor Ihre bestehende API oder Datenbank aufgerufen. MCP gibt Ihnen keine neuen Fähigkeiten – es gibt externen Agenten einen standardisierten, auffindbar dokumentierten Zugang zu Fähigkeiten, die Sie bereits haben. Das ist das gesamte Wertversprechen: Statt für jede Agenten-Plattform, die Ihre Kunden nutzen, eine Individualintegration zu bauen, erstellen Sie einen Server – und jeder MCP-kompatible Agent kann damit kommunizieren.

Wer das gerade wirklich braucht

Wir sind bei unserer eigenen Outreach-Engine auf genau diese Entscheidung gestoßen – dem Tool, das wir weiter unten erwähnen und das die Website eines Interessenten analysiert und eine individuelle Kaltakquise-E-Mail entwirft. Ein Kunde fragte, ob er seinen internen Agenten-Stack direkt darauf zeigen könnte, anstatt über unsere UI zu gehen. Diese Frage ist der eigentliche Test: Jemand mit einem bereits laufenden eigenen Agenten möchte Ihr Produkt als Tool aufrufen – nicht als Website. Drei Situationen, in denen das eine echte Anforderung ist, kein Nice-to-have:

• Sie verkaufen an technische Käufer, die eigene Agenten-Stacks betreiben. Wenn Ihre Kunden Claude oder interne Agenten bereits in ihre Workflows einbinden und fragen „Können wir von unserem Agenten auf Ihre API zugreifen?", ist ein MCP-Server der Unterschied zwischen einem Ja in derselben Woche und einem Angebot für eine Individualintegration.
• Ihr Produkt ist selbst eine Agenten-Orchestrierungsschicht und Sie müssen Sub-Tools für einen übergeordneten Agenten bereitstellen – das überschneidet sich stark mit den Abwägungen in Agenten vs. Workflows: Wenn ein fixer Workflow ausreicht, brauchen Sie keine agentenaufrufbaren Tools.
• Sie bauen eine Entwicklerplattform, bei der „KI-native Integration" Teil des Versprechens ist und kein Nachgedanke.

Wenn keine dieser Beschreibungen auf Sie zutrifft, ist ein MCP-Server eine Lösung auf der Suche nach einem Problem. Die meisten SaaS-Produkte erzielen kurzfristig mehr Nutzen aus einer soliden, versionierten REST API mit einer OpenAPI-Spezifikation – die nahezu jedes Agent-Framework bereits als Tools konsumieren kann, ohne dass Sie eine MCP-Schicht schreiben müssen.

Die tatsächlichen Kosten

Für ein Produkt mit fünf bis zehn Kernaktionen ähnelt der Bau eines MCP-Servers vom Umfang her eher einem fokussierten API-Integrationsprojekt als einer Plattform-Neuentwicklung – in der Regel ein paar Wochen für einen Entwickler, vorausgesetzt, die zugrunde liegende Logik existiert bereits und ist halbwegs sauber. Das Tool-Design ist der Teil, der den Zeitplan tatsächlich beansprucht – nicht das Protokoll selbst. Dieselbe Erkenntnis haben wir beim Zusammenführen des zweistufigen „Fakten extrahieren, dann E-Mail verfassen"-Flows unserer Outreach-Engine zu einem einzigen Aufruf gemacht, dazu gleich mehr: Zu entscheiden, was man exponiert und in welcher Granularität, dauert länger als das Schreiben des Adapter-Codes. Die Arbeit gliedert sich in:

• Tool-Design: Entscheiden, welche Aktionen in welcher Granularität exponiert werden. Das ist der Teil, den Teams unterschätzen.
• Schema und Validierung: Strikte Input/Output-Schemas, damit der Agent vorhersehbare Fehler erhält statt stiller Ausfälle.
• Authentifizierung und Berechtigungsrahmen: Ein Agent, der im Namen eines Nutzers handelt, benötigt dieselben Berechtigungsgrenzen wie eine menschliche Sitzung – nicht weitere.
• Observability: Jeder Tool-Aufruf muss mit ausreichend Kontext protokolliert werden, um „Warum hat der Agent das getan?" debuggen zu können – denn das werden Sie brauchen.

Die Kosten liegen nicht im Protokoll, sondern in derselben Sorgfalt, die Sie von jeder API erwarten würden, die Sie Dritten gegenüber öffnen – zuzüglich der zusätzlichen Angriffsfläche durch etwas Nicht-Deterministisches (ein LLM), das entscheidet, wann es sie aufruft.

Der typische Fehler: zu viele Tools, zu feingranular

Der häufigste Fehler ist, MCP-Tool-Design wie REST-Endpoint-Design zu behandeln – ein Tool pro Datenbanktabelle, eines pro CRUD-Operation. Das gibt einem Agenten 40 schmale Tools zur Auswahl, was sowohl Genauigkeit als auch Latenz verschlechtert, weil das Modell überlegen muss, welches von vielen ähnlich aussehenden Tools passt.

Wir haben eine Version dieses Problems beim Aufbau unserer eigenen Outreach-Engine erlebt, die die Website eines Interessenten analysiert und eine maßgeschneiderte Kaltakquise-E-Mail verfasst. Frühe Versionen trennten das in separate Schritte „Fakten extrahieren" und „E-Mail verfassen" und riefen das Modell zweimal auf. Das Zusammenführen zu einem einzigen Aufruf – mit der Extraktion als Zwischenergebnis in einem einzigen Prompt – schlug die zweistufige Kette sowohl bei Kosten als auch bei Qualität: Weniger Round Trips bedeuteten weniger kumulierende Fehler. Dasselbe Prinzip gilt für MCP-Tools: Weniger, höherstufige Tools („find_and_summarize_customer" statt „get_customer" plus „get_orders" plus „get_notes") bieten dem Agenten weniger Angriffsfläche für Fehler. Das ist derselbe Kompromiss, den wir in Single-Call vs. Agent Chains beschreiben – er gilt für Tool-Design genauso wie für Prompt-Design.

Wann Sie ganz darauf verzichten sollten

Verzichten Sie auf MCP, wenn:

• Ihr einziges Ziel ein KI-Feature im Produkt ist (Chatbot, Suche, Zusammenfassung) – das ist eine direkte LLM API-Integration, und die Kostenüberlegungen ähneln eher LLM Cost Optimization als Protokolldesign.
• Kein Kunde oder Partner tatsächlich nach Agentenzugang gefragt hat – bauen Sie die REST API solide und fügen Sie eine MCP-Schicht später hinzu, wenn die Nachfrage entsteht. Es ist ein schlanker Wrapper, den Sie ohne Re-Architektur ergänzen können.
• Sie zwischen einem Custom Agent und einer Off-the-Shelf-Chatbot-Plattform für einen einzelnen Anwendungsfall wählen – diese Entscheidung, beschrieben in Custom AI Agent vs. Chatbot Platform, löst sich meist, bevor MCP überhaupt relevant wird.

Ein pragmatischer Einführungspfad

Beginnen Sie damit, Ihre bestehende API als OpenAPI-Spezifikation bereitzustellen – falls noch nicht geschehen. Die meisten Agent-Frameworks können diese direkt als Tools konsumieren, ohne dass MCP involviert ist. Wenn Sie echte Nachfrage von Kunden sehen, die explizit MCP-Kompatibilität fordern (in Enterprise-Procurement-Gesprächen zunehmend üblich), kapseln Sie drei bis fünf Ihrer wertvollsten Aktionen als MCP-Server, instrumentieren ihn sorgfältig, und erweitern Sie basierend darauf, was Agenten tatsächlich aufrufen – nicht darauf, was auf dem Papier vollständig wirkt.

MCP ist ein echter Standard, der auf der Roadmap stehen sollte, wenn agentengetriebene Integration zentral dafür ist, wie Ihre Kunden Ihr Produkt nutzen werden. Es ist keine Checkbox, die dieses Quartal auf jedes SaaS-Produkt gehört.

Wenn Sie herausfinden möchten, ob Ihr Produkt einen benötigt, oder Hilfe beim richtigen Zuschnitt und Aufbau brauchen, sprechen Sie uns an.