Ihre Website als schreibgeschützter MCP-Server

Die meisten Anleitungen zum Model Context Protocol gehen davon aus, dass Sie einen Server vor einem Shop oder einer Datenbank bauen, etwas mit Bestellungen und Lagerbeständen. Wir haben das weniger Naheliegende getan: Wir haben eine statische Marketing-Website in einen aktiven, schreibgeschützten MCP-Server verwandelt. Jeder MCP-Client kann jetzt einen POST an einen einzigen Endpunkt senden und in typisiertem JSON-RPC fragen, welche Leistungen es gibt oder wie man eine Anfrage startet, ohne eine einzige HTML-Seite zu parsen.

Dies ist ein Praxisbericht über diesen Aufbau. Er ist bewusst schmal gehalten: zwei schreibgeschützte Tools, keine Datenbank, keine Schreibvorgänge. Diese Schmalheit ist der Kern, und die meisten interessanten Entscheidungen ergeben sich daraus. Es folgt, warum eine Content-Website überhaupt von einem MCP-Endpunkt profitiert, warum der Endpunkt eine Cloudflare Pages Function statt einer Framework-Route ist, warum wir JSON-RPC selbst geschrieben haben, statt das SDK einzubinden, und der eine Bug mit abschließendem Schrägstrich, der jeden POST stillschweigend zerstört, wenn Sie ihn übersehen.

#Warum einen MCP-Server auf eine Marketing-Website setzen

Ein Shop stellt MCP bereit, weil ein Agent eine Aktion ausführen muss: Lagerbestand prüfen, einen Warenkorb aufbauen, eine Bestellung aufgeben. Eine Marketing-Website hat keinen Warenkorb. Wofür ist die Tool-Oberfläche also da?

Die ehrliche Antwort ist Agent-Discovery. Unsere Website betrieb bereits eine Agent-Discovery-Schicht: eine llms.txt, einen Satz von .well-known-Dokumenten und eine MCP-Server-Card unter /.well-known/mcp/server-card.json. Diese Card beschrieb einen Server, seinen Transport und seine Fähigkeiten. Sie deklarierte sogar eine tools-Fähigkeit. Es gab ein Problem: Dahinter lebte nichts. Die Card bewarb einen Server, der nicht existierte. Ein Agent, der der Card folgte und eine Verbindung aufzubauen versuchte, bekam nichts.

Das ist ein häufiger Zustand für diese Dateien. Sie werden generiert, sie werden in einem Link-Header beworben, und dann verweisen sie auf eine Ressource, die nie gebaut wurde. Die Card ist ein Versprechen ohne Implementierung.

Das Ziel war also nicht, eine neue Oberfläche zu erfinden. Es war, eine bestehende, beworbene Oberfläche real zu machen. Die Tools ergeben sich direkt daraus, wofür eine Marketing-Website da ist:

• check_services gibt den Leistungskatalog zurück: id, Name, Beschreibung, Kategorie und kanonische URL.
• request_quote gibt die lokalisierte Kontakt-URL und Anweisungen zum Einreichen einer Anfrage zurück.

Zwei Tools, beide schreibgeschützt. Ein Agent kann jetzt aufzählen, was wir tun, und einem Nutzer deterministisch den richtigen nächsten Schritt geben, statt aus Prosa zu raten.

#Die Architekturentscheidung: eine Pages Function, keine Astro-Route

Die Website wird mit Astro im statischen Ausgabemodus gebaut. Es gibt keinen SSR-Adapter. Jede Seite wird zur Build-Zeit zu HTML vorgerendert, und die API-artigen Dateien, die sie ausliefert (der Leistungskatalog als JSON, das Agent-Profil), sind statische Dateien unter public/, keine Server-Routen.

