Claude für ServiceNow: So verbindest du es – und das kostet es

Was ServiceNow tatsächlich angekündigt hat

Zwei Ankündigungen, fünf Monate auseinander, die ständig durcheinandergebracht werden.

Am 28. Januar 2026 kündigten Anthropic und ServiceNow an, dass Claude das Standardmodell hinter ServiceNow Build Agent ist und ein bevorzugtes Modell in der gesamten ServiceNow AI Platform. ServiceNow rollte Claude und Claude Code außerdem intern an mehr als 29.000 Mitarbeitende aus und berichtete von einer Reduktion der Meeting-Vorbereitungszeit für Vertriebsmitarbeitende von bis zu 95 %. Bill McDermott bezeichnete das als Neuerfindung der Art, wie Arbeit erledigt wird. Dario Amodeis Punkt war, dass KI in die tägliche Arbeit eingewoben statt nachträglich angeflanscht wird.

Am 5. Mai 2026, auf der Knowledge 2026, kündigte ServiceNow Action Fabric an und öffnete die Plattform über einen generell verfügbaren MCP-Server für jeden externen Agenten. Anthropic wird als erster Design-Partner genannt und verbindet Claude Cowork mit dem, was ServiceNow sein System of Action nennt. Boris Cherny, Head of Claude Code bei Anthropic, wird zitiert mit dem Punkt, die Lücke zwischen Wissen, was passieren muss, und dem tatsächlichen Geschehenlassen zu schließen.

Liest man beides zusammen, ist die Geschichte stark. ServiceNows eigene Darstellung lautet: Andere Plattformen lassen Agenten Daten lesen und schreiben, während ServiceNow sie kontrollierte Arbeit ausführen lässt: Flows, Playbooks, Freigaben, Kataloge.

Jetzt der Teil, den die Pressemitteilungen auslassen. Der MCP-Server ist in den Now-Assist- und AI-Native-SKUs enthalten, und headless ausgeführte Aktionen verbrauchen dieselbe Assist-Währung wie Now Assist und AI Agents. Dieser Satz steht im Action-Fabric-Beitrag selbst, kursiv, weit unten. Das ist die gesamte kommerzielle Form dieser Integration, und alles Weitere ergibt sich daraus.

Noch etwas, das auffällt, wenn man in den Docs liest: ServiceNow steckt mitten in einem Rebranding. Ein Banner in der Dokumentation weist inzwischen darauf hin, dass ServiceNow Otto die neue KI-Experience-Marke ist, und Community-Artikel-URLs sind bereits von now-assist-articles zu servicenow-otto-articles gewechselt. Gleiches Produkt, neuer Name, halb migrierte Docs.

Vier Wege, wie Claude eine ServiceNow-Instanz erreicht

Es gibt vier, und sie sind nicht gleichwertig.

Die ersten beiden kannst du schon heute nutzen. Das dritte zeigt in die andere Richtung: Claude arbeitet an ServiceNow statt in deiner Warteschlange. Das vierte ist das, worüber die Pressemitteilung am lautesten spricht, und das, was du gerade am wenigsten verlässlich kaufen kannst.

Der offizielle Weg: MCP Server Console

Die MCP Server Console ist die unterstützte Antwort, und die ServiceNow-Docs nennen Claude ausdrücklich als Client neben Microsoft Copilot.

Die vier Quickstart-Tools

Du musst nichts bauen, um loszulegen. Es gibt einen vorkonfigurierten Quickstart Server, und das ist die gesamte Oberfläche, die er bereitstellt:

Zwei Lookups und zwei Zusammenfasser. Die Out-of-the-Box-Erfahrung von Claude auf ServiceNow ist Lesen-und-Zusammenfassen, nicht Handeln. Frag „alle offenen Incidents abrufen" oder „alle diese Woche geschlossenen Cases zusammenfassen" und es funktioniert gut. Bitte es, einen P1 neu zuzuweisen, einen Change freizugeben oder einen Katalogeintrag auszulösen, und es gibt dafür kein Tool, bis jemand eins baut.

