Model Context Protocol (MCP) erklärt: Was SaaS-Gründer 2026 wissen müssen

Ein Procurement-Fragebogen, den wir letzte Woche von einer Hamburger Logistikplattform erhielten, enthielt einen Abschnitt, den wir vor sechs Monaten noch nicht gesehen hatten: sieben Fragen zum Model Context Protocol. Bietet das Produkt einen MCP-Server an? Welche Ressourcen und Tools stellt er bereit? Ist der Server per OAuth oder statischen Schlüsseln gesichert? Welches Rate-Limiting-Modell gilt pro Consumer? Ist das Schema versioniert? Der Anbieter, den wir berieten, hatte von MCP nichts gehört, bis wir es erwähnten. Ihr Produkt ist exzellent. Den Deal verloren sie drei Wochen später - nicht wegen MCP an sich, sondern weil das KI-Engineering-Team des Käufers MCP-Unterstützung zur harten Anforderung für 2027 erklärt hatte und die Roadmap des Anbieters das nicht versprechen konnte.

So sieht MCP im B2B-SaaS des Jahres 2026 aus. Ein Protokoll, das Ende 2024 fast niemand kannte, ist inzwischen eine Spalte in den Lieferantenbewertungs-Tabellen jedes Enterprise-Kunden, mit dem wir zusammenarbeiten und der ein internes KI-Team hat. Das Muster ist bekannt - erst öffentliche APIs, dann GraphQL, dann OpenAPI, dann Webhooks - aber das Tempo ist diesmal schneller, die Käufer lauter, und die Frage, ob man einen MCP-Server ausliefern soll, taucht auf Roadmaps auf, wo es noch keine klare Antwort gibt. Dieser Beitrag erklärt, was SaaS-Gründer 2026 wissen müssen: was MCP wirklich ist, was die Bereitstellung eines Servers wirklich kostet und wie ein SaaS-Gründer jetzt zwischen Build, Wait und Skip entscheiden sollte.

Was Model Context Protocol 2026 wirklich ist

Model Context Protocol ist ein JSON-RPC-basierter Standard, mit dem eine LLM-gesteuerte Anwendung die Ressourcen, Tools und Prompts entdecken und aufrufen kann, die ein anderes System bereitstellt. Anthropic hat ihn Ende 2024 eingeführt; Mitte 2026 wird er nativ in Claude, ChatGPT, jedem wichtigen IDE-Assistenten und den relevanten Agentenplattformen unterstützt. Der Grund, warum sich der Standard schnell durchgesetzt hat: Er löst ein Problem, das jedes Team, das KI-Features entwickelte, schlechter gelöst hatte - wie lässt man ein Sprachmodell in ein echtes System greifen - ein CRM, ein Ticketing-Tool, eine Datenbank, ein Code-Repository - ohne für jedes Modell- und Systempaar eine eigene Integrations-Klebe-Schicht schreiben zu müssen?

Drei Konzepte tragen das Gewicht des Protokolls. Ressourcen sind schreibgeschützte Kontextdaten, die das Modell abrufen kann - ein Kundendatensatz, ein aktueller Support-Thread, ein Dokument. Tools sind Operationen, die das Modell aufrufen kann - ein Ticket erstellen, eine Abfrage ausführen, eine Nachricht senden. Prompts sind wiederverwendbare Template-Workflows, die der Server bereitstellt und die die Host-Anwendung dem Nutzer anbieten kann. Der MCP-Server (betrieben vom SaaS-Anbieter) verkündet, was er anbietet; der MCP-Client (innerhalb von Claude, ChatGPT, der IDE oder der Agentenplattform des Kunden) entdeckt, zeigt und ruft sie im Namen des Nutzers auf. Die Authentifizierung in jeder echten Deployment-Umgebung erfolgt per OAuth, mit Scopes, die sauber auf die Tools abgebildet sind, die das Modell aufrufen darf.

