Was das Model Context Protocol ist, für welche Use Cases es sinnvoll wird — und was eine MCP-Anbindung in der Praxis bedeutet
SerieAI liest deine Website
Teil 4 von 4
Die ersten drei Teile dieser Serie haben sich mit einer Frage beschäftigt: Wie gut kann ein AI-System eine Website lesen? Serverseitig gerenderter Inhalt, konsistente Daten, Schema.org-Markup — das alles verbessert, was ein System aus einer Website extrahieren kann.
MCP stellt eine andere Frage: Was kann ein AI-System mit einer Website tun?
Das Model Context Protocol ist ein offener Standard, den Anthropic Ende 2024 veröffentlicht hat. Es beschreibt, wie AI-Agenten auf externe Daten und Funktionen zugreifen können — nicht über das Lesen von Webseiten, sondern über strukturierte Schnittstellen. Statt eine HTML-Seite zu parsen, um einen Preis herauszulesen, fragt ein MCP-fähiger Agent direkt: “Was kostet Produkt X?”
Das ist ein Qualitätssprung in der Interaktion zwischen AI und Websites. Und es ist heute umsetzbar — wenn auch noch nicht Standard.
Was MCP ist — die nicht-technische Erklärung
Stell dir eine sehr gut ausgebildete Assistentin vor, die für dich Aufgaben im Internet erledigt. Sie kann Websites lesen — das kann sie gut. Aber wenn sie auf einer Buchungsseite einen Termin buchen soll, muss sie die Seite wie ein Mensch bedienen: Formular ausfüllen, Knopf klicken, Bestätigungsseite lesen. Das ist langsam, fehleranfällig und oft nicht möglich, wenn das Formular JavaScript-Interaktion erfordert.
MCP gibt dieser Assistentin eine direktere Schnittstelle. Statt die Website zu bedienen, ruft sie eine definierte Funktion auf: “Zeig mir verfügbare Termine für nächste Woche” oder “Buche den Termin am Dienstag um 14 Uhr für Max Mustermann.” Die Website antwortet strukturiert, die Assistentin bestätigt.
Das setzt voraus, dass die Website einen MCP-Server betreibt — eine Schnittstelle, die genau diese Anfragen versteht und beantwortet. Auf der anderen Seite steht ein MCP-Client: ein AI-Agent wie Claude, der über einen Hostsystem (Claude Desktop, eine Anwendung, ein Backend) diese Schnittstelle nutzen kann.
Was der Unterschied zu einer normalen API ist
APIs existieren seit Jahrzehnten. Was macht MCP anders?
Eine klassische API ist für Softwareentwickler gebaut. Sie definiert Endpunkte (/api/products/123), erwartet bestimmte Parameter und gibt strukturierte Daten zurück. Ein AI-Agent könnte eine API theoretisch direkt nutzen — aber er müsste wissen, welche Endpunkte existieren, welche Parameter erwartet werden, und wie die Antworten zu interpretieren sind.
MCP fügt eine Beschreibungsschicht hinzu. Ein MCP-Server teilt dem AI-Agenten mit:
- Welche Tools verfügbar sind: “Du kannst
get_available_appointments,book_appointmentundcancel_appointmentaufrufen.” - Was jedes Tool macht: Beschreibung in natürlicher Sprache, die das Modell versteht.
- Welche Parameter benötigt werden: Name, Datum, Uhrzeit — mit Typen und Pflichtangaben.
Ein AI-Agent kann diese Beschreibung lesen und selbständig entscheiden, welche Funktion er für eine bestimmte Nutzeranfrage aufrufen soll. Das macht MCP-Server selbstbeschreibend — der Agent muss nicht vorab programmiert sein, um sie zu nutzen.
Wie ein MCP-Server aussieht
Ein einfacher MCP-Server in TypeScript, der Produktinformationen bereitstellt:
import { Server } from '@modelcontextprotocol/sdk/server/index.js';
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js';
const server = new Server(
{ name: 'shop-server', version: '1.0.0' },
{ capabilities: { tools: {} } }
);
// Tool-Definition: Was kann dieser Server?
server.setRequestHandler('tools/list', async () => ({
tools: [
{
name: 'get_product',
description: 'Gibt Informationen zu einem Produkt zurück, inklusive Preis und Verfügbarkeit.',
inputSchema: {
type: 'object',
properties: {
product_id: {
type: 'string',
description: 'Die Produkt-ID aus dem Shop-System',
},
},
required: ['product_id'],
},
},
{
name: 'check_availability',
description: 'Prüft ob ein Produkt auf Lager ist und gibt die Lieferzeit zurück.',
inputSchema: {
type: 'object',
properties: {
product_id: { type: 'string' },
quantity: { type: 'number', description: 'Gewünschte Menge' },
},
required: ['product_id'],
},
},
],
}));
// Tool-Ausführung: Was passiert bei einem Aufruf?
server.setRequestHandler('tools/call', async (request) => {
const { name, arguments: args } = request.params;
if (name === 'get_product') {
// Verbindung zur eigenen Datenbank oder API
const product = await fetchProductFromDatabase(args.product_id);
return {
content: [{ type: 'text', text: JSON.stringify(product) }],
};
}
if (name === 'check_availability') {
const available = await checkStock(args.product_id, args.quantity);
return {
content: [{ type: 'text', text: JSON.stringify(available) }],
};
}
});
const transport = new StdioServerTransport();
await server.connect(transport);Das ist der Kern eines MCP-Servers: Tool-Definitionen mit Beschreibung und Schema, plus die Logik dahinter. Ein AI-Agent, der diesen Server kennt, kann get_product und check_availability aufrufen, ohne programmiert worden zu sein, dass diese Funktionen existieren.
Für welche Use Cases MCP heute sinnvoll ist
MCP ist nicht für jede Website sinnvoll. Es lohnt sich dort, wo ein AI-Agent echte Aktionen ausführen oder präzise, strukturierte Daten abrufen soll.
Buchungssysteme. Für Dienstleister mit Online-Terminbuchung — Kanzleien, Arztpraxen, Handwerker, Agenturen — kann ein MCP-Server verfügbare Termine liefern und Buchungen entgegennehmen. Ein AI-Agent im Kundengespräch kann so direkt einen Termin vereinbaren, ohne den Nutzer auf eine separate Buchungsseite zu schicken.
Produktkataloge im E-Commerce. Statt HTML-Seiten zu parsen, kann ein MCP-Server präzise Produktdaten liefern: Preis, Varianten, Verfügbarkeit, Lieferzeit. Für Shops mit komplexen Produkten oder häufig wechselnden Preisen ist das zuverlässiger als jedes Schema.org-Markup.
Wissensdatenbanken und Dokumentation. Unternehmen mit umfangreicher Dokumentation — technische Spezifikationen, Produkthandbücher, interne Richtlinien — können diese über MCP für AI-Agenten zugänglich machen. Der Agent fragt gezielt, statt Hunderte von HTML-Seiten zu durchsuchen.
Konfigurationstools und Preisrechner. Komplexe Produkte, die konfiguriert werden müssen — Software-Lizenzen, maßgefertigte Produkte, Versicherungen — können über MCP konfiguriert und bepreist werden. Ein Agent führt den Nutzer durch die Optionen, ohne dass der Nutzer selbst ein Formular ausfüllen muss.
CRM- und Systemanbindungen. Für interne Use Cases: Ein AI-Assistent, der auf das CRM, das Ticket-System oder die Projektdatenbank zugreift, kann Anfragen beantworten und Aktionen ausführen, die sonst manuelles Navigieren in Softwareoberflächen erfordern.
Der technisch schwierigste Teil bei einer MCP-Implementierung ist dabei nicht der Server-Code selbst — das SDK hält den Boilerplate überschaubar. Es ist die Präzision der Tool-Beschreibungen: Zu weite Formulierungen führen dazu, dass ein Agent ein Tool in Situationen aufruft, für die es nicht gedacht war. Zu enge Formulierungen führen dazu, dass er das richtige Tool in eindeutigen Fällen nicht erkennt. Diese Kalibrierung braucht mehrere Iterationen mit echten Anfragen, lässt sich aber nicht am Schreibtisch vollständig vorhersagen.
Was das für Betreiber bedeutet — heute und morgen
Heute ist MCP noch nicht weit verbreitet. Die meisten Nutzer interagieren mit Websites über Browser, nicht über AI-Agenten. MCP-fähige Clients sind vor allem bei technisch versierten Nutzern im Einsatz — über Claude Desktop, Cursor, oder spezialisierte Unternehmensanwendungen.
Aber die Kurve ist steil. Anthropic hat MCP als offenen Standard veröffentlicht, um genau diese Verbreitung zu fördern. Andere Anbieter implementieren das Protokoll. Die Zahl der MCP-fähigen Clients wächst.
Wer in technischen Umgebungen mit AI-Tools arbeitet — Entwicklungsteams, die Cursor oder Claude Desktop einsetzen, Unternehmen, die interne Assistenten aufbauen — trifft MCP bereits regelmäßig im Alltag. Die Verbreitung in breiteren Nutzungskontexten ist eine Frage von Monaten, nicht Jahren.
Für Website-Betreiber und Auftraggeber bedeutet das heute: Wer weiß, was MCP ist und für welche eigenen Anwendungsfälle es sinnvoll sein könnte, ist besser positioniert, wenn die Nachfrage kommt. Wer jetzt saubere APIs und strukturierte Daten aufbaut — ohne speziell für MCP zu entwickeln — legt die Grundlage, die später eine MCP-Anbindung deutlich einfacher macht.
Die Investition in MCP-Entwicklung selbst lohnt sich heute vor allem in einem Kontext: wenn es einen konkreten Use Case gibt, für den ein AI-Agent heute schon genutzt wird oder genutzt werden soll.
Wann MCP (noch) keinen Sinn macht
Für eine statische Unternehmenswebsite ohne transaktionalen Inhalt ist MCP heute kein sinnvoller Schritt. Schema.org, serverseitig gerenderter Inhalt und konsistente Informationen bringen deutlich mehr, mit deutlich weniger Aufwand.
MCP lohnt sich, wenn mindestens eines dieser Kriterien zutrifft:
- Es gibt strukturierte, häufig abgefragte Daten (Preise, Termine, Produktvarianten)
- Es gibt Aktionen, die ein Agent ausführen soll (buchen, anfragen, konfigurieren)
- Es gibt einen aktiven AI-Agenten-Use-Case im Unternehmen oder bei Kunden
Fehlen diese Kriterien, ist MCP heute Investition ohne Return.
Was Auftraggeber wissen sollten
Wer in den nächsten 12 bis 24 Monaten eine Website neu baut oder grundlegend überarbeitet, sollte diese Frage in das Briefing aufnehmen: “Könnte hier irgendwann eine AI-Agenten-Schnittstelle sinnvoll sein?”
Wenn die Antwort “vielleicht” ist, dann lohnt es sich, bereits bei der Architektur darauf zu achten: saubere interne APIs, strukturierte Datenbankabfragen, klare Trennung zwischen Frontend und Backend-Logik. Das ist keine spezifische MCP-Vorbereitung — es ist gute Software-Architektur (mehr dazu im Leitfaden für skalierbare Webplattform-Architektur), die eine spätere MCP-Anbindung vereinfacht.
Wer heute bereits AI-Agenten im Einsatz hat oder plant, für den ist MCP konkret: Was soll der Agent können? Was soll er sehen? Was soll er ausführen dürfen? Diese Fragen führen direkt zur Tool-Definition eines MCP-Servers.
Die vier Teile — was bleibt
Diese Serie ist mit einem Bild gestartet: ein Interessent, der ChatGPT statt Google fragt und eine Antwort bekommt, die von einigen Websites gespeist wurde und von anderen nicht.
Die vier Teile haben gezeigt, was den Unterschied macht:
Teil 1 hat erklärt, warum sich der Weg von der Suche zur Entscheidung verändert — und was das für Website-Betreiber und Auftraggeber bedeutet.
Teil 2 hat gezeigt, was AI-Systeme technisch sehen — und warum gut gemeinte Inhalte hinter JavaScript-Konstrukten unsichtbar werden können.
Teil 3 hat Schema.org als die Sprache für maschinelle Kontextinformation eingeführt — mit konkreten Typen und Beispielen.
Und dieser vierte Teil hat mit MCP die nächste Schicht beschrieben: nicht mehr Lesen, sondern Interagieren.
Der rote Faden durch alle vier: Es geht nicht darum, für eine unklare Zukunft zu optimieren. Es geht darum, Websites so zu bauen, dass sie für Menschen und Maschinen gleichermaßen zugänglich sind. Das ist keine neue Anforderung — es ist die konsequente Weiterführung von dem, was gute Webentwicklung immer war.