Das ist ein schmalerer Standard als die vier On-Call-Tools, die ich in Atlassians Rovo-MCP-Server gefunden habe, und viel schmaler als die zwölf Confluence-Tools in meinem Claude für Confluence-Beitrag. Der Unterschied ist bewusst: Atlassian liefert eine feste Tool-Liste, ServiceNow liefert einen Baukasten.

Was du darüber hinaus bauen kannst

Tools in der MCP Server Console stammen aus fünf Kategorien, und genau hier zeigt sich die Tiefe der Plattform:

• REST-API umhüllt jeden Endpunkt der Instanz, einschließlich der Table API.
• Action und Subflow sind die interessanten, weil sie kontrollierte Arbeit statt reinen Datenzugriff bedeuten. ServiceNows eigene Docs beschreiben Subflows und Actions so, dass Agenten Anfragen einreichen, zur Freigabe weiterleiten und Ergebnisse bestätigen können, ohne den Client zu verlassen.
• Knowledge Graph ermöglicht beziehungsbewusste Abfragen über Live-Instanzdaten statt flacher Datensatz-Lesevorgänge.
• Now-Assist-Skill stellt einen bestehenden Skill bereit, einschließlich eigener aus dem AI Skill Kit.

Pro Tool kannst du einzelne Inputs abschalten, sodass sie den Client nie erreichen, auch wenn sich manche Pflicht-Inputs nicht abschalten lassen. Diese feldweise Kontrolle ist das beste Governance-Feature im gesamten Setup, und deshalb würde ich eigene Tools bauen, statt die Table API komplett offenzulegen.

Zwei Reibungspunkte aus den Docs, die dich beim Bauen erwischen werden. Fügst du einem Now-Assist-Skill Inputs hinzu, nachdem du daraus schon ein Tool gemacht hast, musst du ein Ersatz-Tool erstellen, nicht das bestehende bearbeiten. Und die Tool-Erstellung braucht mindestens Zurich Patch 9 oder Australia Patch 2 – neuer als der Patch-Level, der dir überhaupt erst den MCP-Server gebracht hat.

So verbindest du Claude mit ServiceNow

Die Verbindung ist ein OAuth-Handshake, kein Eintrag in einem Verzeichnis, den du anklickst. Es gibt keinen One-Click-ServiceNow-Eintrag in Claudes Connector-Verzeichnis, das ist der wichtigste praktische Unterschied zu etwas wie Fronts offiziellem MCP-Server.

1. Besorg dir eine qualifizierende SKU. Now Assist (Pro Plus, Enterprise Plus) oder eine KI-SKU, laut ServiceNows eigener Voraussetzungsliste. Ebenfalls auf dieser Liste: Zurich Patch 4 oder höher, die AI-Agents-Store-App ab 6.x, und die MCP-Client-Store-App ab 1.1.
2. Wähle oder erstelle einen Server. Unter All > MCP Server Console > Configuration > Servers. Starte mit dem Quickstart Server; erstelle einen eigenen, wenn du ein abgegrenztes Tool-Set willst, etwa einen Server für IT und einen für HR.
3. Erstelle Tools, falls nötig. Configuration > Tools > Create tool, dann eine Kategorie wählen. Benötigte Rolle: sn_mcp_server.tools_admin, sn_mcp_server.admin oder admin. Jeder Server braucht mindestens ein Tool.
4. Erstelle eine eingehende OAuth-Integration für Claude. Eine pro Client. Daher kommen Client-ID und Secret.
5. Richte Claude auf den Server aus. Das URL-Muster ist https://<instance>.service-now.com/sncapps/mcp-server/mcp/<server-name>, beim Quickstart Server lautet der Name sn_mcp_server_default. Auth-Typ ist OAuth 2.0 mit einem generischen OAuth-2-Identity-Provider, Autorisierung unter /oauth_auth.do, Token unter /oauth_token.do, Widerruf unter /oauth_revoke.do, Callback unter /oauth/callback, Scope mcp_server.
6. Prompte es. Claude sendet Authorization: Bearer <token>, der Server validiert und liefert seine Tool-Liste zurück, und Ergebnisse kommen als JSON zurück, das der Client als Text darstellt.