Diese Definition ist wichtig, weil sie zeigt, wie die Engineering-Arbeit aussieht. Ein MCP-Server ist kein neues Produkt. Er ist eine dünne, gut spezifizierte Protokollschicht vor Fähigkeiten, die Ihre Plattform bereits über ihre REST- oder GraphQL-API bereitstellt, plus das Sicherheits- und Observability-Gerüst, um Aufrufe von einem fremden LLM sicher zu machen.

Warum Enterprise-Käufer nach MCP fragen

Drei Dinge geschahen 2025, die den Druck erklären.

Die großen KI-Anbieter haben sich auf MCP als die nativ unterstützte Integrations-Geschichte geeinigt. Wer eine interne KI-Plattform betreibt, hat in MCP jetzt den Weg des geringsten Widerstands, um sein Modell mit den Dutzenden von SaaS-Tools zu verbinden, die das Unternehmen nutzt. Die Alternative - maßgeschneiderte Integrationen, brüchige Screen-Scraping-Lösungen oder Zapier-ähnliche Mittelmänner - ist genau das, was Enterprises aktiv abzuschalten versuchen.

Interne KI-Teams haben auf die harte Tour gelernt, dass die Bereitstellung nützlicher KI-Features ohne guten Kontext meist unmöglich ist. Ein Modell, das keine aktuelle Kundenaktivität abrufen, keine offenen Tickets einsehen oder kein relevantes Dokument lesen kann, ist auf Chat reduziert. Mit MCP kommt dieser Kontext von den Systemen, die ihn bereits besitzen, auf Anfrage, mit den Berechtigungen des Nutzers erhalten.

Procurement-Teams, besonders in regulierten Branchen, schätzen, dass MCP die Integrationsform lesbar macht. Anstatt eines undurchsichtigen "Wir nutzen KI"-Pitches veröffentlicht der Anbieter einen MCP-Server, das Sicherheitsteam des Käufers prüft die bereitgestellten Ressourcen und Tools, und das Audit-Gespräch wird konkret. Diese Vorhersehbarkeit ist genau das, was Käufer zunehmend in ihren RFPs fordern.

Das Ergebnis ist ein ziemlich klares Gefälle: B2B-SaaS-Anbieter, die an KI-affine Käufer verkaufen - Fintech, Dev-Tools, Support-Plattformen, Internal-Ops-Tools - bekommen die Frage schon jetzt. Anbieter, die an konservativere Käufer verkaufen, werden sie innerhalb von zwölf Monaten bekommen.

Wie eine MCP-Server-Implementierung wirklich aussieht

Die gute Nachricht ist, dass ein MCP-Server klein ist. Die schwierigen Teile sind nicht das Protokoll selbst, sondern Authentifizierung, Autorisierung und die Verträge zwischen Ihrem Server und den Systemen, die er frontet.

Ein minimaler Symfony-basierter Server, der eine Ressource und ein Tool bereitstellt, per OAuth gesichert und pro Nutzer begrenzt, sieht ungefähr so aus:

// src/Mcp/CrmServer.php
final class CrmServer implements McpServer
{
    public function __construct(
        private readonly CustomerRepository $customers,
        private readonly TicketService $tickets,
        private readonly Authorization $authz,
        private readonly LoggerInterface $log,
    ) {}

    public function listResources(McpContext $ctx): array
    {
        return [
            new Resource(
                uri: 'crm://customer/{id}',
                name: 'Kundendatensatz',
                mimeType: 'application/json',
                description: 'Liest ein Kundenprofil und aktuelle Aktivitaeten.',
            ),
        ];
    }

    public function readResource(string $uri, McpContext $ctx): ResourceContent
    {
        $id = $this->extractId($uri);
        $this->authz->assertCanRead($ctx->userId, 'customer', $id);
        $this->log->info('mcp.resource.read', ['user' => $ctx->userId, 'uri' => $uri]);
        return ResourceContent::json($this->customers->snapshot($id));
    }

