Browser- & Screenshot-Loop

Der Client sieht das echte confBuild-Ergebnis

Im gehosteten Remote-Modus rendert nicht die KI und auch nicht ein Browser im MCP-Backend. Stattdessen übernimmt der bereits angemeldete confBuild-Tab des Nutzers die Aufnahme:

1. Der MCP-Client speichert die gewünschte Projektversion.
2. Der Nutzer öffnet den Projektlink parallel in app.confbuild.com.
3. confbuild_render_project legt einen privaten Renderjob für diesen Nutzer und diese Projekt-ID an.
4. Die confBuild-Web-App erkennt den Job nur im passenden geöffneten Projekt.
5. Der Tab erfasst die Three.js-Canvas aus den angeforderten Blickrichtungen und lädt private PNGs hoch.
6. confbuild_get_render_result gibt Diagnosen und native MCP-Bildblöcke an Codex oder Claude zurück.
7. Der MCP-Client – nicht der Server – interpretiert die Bilder und entscheidet über den nächsten Patch.

Voraussetzungen für Remote-Screenshots

• Der Browser ist mit demselben confBuild-Konto angemeldet, das den MCP per OAuth freigegeben hat.
• Das angeforderte Projekt ist unter /e/… oder einer unterstützten Projekt-Route geöffnet.
• Editor und 3D-Szene sind vollständig geladen.
• Der Tab bleibt während des Renderjobs offen.

Eine Browser-Erweiterung, lokales Node.js, CDP oder Remote Debugging sind im Kundenmodus nicht erforderlich.

Asynchroner Renderablauf

Der Ablauf verwendet zwei Tools, damit ein langsames Projekt keinen einzelnen Tool-Aufruf blockiert:

1. confbuild_render_project startet den Job und gibt renderJobId zurück.
2. confbuild_get_render_result wird abgefragt, bis der Job completed oder failed ist. Mit waitMs (bis 30.000) wird daraus ein Long-Poll: Der Server wartet serverseitig, statt schnelles Client-Polling zu erzwingen, und meldet bei einem unbeanspruchten Job, wie lange er schon wartet — samt Hinweis, wenn kein angemeldeter Editor-Tab mit dem Projekt geöffnet ist.

Beispiel:

{
  "editSessionId": "edit-…",
  "views": ["default", "right", "front", "left"],
  "timeoutMs": 120000
}

Der Server rendert ausschließlich gespeicherte Daten. Eine Edit-Session mit ungespeicherten Änderungen muss zuerst validiert und committet werden.

Zurückgegebene Ansichten

Bis zu vier PNGs sind möglich:

• default: aktuelle Editoransicht;
• right: Ansicht von rechts;
• front: frontale Ansicht;
• left: Ansicht von links.

Für die Richtungsansichten ermittelt der Browser die sichtbaren Modellgrenzen, setzt Kamera und Orbit-Ziel auf das Modell und stellt danach die ursprüngliche Kamera wieder her. Es handelt sich um visuelle Perspektiven, nicht um garantiert orthogonale CAD-Projektionen oder Messnachweise.

Die an Codex, Claude oder einen anderen MCP-Client zurückgegebenen PNG-Vorschauen behalten ihr Seitenverhältnis und sind auf maximal 960 × 640 Pixel begrenzt. Die Antwort enthält zusätzlich Vorschau- und Originalmaße. So bleiben häufige mehrperspektivische Prüfungen aussagekräftig, während Bilddaten und Cloud-Transfer deutlich kleiner bleiben.

Sichtbarer MCP-Status im Editor

Sobald ein OAuth-MCP für das angemeldete Konto autorisiert ist, zeigt der Editor ein kompaktes MCP-Badge. Es unterscheidet bereit, aktiv, wartet auf die 3D-Ansicht, Vorschau wird aufgenommen, Vorschau wird gesendet, gesendet und fehlgeschlagen. Bei mehreren autorisierten Clients zeigt das Badge den zuletzt aktiven Clientnamen. Ohne gültige Autorisierung oder passenden Renderjob bleibt es ausgeblendet.

Diagnosedaten

Der Remote-Browserkanal liefert derzeit unter anderem:

Captures laufen im Agent-Capture-Modus: Selektionskonturen, Gizmos, Raster und Mess-Overlays werden für die Aufnahme ausgeblendet (und danach wiederhergestellt), und jede Ansicht — auch default — verwendet ein deterministisches Kamera-Preset. Screenshots hängen damit nicht mehr davon ab, wo der Nutzer die Kamera zuletzt stehen ließ.

Diagnosen ergänzen das Bild, ersetzen aber keine visuelle Prüfung. Zuerst die Geometrie-Funde lesen, dann in den Ansichten bestätigen: Sie sind näherungsweise Evidenz, keine Urteile.

Visuelle Prüfliste für den Client

Der Agent sollte jedes Bild prüfen:

1. Entspricht die Silhouette dem Auftrag?
2. Sind alle geforderten Hauptbaugruppen vorhanden?
3. Sind Maßstab und Proportionen plausibel?
4. Treffen Bauteile an vorgesehenen Schnittstellen zusammen?
5. Sind unbeabsichtigte Kollisionen oder Doppelgeometrien sichtbar?
6. Gibt es schwebende oder weit außerhalb liegende Teile?
7. Sind sichtbare Muster, Abstände und Parameter konsistent?
8. Melden Browser oder Szene Fehler?

„Visuell geprüft“ ist erst zulässig, wenn der finale Render abgeschlossen und jedes zurückgegebene Bild tatsächlich betrachtet wurde.

Wenn kein Screenshot zurückkommt

Prüfen Sie in dieser Reihenfolge:

1. Ist exakt das angeforderte Projekt im Browser geöffnet?
2. Sind Browser und MCP mit demselben confBuild-Konto verbunden?
3. Ist die 3D-Szene vollständig geladen?
4. Bleibt der Tab geöffnet und aktiv genug, um Canvas-Frames zu rendern?
5. Wird derselbe Job gepollt, statt wiederholt neue Jobs zu starten?

Nach Ablauf des Timeouts meldet der Server RENDER_FAILED, statt auf einen anderen Tab oder Benutzer zuzugreifen.

Mehrere geöffnete Tabs

Sind mehrere Tabs desselben Projekts geöffnet, können sie denselben Job erkennen. Uploadpfade und Jobstatus sind idempotent, dennoch ist für einen stabilen Ablauf nur ein geöffneter Zieltab empfohlen. Eine künftige Tab-Lease soll genau einen Tab auswählen.

Lokaler Entwicklermodus

Der lokale STDIO-Server unterstützt zusätzlich auto, headed, headless und einen bewusst über CONFBUILD_MCP_CDP_URL freigegebenen attached-Modus. Diese Playwright-/CDP-Modi sind Entwicklungs- und CI-Funktionen; Kunden mit dem gehosteten MCP verwenden den Browser-Tab-Kanal.

Nächster Schritt

Die Eingaben der Render-Tools stehen in der Tool-Referenz. Fehler behandelt Sicherheit & Fehlerbehebung.