Plane eine Stunde ein, wenn deine Instanz bereits gepatcht ist und jemand mit sn_mcp_server.admin im Raum sitzt. Plane einen Beschaffungszyklus ein, wenn die Now-Assist-SKU noch nicht unterschrieben ist.

Was ein Claude-Aufruf tatsächlich kostet

Hier ist der Satz, der entscheidet, ob das billig oder teuer wird, direkt aus ServiceNows eigener MCP-FAQ: Now-Assist-Skills, die als Tools über den MCP-Server bereitgestellt werden, verbrauchen bei Aufruf ihre übliche Anzahl an Assists plus 1 Assist.

Dieser Aufschlag ist pauschal, was bedeutet, dass er je nach Skill sehr unterschiedlich ausfällt. Incident-Zusammenfassung ist ein 1-Assist-Skill, ein Aufruf über Claude kostet also 2 – ein Overhead von 100 % auf die günstigste Sache, die du machen willst. Eine 250-Assist-Work-Notes-Analyse zahlt denselben zusätzlichen Assist und merkt es kaum. Die veröffentlichte Preistabelle setzt außerdem Virtual-Agent-Themen und Ticket-Aktionen bei je 10 Assists an, und agentische Workflows bei 25, 50 oder 150, je nachdem, wie viele Tools sie berühren.

Assists werden auf Kontoebene über Produktions- und Sub-Produktionsinstanzen hinweg gebündelt und setzen sich an deinem Kaufjahrestag zurück – ein Team, das in einer Dev-Instanz experimentiert, verbraucht also denselben Pool, aus dem auch die Produktions-Warteschlange schöpft.

Das Ergebnis daraus ist kontraintuitiv. Der MCP-Aufschlag bestraft genau die günstigen, hochfrequenten Lesevorgänge, die du am liebsten von Claude erledigen lassen würdest, und verschwindet bei den teuren Workflows im Rauschen. Wenn dein Plan lautet „jeder in der IT fasst den ganzen Tag Incidents über Claude zusammen", ist das genau der Fall, in dem der zusätzliche Assist deinen Verbrauch verdoppelt.

Ich sehe Käufer ständig gegen diese Wand laufen. Einer, mit dem ich gearbeitet habe, ein E-Mail-Security-Unternehmen mit Freshdesk auf dem Weg zu 20.000 Tickets pro Jahr, verbrauchte an einem einzigen Testtag 200 gemessene Interaktionen und machte sich sofort Sorgen um die Zahl bei echtem Volumen. Ein anderer, ein Betreiber mit sehr hohem Volumen, fand die Unterscheidung zwischen Pro-Interaktion und Pro-Ticket mitten im Gespräch verwirrend genug, um für sein Unternehmen rund 30.000 $ im Monat zu projizieren, bevor jemand die Rechnung korrigieren konnte. Gemessene KI-Preise sind nicht falsch. Sie sind nur sehr schwer vorherzusagen, bevor man sie tatsächlich laufen lässt – deshalb bestehe ich inzwischen darauf, jeden eesel-Rollout gegen die eigenen historischen Tickets eines Kunden zu simulieren, bevor irgendjemand ihn live schaltet.

Wo der offizielle Weg endet

Sechs Grenzen, die du kennen solltest, bevor du dich festlegst. Keine davon ist geheim; sie stehen alle in ServiceNows Docs und FAQ, was mehr ist, als die meisten Anbieter veröffentlichen.

Nur Remote-Transport. Streambares HTTP und SSE werden unterstützt. Stdio nicht, und lokale MCP-Server werden überhaupt nicht unterstützt. Wenn dein Bild von Claude-MCP-Konfiguration ein lokaler Befehl in einer JSON-Datei ist, passt das hier nicht.

