ooligo
mcp-server

Pull Vitally account health into Claude via MCP for CS conversations

Difficulty
Profi
Setup time
1-2 hours
For
csm
RevOps

Stack

Ein Model Context Protocol-Server, der Claude schreibgeschützten Zugriff auf Vitally Account-Health-Scores, Health-Komponenten-Aufschlüsselungen und Konversationsverläufe gibt. Einmal in Claude Desktop oder Claude Code registriert, kann jeder CSM in Ihrem Team fragen „Was ist der Health-Score von Acme Corp und warum ist er rot?” oder „Zeig mir die letzten fünf Konversationen zu diesem Account vor meinem Renewal-Gespräch” — und erhält eine strukturierte Antwort, die in Echtzeit aus Vitally gezogen wird, ohne einen zweiten Tab öffnen zu müssen.

Das vollständige Scaffold liegt im Artefakt-Bundle unter apps/web/public/artifacts/mcp-server-vitally-cs/, das ein README.md, pyproject.toml, src/vitally_cs_mcp/__init__.py und src/vitally_cs_mcp/server.py enthält.

Wann Sie dies verwenden sollten

Dieser MCP-Server zahlt sich aus, wenn der Workflow Ihres CS-Teams ein wiederkehrendes Muster aufweist: Vitally-Kontext vor einem Gespräch abrufen, ein Renewal-Vorbereitungsdokument schreiben, die At-Risk-Queue priorisieren oder eine QBR-Folie mit Health-Daten erstellen. Das Muster funktioniert gut für zwei CSM-Archetypen.

Der CSM, der ein Portfolio von 80 bis 120 SMB-Accounts verwaltet und derzeit jeden Montag durch Vitallys Account-Liste klickt, um herauszufinden, wer letzte Woche ins Rote gefallen ist. Mit diesem Server können Sie Claude fragen „Zeig mir meine At-Risk-Accounts unter 40” und erhalten eine priorisierte Liste in unter fünf Sekunden — dann können Follow-up-Fragen zur Health-Komponenten-Aufschlüsselung eines beliebigen Accounts gestellt werden, ohne durch mehrere Vitally-Bildschirme navigieren zu müssen.

Der Enterprise-CSM, der vor jedem EBR zwanzig Minuten damit verbringt, in Vitally nach Konversationsverlauf, Health-Trends und der letzten Notiz eines Kollegen zu suchen. Mit diesem Server beschreiben Sie den Account gegenüber Claude und erhalten eine einzelne Antwort mit Health-Score, Komponenten-Aufschlüsselung und aktuellen Konversationsthemen — bereit zum Einfügen in das Vorbereitungsdokument.

Es ist auch das richtige Muster, wenn Ihr CS-Team Claude bereits für andere Aufgaben nutzt (Follow-up-E-Mails schreiben, Gesprächsnotizen zusammenfassen, Erfolgspläne erstellen) und Sie die Konversationsoberfläche, in der das Team bereits arbeitet, mit den benötigten CS-Daten verbinden möchten. Der MCP-Server fügt Vitally-Kontext hinzu, ohne zu ändern, wie das Team Claude nutzt.

Wann Sie dies NICHT verwenden sollten

