MCP und CLI

Verbinde deinen KI-Agenten mit Overhub, um Befunde zu lesen, Fixes zu melden und Nachprüfungen anzufordern. Du brauchst ein Overhub-Konto und einen MCP-Service-Key für deine Projekte. Lege ihn in der App unter Einstellungen → Service Keys → MCP-Agent an; beim Login wählst du diesen Key und damit die freigegebenen Rechte.

CLI anmelden

Mit der installierten overhub-CLI:

overhub config set-url https://app.overhub.io
overhub login
overhub --help

Der Login öffnet den Browser. Melde dich mit deinem Overhub-Konto an und wähle den passenden MCP-Key. Nach dem Domain-Wechsel ist eine erneute Anmeldung nötig.

Claude verbinden

Füge in Claude einen Connector mit dieser URL hinzu:

https://app.overhub.io/api/mcp

Schließe den OAuth-Login im Browser ab. Für ein einzelnes Projekt findest du unter Projekteinstellungen → Integrationen → KI-Agenten (MCP) die projektgebundene URL. Keys und Tokens gehören nicht in die Connector-URL oder ins Repository.

Werkzeuge

Die Tabelle wird beim Build aus den MCP-Werkzeugen erzeugt. Dein Key bestimmt, welche davon du verwenden darfst.

