Konsolidierter Report · MCP-Top-3-Recherchen · Stand 2026-10-17
Drei Recherchen, ein Urteil
Die drei heutigen MCP-Recherchen (Architekten, Software-Enthusiasten, Designer) liefern 20 Vorschläge für den MZP. Hier steht, was davon der MZP schon hat, was fehlt, was sich lohnt, und was ich aus Agenten- und aus Menschensicht empfehle.
Kurzurteil
Von 20 Vorschlägen lohnen sich drei Pakete. Das stärkste ist ein Render-Dienst-Paket: ein Seiten-Screenshot auf Wunsch plus Gewicht der Seite (Transfer- und JS-Bytes) im Browser-Blick. Dazu kommen adressierbare Abschnitte statt ganzer Seiten (MZP-211, geschnitten). Sechs Vorschläge sind erledigt, überholt oder gar kein Feature.
Die Recherchen sind handwerklich solide: Primärquellen gelesen, Aggregatoren-Streuung benannt, Caveats ehrlich. Ihre Schwäche liegt auf der MZP-Seite. Mehrere „Anknüpfungen" zeigen auf einen Stand, den es nicht mehr gibt: 28 statt 42 Tools, ein fehlendes llms.txt, eine Wissens-Engine, die MZP-151 abgebaut hat. Wer ihre Tickets 1:1 übernimmt, baut zum Teil Dinge, die der Bestand schon deckt oder die der Auftraggeber bewusst entfernt hat.
Vorschläge gesamt
20
Bauen
4 in 3 Paketen
Klein oder umschneiden
5
Zurückstellen / verwerfen
11
Die drei Recherchen im Überblick
| Report | Top 3 | Vorschläge | Tickets daraus |
|---|---|---|---|
| Architekten & Developer | GitHub MCP, Serena, Context7 | W1–W6 | keine |
| Software-Enthusiasten | GitHub MCP, Context7, Chrome DevTools MCP | E1–E7 | MZP-207 bis 212 (E7 ohne Ticket) |
| Designer | Framelink Figma, Penpot MCP, 21st MCP | D1–D7 | keine (D1 deckt sich mit dem alten MZP-115) |
Sieben verschiedene Server, zwei davon in beiden ersten Reports. W1 und E5 beschreiben dieselbe Idee, W3 und E3 überlappen.
Abgleich: was der MZP hat, was fehlt, was ich daraus mache
Urteile: bauen klein / umschneiden zurückstellen verwerfen / erledigt. Die Spalte M/PT nennt geschätzten Mehrwert und Aufwand in Personentagen.
| ID | Vorschlag | Das hat der MZP schon | Was wirklich fehlt | Urteil | M/PT |
|---|---|---|---|---|---|
| W1 + E5 | Outline und Abschnitts-Adressen Architekten W1, Enthusiasten E5 (MZP-211) |
getArtifactSource mit maxBytes, publishArtifact(mode='patch'). Die WebMCP-Bridge kennt nur diagram.*. | Nichts, das Überschriften oder Abschnitte adressiert (im Code kein Treffer auf Outline). Ein Agent liest 24–42 KB, um 2 KB zu ändern. | bauen MZP-211, Stufe 1 |
6 / 1,5 |
| E6 | Browser-Blick misst Kosten Enthusiasten (MZP-212) |
Render-Dienst /render liefert Konsole, Seitenfehler, gescheiterte Requests, a11y, Figuren-Befunde. | Keine Zeiten, keine Bytes. Transfer- und JS-Bytes sind deterministisch messbar, LCP im Headless-Lauf nicht verlässlich. | bauen Bytes, ohne LCP |
5 / 1,5 |
| D3 | Screenshot als Beleg Designer |
Der Render-Dienst kann Elemente fotografieren (Figuren). exportFigurePng liefert dafür eine URL, rastert lazy. | Kein Seitenbild. Heute veröffentlicht ein Agent Layout blind: er sieht Konsolenfehler, aber keine kaputte Karte. | bauen auf Wunsch, nicht speichern |
7 / 1,5 |
| W3 | Versionsgenaue Capabilities Architekten |
olderVersions je Bibliothek (nur Nummern), Info-Feld sinceLast im Katalog. | Kein Versionsparameter, kein „seit Version X" je Klasse. Relevant, weil Bestandsseiten mzone-ui@1.8.0 pinnen, der Katalog aber 1.9.0 beschreibt. | klein sinceVersion je Klasse |
4 / 1 |
| E1 | Auslieferungsprofile Enthusiasten (MZP-207) |
Eine Fassung je Seite, no-store. Eine .md-Fassung gibt es nicht (MZP-69 wurde mit dem Wiki-Abbau verworfen). HtmlTextExtractor existiert. | Ein günstiger Lesepfad für Agenten. „Keine Doppelpflege" ist unbelegt: eine fx-freie Fassung aus beliebigem HTML ableiten kann der Server nicht. | umschneiden Text-Lesemodus |
4 / 0,5 |
| E2 | Katalog je Site Enthusiasten (MZP-208) |
llms.txt seit MZP-62/149 (Titel, 160 Zeichen Beschreibung, nur CURRENT). listPublishedPages mit Feldwahl, Cursor, Status-, Art-Filter. | Ein _index.json für Agenten ohne MCP. Die Gruppen in llms.txt sind noch wiki-*-Präfixe, fast alles landet in „Weitere Seiten". | klein P1 → P3 |
3 / 0,5 |
| E4 | Injection-Hygiene Enthusiasten (MZP-210) |
Vertrauens-Label (trust) an Assets. | GitHubs Lockdown schützt vor fremden Autoren. Beim MZP publiziert nur der Eigentümer, die Gefahr ist abgeschriebener Webtext. Ein Muster-Hinweis beim Publish genügt, Skript-Entzug nicht. | klein P1 → P3, nur Notice |
3 / 0,5 |
| D1 | Design-Tokens als DTCG Designer |
Branding-Profile in der DB (MZP-160), Katalogfeld tokens. MZP-115 beschreibt genau das seit 20 Tagen (IDEA, P3). | Der Export. Nachfrage ist nicht belegt: searchBranding und getDesignMdFor stehen im Zählerfenster auf 0 Aufrufen. | zusammenlegen in MZP-115, P3 bleibt |
3 / 1 |
| W5 | Interaktive Verifikation Architekten |
Playwright im Render-Dienst. | /render nimmt keine Klickschritte. Der Dienst-Code auf dem VPS ist nicht mit dem Repo mzone-render abgeglichen (/pdf fehlt dort). | zurückstellen erst Repo-Abgleich |
5 / 3 |
| W6 | Entscheidungs-Gedächtnis Architekten |
ADR-Seiten, Backlog mit Rümpfen und Kommentaren. | Ein Modell, das die Recherche selbst als „Design nötig" einstuft. Keine Nachfrage belegt. | zurückstellen | 3 / 4 |
| D4 | Visueller Regressions-Diff Designer |
diffDiagram, listVersions (textlich). | Bauen heißt Bilder je Version speichern und vergleichen. Setzt D3 voraus. | zurückstellen nach D3 |
3 / 2 |
| D5 | Design-Hinweise beim Publish Designer |
a11y=true misst axe-core (WCAG 2.2 AA), darin liegt der Kontrast. NODE_TEXT_OVERFLOW für Diagramme. | Typo-Konsistenz und Überlauf bei freien Seiten. Ob axe die Zielgröße einschließt, habe ich nicht geprüft. | zurückstellen | 4 / 1,5 |
| D6 | Komponenten-Registry Designer |
publishAsset, kind='asset', usedAssets, listAssetUsage. | Die Grundlage ist da, wird aber nicht benutzt: publishAsset und listAssetUsage stehen im Fenster auf 0. | zurückstellen | 3 / 2 |
| W2 | Toolsets und Read-only-Profil Architekten |
42 sichtbare Tools, davon 15 DEPRECATED; 14 davon stehen auf 0 Aufrufen. MZP-179 entfernt in Phase 3 neun, nach der Template-Entscheidung bis zu 15 (42 → 33 → 27). | Nach der Verschlankung bleibt wenig, das ein Profil trennen müsste. Zwei Clients im Fenster, kein Mehrmandanten-Bedarf. | erledigt durch MZP-179 | – |
| W4 | Deep Search über den Bestand Architekten |
fullTextSearch (Wortformen, Phrase, Ausschluss, Relevanz). | Die Anknüpfung (MZP-38 knowledgeQuery, MZP-46 /api/wiki) hat MZP-151 abgebaut. Eine Server-seitige Synthese bräuchte ein eigenes LLM, der Agent ist selbst eines. | verwerfen | – |
| E3 | Fähigkeiten-Snapshots je Version Enthusiasten (MZP-209) |
Seitenversionen (max. 5), globaler Katalog. | Der Nutzen ist ein Agent, der eine alte Version analysiert. Dafür genügt W3 (sinceVersion) für einen Bruchteil. | verwerfen W3 deckt es |
2 / 3 |
| E7 | Berichte altern lassen Enthusiasten (kein Ticket) |
mode='patch', fromSlug, setPageLifecycle mit supersededBy: alles da. | Kein Feature, eine Gewohnheit. setPageLifecycle hatte im Fenster 0 Aufrufe. | kein Feature | – |
| D2 | Design als Quelle (Figma/Penpot-URL) Designer |
Nichts. Der MZP kennt nur eigene Dateien (fromSlug). | Ein externer Dienst mit API-Schlüssel und Abhängigkeit, ohne erkennbaren Nutzer. | verwerfen | – |
| D7 | Themenwechsel zur Laufzeit Designer |
Seiten bringen data-theme und prefers-color-scheme selbst mit (auch die drei Reports). Diagramme haben Varianten und Branding-Profile. | Farbe ist keine Messzahl wie bei _data.json. Ein Laufzeit-Endpunkt erfindet CSS neu. | verwerfen | – |
Empfehlung aus Agentensicht
Ein Agent veröffentlicht heute blind und liest zu viel. Die größte Lücke ist deshalb nicht „mehr Fähigkeiten", sondern Rückmeldung nach dem Publish: sehen, wie die Seite aussieht und was sie wiegt. Danach folgt der gezielte Zugriff auf Teile statt Ganzes.
-
A1Paket 1 · D3 + E6Render-Dienst-Paket: Seiten-Screenshot und Seitengewicht. validateArtifact und publishArtifact bekommen ein Opt-in screenshot. Es liefert eine URL mit kurzer Lebensdauer, nach dem Muster von exportFigurePng und der Preview (900 s), also ohne Speicher je Version und ohne neues Tool. Der Browser-Blick meldet zusätzlich Transfer- und JS-Bytes als WARNING (nie ERROR), Schwellen aus einer Messung über den Bestand statt geraten, wie es die Ratschen-Regel verlangt.
Voraussetzung: der /pdf-Code und der aktuelle /render-Stand des VPS müssen zuerst ins Repo mzone-render (der offene Ops-Punkt aus MZP-206). Sonst erweitert man ein Repo, das nicht die Wahrheit ist.
Abnahme: eine Seite mit 1,4 MB Bundle (z. B. legacy-frontend-migration-playbook) erzeugt die Gewichts-Warnung, der Screenshot ist mindestens 1280 px breit, nichts wird dauerhaft gespeichert. -
A2Paket 2 · W1 + E5 = MZP-211Adressierbare Abschnitte, ohne neues Tool. getArtifactSource bekommt outline (Überschriften mit stabilen Ankern und Byte-Umfang) und section (ein Abschnitt). MZP-179 will weniger Tools, deshalb Parameter statt getArtifactOutline. Die Bridge-Erweiterung report.section und report.figure ist Stufe 2 und kann warten.
Grenze: Lesen wird billig, Schreiben bleibt ein Datei-Patch. Ein Abschnitts-Patch ist ein eigenes Vorhaben und gehört nicht in dieses Paket. -
A3Füllarbeit · W3, E1Zwei kleine Dinge, erst nach MZP-179 Phase 3. Ein sinceVersion je Katalogklasse (W3) und ein Text-Lesemodus über den vorhandenen HtmlTextExtractor (E1, statt Auslieferungsprofilen). Neue Katalogtexte kosten direkt Platz in der Landkarte, die dicht am 8192-Byte-Budget steht; also über topic ausliefern, nicht in die Landkarte.
Empfehlung aus Menschensicht
Der Engpass des Projekts ist nicht fehlende Arbeit, sondern Abnahme. Die Abfrage von heute zeigt 15 Tickets auf REVIEW und vier auf DOING. Jede neue Idee, die als P1 ins Backlog fällt, verschärft das.
-
H1NutzenA1 spart dir das Öffnen. Eine Gewichts-Warnung und ein Screenshot in der Publish-Antwort lassen dich einen Report beurteilen, ohne ihn zu laden. Das ist der einzige Vorschlag der Recherchen, der vor allem dir Zeit schenkt und erst danach dem Agenten.
-
H2ReihenfolgeNach MZP-206, nicht davor. Block 3 bis 5 (MZP-193, 198, 164) sind entschieden und tragen größeren Mehrwert. A1 und A2 gehören dahinter, vor Welle 5. Beide sind klein genug, um dazwischenzupassen, wenn du auf Abnahmen wartest.
-
H3Entscheidungen bei dir
- Ops: den /pdf-Code (und den echten /render) vom VPS ins Repo mzone-render holen. Ohne das startet A1 nicht.
- Screenshot per URL mit Ablauf statt Bild im Tool-Ergebnis. Ob die MCP-Basis ein Bild im Ergebnis trägt, habe ich nicht geprüft; der URL-Weg ist bereits erprobt.
- Die Tickets 207 bis 212 wie unten umpriorisieren. Am Backlog habe ich nichts geändert.
Reihenfolge
| Schritt | Inhalt | Voraussetzung | Aufwand |
|---|---|---|---|
| 0 | Ops: mzone-render mit dem VPS abgleichen | du | offen |
| 1 | A1 Screenshot und Seitengewicht (D3 + E6) | Schritt 0 | ≈ 3 PT |
| 1 | A2 Outline und Abschnitt in getArtifactSource (MZP-211, Stufe 1) | keine, parallel möglich | ≈ 1,5 PT |
| 2 | A3 sinceVersion und Text-Lesemodus; D1 in MZP-115 | MZP-179 Phase 3 | ≈ 2,5 PT |
| 3 | E2 _index.json, E4 Muster-Notice | Bedarf zeigt sich | ≈ 1 PT |
Ticket-Hygiene: MZP-207 bis 212
Die sechs Tickets entstanden heute um 06:29 in einem Zug, alle ohne Welle. Zwei tragen P1 ohne Beleg für Dringlichkeit.
| Ticket | Heute | Vorschlag |
|---|---|---|
| MZP-207 | P2 · Auslieferungsprofile | P3, umschneiden auf Text-Lesemodus (E1) |
| MZP-208 | P1 · Katalog | P3, verkleinern auf _index.json und neue Gruppen |
| MZP-209 | P2 · Snapshots | verwerfen; Nutzen übernimmt sinceVersion (W3) |
| MZP-210 | P1 · Injection | P3, nur Muster-Notice beim Publish |
| MZP-211 | P2 · Adressen | bleibt P2, Stufe 1 (Outline, Abschnitt), W1 aufnehmen |
| MZP-212 | P2 · Kosten | bleibt P2, Bytes statt LCP, mit Screenshot bündeln |
| neu | – | Screenshot auf Wunsch (D3), P2, Paket mit MZP-212 |
| MZP-115 | P3 · Token-Export | D1 als Ergänzung; Auslieferung über getCapabilities(topic='tokens') oder Endpunkt, kein neues Tool |
Wo die Recherchen den MZP falsch sehen
Diese Korrekturen sind der Grund, warum ich die Tickets nicht 1:1 übernehme.
| Behauptung | Befund |
|---|---|
| „Der MZP exponiert rund 28 Tools" (W2) | 42 sichtbare, 15 davon DEPRECATED (MZP-179, Zwischenbericht 2026-10-17). |
| „Ein Agent muss fullTextSearch raten oder blättern" (E2) | llms.txt gibt es seit MZP-62; listPublishedPages filtert und blättert. |
| Anknüpfung an MZP-38/46, knowledgeQuery und /api/wiki (W4, W6) | Mit MZP-151 abgebaut. Die Anknüpfung existiert nicht mehr. |
| „MZP kennt schon Toolsets: getCapabilities(include='minimal')" (E1) | Das verkleinert die Antwort. Toolsets im GitHub-Sinn (Fähigkeiten gruppiert zuschaltbar) sind es nicht. |
| „Die Palette liegt nur implizit in der Bibliothek" (D1) | Branding-Profile (MZP-160) und Katalogfeld tokens existieren; MZP-115 ist 20 Tage alt. |
| MZP-44 als Anknüpfung für Outline (W1) | MZP-44 ist die Repo-Map für Code, nicht für veröffentlichte Seiten. |
| Penpot „61,2k ★, Adoption 90" (D, Platz 2) | Die Zahl gehört dem gesamten Penpot-Editor-Repo; der MCP-Server ist ein Unterordner mcp/. Die Platzierung stützt sich auf geliehene Popularität. |
| Berichte werden nicht als Patch/Lifecycle geführt (E7) | Stimmt, und der Zähler bestätigt es: setPageLifecycle 0 Aufrufe. Es ist eine Gewohnheitsfrage. |
Grenzen dieser Prüfung
- Der Abgleich beruht auf Backlog und Code-Stichproben (Suche nach Outline-Funktionen, Render-Check-Ausgabe, Tool-Zahl, Katalogfelder). Ich habe die Anwendung nicht gestartet und nicht live gegen Produktion getestet.
- Der Zählerstand stammt aus dem MZP-179-Kommentar von heute 03:39 (Fenster seit 2026-10-11, zwei Clients). Er ist kurz und sagt wenig über seltene Werkzeuge.
- Von den Fremdservern habe ich nichts nachgemessen. Wo ich Zahlen nenne, stehen sie so in den Reports.
- Mehrwert und Aufwand sind Schätzungen. Der Aufwand von A1 hängt daran, ob der Render-Dienst auf dem VPS dem Stand entspricht, den ich im Repo sehe.