Überspringen Sie es, wenn eine der folgenden Bedingungen zutrifft:

  • Sie müssen Daten zurück in Vitally schreiben. Dieses Scaffold ist bewusst schreibgeschützt. Wenn Ihr Workflow das Erstellen von Notizen, das Aktualisieren von Traits oder das Protokollieren von Konversationen aus Claude heraus erfordert, müssen Sie den Server mit Schreib-Tools erweitern — und diese mit einem Audit-Pattern koppeln, ähnlich dem Salesforce-Scaffold unter apps/web/public/artifacts/mcp-server-salesforce-revops/. Versuchen Sie keine Schreiboperationen, indem Sie dieses Scaffold modifizieren, ohne diese Audit-Schicht hinzuzufügen.
  • Ihr Portfolio überschreitet 100 Accounts und Sie benötigen eine vollständige At-Risk-Übersicht. Das Tool list_at_risk_accounts ruft eine Seite Accounts ab (bis zu 100, gemäß Vitalllys API-Limit) und filtert lokal. Orgs mit mehr als 100 aktiven Accounts erhalten eine Teilansicht, bis Cursor-Paginierung implementiert ist (README TODO #2). Für größere Portfolios exportieren Sie ein Vitally-CSV-Segment und fügen es direkt in Claude ein, anstatt sich für die Triage auf diesen Server zu verlassen.
  • Vitally ist nicht Ihr System of Record für Health. Einige CS-Teams pflegen Health-Scores in Gainsight, ChurnZero oder einem eigenen Tabellenmodell und schieben eine zusammengefasste Metrik in Vitally. Wenn die maßgeblichen Health-Daten woanders liegen, liest Claude eine abgeleitete oder veraltete Kopie. Richten Sie den MCP-Server auf die eigentliche Quelle.
  • Ihre Datenschutzrichtlinie verbietet, dass Account-Daten in ein LLM eines Drittanbieters gelangen. Account-Namen, Health-Scores, Konversationsthemen und Nachrichtentexte passieren Claudes Kontextfenster. Wenn Ihre Verträge mit Enterprise-Kunden die KI-Verarbeitung ihrer Daten einschränken, klären Sie die Rechtslage, bevor Sie dies aktivieren.
  • Ihr CS-Team hat weniger als fünf aktive Accounts. Die Einrichtung dauert ein bis zwei Stunden; die Token-Kosten sind real. Bei sehr wenigen Accounts ist das direkte Öffnen von Vitally schneller.

Einrichtung

Das README.md des Bundles ist die maßgebliche Referenz; die folgenden Schritte sind die Orientierung. Rechnen Sie mit etwa einer Stunde, wenn Ihr Vitally-API-Key bereits verfügbar ist, bis zu zwei Stunden, wenn Sie einen dedizierten Service-Account einrichten.

  1. Paket installieren. Vom Bundle-Stammverzeichnis aus: python -m venv .venv, aktivieren, pip install -e .. Die Abhängigkeiten sind mcp>=1.2.0, httpx>=0.27.0 und pydantic>=2.6.0 — kein Vitally-spezifisches SDK, nur einfache HTTP-Aufrufe.
  2. Vitally-API-Key beschaffen. In Vitally: Settings → Integrations → API. Generieren Sie einen Key von einem dedizierten Integrations-User (nicht Ihrem persönlichen Admin-Account). Vitally verwendet HTTP Basic Auth — der Server übernimmt die Kodierung; Sie liefern den Roh-Key als VITALLY_API_KEY.
  3. Subdomain ermitteln. Wenn Ihre Workspace-URL acme.vitally.io ist, ist Ihre Subdomain acme. EU-Tenants setzen VITALLY_BASE_URL=https://rest.vitally-eu.io.
  4. Umgebungsvariablen setzen. VITALLY_API_KEY, VITALLY_SUBDOMAIN (oder VITALLY_BASE_URL für EU), optional VITALLY_HEALTH_THRESHOLD (Standard 50) und VITALLY_PAGE_LIMIT (Standard 100, Vitalllys API-Limit).
  5. Mit Claude Desktop oder Claude Code registrieren. Fügen Sie den JSON-Block aus dem README.md zur claude_desktop_config.json (Desktop) oder zur settings.json Ihres Projekts (Code) hinzu. Starten Sie Claude Desktop neu.
  6. Funktionsprüfung. Fragen Sie Claude „Zeig mir den Health-Score für Account-ID <eine echte Account-ID>” und vergleichen Sie die Antwort mit der Vitally-Oberfläche. Fragen Sie dann „Zeig mir At-Risk-Accounts unter 40” und überprüfen Sie, ob die zurückgegebenen Accounts tatsächlich Health-Scores in diesem Bereich in Vitally aufweisen.

Was es tut — und warum die Tools so gestaltet sind

Drei Tools, durchgehend schreibgeschützt.

get_account_health(account_id) macht zwei sequentielle GET-Anfragen an Vitally: GET /resources/accounts/:id für den Basis-Account-Datensatz und GET /resources/accounts/:id/healthScores für die Komponenten-Aufschlüsselung. Diese werden zu einer einzelnen Antwort mit dem Gesamt-healthScore plus einem Array von Health-Komponenten zusammengeführt, jede mit Name, Score und Status. Zwei Anfragen statt einer, weil Vitalllys REST-API den Basis-Account-Datensatz vom Health-Score-Detailbericht trennt — es gibt keinen einzelnen Endpunkt, der beides zurückgibt.

list_at_risk_accounts(health_threshold?, limit?) ruft eine Seite aktiver Accounts ab (GET /resources/accounts?limit=100&status=active), filtert auf diejenigen, deren healthScore dem Schwellenwert entspricht oder darunter liegt, sortiert aufsteigend nach Score (schlechteste zuerst) und kürzt auf das angeforderte Rückgabelimit. Der lokale Filteransatz vermeidet den Bedarf nach einem serverseitigen Filter in Vitally, den die öffentliche REST-API nicht bereitstellt — Sie können healthScore[lte]=50 nicht als Query-Parameter übergeben. Der Kompromiss ist, dass pro Aufruf nur die ersten 100 Accounts gescannt werden; das README dokumentiert dieses Limit und den Cursor-Paginierungspfad zur Behebung.

get_account_conversations(account_id, limit?) ruft GET /resources/accounts/:id/conversations?limit=N auf. Vitally gibt Konversationen standardmäßig in umgekehrter chronologischer Reihenfolge zurück. Der Server kürzt jede Konversation auf die Felder, die im Kontextfenster von Claude am nützlichsten sind — Betreff, Nachrichtenanzahl, der Text der ersten Nachricht, Traits und Zeitstempel — anstatt das vollständige Nachrichten-Array zurückzugeben. Eine 10-Konversationen-Antwort von einem ausführlichen Account kann sonst auf mehrere tausend Tokens anwachsen; das Kürzen hält das Kontextfenster vorhersagbar.

Schreibgeschützt durch Design. Jedes Tool stellt nur GET-Anfragen. Es gibt kein update_account, kein create_note, kein delete_conversation. Die Wahl ist bewusst: CS-Tools, die zurück in das System of Record schreiben können, benötigen eine separate, benannte Audit-Story (wer hat was geändert, warum, wann), bevor sie in Betrieb gehen. Zuerst schreibgeschützten Mehrwert zu liefern ist risikoärmer und schneller genehmigt.

Auth per Basic, nicht Bearer. Vitalllys REST-API authentifiziert sich per HTTP Basic Auth mit dem API-Key als Benutzername und einem leeren Passwort. Dies unterscheidet sich vom OAuth-Bearer-Pattern, das Salesforce und HubSpot verwenden. Der Server kodiert dies zur Laufzeit korrekt — Authorization: Basic base64("apikey:"). Sie müssen den Key nicht selbst in Base64 kodieren; liefern Sie den Roh-Key als VITALLY_API_KEY.

Kostenrealität

Drei Kostenpositionen zu berücksichtigen.

Claude-Abonnement. Was Ihr Team bereits für Claude Desktop oder Claude Code zahlt (Pro bei $20/User/Monat; Max-Stufen $100–200/User/Monat; oder API-Verbrauch nach Token-Preisen). Der MCP-Server ändert das nicht.

Vitally-API-Kontingent. Vitalllys REST-API erlaubt 1.000 Anfragen pro Minute in einem gleitenden Fenster, gemäß der API-Dokumentation. Ein CSM, der Pre-Call-Vorbereitung durchführt (ein get_account_health + ein get_account_conversations), verbraucht 3 API-Aufrufe (2 für Health, 1 für Konversationen). Eine wöchentliche At-Risk-Überprüfung (list_at_risk_accounts) verbraucht 1 Aufruf. Bei 20 CSMs, die 5 Vorbereitungssitzungen pro Woche plus eine wöchentliche Triage durchführen, sind das ungefähr (20 × 5 × 3) + (20 × 1) = 320 Aufrufe/Woche — weit innerhalb des Rate-Limits. Das Limit wird nur relevant, wenn Sie automatisierte Batch-Jobs ausführen oder hunderte Accounts in schneller Folge durchlaufen.

Token-Kosten in Claude. Eine einzelne get_account_health-Antwort für einen typischen Account umfasst ca. 800–1.500 Tokens, je nachdem wie viele Health-Komponenten Ihr Org konfiguriert hat und wie ausführlich der Traits-Payload ist. Eine get_account_conversations-Antwort für 10 Konversationen mit gekürzten Nachrichtentexten umfasst ca. 2.000–5.000 Tokens. Eine vollständige Pre-Call-Vorbereitungssitzung mit zwei Tool-Aufrufen kostet unter $0,02 in Tokens. Zehn CSMs mit je 5 Vorbereitungssitzungen pro Woche = $1–5/Monat an Token-Kosten zusätzlich zum Abonnement. Großzügig aufgerundet für längere Konversationen ergibt das ca. $10/User/Monat insgesamt.

Dies sind Schätzungen basierend auf typischen Vitally-Datenstrukturen; die tatsächlichen Token-Zahlen Ihres Orgs hängen von der Traits-Payload-Größe und dem Konversationsvolumen ab.

Fehlermodi

Der Health-Score ist null für einen neuen Account. Vitally berechnet keinen Health-Score für Accounts, denen ausreichende Daten fehlen — neue Kunden, Accounts ohne ingestierte Events oder Accounts außerhalb eines Health-Score-Segments. get_account_health gibt healthScore: null und ein leeres healthScores-Array zurück. Guard: Der Server gibt null durch, anstatt einen Fehler auszulösen; Claude meldet die Abwesenheit. Weisen Sie Ihre CSMs an, einen Null-Health-Score als Signal zu behandeln, die Dateneingabe von Vitally zu prüfen, nicht als gesunden Account.

list_at_risk_accounts gibt für große Portfolios eine unvollständige Ansicht zurück. Das Tool scannt eine Seite von 100 Accounts. Wenn Ihr Org 250 aktive Accounts hat und die schlechtesten auf Seite 2 oder 3 liegen, wird das Tool sie verfehlen. Guard: Der Response-Payload enthält ein note-Feld, das explizit signalisiert, wenn Vitally einen next-Cursor zurückgegeben hat (d.h. es gibt weitere Seiten). CSMs sollten ein nicht leeres note als Signal behandeln, die Abfrage einzugrenzen oder Vitalllys nativen Segment-Filter für die vollständige Portfolio-Triage zu verwenden, bis Cursor-Paginierung implementiert ist (README TODO #2).

Vitally-429-Rate-Limit bei schnellen sequentiellen Aufrufen. Das schnelle Durchlaufen vieler Accounts hintereinander (z.B. get_account_health für jeden Account in einer Liste aufzurufen) wird das 1.000-Req/Min-Limit erreichen, wenn die Schleife eng genug ist. Guard: Das Scaffold hat kein eingebautes Retry oder Backoff. Für jeden Workflow, der mehr als ~50 get_account_health-Anfragen in einer einzelnen Sitzung aufruft, fügen Sie exponentielles Backoff mit Jitter um vitally_get hinzu. Claude-Code-Nutzer können dies in einem Fork von server.py in ca. 15 Zeilen mit httpxs Retry-Transport ergänzen.

API-Key läuft ab oder wird widerrufen. Vitalllys API-Keys haben keine dokumentierte TTL, aber Keys, die von einem Nutzer generiert wurden, der später deaktiviert wird oder dessen Rolle sich ändert, hören auf zu funktionieren. Eine 401 taucht als httpx.HTTPStatusError mit Status 401 auf. Guard: require_config() wird bei jedem Tool-Aufruf ausgeführt und löst erneut aus, wenn der Key fehlt. Für den Fall eines widerrufenen, aber vorhandenen Keys propagiert sich die 401 von Vitally als Fehlermeldung in Claudes Antwort. Richten Sie eine monatliche Kalender-Erinnerung ein, um zu überprüfen, ob der Integrations-Key noch aktiv ist.

Versus den Alternativen

Vitalllys native KI-Funktionen (Vitally Copilot / KI innerhalb der App). Vitally hat KI-gestützte Zusammenfassungen und Vorschläge nativ in der Plattform eingeführt. Erstanbieter, keine Einrichtung, kein separater Prozess zum Hosten. Der Kompromiss: Die KI befindet sich innerhalb von Vitally, was bedeutet, dass Ihre CSMs in Vitally sein müssen, um sie zu nutzen. Das MCP-Server-Muster hält Claude als einheitliche Chat-Oberfläche über alle Tools hinweg — wenn Ihr Team Claude bereits für E-Mail-Entwürfe, Gesprächs-Zusammenfassungen und Erfolgspläne nutzt, bedeutet das Hinzufügen von Vitally-Kontext dort weniger Kontextwechsel, nicht mehr.

CSV-Export + manuelles Einfügen. Vitally-Segment als CSV exportieren, in Claude einfügen. Kostenlos, keine Einrichtung, funktioniert sofort. Der Kompromiss: Es ist ein manueller Schritt (exportieren, Datei öffnen, einfügen), die Daten sind ein Snapshot und keine Live-Abfrage, und es lässt sich nicht gut mit anderen Tools in derselben Claude-Konversation kombinieren. Der MCP-Server übertrifft dies bei der Zeit bis zur Antwort und übertrifft es mehr, je mehr Ihr Team Claude nutzt.

Direkte Vitally-REST-API-Aufrufe in einem Claude-Code-Skript. Ein CSM, der mit Python vertraut ist, kann die Vitally-API direkt aus einer Claude-Code-Sitzung mit wenigen Zeilen httpx aufrufen. Der Kompromiss: Jede neue Sitzung authentifiziert sich neu, der Code lebt in einer flüchtigen Konversation und nicht in einem persistenten registrierten Tool, und andere CSMs im Team können ihn nicht ohne die gleiche Einrichtung wiederverwenden. Der MCP-Server registriert die Tools einmalig und macht sie für jeden mit der Claude-Desktop- oder Code-Integration verfügbar.

Referenzen

Bundle-Dateien:

  • apps/web/public/artifacts/mcp-server-vitally-cs/README.md — Installation, Umgebungsvariablen, Registrierungs-JSON, Funktionsprüfung, Sicherheitsmodell
  • apps/web/public/artifacts/mcp-server-vitally-cs/pyproject.toml — Python-Paketdefinition
  • apps/web/public/artifacts/mcp-server-vitally-cs/src/vitally_cs_mcp/__init__.py — Paket-Init
  • apps/web/public/artifacts/mcp-server-vitally-cs/src/vitally_cs_mcp/server.py — vollständiges Server-Scaffold mit den drei Tools und dem Dispatch

Verwandte Tools: Vitally, Claude

Files in this artifact

Download all (.zip)