Name	Titel	Beschreibung
get_project_settings	Projekteinstellungen lesen	Scan- und Engine-Einstellungen lesen; Zugangsdaten bleiben redigiert. Recht read. Bei Budgetüberschreitung vollständiges JSON seitenweise mit responseOffset=0 lesen; responseJson verketten, nextResponseOffset und responseRevision bei unveränderten Argumenten weitergeben. Erst bei nextResponseOffset=null parsen. Kontextseiten liefern alle gewählten Rohfelder ohne Sammlungs-Filter oder -Limits.
get_scan_schedules	Scan-Zeitpläne lesen	Zeitpläne aller Engines des Projekts lesen. Recht read. Bei Budgetüberschreitung vollständiges JSON seitenweise mit responseOffset=0 lesen; responseJson verketten, nextResponseOffset und responseRevision bei unveränderten Argumenten weitergeben. Erst bei nextResponseOffset=null parsen. Kontextseiten liefern alle gewählten Rohfelder ohne Sammlungs-Filter oder -Limits.
get_squirrel_rules	Squirrel-Regeln lesen	Wirksame Squirrel-Regeln für das Projekt und optional sein System lesen. Recht read. Bei Budgetüberschreitung vollständiges JSON seitenweise mit responseOffset=0 lesen; responseJson verketten, nextResponseOffset und responseRevision bei unveränderten Argumenten weitergeben. Erst bei nextResponseOffset=null parsen. Kontextseiten liefern alle gewählten Rohfelder ohne Sammlungs-Filter oder -Limits.
list_playwright_tests	Playwright-Tests lesen	Verfügbare Playwright-Tests lesen, optional nach System filtern. Recht read. Bei Budgetüberschreitung vollständiges JSON seitenweise mit responseOffset=0 lesen; responseJson verketten, nextResponseOffset und responseRevision bei unveränderten Argumenten weitergeben. Erst bei nextResponseOffset=null parsen. Kontextseiten liefern alle gewählten Rohfelder ohne Sammlungs-Filter oder -Limits.
get_playwright_override	Deaktivierte Playwright-Tests lesen	Deaktivierte Playwright-Tests des Projekts lesen. Recht read. Bei Budgetüberschreitung vollständiges JSON seitenweise mit responseOffset=0 lesen; responseJson verketten, nextResponseOffset und responseRevision bei unveränderten Argumenten weitergeben. Erst bei nextResponseOffset=null parsen. Kontextseiten liefern alle gewählten Rohfelder ohne Sammlungs-Filter oder -Limits.
save_project_settings	Projekteinstellungen speichern	Nur übergebene Scan- und Engine-Einstellungen ändern; keine Secrets, Secret-Flags, id oder repoPath. Recht manageSettings.
set_squirrel_rules	Squirrel-Regeln setzen	Regeln per Regel-ID aktivieren, deaktivieren oder auf den Standard zurücksetzen. Recht manageSettings.
set_disabled_playwright_tests	Deaktivierte Playwright-Tests setzen	Die gesamte Liste deaktivierter Tests ersetzen; [] aktiviert alle Tests. Recht manageSettings.
set_scan_schedule	Scan-Zeitplan setzen	Den gesamten Zeitplaneintrag ersetzen; nicht übergebene optionale Felder fallen auf Engine-Standards zurück. Recht manageSettings.
delete_scan_schedule	Scan-Zeitplan löschen	Den Zeitplaneintrag der gewählten Engine entfernen. Recht manageSettings.
set_serp_target_domain	SERP-Zieldomain setzen	Die Zieldomain ändern, ohne die Keyword-Liste zu ersetzen. Recht manageSettings.
list_finding_groups	Finding-Gruppen auflisten	Kompakte Rangfolge offener Finding-Gruppen über alle URLs: Titel, Schweregrad, Aufwand, Anzahl Vorkommen (unlistedOccurrenceCount: davon vom Scanner nur gezählt, ohne Beleg), zuletzt gesehen (lastSeenAt, lastSeenRunId). status "all" hängt geschlossene Gruppen an und nennt je Gruppe status und resolvedAt, etwa um nach einem Re-Scan Behobenes zu sehen. workState nennt den Arbeitsstand; Filter scanner, fixChannel, severity, category, workState wirken serverseitig; Seiten bleiben im 10.000-Byte-Budget der gesamten MCP-Antwort; kleinere Seiten nennen truncated, hint und nextCursor. fields "compact" liefert nur groupId als 12-Zeichen-Präfix, rank, severity, title, scanners, fixChannel, occurrenceCount sowie fixReport und workState als reine State-Strings, falls vorhanden. workState "none" filtert unbearbeitete Gruppen. Details über get_finding_group.
get_finding_group	Finding-Gruppe lesen	Details einer Finding-Gruppe: closeEta.cleanViewsNeeded nennt bei Browser-Fehlern die noch nötigen fehlerfreien Besuche (null ohne belastbare Besuchsrate, unavailable: Besuchsdaten nicht lesbar); bei anderen Scannern fehlt closeEta. (stack nennt type, cms_shop und coreVersion des Projekts; playbook liefert die passende Arbeitsanleitung als body; vor dem Fix danach arbeiten, fehlt body, per get_playbook lesen): costByEntity (Kosten je Skript-Eigentümer als Seitenmittel mit pages), Maßnahme (Titel, Begründung, Maßnahmentext, Fix-Typ, Aufwand), Priorität und die ersten Vorkommen samt Evidenz. Weitere Vorkommen über list_group_occurrences mit nextOffset; im 10.000-Byte-Budget gekürzte Vorkommen nennen truncated und hint. fields "compact" liefert Titel, Maßnahme, Quelle/Skript-URL und höchstens drei Beispiel-URLs ohne Evidenz; Standard full. research nennt die letzten drei researchLog-Einträge mit dieser groupId (researchCount: alle; Volltext per get_project_context, auch wenn researchVia statt research kommt; researchUnavailable: Kontext nicht lesbar): frühere Fix-Versuche und ausgeschlossene Hypothesen vor neuer Untersuchung lesen.
list_group_occurrences	Vorkommen einer Gruppe auflisten	Weitere Vorkommen einer Finding-Gruppe seitenweise lesen: URL, Status, Scanner, betroffene Elemente. elementOffset (Standard 0) wählt je Vorkommen zehn Elemente; nextElementOffset als elementOffset mit demselben offset für weitere Elemente verwenden. fields "compact": nur url, status, lastSeenAt, message, selector, ohne breadcrumbs/frames/pages; 10.000-Byte-Budget der gesamten MCP-Antwort mit nextOffset für weitere Vorkommen; gekürzte Seiten nennen truncated und hint; Standard full.
report_finding_fix	Finding-Fix melden	Fix für eine Gruppe auditierbar melden. Optional reproSteps: höchstens 10 Schritte mit action click/hover/scroll und selector (1..300 Zeichen); Browser-Fehler-Rechecks spielen sie in Reihenfolge ab. Fehlende Selektoren lassen die Prüfung unbelegt, niemals behoben. Ändert keinen Finding-Status; requestId bei Wiederholung beibehalten. Mit verifyUrls ist zusätzlich das Recht rescan erforderlich; verifyUrls (1-10 Vorkommens-URLs der Gruppe) startet die gezielte Prüfung genau dieser URLs sofort (Antwort verification mit jobId, Status über get_rescan_status mit derselben requestId); nur dort geprüfte Vorkommen können als behoben bestätigt werden; ist für die Gruppe keine gezielte Prüfung möglich (etwa Squirrel-Regeln mit Site-Kontext), wird der Fix trotzdem gespeichert und verification nennt mode "unavailable" mit reason. Mit commitUrl wird die Gruppe nach 10 und 30 Minuten automatisch erneut geprüft (Deploy-Wartezeit); ein manueller request_finding_rescan bleibt möglich.
set_finding_status	Arbeitsstand setzen	Arbeitsstand einer offenen Gruppe auditierbar setzen, ohne Finding-Status zu ändern oder die Gruppe auszublenden. needs-human braucht action und owner, third-party vendor, false-positive und accepted eine note (1..2000 Zeichen); accepted erlaubt ISO reviewAt. verified, resolved, fix-deployed und open sind keine Eingaben. requestId bei Wiederholung beibehalten. Nach jedem Bearbeitungsschritt aufrufen, sofern kein Fix gemeldet wurde (fix-deployed/regressed werden vom Scan abgeleitet).
propose_finding_rule	Regel für eine Finding-Gruppe vorschlagen	Schlägt eine findingPolicy-Regel (unterdrücken oder Schweregrad herabstufen) für eine Finding-Gruppe vor. Wirkt erst nach Freigabe im Dashboard oder über approve_pending_finding_rules (Recht manageFindings); requestId bei Wiederholung beibehalten.
check_url	URL gegen Gruppenregel prüfen	Trockenlauf: prüft eine beliebige http(s)-URL (auch Preview oder Staging) gegen die schnelle Regel der Gruppe (axe-core oder Browser-Fehler) und antwortet in höchstens 25 Sekunden mit outcome present (Regel verletzt, occurrences), absent oder unclear (reason). Ändert nie ein Finding, keinen Arbeitsstand und kein Audit: persisted ist immer false; behoben wird die Gruppe nur vom Scan. Private und lokale Adressen werden mit 400 abgelehnt; Gruppen ohne schnelle Regel (409) über request_finding_rescan prüfen. Höchstens 20 Aufrufe je 10 Minuten. Recht rescan.
request_finding_rescan	Finding-Re-Scan anfordern	Re-Scan der Gruppe anfordern. Bevorzugt die gezielte Prüfung nur der betroffenen URLs und Regeln (mode recheck, jobId); ohne Unterstützung ein Engine-Lauf je Quelle (mode engine, runs), wobei ein bereits wartender oder laufender Lauf desselben Projekts wiederverwendet wird. skipped nennt Quellen, die die gezielte Prüfung nicht abdeckt. Hat die Gruppe mehr als 200 URLs, prüft die gezielte Prüfung nur eine Stichprobe von höchstens 20 URLs über alle Seitentypen und Märkte (sampled: checked von of); nicht geprüfte Vorkommen bleiben offen, bis der nächste reguläre Lauf sie bestätigt. Nur der Scan bestätigt die Behebung; Fortschritt über get_rescan_status. wait wird serverseitig auf 10 Sekunden begrenzt; danach status queued/running mit jobId und requestId, Ergebnis nur wenn bereits fertig. requestId bei Wiederholung beibehalten; sie muss eine UUID sein (oder weglassen).
get_rescan_status	Re-Scan-Status lesen	Status eines über request_finding_rescan angeforderten Re-Scans anhand der requestId: queued, running, completed, partial, failed, skipped (kein Scan; runs nennen reason, z. B. Cache, Sperre oder deaktiviert) oder unknown (Job nicht mehr vorhanden). Bei gezielter Prüfung mit Fortschritt und Ergebnis (geprüfte, behobene und verbleibende Vorkommen). result.errors ist nach message gruppiert, mit count und höchstens fünf exampleUrls. Bei Erreichen des 10.000-Byte-Budgets nennt omittedErrorCount die zusätzlich ausgelassenen Fehler.
get_playbook	Playbook lesen	Kurze Methodenanleitung für einen Fix oder Ablauf: ohne playbook die Liste (name, title, summary), mit playbook den Markdown-Text. get_finding_group liefert das playbook einer Gruppe bereits mit body; get_playbook nur, wenn dort body fehlt (readVia). client-task gehört zu keiner Gruppe: vor jedem Kundentask aus Gruppen lesen. Falsche oder fehlende Anweisung in einem Playbook: report_overhub_issue mit tool get_playbook. Bei Budgetüberschreitung vollständiges JSON seitenweise mit responseOffset=0 lesen; responseJson verketten, nextResponseOffset und responseRevision bei unveränderten Argumenten weitergeben. Erst bei nextResponseOffset=null parsen. Kontextseiten liefern alle gewählten Rohfelder ohne Sammlungs-Filter oder -Limits.
get_project_context	Projekt-Kontext lesen	Markennamen, Geschäftsüberblick, Kernseiten, Recherche-Log, Zielgruppe (audience), Tonalität (voice), Märkte (markets) und Inhaltsregeln (contentRules) für Textfixes wie Meta-Titel (diese Felder vor jedem Textfix lesen), Stack (stack: type, detected aus dem letzten Techstack-Scan mit nur bestätigten Einträgen, platform mit Shopware-Core-Version/Plugins oder Shopify-Apps und platform.shop mit dem Shop-Profil (Zahlungs- und Versandarten, Katalog-Zähler, Kategorien/Kollektionen, Verkaufskanäle/Märkte, Sprachen, Währungen; nur Zähler und Namen, nicht lesbare Abschnitte null); null, wenn nicht erfasst – nie raten) und aktive Ausschluss-/Herabstufungsregeln des Projekts (exclusionRules, nur lesend) lesen. Zu Beginn jeder Runde vor Recherche und vor dem Setzen neuer Regeln aufrufen: bereits ausgeblendete Quellen und beantwortete Fragen nicht erneut erarbeiten; Erkenntnisse über das Projekt per save_project_context im researchLog festhalten. fields wählt Kontextfelder; researchLogLimit liefert die neuesten N Einträge (0: keine), im 10.000-Byte-Budget; gekürzte Seiten nennen truncated und nextResearchLogOffset, damit als researchLogOffset weiter zurücklesen (Standard 0). exclusionRules liefert ohne exclusionRulesRule und exclusionRulesLimit nur {count, byRule}; mit Filter auf rule oder Limit die Regeln selbst (Standard 100, maximal 1000). Bei Budgetüberschreitung vollständiges JSON seitenweise mit responseOffset=0 lesen; responseJson verketten, nextResponseOffset und responseRevision bei unveränderten Argumenten weitergeben. Erst bei nextResponseOffset=null parsen. Kontextseiten liefern alle gewählten Rohfelder ohne Sammlungs-Filter oder -Limits.
propose_finding_ignore	Ausblenden vorschlagen	Vorschlag einreichen, eine Finding-Gruppe zu ignorieren. Setzt keinen Finding-Status und blendet nichts aus: der Vorschlag wirkt erst, wenn ein Mensch ihn im Dashboard freigibt. Mit Recht manageFindings stattdessen hide_finding_group nutzen. requestId bei Wiederholung beibehalten.
report_overhub_issue	Overhub-Fehler melden	Meldet ohne Rückfrage einen Overhub-Fehler oder belegten Scanner-Fehlalarm als GitHub-Issue. Keine Kundenshop-Befunde; Features nur auf ausdrücklichen Nutzerauftrag (category: feature). Fehlgeschlagene Lesezugriffe einmal wiederholen; bei Schreibfehlern zuerst die Wirkung prüfen und eine vorhandene requestId beibehalten. Jeden belegten Fehler melden, auch einmalige intermittierende, mit Versuchszahl und Ergebnis der Wiederholung. Ein Issue je unabhängig behebbarer Ursache; mehrere Beispiele derselben Ursache zusammenfassen, weitere Ursachen separat melden. title: Tool/Bereich und Symptom, möglichst unter 100 Zeichen. Bekannte Meldung: issueNumber angeben; sonst tool und title unverändert wiederverwenden. Alle sechs Abschnitte sind Pflicht und werden vor dem Melden vollständig ausgefüllt, keine Vorschläge im Konjunktiv: observed, contract, source, class, remedy, verify. Vermutungen kennzeichnen. Keine Secrets, personenbezogenen Daten oder vollständigen Kundenobjekte. Server ergänzt Empfangszeit, Overhub-Version und je groupId/groupIds die Gruppen-Evidenz.
save_project_context	Projekt-Kontext speichern	Projekt-Kontext pflegen: Markennamen (brandNames, ersetzen die bisherigen), Geschäftsüberblick (ersetzt den bisherigen), Schlüsselseiten (ersetzen die bisherigen), Recherche-Log-Einträge (werden nur angehängt, nie geändert oder gelöscht), Zielgruppe (audience), Tonalität (voice), Märkte (markets, Locales wie de-CH; ersetzen die bisherigen), Inhaltsregeln (contentRules; Textfixes lesen diese Felder zuerst; leerer String oder leere Liste löscht) und Repo/Checkout (url, branch, revision; ersetzt den bisherigen). Nicht übergebene Felder bleiben unverändert. Keine Zugangsdaten oder Secrets, auch nicht in der Repo-URL. Antwort: kurze Bestätigung ok, updatedFields, researchLogEntries (Gesamtzahl), savedAt, kein Volltext-Echo.
add_project_exclusion_rule	Projektweite Ausschlussregel setzen	Setzt sofort und ohne Freigabe eine projektweite Ausschlussregel: alle Befunde aller Scanner auf URLs, die zum url_pattern (RegExp, Groß-/Kleinschreibung egal) passen, werden künftig unterdrückt; bereits offene passende Vorkommen setzt der Aufruf sofort auf suppressed (suppressedCount in der Antwort). Braucht das Recht manageFindings; wird protokolliert und ist im Dashboard unter Projekt-Einstellungen entfernbar. Nur mit klarer Begründung und eng gefasstem Muster setzen.
hide_finding_group	Finding-Gruppe ausblenden	Blendet eine Finding-Gruppe sofort und ohne Freigabe aus (gleiche Wirkung wie Ausblenden im Dashboard; rückgängig im Dashboard oder per unhide_finding_group). Offene Ausblend-Vorschläge dieser Gruppe gelten damit als freigegeben (approvedProposals). Braucht das Recht manageFindings und wird protokolliert.
list_hidden_finding_groups	Ausgeblendete Finding-Gruppen lesen	Eine Liste items: zuerst Ausblend-Vorschläge, die auf Freigabe warten (kind pendingIgnoreProposal: proposalId, groupId, reason gekürzt, actor, recordedAt), danach ausgeblendete Finding-Gruppen (kind hidden: groupId, title, severity, ruleId, occurrenceCount). Mit Recht manageFindings erledigt hide_finding_group einen Vorschlag direkt. Standard 25 Einträge ab offset, maximal 100; totalPendingIgnoreProposals und totalHidden nennen die Gesamtzahlen, weitere Seiten mit nextOffset als offset, im 10.000-Byte-Budget gekürzte Seiten nennen truncated und hint. Recht read.
unhide_finding_group	Finding-Gruppe wieder einblenden	Blendet eine ausgeblendete Finding-Gruppe sofort wieder ein und öffnet ihre unterdrückten Vorkommen (gleiche Wirkung wie Einblenden im Dashboard). groupId aus list_hidden_finding_groups, 12-Zeichen-Präfix genügt. Braucht das Recht manageFindings und wird protokolliert.
apply_finding_rule	Regel für eine Finding-Gruppe setzen	Setzt sofort und ohne Freigabe eine findingPolicy-Regel (unterdrücken oder Schweregrad herabstufen, optional mit url_pattern und messagePattern) für eine Finding-Gruppe. Die Regel muss offene Befunde dieser Gruppe treffen. Braucht das Recht manageFindings; wird protokolliert und ist im Dashboard unter Projekt-Einstellungen → Projektregeln entfernbar. Ohne dieses Recht propose_finding_rule nutzen.
approve_pending_finding_rules	Offene Regelvorschläge freigeben	Gibt alle offenen Regelvorschläge (propose_finding_rule) eines Projekts sofort frei, als hätte ein Mensch sie im Dashboard freigegeben. Braucht das Recht manageFindings und wird protokolliert; wiederholbar, bereits entschiedene Vorschläge bleiben unberührt. failed nennt Vorschläge, die nicht übernommen werden konnten.
list_serp_keywords	SERP-Keywords lesen	Getrackte SERP-Keywords des Projekts samt Zieldomain (targetDomain). Pro Keyword: lastPosition, lastCheckedAt, rankingUrl und targetUrlMatch aus dem neuesten Lauf derselben Variante; ohne passenden Lauf null, targetUrlMatch auch ohne targetUrl oder Ranking null. index ist die Position für replace_serp_keyword und delete_serp_keyword. Standard 50 Keywords ab offset, maximal 200; totalKeywords nennt die Gesamtzahl, weitere Seiten mit nextOffset als offset, im 10.000-Byte-Budget gekürzte Seiten nennen truncated und hint.
add_serp_keyword	SERP-Keyword anlegen	Legt ein Keyword (keyword) oder bis zu 100 auf einmal (keywords) zum Ranking-Tracking an; wird beim nächsten SERP-Lauf abgefragt. Dieselbe Variante (Keyword, Gerät, Location, Sprache) doppelt gibt 409, bei keywords je Eintrag in results ohne Abbruch der übrigen. Ohne gesetzte Zieldomain (list_serp_keywords) liefert der Lauf keine Positionen; die setzt set_serp_target_domain (Recht manageSettings).
replace_serp_keyword	SERP-Keyword ersetzen	Ersetzt das Keyword an index vollständig; nicht angegebene Felder fallen auf ihre Standardwerte zurück.
delete_serp_keyword	SERP-Keyword löschen	Entfernt das Keyword an index aus dem Tracking; bisherige Ranking-Historie bleibt.
get_search_performance	Search-Console-Leistung lesen	Vollständige Search-Console-Liste des Projekts aus dem letzten GSC-Lauf, nicht nur Befund-Zeilen: je Seite, Suchanfrage oder Seite+Suchanfrage clicks, impressions, ctr und position (impressions-gewichtet), absteigend nach impressions. dataAsOf nennt Lauf, Abrufzeit und Zeitraum (endgültige GSC-Daten, Stand etwa 3 Tage zurück). Standard 50 Zeilen, maximal 100; im 10.000-Byte-Budget gekürzte Seiten nennen truncated und hint. Weitere Seiten mit nextCursor als cursor. Seiten ohne Impressionen fehlen; GSC anonymisiert seltene Suchanfragen, deshalb ergeben page+query-Zeilen nicht die Seitensumme.
inspect_url	Google-Indexierung prüfen	Nur lesende Live-Abfrage der Google URL Inspection mit url für eine einzelne URL (Felder direkt in der Antwort) oder urls für 1 bis 20 URLs der Search-Console-Property des Projekts (URLs außerhalb der Property werden abgelehnt). Je URL: googleCanonical, userCanonical, canonicalMismatch (true, wenn Google eine andere Canonical wählt als angegeben), coverageState, indexingState, robotsTxtState, lastCrawlTime, crawledAs und inspectionResultLink; Fehler stehen je URL im Feld error und brechen den Aufruf nicht ab. Quota von Google: 600 Abfragen pro Minute und 2000 pro Tag je Property, geteilt mit dem GSC-Lauf; bei Quota-Fehler später erneut versuchen und nur wenige gezielte URLs prüfen. Recht read. Bei Budgetüberschreitung vollständiges JSON seitenweise mit responseOffset=0 lesen; responseJson verketten, nextResponseOffset und responseRevision bei unveränderten Argumenten weitergeben. Erst bei nextResponseOffset=null parsen. Kontextseiten liefern alle gewählten Rohfelder ohne Sammlungs-Filter oder -Limits.
get_performance_overview	Performance-Felddaten lesen	CrUX-Felddaten des letzten Lighthouse-Laufs: templates nennt je Seite origin sowie mobile und desktop mit p75 und category für LCP, CLS und INP; origins nennt dieselben Werte einmal je Origin. trend enthält je Lauf die origin-p75 der letzten höchstens fünf gespeicherten Läufe, neuester zuerst. Fehlt ein Gerät, ist es null; eine fehlende Metrik hat reason no-field-data. Ohne Lauf bleibt die Übersicht leer. Recht read. Bei Budgetüberschreitung vollständiges JSON seitenweise mit responseOffset=0 lesen; responseJson verketten, nextResponseOffset und responseRevision bei unveränderten Argumenten weitergeben. Erst bei nextResponseOffset=null parsen. Kontextseiten liefern alle gewählten Rohfelder ohne Sammlungs-Filter oder -Limits.
setup_openpanel_tracking	OpenPanel-Tracking einrichten	OpenPanel-Projekt und projektspezifische Schreib-/Lese-Clients sicherstellen; liefert contractVersion, events und die Liste installierbarer files ohne Secrets; Inhalt je Datei mit file=<path>. leadgen ist für nuxt standardmäßig true, für Shops false. stack wird für Shopify/Shopware abgeleitet, sonst explizit angeben. Recht writeContext.
query_openpanel	OpenPanel abfragen	Projektgebundene, nur lesende OpenPanel-MCP-Bridge: ohne tool Namen und Kurzbeschreibungen listen (bei Budgetüberschreitung per responseOffset weiterlesen), mit tool ohne arguments das Schema lesen, mit tool und arguments aufrufen ({} für leere Argumente). Zuerst setup_openpanel_tracking ausführen. Recht read. Bei Budgetüberschreitung vollständiges JSON seitenweise mit responseOffset=0 lesen; responseJson verketten, nextResponseOffset und responseRevision bei unveränderten Argumenten weitergeben. Erst bei nextResponseOffset=null parsen. Kontextseiten liefern alle gewählten Rohfelder ohne Sammlungs-Filter oder -Limits.
run_engine	Engine-Lauf starten	Startet jetzt einen regulären Vollauf einer Engine (squirrel, lighthouse, gsc, playwright, e2e) für das Projekt, ohne den Zeitplan zu ändern. Ein bereits wartender oder laufender Lauf derselben Engine wird wiederverwendet (reused). Antwort: requestId (= jobId), engine, reused, status (queued; bei wiederholter requestId der Stand dieses Laufs: running, completed, skipped mit reason oder failed, dann startet kein neuer Lauf). Fortschritt über get_engine_run_status mit derselben requestId. Bei Wiederholung requestId beibehalten; sie muss eine UUID sein (oder weglassen). Teilt die stündliche Re-Scan-Quota.
get_engine_run_status	Engine-Lauf-Status lesen	Status eines Engine-Laufs: queued, running, completed, skipped oder failed, außerdem unknown (Lauf nicht mehr vorhanden). skipped nennt mit reason, warum nicht gescannt wurde (z. B. Cache, Sperre oder deaktiviert); completed bedeutet, dass der Lauf gearbeitet hat. Mit requestId aus run_engine genau dieser Lauf; ohne requestId der jüngste Lauf der Engine, auch wenn er im Dashboard gestartet wurde (running, solange die Engine für das Projekt aktiv läuft). Bei Budgetüberschreitung vollständiges JSON seitenweise mit responseOffset=0 lesen; responseJson verketten, nextResponseOffset und responseRevision bei unveränderten Argumenten weitergeben. Erst bei nextResponseOffset=null parsen. Kontextseiten liefern alle gewählten Rohfelder ohne Sammlungs-Filter oder -Limits.
get_run_artifact	Lauf-Artefakt abrufen	Liefert für eine Playwright-Trace- oder Video-Datei (tracePath/videoPath aus den Belegen, z.B. /reports/<clientId>/traces/<run>/<id>-trace.zip oder die E2E-Fehlerseite /reports/<clientId>/traces/e2e-<runId>/<name>.md) eine kurzlebige signierte Download-URL (url, expiresAt, 15 Minuten gültig). Die Datei selbst wird nie in die Antwort eingebettet. Nur Dateien unter traces/ und videos/ des eigenen Projekts; die URL ist ein Zugriffsschlüssel und nicht weiterzugeben oder zu speichern. Trace-ZIP lokal öffnen mit npx playwright show-trace; die E2E-Fehlerseite ist Markdown. Bei Budgetüberschreitung vollständiges JSON seitenweise mit responseOffset=0 lesen; responseJson verketten, nextResponseOffset und responseRevision bei unveränderten Argumenten weitergeben. Erst bei nextResponseOffset=null parsen. Kontextseiten liefern alle gewählten Rohfelder ohne Sammlungs-Filter oder -Limits.