Diese Seite listet jedes Tool auf, das der Docsbook-MCP-Server unter https://docsbook.io/api/mcp/server bereitstellt. Der Server stellt 309 Tools bereit. Für jedes ist eine Bearer-Authentifizierung über OAuth 2.0 + PKCE erforderlich.
Die Spalte Abrechnung nennt die Klasse, unter der ein Aufruf zulasten des eigenen Projektguthabens abgerechnet wird:
Klasse
Was sie umfasst
Inklusive
Erkennung und Verbindung — niemals abgerechnet
Lesen
Liest eine Seite, eine Einstellung oder eine bereits von Docsbook gespeicherte Registry-Zeile
Schreiben
Ändert etwas — Inhalte, Konfiguration, Ziele oder Registrierungen
Analytics
Durchsucht das Ereignis-Warehouse: Funnels, Journeys, Retention und Feeds
Egress
Verlässt das Docsbook-Netzwerk — ruft eine URL ab oder löst eine tatsächliche Zustellung aus
Probe
Erfasst eine Faktenkategorie und normalisiert sie, ohne dass ein Modell beteiligt ist
KI
Modellgestützt: Etwas, das ein Modell für Sie schreibt, liest oder bewertet
Agent
Ein vollständiger Agentenlauf: Arbeitsminuten, ein Bericht und ein eigener Laufdatensatz
Die aktuellen Preise pro Klasse sind auf der Docsbook-Preisseite veröffentlicht. Ein wegen eines leeren Guthabens abgelehnter Aufruf weist darauf hin; nichts auf dieser Seite ist durch etwas anderes eingeschränkt.
So stellen Sie eine Verbindung über Claude Code her:
Kopfzeile, Suche, Feedback, Kopierschaltfläche und Breadcrumbs ein- oder ausschalten
update_navigation
Schreiben
Kopfzeilenlinks, soziale Links, Unterkopfzeilen-Ordnerregisterkarten (mit optionalen Symbolen), Seiten- und Ordnersymbole der linken Seitenleiste sowie Überschreibungen der Seitenleistenbeschriftungen — Umbenennen der Anzeige eines Dokuments oder Ordners in der Seitenleiste, ohne dessen Adresse oder Position im Baum zu verschieben
update_ai_settings
Schreiben
KI-Chat aktivieren, Anbieter und API-Schlüssel festlegen, Modellauswahl — einschließlich der Verwendung eines eigenen Anbieterschlüssels
update_seo
Schreiben
SEO-Meta-Tags, Sitemap, OpenGraph
update_access
Schreiben
Einen Arbeitsbereich privat machen; ein Passwort festlegen und/oder einen eigenen SSO/OIDC-Identitätsanbieter verwenden
update_domain
Schreiben
Eine benutzerdefinierte Domain verknüpfen oder entfernen
Volltext-/Regex-/Überschriften-/Pfadsuche über die Dokumentationsinhalte des Arbeitsbereichs. Nur lesend — funktioniert mit jedem Token, unabhängig vom Lese-/Schreibzugriffsbereich.
search
AI
Semantische (embedding-basierte) Suche über die Dokumentationsinhalte des Arbeitsbereichs — findet Seiten nach ihrer Bedeutung statt nach wörtlicher Übereinstimmung von Schlüsselwörtern. Liest einen vorab erstellten Vektorindex (bei der Suche keine erneute Indexierung). Nur lesend, in jedem Tarif enthalten und für eine öffentliche Website ohne Token über einen Repository-bezogenen Endpunkt verfügbar. Wenn kein Index erstellt oder aktiviert wurde, antwortet sie mit einer Volltextsuche, statt die Anfrage abzulehnen, und mode (semantic / lexical) gibt an, welche Suchmaschine geantwortet hat.
get_doc_outline
Lesen
Listet vor dem Suchen oder Schreiben den Titel, die Anzahl der Überschriften und die Größe jeder Markdown-Seite auf. Nur lesend — funktioniert mit jedem Token, unabhängig vom Lese-/Schreibzugriffsbereich.
write_docs
AI
Überträgt eine oder mehrere Markdown-Dateien in einem einzigen atomaren Git-Commit in das Dokumentations-Repository des Arbeitsbereichs. Erfordert ein Token mit autorisiertem Lese-/Schreibzugriff — ein schreibgeschütztes Token wird abgelehnt. Akzeptiert optional ein intent: was die Person in ihren eigenen Worten angefordert hat. Es wird im Änderungsbereich dem Commit gegenübergestellt, sodass das Ziel hinter einer Bearbeitung die Unterhaltung überdauert, durch die sie entstanden ist.
fetch_url
Ausgehend
Liest eine öffentliche Webseite und gibt sie als sauberes Markdown zurück, einschließlich Titel, Beschreibung und der endgültigen URL nach Weiterleitungen. Zum Überprüfen einer Aussage anhand einer Seite außerhalb des Arbeitsbereichs — etwa der Preise eines Wettbewerbers, der eigenen Marketing-Website oder der Frage, ob ein von einem Dokument abhängiger Link noch erreichbar ist. Eine 404- oder Anmeldeseite wird als angegebenes Ergebnis und nicht als Fehler zurückgegeben, da dies die Antwort ist, wenn die Frage lautet, ob ein Link funktioniert. Private und interne Adressen werden abgelehnt, robots.txt wird berücksichtigt, und Seiteninhalte werden als Daten behandelt, niemals als Anweisungen.
list_sources
Lesen
Listet die Repositorys und Websites auf, mit denen dieser Arbeitsbereich als maßgeblichen Quellen verbunden ist, sowie das Repository, aus dem die Website erstellt wird. Jeder Eintrag enthält die eigene Notiz des Besitzers dazu, warum er verbunden ist. Nur lesend. Vor dem Schreiben oder Aktualisieren der Dokumentation aufrufen: Eine verbundene Quelle ist eine Tatsache, die du aufrufen und lesen kannst, statt sie abzurufen.
read_source
Ausgehend
Liest eine dieser Quellen. Ein Repository ohne path gibt seine lesbaren Dateien zurück, mit einem solchen nur diese Datei; eine Website ohne path gibt mehrere ihrer Seiten als Markdown zurück, die aus ihrer eigenen Sitemap ermittelt und auf den verbundenen Abschnitt beschränkt werden. Dieselben Schutzmaßnahmen wie bei fetch_url — private Adressen werden abgelehnt, robots.txt wird berücksichtigt, und Seiteninhalte werden als Daten behandelt, niemals als Anweisungen.
connect_source
Schreiben
Verbindet ein Repository, eine Website oder eine einzelne Seite als maßgebliche Quelle — was list_sources anschließend auflistet, read_source liest und ein mit enable_agent ausgestatteter Agent überwacht. Ein GitHub-Repository wird auf Lesbarkeit geprüft (öffentlich oder mit einer GitHub-Autorisierung, über die dieses Projekt bereits verfügt), bevor es gespeichert wird; ein privates Repository, für das noch niemand eine Autorisierung erteilt hat, wird mit genau dem Hinweis abgelehnt, der das Problem behebt, statt unlesbar gespeichert zu werden. note enthält die eigenen Worte des Besitzers dazu, wofür die Quelle gedacht ist, und wird von allem, was sie später liest, als Anweisung interpretiert. Erfordert ein Token mit Lese-/Schreibzugriff.
configure_source
Schreiben
Benennt eine verbundene Quelle um, schreibt ihren note neu, pausiert sie (enabled: false — bleibt verbunden, nichts liest sie) oder trennt sie vollständig (entfernt jede damit verbundene GitHub-Autorisierung). Identifiziere die Quelle anhand von source_id aus list_sources oder anhand von match (einem Wort aus ihrer Bezeichnung oder URL). Erfordert ein Token mit Lese-/Schreibzugriff.
Für eine detailliertere lokale Graphnavigation (Gliederung, unscharfe Überschriften, Linkreferenzen, Auflösen von Links), während ein Agent deine Dokumentation auf dem Datenträger ausgecheckt hat, verwende stattdessen markdown-lsp — führe npx markdown-lsp <subcommand> ./docs aus, um LSP-ähnliche doc_*-Werkzeuge im Arbeitsbaum bereitzustellen. Informationen zur Einrichtung findest du in der README von markdown-lsp. search_docs/write_docs und markdown-lsp ergänzen sich: Erstere arbeiten über die gehostete MCP-Verbindung ohne lokalen Checkout, Letztere benötigen das Repository auf dem Datenträger.
Die Issues im GitHub-Repository, aus dem Ihre Dokumentation erstellt wird – die offenen Arbeiten am Projekt. Hier überlebt eine Erkenntnis das Gespräch, aus dem sie hervorgegangen ist: Ein Agent, der Ihre Dokumentation gerade geprüft hat, kann festhalten, was er gefunden hat, anstatt es in einem Chatverlauf zu hinterlassen.
Dieselben drei Tools liest und schreibt der Bereich Issues im Admin-Panel, sodass ein aus Claude Code erstelltes Issue in dieser Tabelle angezeigt wird und umgekehrt.
Tool
Abrechnung
Beschreibung
list_issues
Lesen
Listet die Issues im Repository des Projekts auf – offene, geschlossene oder alle, optional nach Label gefiltert. Pull Requests werden niemals einbezogen. Nur lesend. Rufen Sie dieses Tool vor create_issue auf: Ein Issue, das ein offenes Issue dupliziert, ist schlechter als gar kein Issue.
get_issue
Lesen
Liest ein einzelnes Issue vollständig – den kompletten Inhalt, Labels, Status und Link. Nur lesend. Das Handeln auf Grundlage der 280 Zeichen umfassenden Vorschau, die list_issues zurückgibt, führt dazu, dass Sie die falsche Hälfte einer Anfrage umsetzen.
create_issue
Schreiben
Erstellt ein Issue im Repository des Projekts mit einem Titel, einem Markdown-Inhalt und Labels. Erfordert ein mit dem Bereich read-write autorisiertes Token – ein schreibgeschütztes Token wird abgelehnt. Ein Aufruf pro Issue. Gibt die Nummer und den Link des Issues zurück.
Die Issues einer von Docsbook gehosteten Website befinden sich in dem Repository, das Docsbook dafür hostet; eine aus Ihrem eigenen Repository erstellte Website verwendet dieses Repository, und ein MCP-Aufruf agiert dort über Docsbooks eigenes Konto – ausreichend, um ein öffentliches Repository zu lesen und darin ein Issue zu erstellen, und bei einem privaten Repository wird ein entsprechender Berechtigungsfehler statt einer leeren Liste ausgegeben.
Die Registrierung eines Webhooks ist kostenlos; nur ausgehende Zustellungen und Wiederholungen werden als Egress abgerechnet.
Werkzeug
Abrechnung
Beschreibung
register_webhook_<event>
Schreiben
Einen Webhook für eines der 18 typisierten Ereignisse registrieren (HMAC-Geheimnis + URL)
list_webhooks
Lesen
Registrierte Webhooks für den Workspace auflisten
unregister_webhook
Schreiben
Ein Webhook-Abonnement entfernen
list_webhook_deliveries
Analysen
Zustellungsverlauf mit Status, Anzahl der Wiederholungsversuche und Payload
replay_webhook_delivery
Egress
Eine bestimmte vergangene Zustellung erneut senden
test_webhook
Egress
Einen synthetischen Payload an eine URL senden
Es gibt 18 typisierte Ereignisse, darunter content.indexed, translation.completed, chat.no_answer, chat.negative_feedback und usage.limit_approaching — die vollständige Liste und die Payload-Schemas finden Sie unter Webhooks.
Durchsuchen Sie den docs-skills-Katalog nach query mit optionalen category- und requires_plan-Filtern. Gibt raw_url zurück, damit der Agent die SKILL.md direkt abrufen kann.
Aktionswerkzeuge — ein Arbeitsschritt, ein Werkzeug#
135 schreibgeschützte Werkzeuge. Jedes ist eine Aktion zu einem Thema, keine ganze Disziplin: observe_link_graph meldet die Verbindungen zwischen Ihren Seiten, decide_next_market wählt einen Markt aus und erklärt, warum nicht die anderen, draft_comparison_page schreibt die Seite. Der Aufrufer wählt einen Schritt, keine Abteilung.
Die Familie ist eine Kombination aus drei Achsen, und jedes Werkzeug gibt seine Position auf allen drei an:
Das Verb bestimmt die Form der Antwort und was der Durchlauf ablehnt.
Die Domäne bestimmt das Thema und die von ihr gelesenen Belege.
Das Ergebnis — Supportaufwand, organischer Traffic, KI-Zitate, Antwortzeit, Conversion und acht weitere — ist die Kennzahl, deren Veränderung mit diesem Werkzeug erreicht werden soll, und wird in der eigenen Beschreibung des Werkzeugs genannt.
Verb
Antwortet mit
Lehnt ab
observe_*
Was vorhanden ist, mit der Quelle jeder Zeile
Etwas zu empfehlen
explain_*
Der Mechanismus dahinter, nicht eine wiederholte Korrelation
Eine Geschichte, die es nicht auf einen konkreten Schritt zurückführen kann
discover_*
Was fehlt, spezifisch genug benannt, um es zu erstellen
„Mehr Inhalte über X“
decide_*
Eine Entscheidung, mit jeder Ablehnung und ihrem Grund
Eine Rangliste zurückzugeben, statt eine Entscheidung zu treffen
plan_*
Eine geordnete Abfolge, deren erster Schritt ein Aufruf ist
Über die erste Sache hinaus zu planen, die sie ungültig machen könnte
draft_*
Das Artefakt selbst, bereit zur Anwendung
Ein Briefing zurückzugeben und es als Entwurf zu bezeichnen
measure_*
Eine von uns berechnete, von Durchlauf zu Durchlauf vergleichbare Scorecard
Einen Score zu verfassen oder eine Lücke mit null zu füllen
verify_*
Ein Urteil im Vergleich zu einer Kontrolle, wobei „zu früh“ zulässig ist
Bei einem zu kurzen Zeitraum nach „bestätigt“ zu greifen
learn_*
Eine übertragbare Regel und der Punkt, an dem sie nicht mehr gilt
Eine Erkenntnis ohne Grenze
handoff_*
Den exakten Aufruf, seine Argumente und die Abnahmeprüfung
Arbeit, deren Abnahmetest es nicht benennen kann
Jedes liefert eine validierte JSON-Nutzlast statt eines Absatzes mit Prosa zurück: eine evidence-Karte, die jede vom Durchlauf gesammelte Rohinformation enthält, sowie Aussagen, die nur eine in den von ihnen zitierten Belegen vorkommende Zahl nennen dürfen. Eine Zahl, die sich auf nichts zurückführen lässt, lässt den Durchlauf scheitern, statt ausgeliefert zu werden — eine erfundene Zahl müssen Sie also nicht selbst überprüfen.
Wenn ein Werkzeug bewertet — die fünfzehn measure_*-Werkzeuge, eines pro Domäne —, wird der Score von uns anhand der gesammelten Belege berechnet, wobei seine Gewichtungen in der Nutzlast veröffentlicht sind, nicht vom Modell verfasst. Ein Wert von 0–100 eines Modells ist nicht mit dem Wert desselben Modells in der nächsten Woche vergleichbar, wodurch der einzige Grund für einen solchen Wert zunichtegemacht wird: seine Entwicklung zu beobachten. Eine Achse, die nicht überprüft werden konnte, wird als nicht gemessen und niemals als null gemeldet.
Alle 135 verändern nichts und arbeiten mit einem schreibgeschützten Token: Schreibvorgänge werden für den gesamten Durchlauf abgelehnt. Jedes von ihnen wird in der Agentenklasse abgerechnet. Das umfasst auch draft_*, das die Seite oder den Block erstellt und den Aufruf benennt, der ihn anwenden würde (run_docs_create / run_docs_manage), statt ihn selbst anzuwenden. Jede Zeile enthält diesen Aufruf, sodass eine Analyse ohne menschliche Übersetzung dazwischen übergeben werden kann.
Jedes wird anhand der von ihm deklarierten Arbeit bepreist — wie viele Belegfamilien es liest, wie viele Modell-Roundtrips es möglicherweise ausführt, ob es Ihre Website verlässt und ob es ein Artefakt ausgibt —, sodass eine schmale Beobachtung einen Bruchteil eines tiefgehenden Entwurfs kostet, statt dass jede Aktion denselben pauschalen Agentenpreis trägt. Die Wartezeit unterscheidet sich auf dieselbe Weise, und die typische Wartezeit ist unten für jedes Werkzeug aufgeführt. Der aktuelle Preis jedes Werkzeugs wird neben ihm im Panel und auf der Docsbook-Preisseite angezeigt.
Eine Zeile pro Funktion, die Ihr Produkt tatsächlich bereitstellt, neben der Seite, die sie dokumentiert – und das Leerfeld, wenn keine Seite existiert.
~41 s
explain_capability_confusion
Der Mechanismus dahinter, dass Leser nach etwas fragen, das das Produkt bereits kann – die genaue Formulierung, Platzierung oder Abwesenheit, durch die eine vorhandene Funktion unsichtbar wird.
~45 s
discover_undocumented_capabilities
Funktionen, die im Produkt existieren, aber nirgendwo in der Dokumentation auftauchen, jeweils so spezifisch benannt, dass ab morgen eine Seite dazu geschrieben werden kann.
~45 s
decide_capability_priority
Eine Funktion, die als Nächstes dokumentiert werden soll, mit jeder ernstzunehmenden Alternative und dem Grund, warum sie ausgeschieden ist.
~26 s
plan_capability_page_set
Die Menge an Seiten, die eine Funktion tatsächlich benötigt – und ebenso wichtig: die Seiten, die sie nicht benötigt –, in der Reihenfolge, in der sie geschrieben werden sollten.
~39 s
draft_capability_matrix
Eine fertige Seite mit Funktionsmatrix – jede Funktion, ihr Status, ihr Planungs-Gate und ihr Seitenlink – in Markdown, bereit zum Committen.
~52 s
measure_capability_coverage
Eine wiederholbare Bewertung darüber, wie viel des Produkts die Dokumentation tatsächlich abdeckt, anhand von fünf Achsen, die von unterschiedlichen Personen festgelegt werden.
~45 s
verify_capability_claims
Für jede Funktion, die in der Dokumentation behauptet wird, ein Urteil darüber, ob das Produkt dies weiterhin kann – mit der Quelle, die dies entscheidet.
~52 s
handoff_capability_backlog
Die Funktionsarbeit für die nächste ausführende Person aufbereitet: der genaue Aufruf, seine Argumente und woran sie erkennt, dass er funktioniert hat.
Die Aufgaben, die Leser mit ihren eigenen Worten formuliert haben – aus Fragen an den Assistenten und Suchanfragen –, gruppiert, gezählt und wörtlich zitiert.
~32 s
explain_job_abandonment
Wo eine Aufgabe nicht mehr abgeschlossen werden kann und welcher Mechanismus sie stoppt – der Schritt, die fehlende Voraussetzung oder der Satz, auf den Leser stoßen, bevor sie gehen.
~42 s
discover_unserved_jobs
Aufgaben, die Ihr Produkt erfüllen kann und auf die Ihre Dokumentation nirgends eingeht – vom Funktionsumfang ausgehend auf den Leser übertragen, denn eine Aufgabe, die nirgends erfüllt wird, hinterlässt keine messbare Spur.
~48 s
decide_primary_job
Die eine Aufgabe, um die diese Dokumentation organisiert sein sollte, mit den konkurrierenden Aufgaben und den Kosten jeder Ablehnung.
~32 s
plan_job_journey
Die geordnete Seitenfolge, die eine Aufgabe vom ersten Kontakt bis zum Abschluss führt, mit markierten Lücken in dieser Abfolge.
~33 s
draft_job_walkthrough
Die Walkthrough-Seite selbst, vollständig für eine Aufgabe verfasst, mit jeder angegebenen Voraussetzung und jedem überprüfbaren Schritt.
~55 s
measure_job_completion
Eine Übersicht darüber, ob Leser mit einer Aufgabe sie tatsächlich abschließen – Einstieg, Fortsetzung, Sackgassen, erklärte Ergebnisse und Rückkehr.
~39 s
verify_job_now_served
Ob die für eine Aufgabe verfassten Seiten tatsächlich verändert haben, was Leser tun – vorher, nachher, Zeitraum, Kontrollgruppe, Ergebnis.
~36 s
learn_job_patterns
Die Regel hinter den Aufgaben, die Ihre Dokumentation gut erfüllt, so formuliert, dass sie übertragbar ist – und die Grenze, jenseits derer sie nicht mehr gilt.
Jedes Thema, das dieser Korpus abdeckt, mit der Anzahl der Seiten, auf denen es behandelt wird, der Tiefe der am weitesten gehenden Seite und der Anzahl der Seiten, die darauf verlinken.
~32 s
explain_authority_shortfall
Warum dieser Korpus wie eine Website wirkt, die ein Thema erwähnt, statt wie die Website zu diesem Thema – mit der konkreten Lücke, die diesen Eindruck hervorruft.
~39 s
discover_missing_entities
Die Entitäten, die ein Thema voraussetzt, die dieser Korpus aber nie nennt – die Konzepte, Tools, Formate und Fehlerfälle, von denen ein Leser erwartet, dass eine echte Quelle sie kennt.
~39 s
decide_topic_cluster_focus
Das eine Themencluster, das als Nächstes aufgebaut werden sollte, mit den genannten Wettbewerbern und dem Grund, warum jeder einzelne verworfen wurde.
~32 s
plan_topic_cluster
Der Hub und seine Speichen: jede Seite, die das Cluster benötigt, worum sich jede einzelne kümmert, wie sie verlinkt werden und in welcher Reihenfolge sie geschrieben werden sollen.
~33 s
draft_topic_hub_page
Die Hub-Seite selbst, ausformuliert: die Definition, die Übersicht der Unterthemen und die Links, die das Cluster zu einem Graphen machen.
~46 s
measure_topical_depth
Ein wiederholbarer Wert dafür, ob der Korpus bei seinen Themen als Autorität wahrgenommen wird – Definition, Abdeckung, Beziehungen, Belege und Vernetzung.
~36 s
verify_cluster_effect
Ob ein aufgebautes Cluster tatsächlich etwas erreicht hat – Rankings, Besucher oder Zitate – im Vergleich zu einer Kontrollgruppe und innerhalb eines festgelegten Zeitraums.
~36 s
learn_authority_wins
Die Regel hinter den Themen, bei denen diese Website tatsächlich gewonnen hat – was diese Seiten hatten, das den anderen fehlte, und wo die Regel nicht mehr gilt.
Die Suchanfragen, über die diese Website gefunden wird, sortiert nach der jeweiligen Suchintention — Anleitung, Definition, Vergleich, Fehler, Preis, Referenz.
~32 s
explain_intent_mismatch
Warum eine Seite, die gut rankt, den Leser trotzdem verliert — die konkrete Lücke zwischen der Form der Frage und der Form der Seite.
~36 s
discover_intent_gaps
Suchintentionen, mit denen Leser nachweislich ankommen und die keine Seite dieser Website gezielt beantwortet.
~36 s
decide_page_shape
Was EINE Seite sein muss — Tutorial, Anleitung, Referenz, Erklärung oder Vergleich — angesichts der Suchintentionen, die sie tatsächlich erreichen, einschließlich der verworfenen Formen.
~26 s
plan_intent_coverage
Die geordnete Gruppe von Seiten, die die Suchintentionen abdecken würde, die diese Website anzieht — jede Seite auf genau eine davon ausgerichtet.
~30 s
draft_intent_matched_opening
Der überarbeitete Titel, die Beschreibung und der erste Bildschirm einer Seite, abgestimmt auf die Suchintention, für die sie tatsächlich rankt — ausformuliert und sofort umsetzbar.
~39 s
measure_intent_match
Eine Bewertungsübersicht darüber, wie gut die Seiten, die den Lesern angezeigt werden, zu den Suchintentionen passen, mit fünf aus Beobachtungen berechneten Dimensionen.
~36 s
verify_intent_fix
Ob eine suchintentionsbasierte Überarbeitung tatsächlich Klicks oder Interaktionen verändert hat — unter Berücksichtigung einer Kontrollgruppe und der Verzögerung bei den Suchdaten.
~36 s
handoff_intent_rewrites
Die Überarbeitungen nach Suchintention als Aufgaben formuliert: welche Seite, worin sie geändert werden soll und welche Suchanfrage die Änderung gewinnen muss.
Die URL-Muster auf dieser Website, die sich bereits entlang einer Achse wiederholen, einschließlich der Anzahl vorhandener Einträge und der tatsächlichen Größe der Achse.
~26 s
explain_thin_family_pages
Warum die generierten Einträge einer Familie unterdurchschnittlich abschneiden – das Feld, das bei den meisten leer, identisch oder erfunden ist.
~36 s
discover_scalable_patterns
Wiederkehrende Suchmuster, die dieses Produkt in großem Maßstab beantworten könnte – die Achse, die Abfragevorlage und die eindeutige Information, die jeder Eintrag enthalten würde.
~48 s
decide_family_worth_building
Ein einziges Urteil darüber, ob eine vorgeschlagene Familie erstellt werden sollte, mit den genannten Alternativen und der von vornherein festgelegten Abbruchbedingung.
~30 s
plan_family_rollout
Der Ausrollplan: welche Einträge zuerst veröffentlicht werden, welche Daten sie versorgen, welche Schutzmaßnahmen gelten und wo der Prüfpunkt liegt.
~42 s
draft_family_template
Das Template selbst – das Seitengrundgerüst, die Variablen pro Eintrag und zwei vollständig gerenderte Beispiel-Einträge.
~58 s
measure_family_coverage
Ein Bewertungsschema je Familie: wie viel von der Achse abgedeckt ist, wie unterschiedlich die Einträge sind, wie gut sie verknüpft sind und wie aktuell ihre Fakten sind.
~32 s
verify_family_indexation
Ob die generierten Einträge tatsächlich erreichbar und indexiert sind – live abgerufen, wobei die nicht erreichbaren oder nicht indexierten Einträge einzeln benannt werden.
~45 s
learn_family_thresholds
Die Schwelle auf dieser Website, ab der ein generierter Eintrag überhaupt einen Nutzen bringt – als Regel formuliert, mit den zugrunde liegenden Fällen.
Die Anfragen, die Leser bereits stellen und die wie ein Tool aufgebaut sind – berechnen, umrechnen, validieren, generieren, prüfen – zitiert und gezählt.
~32 s
explain_tool_underuse
Warum ein bestehendes kostenloses Tool nicht genutzt wird – der Einstieg, die Hürde oder die fehlende Übereinstimmung, die Leser davon abhält, es zu erreichen oder vollständig zu nutzen.
~45 s
discover_tool_ideas
Kostenlose Tools, die dieses Produkt glaubwürdig anbieten könnte, jeweils mit der Suchanfrage, die sie beantworten würden, und den Daten, die dies ermöglichen.
~48 s
decide_tool_to_build
Ein zu entwickelndes Tool, der Rest mit Begründungen abgelehnt, sowie die Wartungskosten des ausgewählten Tools, bevor überhaupt jemand beginnt.
~39 s
plan_tool_launch
Der Launch: wo das Tool zu finden ist, welche Links darauf verweisen, was es dem Leser anschließend bietet und wie sein Erfolg bewertet wird.
~33 s
draft_tool_page
Die Seite des Tools, ausformuliert: was es im sichtbaren Bereich leistet, das ausgearbeitete Beispiel, die verwendete Methode und der nächste Schritt – plus die Einbettungsspezifikation für das Widget selbst.
~58 s
measure_tool_pull
Eine Übersicht darüber, was ein Tool tatsächlich bewirkt – Zugriffe, Abschlüsse, weiterführende Aktionen, gewonnene Links und eigenständige Lesbarkeit.
~32 s
verify_tool_traffic
Ob der Launch des Tools etwas Messbares verändert hat – im Vergleich zu einer Kontrollgruppe, über einen festgelegten Zeitraum und mit einem Ergebnis, das auch „zu früh“ lauten kann.
~32 s
handoff_tool_build
Die Spezifikation des Tools für die Person, die es entwickelt: Eingaben, Regeln, Ausgaben, Sonderfälle und die Abnahmeprüfung, die es bestehen muss.
Die Daten, über die dieses Produkt bereits verfügt und die niemand außerhalb davon berechnen kann – was sie abdecken, wie weit sie zurückreichen und ob sie überhaupt veröffentlicht werden können.
~41 s
explain_research_ignored
Warum eine veröffentlichte Studie keine Zitate erhalten hat – die fehlende Methode, das nicht zitierfähige Format oder die fehlende Aussage, die jemand hätte wiederholen können.
~48 s
discover_research_questions
Fragen, die Ihre eigenen Daten beantworten könnten und die sonst niemand beantworten kann, jeweils mit dem Datenausschnitt, der sie beantworten würde, und dem Publikum, das sie wiederholen würde.
~45 s
decide_research_to_publish
Eine durchzuführende Studie, mit den verworfenen Fragen und dem ehrlichen Risiko: Was passiert, wenn die Antwort langweilig ist?
~30 s
plan_research_release
Die Veröffentlichung: der auszuführende Datenausschnitt, die zu beschreibende Methode, die zu veröffentlichenden Materialien und der Turnus, der sie im nächsten Jahr wiederholbar macht.
~33 s
draft_research_report
Der Bericht selbst: die zentrale Aussage in einem zitierfähigen Satz, die Zahlen mit ihren Nennern, die Methode und die Einschränkungen.
~68 s
measure_research_citations
Eine Bewertung, wie zitierfähig die veröffentlichte Forschung tatsächlich ist – zitierfähige Aussage, angegebene Methode, zugängliche Daten, Datierung und maschinelle Lesbarkeit.
~45 s
verify_research_claims
Ob jede veröffentlichte Zahl noch Bestand hat, wenn derselbe Datenausschnitt erneut ausgeführt wird – mit einzeln benannten Abweichungen.
~39 s
learn_research_formats
Die Regel dahinter, welche Ihrer veröffentlichten Beiträge wiederholt wurden – das Format, die Form der Aussage oder das Veröffentlichungsmuster – und wo sie nicht mehr gilt.
Was Antwortmaschinen derzeit über dieses Produkt sagen und welche Quelle sie dafür verwendet haben – mit Zitat, Datum und den Fragen, die dies hervorgebracht haben.
~46 s
explain_citation_absence
Warum diese Dokumentation nicht die Quelle ist, die ein Assistent zitiert – die konkrete Eigenschaft der Seite, die sie unzitierbar macht.
~48 s
discover_quotable_atoms
Die in sich geschlossenen Passagen, die dieser Korpus enthalten sollte, aber nicht enthält – eine Frage, eine vollständige Antwort, zitierfähig ohne ihren Kontext.
~39 s
decide_geo_surface_priority
Welche maschinenlesbare Oberfläche zuerst korrigiert werden sollte – Seitenstruktur, llms.txt, strukturierte Daten, Feeds oder Crawler-Zugriff – wobei der Rest eingestuft und verworfen wird.
~39 s
plan_geo_surfaces
Die geordnete Arbeit an den maschinenlesbaren Oberflächen, jeder Schritt mit der Einstellung oder Seite, die er betrifft, und der Prüfung, die den erfolgreichen Abschluss bestätigt.
~39 s
draft_answer_blocks
Die zitierfähigen Passagen selbst – Frage, vollständige Antwort, Quelle und Datum –, so formuliert, dass sie vollständig übernommen werden können und dennoch korrekt bleiben.
~55 s
measure_ai_visibility
Eine Bewertung, wie präsent dieses Produkt in Antwortmaschinen ist – Präsenz, Genauigkeit, Zuordnung, Aktualität und Anteil der abgedeckten Fragen.
~48 s
verify_citation_gain
Ob die GEO-Arbeit verändert hat, was Assistenten sagen – dieselben Fragen, die vorher und nachher gestellt wurden, mit wörtlich verglichenen Antworten.
~45 s
learn_citation_patterns
Die Regel dahinter, welche Ihrer Seiten zitiert werden – die Form, die Position der Antwort, die Datierung – einschließlich ihrer Grenze.
Was die Dokumentation eines namentlich genannten Wettbewerbers tatsächlich enthält – Abschnitte, Seitentypen und was sie dokumentiert, Sie aber nicht – abgerufen und datiert.
~46 s
explain_switching_objections
Der konkrete Einwand, den ein Bewerter beim Lesen beider Dokumentationen entwickelt – und die Seite und der Satz Ihrer Dokumentation, die ihn hervorrufen.
~48 s
discover_market_gaps
Bedürfnisse, die weder Sie noch die genannten Wettbewerber abdecken – mit dem Nachweis, dass jemand diesen Bedarf hat und niemand darauf eingeht.
~52 s
decide_positioning_wedge
Der eine Vergleich, zu dem dieses Produkt einladen sollte, sowie die Vergleiche, die es ablehnen sollte, und der Grund für jede Ablehnung.
~33 s
plan_comparison_pages
Die lohnenswerten Vergleichsseiten, was jede enthalten muss, um glaubwürdig zu sein, und in welcher Reihenfolge sie erstellt werden sollten.
~39 s
draft_comparison_page
Die Vergleichsseite selbst, verfasst auf Grundlage abgerufener Nachweise – jeder Anspruch über die andere Seite datiert und mit einer Quelle versehen, auch diejenigen, bei denen sie gewinnt.
~58 s
measure_competitive_coverage
Eine Bewertung, wie Ihre Dokumentation im Vergleich zu namentlich genannten Wettbewerbern auf den von Bewertern tatsächlich geöffneten Bereichen abschneidet.
~48 s
verify_competitor_claims
Ob die Aussagen Ihrer Seiten über Wettbewerber heute noch zutreffen – jede einzelne erneut abgerufen, wobei die veralteten benannt werden.
~42 s
learn_competitor_moves
Was sich seit dem letzten Blick aufseiten der Wettbewerber geändert hat und welches Muster hinter den Änderungen steckt – formuliert als das, worauf als Nächstes zu achten ist.
Die Wörter, die Leser tatsächlich eingeben und fragen – wörtlich und gezählt –, neben dem Wort, das Ihre Dokumentation für dasselbe verwendet.
~29 s
explain_term_misses
Warum ein Leserwort keine Ergebnisse liefert – und welche der zwei sehr unterschiedlichen Ursachen vorliegt: ein anders benanntes Konzept oder ein Konzept, das vollständig fehlt.
~36 s
discover_missing_synonyms
Die alternativen Bezeichnungen für Konzepte, die Sie bereits dokumentieren, die jedoch im Korpus nirgends vorkommen – jeweils mit der Seite, die sie enthalten sollte.
~32 s
decide_canonical_terms
Ein kanonischer Name pro Konzept, wobei die abgelehnten Namen als Synonyme beibehalten und nicht gelöscht werden, einschließlich des Grundes für jede Entscheidung.
~30 s
plan_terminology_migration
Der geordnete Plan, um eine Benennungsentscheidung im gesamten Korpus umzusetzen, einschließlich der Seiten, die unverändert bleiben müssen, und der Gründe dafür.
~30 s
draft_glossary_entries
Die Glossareinträge selbst – jedes Konzept in einem Satz definiert, den ein Neuling verwenden kann, mit seinen Synonymen und der Seite, auf der es geführt wird.
~52 s
measure_vocabulary_alignment
Eine Bewertung, wie stark die Sprache des Korpus von der Sprache der Leser abweicht – die Abdeckung ihrer Begriffe, die Konsistenz unserer Begriffe und wie viel davon durch die Suche aufgelöst wird.
~32 s
verify_renaming_effect
Ob das Hinzufügen der Wörter der Leser die Fehler tatsächlich reduziert hat – dieselben Suchanfragen vorher und nachher, mit einer Kontrolle.
~32 s
handoff_term_changes
Die Benennungsarbeit als konkrete Handlungsaufforderungen aufbereitet: welche Seite, welches Wort zu welchem wird und welche Suche danach nicht mehr fehlschlagen darf.
Die Struktur des Korpus, wie sie tatsächlich ist: Abschnitte, Tiefe pro Zweig, Seitengrößen und wie viel davon die deklarierte Navigation tatsächlich erreicht.
~26 s
explain_navigation_failure
Warum Leser Dinge nicht finden können – die konkrete Diskrepanz zwischen dem von Ihnen deklarierten Baum und den Routen, denen Leser tatsächlich folgen.
~42 s
discover_orphan_pages
Seiten, auf die nirgendwo verlinkt wird, und Seiten, die Leser erreichen und nicht verlassen können – die beiden Enden des Korpus, die innerhalb des Baums unsichtbar sind.
~32 s
decide_structure_model
Das Organisationsprinzip, nach dem dieser Korpus aufgebaut sein sollte – nach Aufgabe, Produktbereich, Seitentyp oder Zielgruppe – einschließlich der verworfenen Modelle und ihrer Kosten.
~36 s
plan_restructure
Die Umzugsliste: Welche Seite wohin verschoben wird und in welcher Reihenfolge, wobei jede URL-Änderung und die dafür erforderliche Weiterleitung als eigene Zeile angegeben werden.
~39 s
draft_navigation_tree
Die Navigation selbst, ausgeschrieben – der vollständige Baum mit Bezeichnungen in den Worten der Leser, bereit zur Umsetzung.
~42 s
measure_findability
Eine Bewertung darüber, ob ein Leser von seinem Einstiegsort zu dem gelangt, was er benötigt – Erreichbarkeit, Tiefenbalance, Orientierung, Einstiegspunkte und Suchalternative.
~39 s
verify_restructure_effect
Ob eine Neustrukturierung geholfen hat – dieselben Auffindbarkeits- und Verhaltensmesswerte vor und nach der Änderung, mit überprüften Weiterleitungen und einem Kontrollabschnitt.
~45 s
learn_structure_lessons
Die Regel hinter den funktionierenden Abschnitten dieses Korpus – wie sie gruppiert sind, wie tief sie reichen, wie sie beginnen – und wo sie nicht mehr gilt.
Das Korpus als Graph: welche Seiten auf welche verlinken, wie viele eingehende und ausgehende Kanten jede Seite hat und welche Seiten der Graph als zentrale Knoten betrachtet.
~29 s
explain_unreachable_pages
Warum eine Seite in der Praxis nicht erreichbar ist – die fehlende Kante, der Link, dem niemand folgt, oder der Ankertext, der keinen Grund zum Klicken liefert.
~36 s
discover_missing_links
Seitenpaare, die dieselbe Entität behandeln und nicht aufeinander verlinken – jeweils mit dem Satz, in den der Link gehört.
~39 s
decide_hub_pages
Welche Seiten zu zentralen Knoten werden – also zu Seiten, auf die alles andere verweist – einschließlich der verworfenen Kandidaten und der Gründe dafür.
~30 s
plan_linking_pass
Der Verlinkungsdurchlauf: welche Seiten bearbeitet werden, in welcher Reihenfolge, wie viele Links jede Seite erhält und die Regel, die verhindert, dass daraus Link-Spam wird.
~30 s
draft_link_insertions
Die exakten Änderungen: für jede Seite der Satz, wie er nach dem Einfügen des Links lautet, einschließlich Ankertext und Ziel.
~46 s
measure_graph_health
Eine Bewertung des Link-Graphen – Vernetztheit, Konzentration auf zentrale Knoten, clusterübergreifende Verlinkung, Qualität der Ankertexte und wie viele Seiten allein von der Navigation abhängen.
~36 s
verify_link_effect
Ob ein Durchlauf zur internen Verlinkung etwas verändert hat – Zugriffe auf die verlinkten Seiten, Anteil der Sackgassen und Rankings im Vergleich zu einer Kontrollgruppe.
~36 s
handoff_link_edits
Die Linkänderungen pro Seite als Aufrufe gebündelt, mit einer Akzeptanzprüfung, angegeben als Zugriff oder Anzahl eingehender Links.
Welche Glaubwürdigkeitsbelege die Seiten tatsächlich enthalten — Autoren, Daten, Quellen, Zahlen mit Nennern, ausgearbeitete Beispiele, ausdrücklich genannte Grenzen — Seite für Seite.
~32 s
explain_disbelief
Warum ein Leser einer Seite nicht glaubt, die sachlich korrekt ist — die unbelegte Zahl, die nicht genannte Grenze oder die Behauptung, die nur du aufstellst.
~45 s
discover_unsourced_claims
Jede Behauptung auf den kommerziell wichtigen Seiten, die keine Quelle, keinen Nenner und kein Datum enthält — einzeln aufgelistet.
~35 s
decide_evidence_standard
Welche Belege jede Behauptungsklasse vor der Veröffentlichung erbringen muss — einmal entschieden, einschließlich der verworfenen Standards und ihrer Kosten.
~29 s
plan_trust_upgrade
Die priorisierte Arbeit, die die Seiten auf den Belegstandard bringt, beginnend mit den Seiten, in die tatsächlich Vertrauen investiert wird.
~30 s
draft_evidence_blocks
Die überarbeiteten Behauptungen selbst — jeweils mit Quelle, Nenner, Datum und der daneben genannten Einschränkung.
~55 s
measure_trust
Eine Bewertung der Glaubwürdigkeit entlang fünf Achsen — Überprüfbarkeit zuerst, weil sie die eine ist, die ein Wettbewerber nicht an einem Nachmittag kopieren kann.
~45 s
verify_claim_freshness
Ob jede datierte oder numerische Behauptung heute noch stimmt — erneut anhand ihrer Quelle geprüft, wobei die veralteten einzeln genannt werden.
~48 s
learn_trust_objections
Das wiederkehrende Einwandmuster in allem, was Leser bezweifelten — als Regel formuliert, was diese Zielgruppe belegt haben muss.
Wer derzeit öffentlich auf dieses Produkt verweist, was diese Person oder Quelle sagt und ob es sich bei dem Verweis um einen Link, eine Erwähnung oder ein Zitat handelt.
~42 s
explain_unlinkable_pages
Warum niemand auf eine Seite verlinkt – was ihr fehlt, das eine Person, die über dieses Thema schreibt, benötigt hätte.
~45 s
discover_link_targets
Konkrete Orte, die plausibel auf dieses Produkt verweisen würden – jeweils mit der Seite, auf die sie verlinken würden, und dem Grund, warum sie sich die Mühe machen würden.
~51 s
decide_linkable_asset
Das eine Asset, das für Verweise erstellt werden sollte – Daten, ein Tool, eine Definition oder ein Argument – einschließlich der verworfenen Optionen und der Gründe, warum sie unterlegen sind.
~39 s
plan_outreach_sequence
Der Outreach-Plan in geordneten Zeilen: wer angesprochen wird, in welcher Reihenfolge, womit und unter welcher Abbruchbedingung.
~42 s
draft_outreach_pitch
Die Nachricht selbst, für jedes Ziel formuliert – worauf sie sich bezieht, was sie anbietet und um genau eine Sache bittet.
~51 s
measure_linkability
Eine Bewertung, wie gut dieses Korpus als Quelle für Verweise geeignet ist – einzigartige Fakten, adressierbare Abschnitte, zitierfähiges Format, Aktualität und Dauerhaftigkeit der URLs.
~45 s
verify_mention_gain
Ob nach der Arbeit tatsächlich neue Verweise aufgetaucht sind – erneut gesucht, mit dem früheren Datensatz verglichen und ergänzt um den Referral-Traffic.
~42 s
handoff_pr_targets
Der für eine Person aufbereitete Outreach: Ziel, deren Seite, die formulierte Nachricht, die Bitte und die Bedeutung einer Antwort.
Woher die Leser bereits kommen – Länder, Sprachen, Verweise – und wie unterschiedlich sich die einzelnen Gruppen hier verhalten.
~32 s
explain_market_stall
Warum ein Markt, der Besucher bringt, nicht konvertiert – die Sprache, das Beispiel, die Preisannahme oder der fehlende Nachweis, der ihn davon abhält.
~42 s
discover_adjacent_markets
Zielgruppen, die dieses Produkt bedienen könnte, die es aber überhaupt nicht erreicht – jeweils mit dem Nachweis, dass der Bedarf besteht, und der Hürde, die überwunden werden müsste.
~48 s
decide_next_market
Ein Markt, in den als Nächstes eingestiegen werden soll, während die übrigen abgelehnt werden, und die laufenden Kosten dieser Entscheidung, bevor sich jemand festlegt.
~36 s
plan_market_entry
Der Einstiegsplan: Welche Seiten zuerst erstellt werden, was über die Sprache hinaus lokalisiert werden muss und der Prüfpunkt, an dem über die Fortsetzung entschieden wird.
~33 s
draft_market_landing
Die Landingpage des Marktes, in seiner Sprache verfasst, mit seinen Beispielen, seiner Währung und dem Nachweis, den dieser Markt verlangt.
~46 s
measure_market_readiness
Eine Bewertung, ob die Dokumentation für einen Markt bereit ist – Abdeckung, Lokalisierung über die Sprache hinaus, Nachweise, Auffindbarkeit und Pflege.
~36 s
verify_market_traction
Ob der Eintritt in den Markt etwas verändert hat – Besucherzahlen, Ergebnisse und Erträge aus diesem Markt im Vergleich zu einer Kontrollgruppe und innerhalb eines festgelegten Zeitraums.
~36 s
learn_expansion_lessons
Die Regel hinter den Märkten, die hier funktioniert haben – was für sie getan wurde, was für die anderen nicht getan wurde – einschließlich ihrer Grenze.
~32 s
Die meisten akzeptieren eine optionale request in Ihren eigenen Worten, die den Durchlauf eingrenzt, ohne die Methode zu ersetzen, sowie die typisierten Eingaben, die ihre Frage benötigt (path, path_prefix, pages, competitors, window_days). Eine Nutzlast, die ihren eigenen Vertrag nicht erfüllt, wird als Fehler mit aufgeführten Verstößen gemeldet – niemals als erfolgreiche Antwort mit leerem Ergebnis, weil „keine Ergebnisse“ als „die Website ist in Ordnung“ verstanden wird.
Fünf Tools gehören zu dieser Familie und verfügen über eine eigene günstigere Abrechnungsklasse, Probe: collect_page_text, collect_corpus_map, collect_assistant_questions, collect_traffic und collect_onsite_search. Sie geben die normalisierten Zeilen zurück, die eine Aktion gelesen hätte, plus einen reproduce-Block, der die exakten Aufrufe hinter jeder Zeile benennt — kein Modell im Ablauf, daher gibt es darin nichts, was man anzweifeln müsste. Kaufen Sie eines, wenn Sie die Zahlen haben möchten, bevor Sie entscheiden, ob Sie auch deren Auswertung kaufen. audit_geo ist ebenfalls aus der vorherigen Generation erhalten geblieben: Seine Nachweisschicht besteht aus Code statt aus einem Modell und beantwortet die Frage, ob Antwortmaschinen Ihre Seiten überhaupt abrufen können.
find_skill übergibt Ihrem eigenen Agenten die SKILL.md zur Ausführung. Diese Tools tun das Gegenteil: Sie führen den Skill auf der Seite von Docsbook für Ihren Arbeitsbereich mit dem vollständigen administrativen Toolset aus, für das der Skill geschrieben wurde — so kann auch ein Assistent, mit dem keine weiteren Docsbook-Tools verbunden sind, die Aufgabe erledigen.
Jeder Aufruf von run_docs_* gibt sofort { run_id, state } zurück. Er gibt nicht das Ergebnis zurück — die Ausführung dauert Minuten, und ein Aufrufer, der den Start als Antwort meldet, berichtet über eine noch nicht erfolgte Arbeit. Fragen Sie get_agent_run mit der zurückgegebenen run_id ab.
Tool
Abrechnung
Beschreibung
run_docs_analyze
Agent
Führt den docs-analyze-Skill aus: Prüft die Website anhand realer Zahlen und meldet, was nicht stimmt und welche Kosten dadurch entstehen. Als Prüfmodus deklariert — Schreibvorgänge werden während der gesamten Ausführung abgelehnt, sodass das Tool mit einem schreibgeschützten Token funktioniert.
run_docs_create
Agent
Führt den docs-create-Skill aus: Erstellt Dokumentation aus Ihrer Website, einem Repository, einer anderen Dokumentationsplattform oder nur aus einem Produktnamen. Überträgt Seiten per Commit — benötigt ein Lese-/Schreib-Token.
run_docs_manage
Agent
Führt den docs-manage-Skill aus: Überarbeitet Seiten und konfiguriert die Website gemäß dem Regelwerk für das Schreiben und Betreiben von Websites. Benötigt ein Lese-/Schreib-Token.
run_docs_automate
Agent
Führt den docs-automate-Skill aus: Richtet Überwachung auf Abweichungen, Ereignisabonnements, Prüfungen eingehender Änderungen, Warnungen und dauerhaft laufende Überwachungen ein. Benötigt ein Lese-/Schreib-Token.
get_agent_run
Lesen
Status einer einzelnen Ausführung (queued, running, succeeded, failed, canceled, expired), Live-Fortschritt während der Ausführung und nach erfolgreichem Abschluss das vollständige Ergebnis: der Bericht, jede durchgeführte Aktion und die Änderungen an der Website.
list_agent_runs
Lesen
Ihre letzten Ausführungen, die neuesten zuerst. Verwenden Sie dies, um zu prüfen, ob der Auftrag bereits ausgeführt wird, bevor Sie einen zweiten starten.
cancel_agent_run
Lesen
Beendet eine noch nicht abgeschlossene Ausführung. Dadurch werden die bereits vorgenommenen Änderungen nicht rückgängig gemacht — Seiten, die bereits per Commit übertragen wurden, bleiben übertragen.
Eine Ausführung gehört zu dem Konto, das sie gestartet hat: run_id eines anderen Kontos liefert genau dasselbe Ergebnis wie bei einem unbekannten. Eine eingereiht Ausführung, die nicht innerhalb weniger Stunden gestartet wurde, läuft ab, statt verspätet ausgeführt zu werden, da eine Prüfung eine Frage über den Zustand der Website zum Zeitpunkt ihrer Abfrage beantwortet. Eine Ausführung wird einmal versucht und nie wiederholt — eine fehlgeschlagene Ausführung kann bereits Seiten per Commit übertragen haben, und ein zweiter Versuch würde sie doppelt übertragen.
Die oben genannten Tools werden einmalig auf Anfrage ausgeführt. Diese beiden richten eine dauerhaft laufende Route ein, die selbstständig ausgeführt wird – nach einem Zeitplan, bei einem von diesem Workspace ausgegebenen Ereignis oder bei neuen Commits in einem verbundenen Repository – denselben Katalog, den die Registerkarte „Agents“ im Adminbereich anzeigt und aktiviert.
Tool
Abrechnung
Beschreibung
find_agent
Lesen
Durchsuche den Katalog der Routen, die dieser Workspace anhand des gewünschten Ergebnisses aktivieren kann („die Dokumentation mit dem Repository synchron halten“, „übersetzen“, „den Datenverkehr überwachen“). Jedes Ergebnis enthält state – also ob dieser Workspace die Route bereits aktiviert hat und wodurch –, sodass du erkennen kannst, ob „niemand überwacht das Repository“ oder „aktiviert und seit Dienstag fehlerhaft“ zutrifft. Rufe es auf, bevor du vorschlägst, etwas manuell einzurichten: Die Route ist normalerweise bereits vorhanden.
enable_agent
Schreiben
Aktiviere (oder deaktiviere) einen Agenten aus dem Katalog von find_agent anhand seiner agent_key. Ausgelöst wird er durch genau eines von schedule (einen Cron-Ausdruck, mit höchstens stündlicher Ausführung), on_event (etwas, das dieser Workspace ausgibt) oder watch_source_id (ein verbundenes GitHub-Repository aus list_sources/connect_source – der Agent wird bei den dorthin übertragenen Commits ausgeführt). Beim Aktivieren für ein Repository wird dessen aktueller Commit gespeichert, sodass die erste Ausführung beim nächsten Push erfolgt und nicht als Wiederholung der gesamten Historie. enabled: false deaktiviert ihn, ohne zu vergessen, wie er konfiguriert wurde. Erfordert ein Lesen-Schreiben-Token.
