MCP-Server

Der branchly MCP-Server (Model Context Protocol) stellt deine branchly-Anwendung für KI-Coding-Assistenten, -Plattformen und -Agenten bereit (z. B. ChatGPT, Claude, Langdock, OpenCode, Claude Code). Sobald die Verbindung hergestellt ist, kann ein KI-Agent deine Wissensbasis lesen und schreiben, Prompts sowie KI-Aktionen verwalten und Sitzungsdaten einsehen – vollständig programmatisch.

Einrichtung

Der MCP-Server ist an eine einzelne Anwendung gebunden. Je nach verwendetem Client erfolgt die Authentifizierung entweder über einen API-Key oder über OAuth.

ChatGPT

ChatGPT ermöglicht die Anbindung benutzerdefinierter MCP-Server, sodass ChatGPT direkten Zugriff erhält, um deine branchly-Anwendung zu analysieren und zu verwalten.

Anwendungsspezifische URL & OAuth ChatGPT authentifiziert sich bei deiner branchly-Anwendung über OAuth. Die Server-URL erfordert deine spezifische Application ID:

https://api.branchly.io/mcp/{application_id}

Ersetze {application_id} durch die ID deiner branchly-Anwendung, die du in der URL oder den Einstellungen deines branchly-Dashboards findest (z. B. https://api.branchly.io/mcp/b8f72a41-6d38-4e92-a9b7-1c3f58a9e204).

Befolge diese Schritte, um den branchly MCP-Server in ChatGPT zu verbinden und zu konfigurieren:

Schritt 1: Benutzerdefinierten MCP-Server hinzufügen

Wähle in ChatGPT in der linken Seitenleiste Plugins. Klicke oben rechts auf das Dropdown Hinzufügen (Add) und wähle Benutzerdefinierten MCP-Server hinzufügen (Add custom MCP server).

Navigiere zu Plugins, öffne das Dropdown „Hinzufügen“ und wähle „Benutzerdefinierten MCP-Server hinzufügen“.

Schritt 2: MCP-Server-Details und OAuth konfigurieren

Im Modal Benutzerdefinierten MCP-Server hinzufügen:

1. Name: Gib einen Namen ein (z. B. branchly).
2. Beschreibung (optional): Gib eine kurze Beschreibung an (z. B. branchly ist die KI-Schicht für deine Website).
3. Verbindung (Connection): Wähle Server-URL.
4. Server-URL: Gib deine anwendungsspezifische URL ein: https://api.branchly.io/mcp/{application_id}.
5. Authentifizierung (Authentication): Wähle OAuth.
6. Aktiviere das Bestätigungs-Kontrollkästchen für den Zugriff des benutzerdefinierten MCP-Servers („Ich habe das verstanden und möchte weitermachen“ / „I understand and wish to proceed“).
7. Klicke auf Als Plugin erstellen (Create as plugin).

Gib die MCP-URL deiner Anwendung ein, wähle OAuth, bestätige den Hinweis und klicke auf „Als Plugin erstellen“.

Schritt 3: Verbindung initiieren

Ein Bestätigungsfenster zum Verknüpfen von branchly erscheint. Klicke auf branchly verbinden ↗ (Connect branchly), um den OAuth-Authentifizierungsflow zu starten.

Klicke auf „branchly verbinden“, um die OAuth-Authentifizierung zu starten.

Schritt 4: ChatGPT in branchly autorisieren

Du wirst auf die branchly-Autorisierungsseite weitergeleitet:

1. Bestätige die zu verbindende branchly-Organisation oder -Anwendung.
2. Überprüfe die angeforderten Berechtigungen (Identität verifizieren, E-Mail-Adresse, grundlegende Profilinformationen und Organisationsmitgliedschaft).
3. Klicke auf Erlauben (Allow), um die Verbindung zu autorisieren.

Nach der Autorisierung wirst du zurück zu ChatGPT geleitet. Der branchly MCP-Server ist nun verbunden und steht in deinen ChatGPT-Unterhaltungen bereit.

Überprüfe die angeforderten Berechtigungen und klicke auf „Allow“, um ChatGPT zu autorisieren.

Claude

Claude ermöglicht die Anbindung benutzerdefinierter MCP-Server über Konnektoren (Connectors), sodass Claude direkten Zugriff erhält, um deine branchly-Anwendung zu analysieren und zu verwalten.

Anwendungsspezifische URL & OAuth Claude authentifiziert sich bei deiner branchly-Anwendung über OAuth. Die Server-URL erfordert deine spezifische Application ID:

https://api.branchly.io/mcp/{application_id}

Ersetze {application_id} durch die ID deiner branchly-Anwendung, die du in der URL oder den Einstellungen deines branchly-Dashboards findest (z. B. https://api.branchly.io/mcp/b8f72a41-6d38-4e92-a9b7-1c3f58a9e204).

Befolge diese Schritte, um den branchly MCP-Server in Claude zu verbinden und zu konfigurieren:

Schritt 1: Benutzerdefinierten Konnektor hinzufügen

Navigiere in Claude in der linken Seitenleiste zu Anpassungen (Customizations) und wähle den Tab Konnektoren (Connectors). Klicke oben rechts auf das Dropdown + Hinzufügen (+ Add) und wähle Benutzerdefinierten Konnektor hinzufügen (Add custom connector).

Navigiere zu Anpassungen → Konnektoren, öffne das Dropdown „Hinzufügen“ und wähle „Benutzerdefinierten Konnektor hinzufügen“.

Schritt 2: Konnektor-Details konfigurieren

Im Modal Benutzerdefinierten Konnektor hinzufügen (Add custom connector):

1. Name: Gib einen Namen ein (z. B. branchly MCP).
2. Server-URL: Gib deine anwendungsspezifische URL ein: https://api.branchly.io/mcp/{application_id}.
3. Klicke auf Weiter (Next).

Gib den Namen des Konnektors und deine anwendungsspezifische MCP-URL ein und klicke anschließend auf „Weiter“.

Schritt 3: Authentifizierung und OAuth-Client konfigurieren

Claude erkennt die Fähigkeiten des Servers automatisch und konfiguriert die Verbindungseinstellungen vor:

1. Authentifizierung (Authentication): Wähle Jetzt anmelden (Erkannt) (Log in now (Detected)), sodass sich jeder Benutzer über den OAuth-Flow des Servers authentifiziert, bevor er auf Tools und Ressourcen zugreift.
2. OAuth-Client: Wähle Claudes veröffentlichte Identität verwenden (Erkannt) (Use Claude’s published identity (Detected)). Der Server liest die Client-Details von Claude aus einem von Anthropic gehosteten Client Identity Metadata Document (CIMD).
3. Klicke auf Hinzufügen (Add).

Bestätige die erkannte OAuth-Authentifizierung sowie die Einstellungen der veröffentlichten Identität und klicke auf „Hinzufügen“.

Schritt 4: Verbindung initiieren

Der Konnektor wird erstellt und unter deinen Konnektoren aufgelistet. Klicke auf den Verbinden-Button, um den OAuth-Authentifizierungsflow zu starten.

Klicke auf den Verbinden-Button, um den OAuth-Authentifizierungsflow zu starten.

Schritt 5: Claude in branchly autorisieren

Du wirst auf die branchly-Autorisierungsseite weitergeleitet:

1. Bestätige die zu verbindende branchly-Organisation oder -Anwendung.
2. Überprüfe die angeforderten Berechtigungen (Identität verifizieren, grundlegende Profilinformationen, E-Mail-Adresse und Organisationsmitgliedschaft).
3. Klicke auf Erlauben (Allow), um Claude für den Zugriff auf deine branchly-Anwendung zu autorisieren.

Überprüfe die angeforderten Berechtigungen und klicke auf „Allow“, um Claude zu autorisieren.

Schritt 6: Tool-Berechtigungen konfigurieren

Nach der Autorisierung wirst du zurück zu Claude geleitet und erhältst die Bestätigung, dass der Konnektor verknüpft ist („Mit branchly MCP verbunden“ / „Connected to branchly MCP“):

1. Unter Tool-Berechtigungen (Tool permissions) siehst du die Liste der verfügbaren Tools, die der branchly MCP-Server bereitstellt (z. B. Get application, Get active sessions over time, Get top searches usw.).
2. Konfiguriere die Berechtigungsregeln (z. B. Genehmigung erforderlich / Permission required, immer erlauben oder einzelne Tools ablehnen).

Der branchly MCP-Server ist nun verbunden und steht in deinen Claude-Unterhaltungen bereit.

Überprüfe die erkannten Tools und konfiguriere die Tool-Berechtigungen in Claude.

Langdock

Langdock ermöglicht es dir, Remote-MCP-Server anzubinden, sodass die KI-Assistenten deines Teams direkten Zugriff auf deine branchly-Anwendungen erhalten.

Befolge diese Schritte, um den branchly MCP-Server in Langdock zu verbinden und zu konfigurieren:

Schritt 1: Neue Integration hinzufügen

Navigiere in deinem Langdock-Workspace in der linken Seitenleiste zu Anpassen (Customize) → Integrationen (Integrations) und klicke oben rechts auf den Button Integration hinzufügen (Add integration).

Navigiere zu Customize → Integrations und klicke auf „Add integration“.

Schritt 2: Remote-MCP verbinden

Wähle im Modal Remote-MCP verbinden (Connect remote MCP). Setze die Server-URL auf https://api.branchly.io/mcp, wähle deine Authentifizierungsmethode (z. B. API Key) und klicke auf Erstellen und verbinden (Create and connect).

Wähle „Connect remote MCP“, gib https://api.branchly.io/mcp ein und klicke auf „Create and connect“.

Schritt 3: Authentifizierung und benutzerdefinierte Header konfigurieren

Gib der Integration einen Namen (z. B. branchly MCP). In der Ansicht MCP-Client konfigurieren (Configure MCP client):

1. Stelle sicher, dass die Server-URL auf https://api.branchly.io/mcp/ eingestellt ist (erkannter Transport: Streamable HTTP).
2. Setze die Authentifizierungsmethode (Authentication method) auf None, falls du deinen Token über benutzerdefinierte Header übergibst.
3. Füge unter Benutzerdefinierte Header (Custom Headers) den Header x-api-key hinzu und trage deinen branchly-API-Key als Wert ein.

Füge den Header x-api-key mit deinem branchly-API-Key im Bereich für benutzerdefinierte Header hinzu.

Schritt 4: Server-Fähigkeiten erkennen und speichern

Klicke unter Schritt 4 (Server-Fähigkeiten erkennen / Discover Server Capabilities) auf Serverfunktionen auflisten (List Server Features). Langdock fragt den branchly MCP-Server ab und listet alle verfügbaren Tools und Aktionen auf (z. B. get_application, list_nodes, create_node, update_node etc.). Aktiviere die Aktionen, die du benötigst, und klicke oben rechts auf Speichern (Save).

Klicke auf „List Server Features“, um Fähigkeiten zu erkennen, aktiviere Aktionen und klicke auf „Save“.

Schritt 5: (Optional) Skills und Workflows konfigurieren

Unter Anpassen (Customize) → Skills kannst du Skills erstellen oder hochladen (wie die offiziellen branchly-Skills), um deinen Langdock-Agenten strukturierte Workflows für Audits, Optimierung und Pflege deiner branchly-Anwendung bereitzustellen.

Konfiguriere oder lade optional Skills in Langdock hoch, um strukturierte Workflows bereitzustellen.

Schritt 6: branchly im Chat abfragen und verwalten

Starte eine neue Chat-Sitzung in Langdock und referenziere @branchly MCP (oder wähle die branchly-Tools aus). Jetzt kannst du Fragen zu deiner Konfiguration stellen oder das Modell anweisen, deine Wissensbasis zu analysieren und zu aktualisieren.

Chatte mit @branchly MCP in Langdock, um deine branchly-Anwendung zu untersuchen und zu verwalten.

OpenCode

Füge folgendes zu deiner opencode.jsonc hinzu:

{
  "mcp": {
    "branchly": {
      "type": "remote",
      "url": "https://api.branchly.io/mcp",
      "enabled": true,
      "headers": {
        "x-api-key": "YOUR_API_KEY"
      }
    }
  }
}

Claude Code

Führe folgenden Befehl einmalig in deinem Terminal aus:

claude mcp add branchly-app --transport http https://api.branchly.io/mcp -H "x-api-key: YOUR_API_KEY"

Methoden

Anwendung

get_application

Gibt die vollständige Konfiguration der verbundenen Anwendung zurück: Name, Einbindungsorte, Sucheinstellungen (Modus, Modelle, Reranking), Chat-Strategie, Locales und Löschrichtlinie.

Verwendung: Wenn du den aktuellen Anwendungsstatus einsehen oder dokumentieren möchtest.

Wissensbasis – Knoten (Nodes)

Knoten sind die kleinsten Einheiten der Wissensbasis. Jeder Knoten besitzt einen nach Sprache/Locale gegliederten title und text (HTML), eine optionale source-URL und optionale custom_metadata.

list_nodes

Gibt eine paginierte Liste von Knoten zurück. Unterstützt Filter nach:

• labels – Knotentyp (entry, content, contact, tool)
• data_source_types – z. B. website_crawler, file_upload, node_editor, webhook
• data_source_ids – eine oder mehrere spezifische Datenquellen-UUIDs
• sort_parameters – Sortierung nach updated_at aufsteigend oder absteigend

create_node

Erstellt einen neuen Inhaltsknoten. Erfordert title und text als Maps mit Locale-Schlüsseln (z. B. {"en": "...", "de": "..."}). Akzeptiert optional label, source, score_boost und custom_metadata. Standardwert für label ist content.

Verwendung: Zum manuellen Hinzufügen von FAQ-Einträgen, Fallback-Antworten oder Kontaktinformationen, die nicht durch eine gecrawlte Datenquelle abgedeckt werden.

read_node

Gibt die vollständigen Details eines einzelnen Knotens anhand seiner ID zurück, einschließlich Textinhalt, Metadaten, score_boost und Zuordnung zur Datenquelle.

update_node

Aktualisiert einen Knoten partiell. Unterstützte Felder:

• title / text – Maps mit Locale-Schlüsseln; übergebene Locales werden zusammengeführt, andere bleiben erhalten
• score_boost – numerischer Multiplikator für das Ranking beim Retrieval (z. B. 1.5, um diesen Knoten häufiger auszuspielen)
• source – kanonische URL
• custom_metadata – beliebige Schlüssel-Wert-Metadaten; Schlüssel werden zusammengeführt

Verwendung: Zur Korrektur veralteter Inhalte, zur Anreicherung von Knotentexten mit typischen Nutzerformulierungen oder zur Signalverstärkung besonders wichtiger Knoten.

Datenquellen

Datenquellen legen fest, wie Inhalte in die Wissensbasis eingespeist werden (Crawling, Datei-Upload, API, Webhook etc.).

list_data_sources

Gibt alle Datenquellen der Anwendung zurück. Unterstützt das Filtern nach data_source_types. Die Ergebnisse sind nach der letzten Aktualisierung sortiert.

Unterstützte Typen:

Typ	Beschreibung
website_crawler	Crawlt öffentliche Websites über Apify
custom_website_crawler	Crawling mit benutzerdefinierten HTML-Markern und Graph-Builder
file_upload	Hochgeladene PDFs oder Dokumente
openAPI	Über OpenAPI-Spezifikation synchronisierter API-Endpunkt
helpspace	Angebundenes HelpSpace / Help Center
webhook	Per Webhook mit individuellem Mapping übertragene Daten
wordpress	Angebundene WordPress-Site mit Import von Seiten und Beiträgen
node_editor	Manuell erstellte oder bearbeitete Knoten

update_data_source

Aktualisiert eine Datenquelle. Unterstützt partielle Aktualisierungen für name, schedule (Cron-Ausdruck oder null zum Deaktivieren) und settings.

settings erfordert das vollständige Objekt – die API führt partielle Einstellungen nicht automatisch zusammen. Lies daher immer zuerst die aktuelle Datenquelle aus und sende anschließend das vollständige Settings-Objekt mit deinen Anpassungen zurück.

Verwendung: Zur Anpassung von Crawler-Selektoren (remove_html_elements), zur Änderung von Crawl-Tiefe oder Seitenlimits sowie zur Aktivierung zeitgesteuerter Re-Syncs.

Prompts

branchly unterscheidet drei spezifische Prompt-Typen, die jeweils eine andere Schnittstelle steuern:

Typ	Subtyp	Bereich
chat – routing_instructions	Prompt Persona	Entscheidet, welche KI-Aktionen im Chat aufgerufen werden; steuert die automatische Evaluierung. Kein Einfluss auf den Tonfall der Antwort.
chat – output_instructions	Output Instructions	Generiert die finale, an den Nutzer gerichtete Chat-Antwort. Kein Einfluss auf das Routing.
search_answering	(keiner)	Steuert die im Search-Interface generierte Antwort. Keine Trennung von Routing und Ausgabe.

list_prompts

Gibt Prompts gefiltert nach prompt_type (chat, search_answering, suggested_questions, chat_evaluation), subtype und is_active zurück. Ohne Filter werden alle Prompts ausgegeben.

create_prompt

Erstellt eine neue Prompt-Version und deaktiviert automatisch den zuvor aktiven Prompt desselben Typs (type + subtype). Ein separater Aktivierungsschritt ist nicht erforderlich.

Verwendung: Zur Anpassung der Routing-Logik, zur Änderung von Tonalität und Format der Antworten oder zur Aktualisierung des Antwort-Prompts für die Suche.

update_prompt

Aktiviert oder deaktiviert einen bestehenden Prompt anhand seiner ID. Verwende is_active=true, um eine frühere Prompt-Version wiederherzustellen (der aktuell aktive Prompt wird automatisch deaktiviert).

Verwendung: Für ein Rollback auf eine vorherige Prompt-Version.

KI-Aktionen (Tools)

KI-Aktionen sind ausführbare Funktionen, die der Chat-Agent während einer Konversation aufrufen kann (z. B. Wissensbasis durchsuchen, Kontaktformular absenden, externe API abfragen).

Hinweis zur Benennung: Im branchly-Dashboard werden diese als „KI-Aktionen“ („AI Actions“) bezeichnet. Die MCP-API stellt sie über die *_tools-Methoden bereit. Beide Begriffe beziehen sich auf dieselben Entitäten.

list_tools

Gibt alle KI-Aktionen zurück. Übergib active=true, um nur aktivierte Aktionen zu erhalten.

read_tool

Gibt die vollständige Konfiguration einer einzelnen KI-Aktion anhand der ID zurück, einschließlich Beschreibung, function_arguments und tool_config.

update_tool

Aktualisiert eine KI-Aktion partiell. Unterstützte Felder:

• name – Funktionsname in snake_case (max. 64 Zeichen)
• description – natürlichsprachige Beschreibung, anhand derer der Routing-Agent entscheidet, wann diese Aktion ausgeführt werden soll; muss präzise und trennscharf (MECE) gegenüber allen anderen Aktionen sein
• active – Aktion aktivieren oder deaktivieren
• function_arguments – Laufzeitkonfiguration (z. B. document_limit_default, retrieval_method, data_source_ids_filter für Wissensbasis-Tools; Empfänger-E-Mail für E-Mail-Versand-Tools)
• tool_config – Parameterschema, das dem LLM bereitgestellt wird (für Formular- und API-Tools)

Verwendung: Zur Behebung fehlerhaft ausgelöster Aktionen, zur Feinabstimmung der Retrieval-Einstellungen der Wissensbasis oder zur Deaktivierung ungenutzter Aktionen.

Sitzungen (Sessions)

read_sessions

Gibt paginierte Sitzungsübersichten zurück, absteigend sortiert nach Startzeit. Unterstützt Filter nach:

• interactions – chat, search, navigation, form_submission, voice
• embed_types – chat, search, chat_widget, search_interface, voice, api
• answer_types – complete, no_knowledge, outside_scope, small_talk, follow_up_question
• tool_ids – Sitzungen, in denen eine bestimmte KI-Aktion ausgeführt wurde
• search_query – Volltextsuche über Sitzungsinhalte
• time_filter – Zeitfenster: als Preset (last_30_days, last_month, this_month, this_year, last_6_months, last_12_months) oder als expliziter ISO-Datumsbereich (YYYY-MM-DD,YYYY-MM-DD)

Verwendung: Zur Analyse von Chatbot-Fehlern, zur Erkennung von Mustern bei no_knowledge oder outside_scope und zur Überprüfung der Tool-Nutzung.

read_session_detail

Gibt den vollständigen Interaktionsverlauf einer einzelnen Sitzung zurück, inklusive aller Chat-Nachrichten, Tool-Aufrufe, abgerufener Dokumente und Antwort-Klassifizierungen.

Verwendung: Zur Diagnose konkreter Einzelfälle – um zu prüfen, ob ein Tool ausgelöst wurde, welche Dokumente zurückgegeben wurden und wie das Modell argumentiert hat.

Um die genauen Dokumente, Tool-Aufrufe oder Suchergebnisse hinter einer einzelnen Interaktion detailliert zu untersuchen, stehen folgende Methoden zur Verfügung:

read_chat_request_documents

Liest die vollständigen Dokument-Chunks aus, die für eine einzelne Chat-Anfrage (QA oder SA) abgerufen wurden (anhand der chat_request_id). Gibt chunk_id, vertex_id, title, Volltext, score, source, Datenquellentyp, Seiten-Metadaten und die Information zurück, ob der Chunk in der finalen Antwort zitiert wurde. Absteigend nach Score sortiert.

Verwendung: Nach read_session_detail, um den exakten Kontext zu prüfen, auf den der Assistent seine Antwort gestützt hat.

read_chat_request_tool_calls

Liest alle Tool-Aufrufe aus, die für eine einzelne Chat-Anfrage ausgeführt wurden (anhand der chat_request_id). Gibt tool_call_id, tool_id, tool_name, tool_type, vollständige Argumente (JSON) und vollständige Antwortinhalte (JSON) zurück, aufsteigend sortiert nach Zeitstempel.

Verwendung: Zur Überprüfung, was der Assistent aufgerufen hat und wie das jeweilige Tool reagiert hat.

read_search_request_results

Liest die vollständigen Suchergebnisse aus, die für eine einzelne Sofortsuche-Anfrage zurückgegeben wurden (anhand der search_request_id). Gibt chunk_id, vertex_id, title, Volltext und Relevanz-Score zurück, absteigend sortiert nach Score.

Verwendung: Zur Überprüfung der exakten Suchergebnisse, die einem Nutzer für seine Suchanfrage angezeigt wurden.

Analytics

Die Analytics-Methoden liefern Einblicke und Qualitätssignale über die Sitzungsdaten deiner Anwendung. Die meisten akzeptieren einen time_filter – entweder als vordefinierten Enum-Wert (this_month, this_year, last_month, last_30_days (Standard), last_6_months, last_12_months) oder als expliziten ISO-Datumsbereich YYYY-MM-DD,YYYY-MM-DD (inklusiv) – und viele unterstützen ein optionales limit (Standard 15), das die Anzahl der zurückgegebenen Top-Einträge steuert.

get_active_sessions_over_time

Zeitreihe der aktiven Sitzungen, zusammengefasst nach Tagen oder Wochen (automatisch anhand des Zeitfensters gewählt). Jeder Datensatz schlüsselt die Gesamtzahl nach Interaktionstyp auf (chat / search / navigation / form_submission / voice). Lücken werden mit Nullen gefüllt, sodass die Daten direkt geplottet werden können. Optional nach embed_types filterbar.

Verwendung: Zur Erkennung von Spitzen, Einbrüchen oder Trends bei den aktiven Sitzungen im Zeitverlauf.

get_active_sessions_by_embed

Zeitreihe der aktiven Sitzungen, aufgeschlüsselt nach Einbindungstyp (chat, chat_widget, navigator, search_interface, voice, api).

Verwendung: Um nachzuvollziehen, welche Schnittstellen (Embed-Typen) die Nutzung maßgeblich antreiben.

get_top_locales

Häufigste Locales (nach BCP-47, z. B. de_DE, en_US) über Chat-, Such- und Navigationsanfragen hinweg, sortiert nach Häufigkeit.

Verwendung: Um zu verstehen, welche Sprachen und Regionen bedient werden und wo möglicherweise Inhaltslücken bestehen.

get_top_languages

Häufigste erkannte natürliche Sprachen der Nutzerfragen im Chat, sortiert nach Häufigkeit. Unterscheidet sich von get_top_locales: Das Locale spiegelt die Browser-/Embed-Einstellung wider, während die Sprache direkt aus dem eingegebenen Fragetext ermittelt wird.

get_top_devices

Häufigste Gerätekategorien (z. B. desktop, mobile, tablet) über alle Anfragetypen hinweg, sortiert nach Häufigkeit.

get_top_geographies

Häufigste (country, region)-Kombinationen über alle Anfragetypen hinweg, sortiert nach Häufigkeit. Land als ISO-Ländercode; Region kann null sein, falls nicht verfügbar.

get_sentiment_distribution

Sentiment-Verteilung der Chat-Antworten als Anzahlen von positive, negative und neutral.

Verwendung: Als schnelles Qualitätssignal – ein steigender Anteil an negative ist meist ein Indikator dafür, einzelne Sitzungen über read_sessions genauer zu untersuchen.

get_top_cited_sources

Knoten der Wissensbasis, die in Chat-Antworten am häufigsten zitiert wurden, sortiert nach Anzahl der Zitate. Jeder Eintrag enthält die Knoten-UUID (vertex_id), den title, die optionale source-URL und citation_count. Optional nach embed_types filterbar.

Verwendung: Um zu identifizieren, welche Inhalte tatsächlich tragend sind; ideal in Kombination mit read_node(vertex_id), um die zitierten Inhalte im Detail zu prüfen.

get_top_clicked_urls

URLs, die Nutzer tatsächlich innerhalb des Embeds angeklickt haben (Suchergebnisse, Quell-Links, Follow-ups), sortiert nach Klickanzahl. Optional filterbar nach event_types (search_result, link, contact, tool, follow_up_navigation, follow_up_question).

Verwendung: Um zu sehen, welche Links und Inhalte von Nutzern als relevant eingestuft und aufgerufen werden.

get_top_interaction_sources

URLs der Seiten, auf denen sich Nutzer befanden, als sie mit dem Embed interagiert haben (Chat, Suche, Navigation, Formularabsendung), sortiert nach Häufigkeit. Unterscheidet sich von get_top_clicked_urls: Hierbei handelt es sich um die Ursprungsseite, nicht das Klickziel.

Verwendung: Um festzustellen, welche Seiten deiner Website das meiste Engagement im Embed generieren.

get_top_searches

Häufigste Nutzersuchanfragen (normalisiert: kleingeschrieben, getrimmt), sortiert nach Häufigkeit.

get_top_tags

Häufigste Tags, die Chat-Antworten zugeordnet wurden (automatisch abgeleitete Klassifizierungen, getrennt von classifications), sortiert nach Häufigkeit. Optional auf bestimmte answer_types einschränkbar.

get_answer_type_distribution

Verteilung der Chat-Antworttypen, sortiert nach Häufigkeit.

get_trending_classifications

Zeitreihe aufkommender Klassifizierungen (Themen ODER Absichten, die aus Chat-Inhalten abgeleitet wurden), eine Reihe pro Klassifizierungs-ID. Jeder Eintrag enthält einen Zeitstempel und die Anzahl. Erfordert classification_type (topic für Fachthemen-Trends, intent für Absichts-/Ziel-Trends der Nutzer).

Verwendung: Um zu erkennen, wie sich thematische Interessen oder Absichten der Nutzer im Zeitverlauf verändern.

update_chat_request_analytics

Die einzige Schreibmethode in der Analytics-Gruppe. Aktualisiert Analytics-Felder einer Chat-Anfrage partiell (anhand der chat_request_id). Es werden nur die übergebenen Felder geändert. Unterstützte Felder:

• summary – Freitext-Zusammenfassung der Interaktion
• tags – Liste von Klassifizierungs-Tags
• answer_type – Neuklassifizierung der Antwort (z. B. Korrektur eines no_knowledge, das tatsächlich beantwortet wurde)
• sentiment – positive, neutral oder negative
• classification_topic_id / classification_intent_id – Neuverknüpfung einer Themen- oder Absichts-Klassifizierung

Verwendung: Zur Korrektur fehlerhaft klassifizierter Sitzungen, zur Verfeinerung von Zusammenfassungen oder zum nachträglichen Retagging von Interaktionen (z. B. zur Bereinigung von Analysen vor einem Reporting).

Typische Workflows

Ziel	Methoden
Eine no_knowledge-Antwort debuggen	read_sessions → read_session_detail
Unruhige gecrawlte Inhalte bereinigen	list_data_sources → update_data_source (mit vollständigen Settings)
Einen wichtigen Knoten stärken	read_node → update_node (score_boost)
Fehlenden FAQ-Eintrag ergänzen	create_node
Eine nie auslösende KI-Aktion beheben	list_tools → read_tool → update_tool (description) + create_prompt (routing)
Antwort-Prompt der Suche anpassen	list_prompts(prompt_type="search_answering") → create_prompt
Rollback eines Prompts durchführen	list_prompts → update_prompt (is_active=true)
HTML-Filter des Crawlers aktualisieren	list_data_sources → vollständige Settings kopieren → update_data_source

Skills

Installiere auch die offiziellen branchly-Skills unter https://github.com/branchly-io/branchly-skills für noch detailliertere Anleitungen zur optimalen Nutzung des MCP-Servers.