Salesforce und Anthropic haben mit Claudeforce ihre Partnerschaft deutlich ausgebaut. Liest man die Ankündigung, könnte man meinen, Claude könne jetzt erstmals direkt mit Salesforce arbeiten.
Das stimmt so allerdings nicht.
Wir verbinden Claude bereits seit Monaten über MCP mit Salesforce. Die technische Brücke gab es also schon vorher. Neu sind vor allem Produktisierung, vorgefertigte Skills, Governance und die strategische Verpackung. Und genau dort liegt aus unserer Sicht die eigentlich interessante Einordnung.
Claude konnte schon vorher mit Salesforce arbeiten
MCP steht für Model Context Protocol. Vereinfacht gesagt ist MCP eine standardisierte Schnittstelle zwischen einem LLM bzw. Agenten und externen Systemen. Statt für jedes Modell eine eigene Integration zu bauen, beschreibt ein MCP-Server gegenüber dem Agenten, welche Tools verfügbar sind und wie sie aufgerufen werden.
Claude / Agent → MCP → Salesforce
Salesforce beschreibt MCP selbst als offenen Standard, über den nicht nur Claude, sondern auch ChatGPT, Cursor oder eigene Agents auf Salesforce zugreifen können. Über MCP kann Claude zum Beispiel:
- Salesforce-Daten abfragen und SOQL verwenden
- Datensätze anlegen, bearbeiten und löschen (CRUD)
- Apex Actions, Flows oder Apex REST APIs als Tools aufrufen
- Metadaten lesen und deployen (je nach Server)
Die interessante Frage ist deshalb nicht, ob Claude mit Salesforce arbeiten kann, sondern über welche Architektur.
Salesforce MCP ist nicht gleich Salesforce MCP
In vielen Diskussionen werden gerade drei Dinge vermischt: ein selbst betriebener Salesforce MCP-Server, die Salesforce Hosted MCP Server und Claudeforce. Oft ist dabei vom „lokalen MCP“ die Rede. Das ist eigentlich die falsche Bezeichnung. Entscheidend ist nicht lokal vs. Cloud, sondern selbst betrieben vs. von Salesforce betrieben.
1. Der selbst betriebene MCP-Server
Hier läuft der MCP-Server in der eigenen Verantwortung. Das kann der Laptop eines Entwicklers sein, aber genauso ein zentraler Server in AWS, Azure, auf einer VM oder in Kubernetes. Bei einem zentral gehosteten Server muss auf den Rechnern der Mitarbeitenden nichts außer dem MCP-Client installiert werden.
Claude / Claude Code / eigene Agents
↓ MCP
eigener zentraler MCP-Server
↓ Salesforce REST · Tooling · Metadata API
Salesforce
Der MCP-Server gehört technisch nicht zur Salesforce-Runtime. Er ist Middleware zwischen Claude und den Salesforce-APIs und enthält die Implementierung der Tools, etwa:
- query_records / describe_object
- create_record / update_record
- deploy_metadata / run_apex
Damit hat man maximale Kontrolle: Man entscheidet selbst, welche Tools bereitstehen, kann eigene Logik implementieren, die Salesforce CLI nutzen, mehrere APIs kombinieren und Salesforce im selben Agenten mit Jira, Bitbucket oder anderen Systemen verbinden.
Der Preis dafür: Betrieb, Authentifizierung, Updates, Security und Tool-Definitionen liegen ebenfalls bei einem selbst. Insbesondere muss man sauber lösen, dass der Agent im Kontext des jeweiligen Benutzers arbeitet, damit Sharing und Field Level Security greifen.
2. Salesforce Hosted MCP Server
Salesforce geht inzwischen einen anderen Weg und betreibt MCP-Server selbst:
Claude → Salesforce Hosted MCP Server → Salesforce Platform
Salesforce stellt dafür Standard-Server bereit, unter anderem für SObjects (alle CRUD-Operationen oder getrennt nach Lesen, Schreiben und Löschen), Data 360 und Tableau Next. Zusätzlich lassen sich eigene Server konfigurieren, über die zum Beispiel Apex-Methoden mit @InvocableMethod oder @AuraEnabled, Flows oder sogar Agentforce Agents als Tools bereitgestellt werden.
Die Authentifizierung läuft per OAuth über eine External Client App, und zwar pro Benutzer. Salesforce bleibt damit für Berechtigungen verantwortlich: Object Permissions, Field Level Security und Sharing bestimmen weiterhin, welche Daten der angemeldete Benutzer über Claude überhaupt erreicht.
Der große Unterschied liegt also weniger im Protokoll. Beide sprechen MCP. Der Unterschied liegt darin, wo die MCP-Schicht läuft und wer sie kontrolliert.
| Self-hosted MCP | Salesforce Hosted MCP | |
|---|---|---|
| Hosting | eigene Infrastruktur (lokal, Cloud, K8s) | Salesforce |
| Installation pro User | nein, wenn zentral gehostet | nein |
| Betrieb & Updates | selbst | Salesforce |
| Tool-Definitionen | vollständig selbst kontrolliert | von Salesforce vorgegeben bzw. konfigurierbar |
| Authentifizierung | selbst implementieren / konfigurieren | OAuth pro User, Salesforce-nativ |
| Sharing & FLS | muss über saubere User-Auth sichergestellt werden | nativ berücksichtigt |
| Eigene Logik | praktisch unbegrenzt | innerhalb der Salesforce-Möglichkeiten |
| Andere Systeme | problemlos integrierbar | Salesforce-zentriert |
| Zusätzliche Salesforce-Kosten | heute keine MCP-Gebühren, API-Limits gelten | Flex Credits können anfallen |
| Vendor Lock-in | geringer | höher |
Für einen einzelnen Entwickler ist ein eigener MCP-Server schnell aufgesetzt. Wer 500 oder 5.000 Mitarbeitende anbinden will, landet aber bei Fragen nach Betrieb, Credential-Management, Versionierung und Security. Hosted MCP macht aus einem Entwicklerwerkzeug zunehmend eine Enterprise-Architektur.
Headless 360: vier Tools statt tausender
Ein grundsätzliches Problem von MCP ist die Anzahl der Tools. Stellt man einem Agenten hunderte Salesforce-Funktionen als einzelne Tools bereit, muss das Modell jedes Mal entscheiden, welches Tool passt. Gleichzeitig verbrauchen die Tool-Definitionen Kontext.
Mit dem Headless 360 MCP Server (seit Juli 2026 in Beta) verfolgt Salesforce deshalb einen anderen Ansatz: Über eine einzige MCP-Verbindung bekommt der Agent nur vier generische Tools: Discover, Describe, Dispatch und Dispatch (Read-Only). Dahinter liegt eine wachsende Bibliothek von Salesforce-Operationen, unter anderem:
- Datensätze abfragen, anlegen und aktualisieren
- Benutzer verwalten und Permission Sets zuweisen
- Apex-Trigger lesen, schreiben und deployen
- Event-basierte Integrationen mit Platform Events und Change Data Capture
- Named Credentials anlegen
Das ist architektonisch deutlich interessanter als „Claude bekommt Zugriff auf Salesforce“. Zum Beta-Start liegt der Schwerpunkt allerdings noch auf Admin- und Setup-Aufgaben.
Was ist an Claudeforce dann tatsächlich neu?
Salesforce und Anthropic machen aus der technischen Verbindung ein gemeinsames Enterprise-Produkt. Der erste konkrete Baustein ist Salesforce in Claude: ein Plugin mit 37 vorgefertigten Sales-Skills, zum Beispiel für Meeting-Vorbereitung, Deal-Health-Reviews oder Pipeline-Analysen. Aktionen laufen dabei über Salesforce, damit Geschäftsregeln weiterhin greifen.
Statt einem Agenten nur generische Tools wie Query, Create oder Update zu geben, bekommt Claude vorgefertigte Fähigkeiten und Salesforce-Kontext. Darunter positioniert Salesforce seine Headless-360-Architektur.
MCP liefert die technische Brücke. Claudeforce liefert zunehmend die fertige Anwendung darauf.
Eine Aussage, die gerade häufig zu lesen ist, stimmt so pauschal übrigens nicht: dass man mit Claudeforce jetzt umfassend schreiben und aktualisieren könne, was vorher nicht ging. Über den SObject-All-Server waren CRUD-Operationen bereits möglich. Gleichzeitig beschreibt Salesforce die Beta von Salesforce in Claude in den Release Notes als read-only, während die Claude-Dokumentation Schreibaktionen mit Freigabe durch den Benutzer beschreibt. Der Funktionsumfang ist also noch in Bewegung.
Gerade dieser Widerspruch zeigt: Claudeforce ist nicht einfach „der bessere Salesforce MCP“. Es ist eine neue Produkt- und Integrationsschicht auf einer technischen Grundlage, die Salesforce bereits vorher geschaffen hat.
Und die Kosten?
Hier wird es wirtschaftlich spannend. Salesforce schreibt ausdrücklich, dass die Hosted MCP Server für Kunden mit Flex Credits vorgesehen sind und die Nutzung abgerechnet werden kann. Zur Einordnung: Flex Credits kosten laut Listenpreis 500 US-Dollar pro 100.000 Credits, eine Standard-Agentforce-Aktion verbraucht 20 Credits, also rund 0,10 US-Dollar. Wie genau eine einzelne MCP-Operation abgerechnet wird, hängt allerdings vom jeweiligen Server bzw. Service ab. Ein pauschales „ein MCP-Call kostet X“ gibt es nicht.
Vereinfacht ergeben sich zwei Kostenmodelle:
Self-hosted: Claude-Tokens + eigene Infrastruktur + Salesforce-Lizenzen
Hosted MCP: Claude-Tokens + Salesforce-Lizenzen + Flex Credits
Die Infrastruktur für einen schlanken MCP-Server ist meist überschaubar. Der größere Posten beim Self-Hosting ist der eigene Entwicklungs-, Security- und Betriebsaufwand. Beim Hosted MCP übernimmt Salesforce genau das, rechnet dafür aber verbrauchsbasiert ab.
Wichtig: Auch Self-Hosting ist nicht dauerhaft automatisch frei von Flex Credits. Salesforce hat sogenannte Headless Platform Interactions angekündigt: Calls von registrierten KI-Agenten, egal ob über MCP oder die normale API, sollen künftig in Produktiv-Orgs Flex Credits verbrauchen. Klassische Integrationen bleiben unverändert, Sandboxes sind ausgenommen, und der Preis-Multiplikator steht noch nicht fest („TBA“). Salesforce will 30 Tage vor Beginn der Abrechnung informieren. Das sollte man bei jeder Architekturentscheidung im Blick behalten.
Zwei Richtungen einer Partnerschaft
In vielen Diskussionen geht unter, dass Claudeforce eigentlich zwei unterschiedliche Bewegungen beschreibt:
- Salesforce → Claude: Salesforce wird über MCP, Headless 360 und fertige Skills für Claude zugänglich.
- Claude → Salesforce: Claude wird als Reasoning-Modell innerhalb des Salesforce-Ökosystems eingesetzt, etwa in Agentforce.
Für uns ist deshalb nicht der Name Claudeforce die spannendste Nachricht, sondern die strategische Richtung dahinter: Salesforce akzeptiert zunehmend, dass die Benutzeroberfläche für Salesforce-Daten künftig nicht zwingend Salesforce sein muss.
Ein Vertriebsmitarbeiter erledigt einen großen Teil seiner Arbeit in Claude oder Slack. Ein Entwickler arbeitet in Claude Code. Ein eigener Unternehmens-Agent orchestriert Salesforce gemeinsam mit weiteren Systemen. Salesforce bleibt dabei System of Record, Berechtigungsinstanz und Plattform für Business-Logik.
Drei Fragen, die Unternehmen jetzt stellen sollten
Die Frage „Kann Claude jetzt mit Salesforce arbeiten?“ ist beantwortet: Das konnte Claude schon vorher. Relevanter sind diese drei:
- Wo soll meine Agent-Infrastruktur liegen? Bei Salesforce oder in meiner eigenen Infrastruktur?
- Wer kontrolliert meine Tools? Salesforce oder wir selbst?
- Wem zahle ich für jede Agent-Aktion? Nur dem LLM-Anbieter und der eigenen Infrastruktur oder zusätzlich Salesforce über ein verbrauchsbasiertes Modell?
Fazit
Claudeforce ist technisch spannend, aber nicht, weil Salesforce MCP erfunden hätte. Spannend ist, dass Salesforce offensichtlich erkannt hat, dass in einer Agent-Welt die entscheidende Position womöglich nicht mehr die Benutzeroberfläche des CRM ist, sondern die Schicht zwischen KI-Agent und Unternehmensdaten. Genau dort positioniert Salesforce gerade Hosted MCP, Headless 360 und Claudeforce.
Für Unternehmen gibt es damit drei Abstraktionsebenen zur Wahl: ein eigener MCP-Server mit maximaler Kontrolle, der Salesforce Hosted MCP mit weniger Betriebsaufwand oder Claudeforce als fertige, produktisierte Experience. Welche passt, hängt von Use Case, Governance-Anforderungen und Kostenmodell ab.
Die eigentliche Veränderung lautet für uns nicht „Claude kann jetzt Salesforce“, sondern: Salesforce entwickelt sich von einer Anwendung, in der Menschen arbeiten, zu einer Plattform, auf der Menschen und externe KI-Agenten arbeiten.
Ihr überlegt, wie ihr Claude oder andere KI-Agenten sicher und wirtschaftlich an Salesforce anbindet? Wir helfen bei Architektur, MCP-Setup und Berechtigungskonzept.
Quellen:
- Salesforce Newsroom: Salesforce and Anthropic Announce Claudeforce (26.08.2026)
- Salesforce Developers: Salesforce Hosted MCP Servers
- Salesforce Developers: Headless 360 MCP Server (Beta)
- Claude Docs: Salesforce-Verbindung
- Salesforce: Flexible Agentforce-Preise mit Flex Credits
Stand: Oktober 2026. Claudeforce, Salesforce in Claude und der Headless 360 MCP Server befinden sich teilweise noch in Beta; Funktionsumfang und Preise können sich ändern.