    public function listTools(McpContext $ctx): array
    {
        return [
            new Tool(
                name: 'create_ticket',
                description: 'Oeffnet ein Support-Ticket im Namen des Nutzers.',
                inputSchema: TicketSchema::INPUT,
            ),
        ];
    }

    public function callTool(string $name, array $args, McpContext $ctx): ToolResult
    {
        if ($name !== 'create_ticket') {
            throw new UnknownToolException($name);
        }
        $this->authz->assertCanInvoke($ctx->userId, 'create_ticket', $args);
        $ticket = $this->tickets->open($ctx->userId, $args);
        return ToolResult::ok(['ticket_id' => $ticket->id]);
    }
}

Der Transport liegt auf JSON-RPC über WebSocket oder HTTP/SSE, je nachdem, wie Ihr Edge konfiguriert ist. Das ist nicht interessant. Interessant - und was neunzig Prozent der Implementierungskosten treibt - ist die Autorisierungsschicht.

Jedes Tool, das Ihr MCP-Server bereitstellt, ist aus der Sicht des Sicherheitsteams des Käufers eine Taste auf der Tastatur des Modells. Wenn die Taste etwas Destruktives ausführen kann, muss das Auth-Modell das explizit einschränken: nutzerspezifische Scopes, Tool-Quoten, Bestätigungsschritte für schreibende Aktionen und ein Audit-Trail, der jeden Aufruf über OAuth auf einen echten menschlichen Nutzer zurückführt. Behandeln Sie das Register der freigegebenen Tools als Sicherheitsgrenze, genau wie eine öffentliche REST-API. Alles andere ist, wie Prompt-Injection Ihren MCP-Server zum Confused Deputy macht. Das breitere Gerüst hierzu haben wir in unserem Entscheidungsframework für agentische Features beschrieben; die MCP-spezifische Lehre lautet: Behandeln Sie das LLM, das Ihren Server aufruft, sicherheitstechnisch als feindlich und leicht austricksbar.

Das Deployment-Muster ist wirklich einfach. Ein einzelner MCP-Server vor einer bestehenden Symfony-Anwendung, daneben deployed, spricht mit derselben Datenbank - kein neuer Microservice nötig. Die meisten Teams, mit denen wir arbeiten, liefern die erste Version in zwei Entwicklerwochen, sobald das Design feststeht.

Build, Wait oder Skip: Ein Entscheidungsframework

Dieselbe Art von Triage, die agentische Feature-Entscheidungen erfordern, gilt hier, mit anderen Eingaben.

Jetzt bauen, wenn Ihre Käufer KI-affin sind, Ihr Produkt klare hochwertige Leseressourcen und risikoarme Schreib-Tools hat und Ihre bestehende API- und OAuth-Schicht in gutem Zustand ist. KI-affine Käufer, die die Frage bereits stellen, sind in der Regel in Fintech, Dev-Tools, Support, Internal-Ops, Marketing-Analytics und Revenue-Ops-Kategorien. Wenn ein repräsentativer Kunde davon profitieren würde, Ihre Daten in seinen internen KI-Assistenten zu ziehen, ist MCP der kürzeste Weg, diesen Wert zu liefern.

Warten, wenn Ihre Auth-Schicht schwach ist, Ihre destruktiven Endpunkte keine Bestätigungsabläufe haben oder Ihr Backend eine Legacy-PHP-Anwendung ist, die in Jahren keinen Code-Qualitäts-Audit hatte. Einen MCP-Server auf einer brüchigen Auth-Schicht zu deployen ist der schlechtmöglichste Zeitpunkt, das zu entdecken. Investieren Sie das nächste Quartal in die Härtung der zugrunde liegenden API, dann deployen Sie MCP darüber.

Vorerst überspringen, wenn Ihre Käufer keine eigenen KI-Plattformen betreiben, Ihre Schreib-Endpunkte irreversible Folgen haben (regulierte Finanzen, Gesundheitsdaten, Identitätssysteme) oder Ihr Differenzierungsmerkmal die UX Ihres eigenen Produkts ist. Einige Kategorien werden MCP-Unterstützung letztendlich brauchen, aber 2026 ist der Käufer-Druck noch nicht da und die Sicherheitsarbeit ist deutlich schwerer. Verfolgen Sie die eingehenden Fragen und überprüfen Sie es quartalsweise.

