MCP Server: Warum meine Website jetzt direkt mit KIs spricht

Einleitung

Wenn du meinen Artikel über GEO gelesen hast, kennst du das Problem: KI-Systeme entscheiden zunehmend, welche Unternehmen in ihren Antworten auftauchen. Aber bisher konntest du nur hoffen, dass der Crawler deine Seite findet, richtig interpretiert und nicht Wochen alte Daten ausliefert. Was wäre, wenn du den KIs stattdessen eine direkte Leitung zu deiner Knowledge Base geben könntest?

Die Idee ist einfach: Warum soll ein LLM sich durch gecrawltes HTML wühlen, wenn ich ihm die Antwort strukturiert auf dem Silbertablett servieren kann? Und das Beste: Die gesamte Infrastruktur existierte bereits. Evitas RAG-Pipeline – Upstash Vector, Gemini Embeddings, das nächtliche Section-Chunking – brauchte nur eine neue Tür nach außen.

Das Problem: Crawler sind blind

Klassisches GEO funktioniert so: Du optimierst deine Seite mit Schema.org, semantischem Markup und Fakten-basiertem Content. Dann hoffst du, dass ein Crawler vorbeikommt, deine Seite richtig versteht und die KI dich zitiert. Das funktioniert – aber es hat drei Schwachstellen:

Verzögerung

Zwischen Änderung auf deiner Website und Aktualisierung im LLM-Trainings-Snapshot können Wochen oder Monate liegen. Dein neues Service, dein aktuellster Blogartikel – für die KI existieren sie noch nicht.

Interpretation

Der Crawler entscheidet, was relevant ist. Er extrahiert vielleicht den falschen Absatz, übersieht den wichtigen, oder mischt Inhalte aus verschiedenen Seiten. Du hast keine Kontrolle über das Ergebnis.

Unsichtbarkeit

Selbst wenn dein Content perfekt ist: Wenn der Crawler dich nicht indexiert, existierst du für die KI nicht. Neue Seiten, kleine Websites, Nischenthemen – sie fallen oft durchs Raster.

Die Lösung: Ein MCP Server für deine Knowledge Base

Der Server stellt zwei Tools bereit, die externe LLMs über das MCP-Protokoll aufrufen können:

search_knowledge

Semantische Suche in der gesamten designare.at Knowledge Base. Ein LLM fragt zum Beispiel: „Was bietet designare.at im Bereich GEO an?“ – und bekommt strukturierte, relevante Textblöcke zurück, inklusive Quellenlinks. Unter der Haube läuft exakt die gleiche Pipeline, die auch Evita nutzt: Gemini Embedding → Upstash Vector Query → Top-5-Chunks.

get_services

Ein strukturierter JSON-Überblick aller Dienstleistungen, Spezialisierungen und Kernkompetenzen. Kein Parsing nötig, keine Interpretation – das LLM bekommt klar getrennte Felder mit Name, Beschreibung und Kontext. Konkret: sechs Services von Webdesign bis KI-Assistenten, fünf technische Spezialisierungen und Evita als Kontext-Referenz.