Diese eine Tatsache treibt das gesamte Design. Ein dynamischer Endpunkt, der einen Request-Body liest und eine berechnete Antwort zurückgibt, kann hier keine Astro-Route sein, weil es keinen Server gibt, der ihn ausführt. Einen hinzuzufügen würde bedeuten, den Ausgabemodus auf hybrid oder server umzustellen und einen Adapter anzuhängen, was eine große, riskante Änderung an einem Build ist, der bereits Tausende von Seiten erzeugt.

Die Website betreibt allerdings bereits handgeschriebene Cloudflare Pages Functions: eine Middleware, die Weiterleitungen behandelt, und ein paar kleine API-Handler. Das ist die Nahtstelle. Ein dynamischer MCP-Endpunkt ist einfach eine weitere Pages Function, functions/mcp.ts, die neben den anderen sitzt. Sie wird mit dem normalen Build ausgeliefert, braucht keinen Adapter und ändert nichts daran, wie die Seiten gerendert werden.

Die Lektion lässt sich verallgemeinern. Wenn Sie einer ansonsten statischen Website einen dynamischen Endpunkt hinzufügen wollen, greifen Sie nicht zum Server-Modus des Frameworks. Greifen Sie zu dem Edge-Function-Primitiv, das Ihr Host Ihnen ohnehin schon gibt. Bei Cloudflare Pages ist das eine Function. Der Preis ist eine Datei, kein Neuaufbau Ihres Rendering-Modells.

#Selbst geschriebenes JSON-RPC schlägt das SDK bei zwei Tools

Der Reflex, wenn Sie “MCP-Server” lesen, ist, @modelcontextprotocol/sdk zu installieren. Für einen stdio-Server mit vielen Tools, Ressourcen und Prompts ist dieser Reflex richtig. Für zwei schreibgeschützte Tools auf einer Edge-Function ist er es nicht.

Das MCP-Wire-Protokoll ist JSON-RPC 2.0. Ein Server, der einem MCP-Client antwortet, muss einen kleinen Satz von Methoden behandeln:

• initialize, wo der Server seine Protokollversion, Fähigkeiten und Identität zurückgibt.
• tools/list, wo er die Tool-Definitionen mit ihrem JSON Schema zurückgibt.
• tools/call, wo er ein benanntes Tool ausführt und das Ergebnis in MCP-Content verpackt zurückgibt.
• Benachrichtigungen wie notifications/initialized, die keine id tragen und keine Antwort erwarten.

Das ist die gesamte Oberfläche für einen schreibgeschützten Server. Sie von Hand zu implementieren sind ungefähr 120 Zeilen. Der Dispatch ist ein einfaches switch:

switch (method) {
  case "initialize":
    return ok({ protocolVersion, capabilities: { tools: { listChanged: false } }, serverInfo });
  case "tools/list":
    return ok({ tools: TOOLS });
  case "tools/call":
    return ok({ content: [{ type: "text", text: callTool(name, args, services).text }] });
  default:
    return err(-32601, `Method not found: ${method}`);
}

Wägen Sie das gegen das SDK ab. Das SDK ist für stdio und für das vollständige Protokoll ausgelegt. Auf einer Edge-Laufzeit erben Sie seine Bundling-Annahmen und seine Transport-Maschinerie für Funktionen, die Sie nicht nutzen. Für zwei Read-Tools ist eine Abhängigkeit, über die Sie nachdenken müssen, ein schlechterer Handel als 120 Zeilen, die Sie vollständig kontrollieren. Das ist dieselbe Read-only-First-Zurückhaltung, angewandt auf Abhängigkeiten: das Minimum bereitstellen, das Minimum besitzen.

Die eine Sache, die es wert ist, von Hand sorgfältig zu machen, ist der Fehlervertrag. JSON-RPC hat definierte Fehlercodes, und MCP-Clients erwarten sie: -32700 für einen Parse-Fehler, -32601 für eine unbekannte Methode, -32602 für schlechte Parameter. Diese richtig hinzubekommen ist das, was einen selbst geschriebenen Server für einen strengen Client wie einen echten wirken lässt.