Ein nützlicher Schnellcheck: Zählen Sie die Anzahl der MCP-Fragen in den letzten zehn Enterprise-Verkaufsgesprächen. Drei oder mehr: jetzt bauen. Ein oder zwei: vorhaben, in den nächsten zwei Quartalen zu liefern. Null: weiter beobachten.

Häufige Fehler beim MCP-Deployment

Die Fehler, die wir am häufigsten in frühen MCP-Implementierungen sehen, häufen sich an drei Stellen.

Authentifizierungsabkürzungen - meist statische API-Schlüssel oder geteilte Service-Accounts - eliminieren die Nutzeridentität, auf die die Audit-Geschichte angewiesen ist. Sobald das Sicherheitsteam des Käufers merkt, dass der MCP-Server nicht beantworten kann "welcher menschliche Nutzer hat dieses Tool aufgerufen?", endet das Gespräch. OAuth mit nutzerspezifischen Scopes ist das einzige Modell, das Procurement übersteht.

Tool-Sprawl - jeder API-Endpunkt als MCP-Tool bereitgestellt - schafft eine Sicherheitsüberprüfungs-Last, die unmöglich zu warten ist. Kuratieren Sie. Drei hochwertige Ressourcen und vier gut begrenzte Tools schlagen ein Register von vierzig dünn beschriebenen jedes Mal. Der Katalog ist eine Produktoberfläche; behandeln Sie ihn so.

Fehlende Observability - kein Audit-Log pro Aufruf, keine Rate-Limit-Metriken, kein Fehlerbudget für den MCP-Transport selbst - macht den Server zu einer Blackbox, sobald etwas schiefläuft. Behandeln Sie ihn wie jede andere Produktionsoberfläche: Traces, strukturierte Logs, Dashboards, Alerts. Das Protokoll ist neu; die operative Disziplin ist es nicht.

Ein vierter erwähnenswerter Fallstrick: Schema-Versionierung auslassen. MCP-Clients cachen Tool-Definitionen; wenn Sie Input-Formen ändern ohne Versionierung, brechen Sie jeden langlebigen Agenten, der Ihr Schema bereits verinnerlicht hat. Benennen Sie den Tool-Namen um (create_ticket_v2), lassen Sie den alten für ein Abkündigungsfenster aktiv, und kündigen Sie die Änderung im Beschreibungsfeld des abgekündigten Tools an - was dem näherkommt, was das Protokoll als API-Changelog hat.

Abschluss

MCP steht 2026 dort, wo öffentliche APIs 2010 und Webhooks 2015 standen - ein Standard, den Ihre Käufer letztendlich erwarten werden, der gerade mit Tempo von den Early Movers angenommen wird und von allen anderen ungleichmäßig verstanden wird. Einen durchdachten MCP-Server zu deployen kostet weniger, als die meisten Gründer annehmen; einen unüberlegt deployten zu haben ist, wie ein Confused-Deputy-Vorfall in Ihrem Sicherheits-Postmortem landet. Das Build/Wait/Skip-Framework oben soll diese Entscheidung jetzt konkret machen, bevor die Frage im nächsten Quartal im RFP auftaucht.

Wolf-Tech hilft europäischen B2B-SaaS-Teams dabei, MCP-Server auf PHP/Symfony- und Next.js-Stacks zu konzipieren und zu deployen - Auth-Design, Tool-Kuration, Observability und das unspektakuläre Gerüst, das eine Integrationsgeschichte zu einem Individual-Software-Entwicklungs-Ergebnis macht, das Enterprise-Sicherheitsprüfungen besteht. Kontaktieren Sie uns unter hello@wolf-tech.io oder besuchen Sie wolf-tech.io für eine kostenlose Erstberatung.