{
  "name": "Michael Kanda",
  "brand": "designare.at",
  "role": "Komplize für Web & KI aus Wien",
  "location": "Wien, Österreich",
  "services": [
    { "name": "Webdesign & Entwicklung",
      "description": "Maßgeschneiderte Websites mit Fokus auf
                      Performance, UX und Barrierefreiheit" },
    { "name": "SEO (Search Engine Optimization)",
      "description": "Klassische Suchmaschinenoptimierung für
                      Google & Bing – von Technical SEO bis
                      Content-Strategie" },
    { "name": "GEO (Generative Engine Optimization)",
      "description": "Optimierung für KI-Suchmaschinen wie ChatGPT,
                      Perplexity, Google AI Overviews und Gemini" },
    { "name": "KI-Sichtbarkeits-Check",
      "description": "Analyse wie sichtbar ein Unternehmen in
                      KI-Antworten ist – mit konkreten
                      Handlungsempfehlungen" },
    { "name": "Website-Roast",
      "description": "Quick-Check mit österreichischem
                      Schulnoten-System (1-5) für SEO,
                      Performance, Mobile & Technik" },
    { "name": "KI-Assistenten",
      "description": "Entwicklung von KI-Chatbots und Assistenten
                      wie Evita" }
  ],
  "specializations": [
    "WordPress & WooCommerce",
    "Core Web Vitals & PageSpeed",
    "Schema Markup & Structured Data",
    "KI-Integration für Websites",
    "Barrierefreies Webdesign"
  ]
}

Unter der Haube: So funktioniert der Datenfluss

Der Weg von der LLM-Frage zur Antwort in vier Schritten – ohne Crawler, ohne Verzögerung:

KI-Suche der Zukunft: So sieht das in der Praxis aus

Theorie ist gut, Praxis ist besser. Die folgende Simulation zeigt, was passiert, wenn ein LLM den designare.at MCP Server nutzt – vom User-Prompt bis zur zitierten Antwort.

Performance: Wie schnell ist das eigentlich?

Theoretische Benchmarks gibt es einige – aber was zählt, ist die reale Latenz. Ich habe meinen produktiv laufenden Server mit 10 aufeinanderfolgenden search_knowledge-Calls gemessen (nach einem Warm-up-Request, unterschiedliche Queries, um Caching auszuschließen). Das Ergebnis:

Run#  Query                                     Latenz
────  ────────────────────────────────────────  ──────
1     Welche Services bietet designare.at?      (warm-up, nicht gezählt)
2     Wie funktioniert die KI-Assistentin Ev     443ms
3     Was macht Michael Kanda?                   465ms
4     Wie kontaktiere ich designare.at?          411ms
5     Was ist GEO?                               400ms
6     Welche Services bietet designare.at?       394ms
7     Wie funktioniert die KI-Assistentin Ev     425ms
8     Was macht Michael Kanda?                   414ms
9     Wie kontaktiere ich designare.at?          428ms
10    Was ist GEO?                               671ms  ← Cold-Start
11    Was ist GEO?                               738ms  ← Cold-Start
                                                 ─────
                                                 Min    394ms
                                                 Median 426ms
                                                 Avg    478ms
                                                 P95    738ms
                                                 Max    738ms

Die entscheidende Frage: Wo geht die Zeit hin? Der MCP-Protokoll-Overhead selbst ist minimal – unabhängige Benchmarks zeigen für reine Protokoll-Operationen bei Java/Go-Implementierungen Sub-Millisekunden-Latenzen.^[11] Die dominanten Faktoren liegen woanders:

Gemini Embedding API (~200–400 ms)

Der größte Posten. Die Query wird in einen 768-dimensionalen Vektor umgewandelt – das passiert in den Google-Rechenzentren. Latenz entsteht durch das HTTP-Round-Trip und die Modellinferenz.

Upstash Vector Query (~30–100 ms)

Die semantische Suche im Vektor-Index. Top-K=8, Ergebnisse mit Metadaten. Fast immer unter 100 ms – Upstash betreibt global verteilte Edge-Knoten.

MCP-Protokoll-Overhead (< 10 ms)

JSON-Parsing, Validierung, Rate-Limit-Check, Response-Serialisierung. Im Verhältnis zu den RAG-Komponenten vernachlässigbar.

Vercel Cold Start (optional, 50–500 ms)

Wenn die Serverless Function seit mehreren Minuten nicht aufgerufen wurde, dauert der erste Request länger. Siehe Call #10 und #11 in der Messung oben. Bei regelmäßiger Nutzung praktisch nicht spürbar.

Netzwerk & Edge (20–80 ms)

TCP-Handshake, TLS, Vercel Edge Routing, Response-Transport. Optimiert durch geografische Nähe – mein Server läuft im Frankfurter Vercel-Edge-Node.

Im Vergleich: Crawler vs. MCP

Um die Zahlen einzuordnen – hier ein Vergleich, wie lange es dauert, bis ein LLM auf einen aktualisierten Inhalt reagieren kann:

Crawler (klassisch)

Tage bis Wochen bis zur LLM-Antwort (Re-Crawl → Re-Index → Re-Training). Inhalte sind wenn sie ankommen bereits veraltet.

RAG über Website-Scrape

5–30 Sekunden pro Anfrage (Fetch → Parse → Embed). Inhalte sind nur so gut wie das HTML – oft fragmentiert, weil Navigation, Sidebars und Widgets mit-extrahiert werden.

MCP Server (dieser hier)

~426 ms Median gemessen an designare.at. Inhalte sind tagesaktuell durch nächtliche Vector-DB-Synchronisation.

Der Geschwindigkeitsunterschied ist nicht 2× oder 10× – er ist mehrere Größenordnungen. Das ist auch der Grund, warum MCP nicht nur eine hübsche Alternative zum Crawler ist, sondern strukturell etwas Neues: Ein LLM kann während einer Antwort mehrere MCP-Calls machen und trotzdem innerhalb der Response-Zeit bleiben. Ein Crawler schafft das nicht.

Die Umsetzung: Drei Dateien, null Dependencies

Das Überraschende: Die gesamte MCP-Integration bestand aus drei neuen Dateien und einer dreizeiligen Änderung am bestehenden Rate Limiter. Kein Umbau, kein neues Framework, keine npm-Packages. Fairerweise: Das funktioniert so schlank, weil die RAG-Pipeline (Upstash Vector, Gemini Embeddings, nächtlicher Cron-Sync) bereits stand. Ohne diese Basis wäre der erste Schritt nicht der MCP Server, sondern die Knowledge Base – ein eigenes Projekt.

api/mcp.js – Der Endpoint

JSON-RPC 2.0 Handler für MCP Streamable HTTP Transport. Unterstützt initialize, tools/list, tools/call und ping. GET für Health-Check, POST für MCP-Kommunikation, DELETE für Session-Cleanup. Gleicher Pattern wie alle anderen Vercel Functions im Projekt.

lib/mcp-config.js – Konfiguration & Tool-Logik

Definiert die zwei Tools im MCP JSON Schema Format und die executeToolCall()-Funktion, die den Dispatch übernimmt. Importiert searchContext() aus der bestehenden rag-service.js – die gesamte Vektor-Suche wird wiederverwendet, nicht dupliziert.

.well-known/mcp.json – Discovery

Eine statische JSON-Datei im public/-Verzeichnis, die den Server für zukünftige MCP-Discovery-Systeme beschreibt. Fünf Zeilen JSON mit Server-URL, Transport-Typ und Tool-Übersicht – das Pendant zu robots.txt für die KI-Ära.

Wo wir stehen: Ecosystem, Registry und was noch kommt

Seit MCP Ende 2024 veröffentlicht wurde, ist das Ökosystem explodiert. 2026 ist nicht mehr die Frage „Wird MCP sich durchsetzen?“, sondern „Wie tief integrierst du es?“. Hier ein ehrlicher Status-Check:

MCP Registry – eingetragen seit 18. April 2026

Unter registry.modelcontextprotocol.io läuft die offizielle Registry seit September 2025 – community-getragen von Anthropic, GitHub, PulseMCP und Microsoft.^[7] Mein Server ist dort seit 18. April 2026 als at.designare/knowledge gelistet – authentifiziert über DNS-Ownership via Ed25519-Signatur am Root-TXT-Record von designare.at. Der Eintrag fliesst automatisch in Sub-Registries wie Smithery, Glama und MCPMarket. Die automatische LLM-Empfehlung auf Basis dieser Metadaten ist noch in Entwicklung – aber das Fundament steht.

Linux Foundation – MCP als echter Industriestandard

Im Dezember 2025 spendete Anthropic MCP an die neu gegründete Agentic AI Foundation unter der Linux Foundation.^[3] Mitglieder: OpenAI, Block, AWS, Google, Microsoft, Cloudflare und Bloomberg. MCP ist jetzt vendor-neutral – kein Hersteller kann einseitig die Spielregeln ändern. Für Website-Betreiber heißt das: Die Investition in einen eigenen MCP Server ist auf Jahre hinaus zukunftssicher.

Spec 2025-11-25 – async Tasks, neue OAuth, Extensions

Zum ersten Geburtstag des Protokolls (25. November 2025) kam ein großes Spec-Update mit async Tasks, Client ID Metadata Documents, Enterprise-Managed Auth (SSO) und einem Extensions-Framework.^[8] Alles abwärtskompatibel – mein Server läuft gerade auf 2025-03-26/2024-11-05 und wird schrittweise auf die neue Spec migriert.

MCP Server Cards – kommender Standard für .well-known/mcp.json

Die 2026-er Roadmap plant einen offiziellen Standard für Server-Metadaten via .well-known-URL.^[9] Damit können Registries, Crawler und Browser die Capabilities eines Servers erkennen, ohne eine Verbindung aufzubauen. Mein .well-known/mcp.json liegt bereits am richtigen Pfad – das Format werde ich anpassen, sobald der Standard final ist.

Runtime statt Training

Der Trend geht von „alles aus dem Training wissen“ zu „zur Laufzeit die beste Quelle anfragen“. MCP ist die Infrastruktur für genau diesen Wandel. Mittelfristig wird ein MCP-Endpoint so selbstverständlich sein wie heute eine Sitemap.

Häufig gestellte Fragen (FAQ)

Fazit: Sei die Quelle, nicht das Suchergebnis

In meinem GEO-Artikel habe ich geschrieben: Die neue Währung ist nicht der Klick, sondern das Zitat. MCP macht daraus eine technische Realität. Du lieferst nicht mehr passiv Content und hoffst auf Crawler – du gibst LLMs eine direkte, verifizierte Leitung zu deinem Wissen.

Quellen

1. Pento: A Year of MCP: From Internal Experiment to Industry Standard – Überblick über die MCP-Adoption inkl. Client-Support in Claude, ChatGPT, Cursor, Gemini, Copilot und VS Code.
2. InfoQ: OpenAI Adds Full MCP Support to ChatGPT Developer Mode (Oktober 2025) – OpenAIs MCP-Integration mit Lese- und Schreibzugriff auf externe Tools.
3. PulseMCP: Anthropic donates MCP to the Linux Foundation (Dezember 2025) – Gründung der Agentic AI Foundation mit OpenAI, Block, AWS, Google und Microsoft.
4. Vercel: Building efficient MCP servers – Streamable HTTP Transport als empfohlener Standard für Remote-MCP-Server.
5. Anthropic: Model Context Protocol – Offizielle Spezifikation (Spec 2025-03-26) – Das Protokoll, auf dem dieser Server basiert.
6. VentureBeat: OpenAI updates Responses API with MCP support (Dezember 2025) – Integration von Remote-MCP-Servern in die OpenAI API.
7. Model Context Protocol Blog: Introducing the MCP Registry (September 2025) – Launch der offiziellen Registry unter registry.modelcontextprotocol.io, getragen von Anthropic, GitHub, PulseMCP und Microsoft.
8. Model Context Protocol: One Year of MCP – November 2025 Spec Release – Async Tasks, Enterprise-Managed Auth, Extensions-Framework. Aktuelle Spec-Version: 2025-11-25.
9. Model Context Protocol Blog: The 2026 MCP Roadmap (März 2026) – Priority-Areas für 2026 inkl. MCP Server Cards (.well-known Metadaten-Standard) und horizontal skalierbares Streamable HTTP.
10. MCP Registry – Eigener Eintrag: at.designare/knowledge in der offiziellen Registry. Publiziert am 18. April 2026 mit DNS-verifizierter Ed25519-Signatur.
11. TM Dev Lab: MCP Server Performance Benchmark v2 (Februar 2026) – 15 MCP-Server-Implementierungen, 39,9 Millionen Requests, I/O-Bound Workloads. Rust führt bei Throughput (4.845 RPS), Java/Go bei Sub-Millisekunden-Latenz für Protokoll-Operationen.
12. Stainless: MCP Streaming Messages: Performance, Transport, Trade-Offs – Analyse der Streaming-Performance und Schema-Design-Auswirkungen auf die Latenz. 10-20 % Overhead bei dynamischen Schema-Transformationen.