MCP-Protokoll 2025-06-18. Das ist die unterstützte Spec-Version. MCP-Resources und -Prompts werden noch nicht unterstützt, ServiceNow zufolge stehen sie aber unter Safe Harbour auf der Roadmap.

Kein GCC für den Server. Der MCP-Client und A2A funktionieren auf GCC. Der MCP-Server nicht, Stand Zurich-Patch-4-FAQ. Für eine US-Bundesinstanz schließt das den offiziellen Weg komplett aus.

Daten verlassen deine Instanz. Die Docs der MCP Server Console sagen unumwunden, dass die Anwendung erfordert, dass Daten von Kundeninstanzen in eine zentralisierte ServiceNow-Umgebung übertragen werden, möglicherweise in eine andere Rechenzentrumsregion, und möglicherweise zu einem Drittanbieter-Cloud-Provider wie Microsoft Azure. Lies das mit deinen Data-Residency-Verpflichtungen vor Augen.

Inputs und Outputs fließen standardmäßig in die Modellentwicklung ein. Dieselbe Doku-Seite besagt, dass ServiceNow Inputs, Outputs und Bearbeitungen an Outputs sammelt und nutzt, um seine Technologien zu entwickeln und zu verbessern, mit einem Opt-out über die Now-Assist-Opt-out-Seite. Opt-out bedeutet, dass tatsächlich jemand hingehen und es tun muss.

Eine OAuth-Integration pro Client. Das ist das Design, und ein vernünftiges dazu, aber es bedeutet, dass das Onboarding einer zweiten KI-Anwendung eine weitere Admin-Aufgabe ist statt einer Checkbox. Im AI Gateway im AI Control Tower siehst du, wer was aufgerufen hat.

Warum Teams trotzdem zu Open Source greifen

Die Community-MCP-Server sind keine Randerscheinung. Der bekannteste, echelon-ai-labs/servicenow-mcp, steht bei 286 Stars und 225 Forks, ist MIT-lizenziert und liefert Tools für Incidents, Change Requests, den Service-Katalog, Knowledge Bases, Nutzer und Gruppen, Workflows, Script Includes, Changesets und Agile Stories. Er unterstützt Basic Auth, OAuth und API-Key, läuft über stdio oder SSE und hat ein Tool-Packaging-System mit rollenbasierten Bundles wie service_desk, change_coordinator und knowledge_author, damit die Zahl exponierter Tools überschaubar bleibt.

Der ehrliche Grund, warum Leute diese nutzen, ist Lizenzierung, und r/servicenow spricht es offen aus:

"These open source ones that keep popping up are more-so alternatives if your company doesn't want to purchase now assist licensing."

u/averageuser612, Reddit

Im selben Thread gibt es die schärfere Version, in einem Kommentar, der voraussagt, dass ServiceNow niemals einen kostenlosen ausliefern wird:

"ServiceNow most definitely won't give customers something for free when the alternative is to charge you in assists. If they could charge you assist to log in to your instance, they would."

u/tokenontokens, Reddit

Dieser Lesart würde ich leicht widersprechen, und das fair. ServiceNow hat einen MCP-Server ausgeliefert, er ist generell verfügbar, und die Docs sind ungewöhnlich genau darin, was er abdeckt und was nicht. Er ist einfach nicht kostenlos, und er gibt auch nicht vor, es zu sein.

Was man bei Open Source aufgibt, ist trotzdem real. Der Maintainer eines neueren Community-Servers wurde direkt zu Guardrails gefragt und antwortete, dass die MCP-Seite ein rohes Set von Tools ohne standardmäßig eingebaute Guardrails ist und dass der Client entscheidet, wie sie genutzt werden. Das ist der Tausch: Der offizielle Server gibt dir feldweise Input-Kontrolle, OAuth, Audit-Trails über den AI Control Tower und Pro-Tool-Metering. Ein roher Table-API-Wrapper gibt dir sofort alles, was dein Service-Account erreichen kann.