#Read-only First ist eine Sicherheitsentscheidung, keine Einschränkung

Das verlockende dritte Tool ist eines, das einen Lead erfasst: einen Namen, eine E-Mail und eine Nachricht entgegennehmen und sie uns mailen. Bauen Sie das nicht als offenes MCP-Tool.

Ein öffentlicher Endpunkt mit einem schreibfähigen Tool ist eine Spam-Senke. Jeder im Internet kann tools/call mit submit_quote und einer gefälschten Nutzlast aufrufen, und schon ist Ihr Posteingang, Ihr CRM oder Ihre Datenbank ein Ziel ohne Reibung und ohne Mensch im Ablauf. In dem Moment, in dem ein Tool schreibt, braucht der Endpunkt Authentifizierung, Rate-Limiting und Missbrauchsbehandlung, was eine große Oberfläche ist, die eine Marketing-Website verteidigen muss.

Also schreibt request_quote nichts. Es gibt die lokalisierte Kontakt-URL und strukturierte Anleitung zurück:

if (name === "request_quote") {
  const lang = LOCALES.includes(String(args?.lang)) ? String(args.lang) : "en";
  return { text: JSON.stringify({
    contact_url: CONTACT_URLS[lang],
    method: "web-form",
    note: "Read-only endpoint. Submit the inquiry through the contact form; this tool does not send it for you.",
    reply_time: "within one working day",
  }, null, 2) };
}

Der Agent erhält alles, was er braucht, um den Nutzer voranzubringen: die richtige Kontaktseite für die Sprache des Nutzers und eine klare Aussage, dass die Einreichung über das Formular erfolgt. Der Mensch bleibt im Ablauf. Der Endpunkt hat nichts zu missbrauchen.

Das ist kein schwächeres Design, das durch Vorsicht erzwungen wird. Es ist dieselbe Haltung, die wir Kunden empfehlen, die MCP für ihre eigenen Systeme bauen: Read-only First, Schreibvorgänge nur hinter Authentifizierung hinzufügen, wenn es einen konkreten Grund gibt. Ein schreibgeschützter Server ist ehrlich darüber, was er ist, und es ist sicher, ihn offen zu lassen.

#Die Schrägstrich-Falle, die Ihren POST-Body verwirft

Diese hat echte Debugging-Zeit gekostet, daher ist sie es wert, klar ausgesprochen zu werden.

Unsere Website kanonisiert URLs auf einen abschließenden Schrägstrich. Die Middleware leitet jeden Pfad ohne einen per 301 auf die Version mit Schrägstrich um. Das ist für Seiten in Ordnung. Für einen JSON-RPC-Endpunkt ist es eine stille Katastrophe.

Ein POST /mcp trifft die Weiterleitung und gibt 301 auf /mcp/ zurück. Viele HTTP-Clients senden, wenn sie der Weiterleitung folgen, den POST-Body nicht erneut oder stufen die Methode herab. Der MCP-Client sieht eine leere oder fehlgeschlagene Antwort und schließt daraus, dass der Server kaputt ist. Der Server ist in Ordnung. Der Request kam nie mit seinem Body an.

Die Lösung besteht nicht darin, die Middleware zu bekämpfen. Sie besteht darin, die URL zu bewerben, die die Website tatsächlich ausliefert. Die MCP-Server-Card und jede Discovery-Referenz verweisen auf /mcp/, mit dem abschließenden Schrägstrich, sodass ein wohlerzogener Client direkt an die kanonische URL postet und die Weiterleitung nie berührt. Wenn Ihr Framework oder Host Schrägstriche normalisiert, entscheiden Sie, welche Form kanonisch ist, und bewerben Sie überall genau diese Form.

Sie können den aktiven Endpunkt auf dieselbe Weise überprüfen wie wir:

curl -s -X POST https://wppoland.com/mcp/ \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

