MCP-Server

Hoste einen Model-Context-Protocol-Server, damit Coding-Agents deine Docs direkt durchsuchen und lesen können — Tools, Ressourcen, Discovery-Dokumente, Filter für Content-Typen und Facetten sowie die dafür nötige Server-Ausgabe.

Hoste einen Model-Context-Protocol-Server, damit Coding-Agents (Claude Code, Cursor, VS Code, claude.ai-Connectoren) deine Docs direkt durchsuchen und lesen können — ohne Scraping. Das ist optional und muss aktiviert werden:

ai: {
  mcp: {
    enabled: true,
    route: "/mcp", // where the server is mounted
  },
}

Tools und Ressourcen

Der Server stellt schreibgeschützte Tools bereit — search_docs, get_page, list_pages und get_navigation — sowie jede Seite als MCP-Ressource (resources/list listet die Seiten unter ihren ausgelieferten URLs mit dem Typ text/markdown auf; resources/read gibt das Agent-Markdown der Seite zurück, dieselbe Ausgabe wie get_page), sodass Clients, die Kontext per URI anhängen, die Docs ohne Tool-Aufruf durchstöbern können. Er veröffentlicht Discovery-Dokumente unter /.well-known/mcp.json und /.well-known/mcp/server-card.json. Die Server Card folgt dem Server-Card-Erweiterungsschema aus SEP-2127 (Reverse-DNS-name, remotes-Transport-Endpunkte), ergänzt um initialize-förmige Kompatibilitätsfelder (serverInfo, capabilities, transports) für Scanner, die gegen die frühere Fassung des Proposals gebaut wurden. Das Menü Connect to MCP jeder Seite bietet eine Copy-and-go-Installation für Claude Code, Cursor, VS Code und Codex (sichtbar, sobald deployment.site gesetzt ist).

search_docs betreibt einen eigenen Volltextindex und funktioniert daher unabhängig von deinem Such-Provider — und selbst dann, wenn die Suche auf none steht. Der MCP-Server ist ein von der seitenbasierten Suche getrenntes Feature.

Dieselben Tools stehen über einfaches HTTP als JSON-API zur Verfügung — für Frameworks, die kein MCP sprechen.

Eingrenzen nach Content-Typ und Facetten

search_docs und list_pages akzeptieren beide einen optionalen contentTypes-Filter, der Ergebnisse auf Seiten mit den angegebenen Frontmatter-types eingrenzt — ["rfc"], ["blog", "changelog"] —, sodass ein Agent auf einer Site, die Docs mit RFCs, Runbooks oder Richtlinien mischt, den Abruf auf die benötigte Seitenart beschränken kann. Jedes Ergebnis nennt seinen Content-Typ, und die Ausgabe von list_pages zeigt die verwendeten Typen.

Beide Tools akzeptieren außerdem ein filters-Objekt, das gegen die Facetten abgleicht, die eine Site pro Content-Typ deklariert (content.types.<type>.facets) — eigene Frontmatter-Keys, deren Werte zu filterbaren Metadaten werden:

{
  "query": "OpenAPI request schemas",
  "contentTypes": ["rfc"],
  "filters": { "domain": "architecture", "status": "enforced" }
}

Jeder filters-Eintrag muss zutreffen (Ergebnisse führen ihre Facettenwerte mit, und list_pages zeigt sie für jede Seite), sodass eine Wissensdatenbank Agent-Workflows nach dem Prinzip der schrittweisen Offenlegung antreiben kann — die durchgesetzten Standards auflisten, nur innerhalb davon suchen — ganz ohne eigenen Server.

Server-Ausgabe erforderlich

Der MCP-Server ist ein Live-Endpunkt (/mcp) und kann daher nicht auf einem statischen Build laufen. Wechsle zur Server-Ausgabe und wähle einen Adapter:

deployment: {
  output: "server",
  adapter: "node", // or "vercel" | "netlify" | "cloudflare"
  site: "https://docs.example.com",
}

Ein statischer Build mit ai.mcp.enabled bricht sofort mit einer Meldung ab, die dich auffordert, deployment.output auf server zu setzen. Die Adapter findest du unter Deployment. Nach dem Deployment verbindest du dich aus Claude Code so:

claude mcp add --transport http my-docs https://docs.example.com/mcp