Es gibt in diesen Threads auch eine dritte Position, die man ernst nehmen sollte, von jemandem, der von alldem nichts wollte:

"Claude has built perfectly fine servicenow fluent code for me without any external tooling whatsoever."

u/Correct-Mood5309, Reddit

Für Scripting- und Fluent-Arbeit stimmt das oft. MCP rechtfertigt sich, wenn Claude den Live-Zustand der Instanz braucht, nicht wenn es Code schreiben soll, den es ohnehin schon kann.

Eine Notiz aus dem Feld von einem Team, das seinen eigenen gebaut hat, zum Australia-Patch-4-Release: Ihr einziger Stolperstein war die Authentifizierung, da die CMDB-Suche derzeit nicht mit dem admin-Konto funktioniert, während jedes andere Konto mit Leserechten problemlos läuft. Das ist die Art von Detail, die einen Nachmittag kostet, wenn niemand vorher warnt.

Build Agent: Claude in die andere Richtung

Lohnt sich, getrennt zu betrachten, denn die Suchintention hinter „Claude für ServiceNow" meint oft genau das.

Build Agent ist ServiceNows Vibe-Coding-Produkt zum Bauen von Apps und Automatisierungen, und Claude ist jetzt das Standardmodell dahinter. ServiceNow erwartet, dass sich die Build-Agent-Nutzung in den nächsten 12 Monaten vervierfacht, und peilt eine Reduktion der Time-to-Implement um 50 % für Kunden mit Claude im Loop an. Das ist Claude, das auf der Plattform baut und Scoped Applications, Flows und Konfigurationen erzeugt.

Die Unterscheidung, die die Community zwischen Build Agent und dem MCP-Weg trifft, ist nützlich. Build Agent basiert auf dem ServiceNow SDK und Fluent, deployt jede freigegebene Änderung in ein eigenes, unabhängiges Update-Set und erzeugt Artefakte tendenziell von Grund auf, weil es für neue Scoped Applications gedacht ist. Ein Table-API-basierter MCP-Server arbeitet mit dem, was schon da ist, und landet Änderungen in deinem aktuellen Update-Set wie jede manuelle Änderung.

Wenn du ServiceNow-Entwickler bist, ist Build Agent wahrscheinlich das interessantere der beiden. Wenn du einen Service Desk betreibst, ist es nicht das Tool, das du gesucht hast.

Niemand überwacht deine Warteschlange

Das ist der Teil, den ich kennen möchte, bevor ich ein Quartal in den Rollout stecke.

Jeder Weg oben wird von einem Menschen initiiert. Eine Person öffnet Claude, tippt einen Prompt, und ein Tool-Aufruf passiert. Es gibt keinen Modus, in dem der MCP-Server bemerkt, dass ein neuer P2 in deiner ITSM-Warteschlange landet, entscheidet, dass er zu einem bekannten Muster passt, eine Antwort entwirft und sie postet. Action Fabrics eigenes Beispiel ist ein Product Manager, der Claude fragt, warum ihm Zugriff fehlt, dann eine Liste prüft und bestätigt. Kontrolliert, auditierbar, nützlich – und trotzdem von einem Menschen ausgelöst.

Diese Lücke wiegt unterschiedlich schwer, je nachdem, wer du bist:

• Ein ServiceNow-Entwickler oder -Admin verliert fast nichts. Du warst ohnehin immer derjenige, der tippt.
• Eine IT-Ops-Führungskraft bekommt einen viel besseren Blick auf die Instanz und schnellere Incident-Zusammenfassungen – das ist echter Wert.
• Ein Service-Desk-Manager, der an Deflection gemessen wird, bekommt direkt gar nichts. Deflection braucht etwas, das antwortet, bevor ein Mensch involviert ist – dafür ist Virtual Agent da, und Virtual Agents eigene Einstiegs-Tier-Grenzen sind ein eigenes Thema.