Ein POST ohne Schrägstrich an denselben Host zeigt Ihnen stattdessen das 301.

#Wie das zu Agent-Readiness und GEO passt

Generative Engine Optimization dreht sich vor allem darum, für Modelle lesbar und überprüfbar zu sein. Strukturierte Daten, klare Entitäten, konsistente Aussagen über Ihre eigenen Oberflächen und externe hinweg. Ein aktiver MCP-Endpunkt ist eine starke Version dieser Lesbarkeit: Er ist kein Hinweis auf Ihren Inhalt, er ist eine aufrufbare Schnittstelle zu ihm.

Zwei Dinge machen ihn den geringen Aufwand wert, auch wenn die Verbreitung noch früh ist. Erstens schließt er die Lücke zwischen dem, was die Discovery-Schicht bewirbt, und dem, was existiert. Eine Card, die auf einen funktionierenden Server verweist, ist ein kohärentes Signal; eine Card, die auf nichts verweist, ist ein kaputtes, und kaputte Signale sind schlimmer als fehlende. Zweitens ist der Endpunkt für jeden, der diese Fähigkeit verkauft, ein Beweis. Wir bauen MCP-Server für Kunden, und die glaubwürdigste Demonstration davon ist ein öffentlicher, schreibgeschützter, der auf unserer eigenen Domain läuft, neben dem quelloffenen WooCommerce-MCP-Server, den wir veröffentlichen.

Kein großer KI-Anbieter verpflichtet sich heute formal dazu, MCP-Server-Cards oder llms.txt zu lesen. Das ist ein fairer Vorbehalt, und wir sagen ihn klar. Der Endpunkt ist günstig im Betrieb, er macht ein beworbenes Versprechen wahr, und er ist ein funktionierendes Artefakt statt einer Behauptung. Diese drei zusammen überspringen die Latte.

#Was wir bewusst weggelassen haben

Eine kurze Liste, denn zu wissen, was ein Aufbau überspringt, ist genauso nützlich wie zu wissen, was er enthält.

• Noch kein get_case_studies-Tool. Ein Agent kann die Fallstudien aus der llms.txt und den verlinkten Seiten lesen. Wir fügen das Tool hinzu, wenn ein echter Kunde danach fragt, nicht vorher.
• Keine resources- oder prompts-Fähigkeit. Der Server deklariert nur tools, weil das alles ist, was er implementiert. Eine Fähigkeit zu deklarieren, die man nicht bedient, ist schlimmer als sie wegzulassen: Ein Client, der resources/list aufruft, bekommt einen Fehler statt eines sauberen “nicht unterstützt”.
• Kein SDK, wie oben behandelt.
• Keine Schreibvorgänge, wie oben behandelt.

Jede Auslassung ist eine Entscheidung, kein Versehen. Der Endpunkt tut genau das, was die beiden Intents erfordern, und nicht mehr, weshalb er klein genug ist, um in einer Sitzung durchdacht zu werden, und sicher genug, um ihn offen für das Internet zu lassen.

#Wohin als Nächstes

Wenn Sie die ausführlichere Version dieser Entscheidungen wollen, deckt das Cluster rund um diesen Beitrag das angrenzende Terrain ab: einen MCP-Server für WooCommerce aufbauen für den zustandsbehafteten, shop-orientierten Fall, MCP vs REST: wann was gewinnt für die Frage, ob Sie MCP überhaupt brauchen, und MCP-Authentifizierungsmuster für den Moment, in dem Sie ein schreibfähiges Tool hinzufügen und Authentifizierung brauchen. Die kommerzielle Version dieser Arbeit finden Sie auf der Leistungsseite MCP-Server-Entwicklung.

Die Kurzfassung passt in einen Satz: Eine Marketing-Website kann ein MCP-Server sein, der Endpunkt ist eine Edge-Function, halten Sie jedes Tool schreibgeschützt und bewerben Sie die URL, die Ihr Host tatsächlich ausliefert.