Zum Inhalt springen
thconsulting
Menü öffnen
Tech-Deep-Dive · Redaktions-MCP

MCP-Server für Site-Pflege.
6 Tools · Branch-PR · Audit-Spur.

Anbieter-neutral via offizielles MCP-Protokoll. Claude oder ChatGPT ruft Tools strukturiert auf, der Server checkt Branches aus und öffnet Pull-Requests. Keine direkten Commits auf main, jede Änderung läuft durch Review, auch wenn ein LLM sie geschrieben hat. Audit-Spur per Default, Schema-Validation vor jedem Publish.

Capability-Stack

Acht Schichten, was sie können.

Konkrete Tool-Wahl behalte ich für mich, was zählt sind die Eigenschaften: anbieter-neutrales Protokoll, harter Review-Gate via PR, Schema-Validation als Default-Pflicht.

MCP-Runtime
Offizielles MCP-Protokoll
stdio + HTTP/SSE · gleicher Handler-Code
Server
Schlanker HTTP-Layer mit MCP-Handler
Kein Express-Erbe, kein Decorator-Magic
Git-Layer
Branch + Commit + Push aus dem Tool
Co-Authored-By LLM · keine direkten main-Commits
GitHub-API
Pull-Request-Erzeugung + Issue-Create
Review-Workflow Pflicht · CI triggert Deploy
HTML-Parser
Schema-Extraktion + Linking-Graph
JSON-LD-Recursion · Inbound/Outbound-Counts
Schema-Validation
Schema.org-Types + Site-Konventionen
Konkrete Fehler mit Anchor-Pfad und Quick-Fix
Linking-Graph
Underlinked-Pages-Detection
Token-Overlap-Score + Inbound-Count-Filter
Auth
Bearer-Token pro Tenant
Tool-Registry pro tenant_id, Audit-Log-tauglich
MCP-Tools

Sechs Standard-Tools.

Default-Set für jede Site. Custom-Tools je Mandanten-Workflow oben drauf, werden via ToolDefinitionBuilder aus Repo-Schema generiert.

plan_to_draft (briefPath: string) → DraftResult

Liest Lifecycle-Brief (JSON), generiert Page-Skeleton mit Title/Meta/H1/Sections/FAQ/Schema gemäß Brief. Nutzt repo-config/page-templates.json für Site-spezifische Komponenten (BaseLayout, BrandArrow etc.).

update_page (path: string, patch: PagePatch) → UpdateResult

Bearbeitet bestehende Page. PagePatch ist strukturiert (sections, faqs, schema-additions). Em-Dash-Replace und Schema-Validation laufen automatisch vor Commit.

validate_schema (htmlPath: string) → ValidationReport

Parsed JSON-LD aus dist/<path>/index.html, validiert gegen Schema.org-Types und Site-Konventionen aus repo-config/schema-rules.json. Konkrete Fehler statt nur "Schema invalid".

update_llms_txt (scope?: "global" | "service" | "all") → SyncResult

Gleicht llms.txt mit aktueller Sitemap ab. Default: alle Scopes. Diff-Output zeigt was hinzugefügt, entfernt, geändert wurde.

propose_internal_links (targetPath: string, count?: number) → LinkProposal[]

Liest internal-linking-graph aus dem letzten Audit, schlägt Inbound-Links auf targetPath vor (Token-Overlap-basiert, Inbound-Count < 5 priorisiert).

publish_page (branch: string, prTitle: string, prBody: string) → PullRequestUrl

Lokaler Build plus Tracking-Snippet-Verify, dann Push des Branches. PR-Erzeugung via GitHub-API. Returnt URL für User-Review.

FAQ

Tech-Fragen.

Welcher MCP-Transport?
HTTP/SSE für Server-Mode (mcp.kunde.de mit Bearer-Token-Auth plus Tenant-ID). stdio für Dev (Claude Desktop / Cursor lokal). Offizielles MCP-Protokoll in beiden Fällen, gleicher Tool-Handler-Code, nur der Transport-Layer wechselt.
Wie ist der Branch-PR-Workflow?
Pro MCP-Tool-Call: Git-Layer checkt Branch redaktion/<topic>-<timestamp> aus, schreibt Files, committed mit Co-Authored-By: <model>. publish_page macht Push und öffnet Pull-Request gegen main via GitHub-API. Du reviewst im UI, mergest. CI triggert Deploy. Keine direkten Commits auf main, jede Änderung läuft durch Review, auch wenn das LLM sie geschrieben hat.
Wie funktioniert Schema-Validation?
validate_schema parsed das gerenderte HTML, extrahiert <script type="application/ld+json">-Blöcke, validiert gegen Schema.org-Types via Type-Definitions. Site-spezifische Konventionen (z.B. Article + BreadcrumbList als Standard für Portfolio-Pages) als JSON-Schema in repo-config/schema-rules.json. Konkrete Fehler statt nur "Schema invalid", mit Anchor-Pfad und Quick-Fix-Vorschlag.
Wie wird llms.txt synchron gehalten?
update_llms_txt parsed die globale /llms.txt plus Per-Service-Hub-llms.txt, gleicht mit aktueller Sitemap ab. Neue Pages bekommen Eintrag (Section + Description), gelöschte Pages werden entfernt, Faktenseiten (/facts) werden bei Schema-Änderungen aktualisiert. Pattern aus convention_llms_txt_strategie, globale Site-Index-Datei plus Per-Service-Hub-Files für Verkaufs-Seiten.
Wie funktioniert propose_internal_links?
Tool nutzt internal-linking-graph aus dem Site-Audit-Tool, extrahiert alle Inbound/Outbound-Counts, Anchor-Texte, Hub-Pages. propose_internal_links checkt Token-Overlap mit der aktuellen Page (Title/H1/H2 vs Linking-Kandidat-Pages), filtert auf Inbound-Count < 5 (Underlinked), schlägt 3-5 Links mit konkreten Anchor-Text-Vorschlägen vor. Kein "verlink doch was passt", sondern "diese Pages sind unterverlinkt, hier sind passende Anchor".
Welche AI-Clients sind kompatibel?
Alle Clients die das MCP-Protokoll sprechen: Claude Desktop, Claude Code, Cursor, Continue, Cline, ChatGPT (via OpenAI-Custom-GPT mit MCP-Plugin), Zed Editor. Anbieter-neutral via offizielles Protokoll. Empfehlung: Claude für Long-Form und Schema-Arbeit, ChatGPT mit Web-Search für Recherche-Tasks.
Was kostet der Setup?
Drei Tier-Stufen. S-Tier: Standard-Server für eine Site, sechs Tools. M-Tier: Multi-Tenant plus CI-Pipeline. L-Tier: Custom-Tools für mandanten-spezifische Workflows. Plus laufender Care-Plan (MCP-Updates, Tool-Pflege, Schema-Konventionen). Konkrete Konditionen klären wir im Erstgespräch nach Scope-Klärung.

MCP-Server für deine Site andocken?

30 Min Erstgespräch, kostenlos. MCP-Setup besprechen, Tool-Set definieren, Branch-PR-Workflow gegen dein Repo abstimmen.

Erstgespräch buchen
→ Klartext-Sicht