Wenn du das evaluierst, um die First-Contact-Resolution zu erhöhen oder das Ticketvolumen an einem internen Helpdesk zu senken, ist der MCP-Server das falsche Instrument. Für etwas anderes ist er ein sehr gutes.

Claude oder Now Assist: Wer sollte an deine Instanz ran?

Eigentlich kein Wettbewerb, aber hier ist die Aufteilung, die ich verwenden würde.

Die eine Zeile, die ich unterstreichen würde: Ein Now-Assist-Skill über MCP aufzurufen kostet mehr, als denselben Skill nativ aufzurufen. Wenn ein Skill ohnehin in einem ServiceNow-Workflow laufen soll, route ihn nicht nur der Form halber über Claude.

eesel AI für ServiceNow-Teams

Erst die klare Antwort: eesel hat keine native ServiceNow-ITSM-Integration. Das sage ich lieber gleich offen, statt dich das drei Absätze später merken zu lassen.

Was eesel macht, ist die unbeaufsichtigte Hälfte, die die MCP Server Console strukturell nicht abdeckt. Es verbindet sich mit deinem Helpdesk und deinem Wissen, trainiert auf deinen eigenen vergangenen Tickets und Docs und bearbeitet dann Konversationen eigenständig, statt darauf zu warten, dass jemand ein Chatfenster öffnet und fragt. Das ist das Stück, nach dem ein Service-Desk-Manager meist sucht, wenn er bei einer „Claude für ServiceNow"-Suche landet.

Drei Unterschiede, die wichtig sind, wenn du gerade die Assist-Rechnung oben gelesen hast:

• Du simulierst, bevor du live gehst. eesel lässt den Agenten gegen deine echten historischen Tickets laufen und zeigt dir, was er gesagt und was er gelöst hätte, bevor er eine Live-Warteschlange berührt. Das gibt es, weil ich selbstsicher klingende Bots in Produktion falsche Antworten habe geben sehen, und ein Trockenlauf über echte Historie ist der einzige ehrliche Weg, das vorher herauszufinden.
• Eine Zahl, pro Ticket. 0,40 $ pro bearbeitetem Ticket oder Chat, kein Pool aus Assists mit unterschiedlichen Pro-Skill-Sätzen und einem unveröffentlichten Überschreitungssatz. Du kannst es auf der Rückseite eines Briefumschlags durchrechnen.
• Es funktioniert auch bei internen Desks. eesel übernimmt die interne Seite über Slack, Microsoft Teams und E-Mail. Es liest aus Confluence und anderen internen Quellen, wo ein großer Teil der ServiceNow-nahen ITSM-Automatisierung tatsächlich stattfindet.

Du nutzt ServiceNow und willst sehen, was ein unbeaufsichtigter Agent mit deiner eigenen Ticket-Historie macht, bevor du dich auf irgendetwas festlegst? Genau dafür ist die Demo da, und die Testphase ist kostenlos.

Wo ich landen würde

Wenn du bereits eine Now-Assist-SKU hast, verbinde Claude diese Woche über die MCP Server Console. Das ist eine Stunde Admin-Arbeit, der Quickstart Server gibt dir sofort eine nützliche Lese-und-Zusammenfassen-Oberfläche, und die feldweisen Input-Kontrollen sind bessere Governance, als jeder Community-Server bietet.

Wenn du Now Assist nicht hast und der Kauf dafür genau die Frage ist, sei nüchtern: Du würdest eine Plattform-KI-Stufe lizenzieren, um vier Tools plus einen Baukasten zu bekommen, zusätzlich zu ServiceNow-Lizenzierung, die schon nicht billig ist. Ein Community-MCP-Server ist kostenlos und deckt die meisten Lesefälle ab, auf Kosten fehlender Guardrails und fehlendem Metering.

Und wenn das, was du eigentlich wolltest, weniger Tickets statt bessere Antworten über Tickets waren, bringt dich keiner der vier Wege dorthin. Das ist ein anderes Tool, und es lohnt sich, den Unterschied vor Beginn des Quartals zu benennen statt danach.