Model Context Protocol (MCP) erklaert: Was SaaS-Gruender 2026 wissen muessen

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 Schluesseln gesichert? Welches Rate-Limiting-Modell gilt pro Consumer? Ist das Schema versioniert? Der Anbieter, den wir berieten, hatte von MCP nichts gehoert, bis wir es erwahnten. Ihr Produkt ist exzellent. Den Deal verloren sie drei Wochen spaeter - nicht wegen MCP an sich, sondern weil das KI-Engineering-Team des Kaeufers MCP-Unterstuetzung zur harten Anforderung fuer 2027 erklaert 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 oeffentliche APIs, dann GraphQL, dann OpenAPI, dann Webhooks - aber das Tempo ist diesmal schneller, die Kaeufer lauter, und die Frage, ob man einen MCP-Server ausliefern soll, taucht auf Roadmaps auf, wo es noch keine klare Antwort gibt. Dieser Beitrag erklaert, was MCP wirklich ist, was die Bereitstellung eines Servers wirklich kostet und wie ein SaaS-Gruender 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 eingefuehrt; Mitte 2026 wird er nativ in Claude, ChatGPT, jedem wichtigen IDE-Assistenten und den relevanten Agentenplattformen unterstuetzt. Der Grund, warum sich der Standard schnell durchgesetzt hat: Er loest ein Problem, das jedes Team, das KI-Features entwickelte, schlechter geloest hatte - wie laesst man ein Sprachmodell in ein echtes System greifen - ein CRM, ein Ticketing-Tool, eine Datenbank, ein Code-Repository - ohne fuer jedes Modell- und Systempaar eine eigene Integrations-Klebe-Schicht schreiben zu muessen?

Drei Konzepte tragen das Gewicht des Protokolls. Ressourcen sind schreibgeschuetzte 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 ausfuehren, 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) verkuendet, 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 duenne, gut spezifizierte Protokollschicht vor Faehigkeiten, die Ihre Plattform bereits ueber ihre REST- oder GraphQL-API bereitstellt, plus das Sicherheits- und Observability-Geruest, um Aufrufe von einem fremden LLM sicher zu machen.

Warum Enterprise-Kaeufer nach MCP fragen

Drei Dinge geschahen 2025, die den Druck erklaeren.

Die grossen KI-Anbieter haben sich auf MCP als die nativ unterstuetzte 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 - massgeschneiderte Integrationen, bruchige Screen-Scraping-Loesungen oder Zapier-aehnliche Mittelmaenner - ist genau das, was Enterprises aktiv abzuschalten versuchen.

Interne KI-Teams haben auf die harte Tour gelernt, dass die Bereitstellung nuetzlicher KI-Features ohne guten Kontext meist unmoglich ist. Ein Modell, das keine aktuelle Kundenaktivitaet 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, schaetzen, dass MCP die Integrationsform lesbar macht. Anstatt eines undurchsichtigen "Wir nutzen KI"-Pitches veroffentlicht der Anbieter einen MCP-Server, das Sicherheitsteam des Kaeufers prueft die bereitgestellten Ressourcen und Tools, und das Audit-Gespraech wird konkret. Diese Vorhersehbarkeit ist genau das, was Kaeufer zunehmend in ihren RFPs fordern.

Das Ergebnis ist ein ziemlich klares Gefalle: B2B-SaaS-Anbieter, die an KI-affine Kaeufer verkaufen - Fintech, Dev-Tools, Support-Plattformen, Internal-Ops-Tools - bekommen die Frage schon jetzt. Anbieter, die an konservativere Kaeufer verkaufen, werden sie innerhalb von zwoelf 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 Vertraege 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 ungefaehr 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 ueber 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 Kaeufers eine Taste auf der Tastatur des Modells. Wenn die Taste etwas Destruktives ausfuehren kann, muss das Auth-Modell das explizit einschraenken: nutzerspezifische Scopes, Tool-Quoten, Bestaetigunsschritte fuer schreibende Aktionen und ein Audit-Trail, der jeden Aufruf ueber OAuth auf einen echten menschlichen Nutzer zurueckfuehrt. Behandeln Sie das Register der freigegebenen Tools als Sicherheitsgrenze, genau wie eine oeffentliche REST-API. Alles andere ist, wie Prompt-Injection Ihren MCP-Server zum Confused Deputy macht. Das breitere Geruest hierzu haben wir in unserem Entscheidungsframework fuer 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 noetig. 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 Kaeufer 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 Kaeufer, die die Frage bereits stellen, sind in der Regel in Fintech, Dev-Tools, Support, Internal-Ops, Marketing-Analytics und Revenue-Ops-Kategorien. Wenn ein repraesentativer Kunde davon profitieren wuerde, Ihre Daten in seinen internen KI-Assistenten zu ziehen, ist MCP der kuerzeste Weg, diesen Wert zu liefern.

Warten, wenn Ihre Auth-Schicht schwach ist, Ihre destruktiven Endpunkte keine Bestaetigunsablaeufe haben oder Ihr Backend eine Legacy-PHP-Anwendung ist, die in Jahren keinen Code-Qualitaets-Audit hatte. Einen MCP-Server auf einer bruechiegen Auth-Schicht zu deployen ist der schlechtmoeglichste Zeitpunkt, das zu entdecken. Investieren Sie das naechste Quartal in die Haertung der zugrunde liegenden API, dann deployen Sie MCP darueber.

Vorerst ueberspringen, wenn Ihre Kaeufer keine eigenen KI-Plattformen betreiben, Ihre Schreib-Endpunkte irreversible Folgen haben (regulierte Finanzen, Gesundheitsdaten, Identitaetssysteme) oder Ihr Differenzierungsmerkmal die UX Ihres eigenen Produkts ist. Einige Kategorien werden MCP-Unterstuetzung letztendlich brauchen, aber 2026 ist der Kaeufer-Druck noch nicht da und die Sicherheitsarbeit ist deutlich schwerer. Verfolgen Sie die eingehenden Fragen und ueberpruefen Sie es quartalsweise.

Ein nuetzlicher Schnellcheck: Zaehlen Sie die Anzahl der MCP-Fragen in den letzten zehn Enterprise-Verkaufsgespraechen. Drei oder mehr: jetzt bauen. Ein oder zwei: vorhaben, in den naechsten zwei Quartalen zu liefern. Null: weiter beobachten.

Haeufige Fehler beim MCP-Deployment

Die Fehler, die wir am haeufigsten in fruehen MCP-Implementierungen sehen, haeufen sich an drei Stellen.

Authentifizierungsabkuerzungen - meist statische API-Schluessel oder geteilte Service-Accounts - eliminieren die Nutzeridentitaet, auf die die Audit-Geschichte angewiesen ist. Sobald das Sicherheitsteam des Kaeufers merkt, dass der MCP-Server nicht beantworten kann "welcher menschliche Nutzer hat dieses Tool aufgerufen?", endet das Gespraech. OAuth mit nutzerspezifischen Scopes ist das einzige Modell, das Procurement uebersteht.

Tool-Sprawl - jeder API-Endpunkt als MCP-Tool bereitgestellt - schafft eine Sicherheitsueberpruefungs-Last, die unmoglich zu warten ist. Kuratieren Sie. Drei hochwertige Ressourcen und vier gut begrenzte Tools schlagen ein Register von vierzig duenn beschriebenen jedes Mal. Der Katalog ist eine Produktoberflaeche; behandeln Sie ihn so.

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

Ein vierter erwaehnenswerter Fallstrick: Schema-Versionierung auslassen. MCP-Clients cachen Tool-Definitionen; wenn Sie Input-Formen aendern 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 fuer ein Abkuendigungsfenster aktiv, und kuendigen Sie die Aenderung im Beschreibungsfeld des abgekuendigten Tools an - was dem naeherkommt, was das Protokoll als API-Changelog hat.

Abschluss

MCP steht 2026 dort, wo oeffentliche APIs 2010 und Webhooks 2015 standen - ein Standard, den Ihre Kaeufer letztendlich erwarten werden, der gerade mit Tempo von den Early Movers angenommen wird und von allen anderen ungleichmaessig verstanden wird. Einen durchdachten MCP-Server zu deployen kostet weniger, als die meisten Gruender annehmen; einen unueberlegt 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 naechsten Quartal im RFP auftaucht.

Wolf-Tech hilft europaeischen 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 unspektakulaere Geruest, das eine Integrationsgeschichte zu einem Individual-Software-Entwicklungs-Ergebnis macht, das Enterprise-Sicherheitspruefungen besteht. Kontaktieren Sie uns unter hello@wolf-tech.io oder besuchen Sie wolf-tech.io fuer eine kostenlose Erstberatung.