Salesforce DX MCP Server: Ende am 2. November 2026

Der lokale Salesforce DX MCP Server hat am 2. November 2026 sein End of Life erreicht, und npm markiert das Paket seit diesem Tag als deprecated. Setzen Ihre Implementierungspartner Claude Code, Cursor, Copilot oder Agentforce Vibes auf Ihren Orgs ein, nutzen einige ihn wahrscheinlich noch. Lassen Sie jede Konfiguration auflisten, Version 0.30.15 fest eintragen, statt immer die neueste zu laden, und die Arbeit auf Salesforce CLI mit Skills, das Claude-Code-Plugin und Hosted MCP umstellen. Wichtiger als das Werkzeug ist für Sie, mit welchem Org-Zugriff es läuft.

Was genau ist am 2. November 2026 zu Ende gegangen?

Das README des Issue-Repositorys forcedotcom/mcp1 und des Quell-Repositorys salesforcecli/mcp2 trägt dasselbe Banner: „End of Life: November 2nd, 2026“. Für Details verweist es auf GitHub-Issue 46. Dieses Issue konnte ich nicht öffnen. Ob die Repositories schreibgeschützt werden, ob das Paket als veraltet markiert wird und ob Sicherheitskorrekturen am Stichtag enden, kann ich Ihnen deshalb nicht sagen.

Am 2. November 2026 hat die npm-Registry das Paket als deprecated markiert, mit dem Hinweis „The Salesforce DX MCP Server has been deprecated“ und einem Link auf Issue 46. Eine neue Version kam nicht: 0.30.15 vom 9. Juli 2026 ist weiterhin die aktuelle (geprüft am 6. November 2026).

Was ich vorher, am 27. Oktober 2026, prüfen konnte:

• Die npm-Registry3 führt 0.30.15 vom 9. Juli 2026 als aktuelle Version. Keine Version trägt bisher einen Deprecated-Hinweis. Seit April 2025 hat Salesforce 121 Versionen einschließlich Vorabversionen veröffentlicht, im Schnitt etwa alle vier Tage eine.
• Der Salesforce DX Developer Guide beschreibt den Server weiterhin ohne Hinweis auf das Ende4. Er konfiguriert das Paket so, dass es immer die neueste Version lädt, „so you always get the latest version“, und neue Versionen werden automatisch installiert.
• Laut Dokumentation von Agentforce Vibes5 wird der DX MCP Server mit Vibes ausgeliefert und ist in Code Builder „installed and enabled by default“.

Vor dem Stichtag stützte sich das Ende allein auf das README-Banner: Keine der drei Dokumentationsseiten oben erwähnte es. Genau diese Kombination ist das Risiko. Ein Server, der sich selbst aktualisiert und auf Rechnern konfiguriert ist, die Sie nicht verwalten, hat seinen Support verloren, während die Anleitungen ihn weiter beschreiben. Was Salesforce unter diesem Namen künftig auf npm veröffentlicht, landet auf diesen Rechnern, ohne dass jemand darüber entscheidet.

Zum Vergleich die Richtlinie für Hosted MCP Server6: Jede Version wird mindestens drei Jahre unterstützt, und das Ende wird mindestens ein Jahr vorher angekündigt. Für den lokalen Server habe ich keine vergleichbare Zusage gefunden.

1. Apr. 2025Erste Versionen des DX MCP Servers auf npm
2. 29.04.2026Hosted MCP Server allgemein verfügbar
3. 09.07.2026Version 0.30.15, die bisher letzte
4. 19.08.2026Ankündigung des Claude-Code-Plugins
5. 02.11.2026End of Life des lokalen DX MCP Servers laut README

Ein Entwicklerwerkzeug mit Org-Zugriff ist Sache der IT-Leitung

MCP (Model Context Protocol) ist der offene Standard, über den ein KI-Werkzeug Funktionen in einem anderen System aufruft. Der DX MCP Server gibt einem Coding-Agenten mehr als 60 solcher Funktionen für Ihre Salesforce-Orgs. Er läuft auf dem Rechner des Entwicklers und nutzt die Orgs, an denen dieser per Salesforce CLI angemeldet ist. Welche Orgs der Agent anfassen darf, legt beim Start eine einzige Einstellung fest. Das README2 nennt die Werte:

• Alle Orgs erlauben öffnet jede auf dem Rechner angemeldete Org; Salesforce schreibt dazu „Use this value with caution.“
• Standard-Org wird bei jedem Tool-Aufruf neu aufgelöst. Wechselt der Entwickler seine Standard-Org, arbeitet der Agent ohne Warnung in der neuen.
• Explizite Benutzernamen oder Aliase binden den Server an benannte Orgs. Nur diese Einstellung akzeptiere ich für Agenten.

Die Werkzeuge hinter dieser Einstellung sind nicht harmlos. Eines deployt in eine Org, eines weist Permission Sets zu, auch für andere Benutzer, eines liest Daten. Telemetrie ist standardmäßig eingeschaltet. Ein Partnerentwickler, der am Montag Ihre Produktion betreut und am Dienstag in einer Sandbox baut, hat womöglich beide Orgs auf demselben Laptop.

Bei einem Hersteller liegen in der Produktions-Org Händlerkonditionen, Garantieanträge, installierte Basis und Wartungsverträge. Einem Integrationsbenutzer würden Sie keine weiten Rechte ohne Prüfung geben. Ein KI-Agent mit der Anmeldung eines Entwicklers verdient dieselbe Prüfung, und das End of Life ist ein guter Anlass dafür. Wie MCP insgesamt in Ihre Architektur passt, beschreibe ich in MCP und Salesforce, erklärt für die IT-Leitung.

Was ersetzt den Salesforce DX MCP Server?

Salesforce hat 2026 drei Bausteine veröffentlicht. Keine der Seiten, die ich geöffnet habe, nennt sie Nachfolger des DX MCP Servers. Die Plugin-Ankündigung7 vom 19. August 2026 erwähnt ihn gar nicht. Die Zuordnung der bisherigen Aufgaben ist meine Lesart:

Was welche Aufgabe übernimmt (meine Lesart)

AufgabeMit dem lokalen DX MCP ServerOption heute

Deployen, abrufen, Tests ausführenMCP-Tools auf dem LaptopSalesforce CLI plus Skills aus sf-skills

Metadatenwissen, Unterstützung für Apex und SOQLMCP-Tools auf dem LaptopClaude-Code-Plugin für Salesforce-Entwicklung

Datensätze als Kontext lesenAbfrage-Tool auf dem LaptopHosted MCP Server zum Lesen von Datensätzen

sf-skills ist eine offene Bibliothek mit mehr als 100 Skills. Das sf-skills-README8 zeigt eine Installation in einer Zeile für Codex, Cursor und Claude Code, in Agentforce Vibes werden die Skills automatisch installiert und aktualisiert. Das README warnt, Skills „may be renamed, restructured, or removed between releases“, und sie haben nicht die Stabilitätszusagen von GA-APIs. Ich würde sie deshalb behandeln wie jede andere Abhängigkeit: Version festhalten, Änderungen prüfen.

Das Claude-Code-Plugin bündelt rund 40 dieser Skills und drei MCP-Server: einen für API-Kontext, einen für Metadatenwissen und einen für die Sprachunterstützung im Editor. Die ersten beiden laufen auf Salesforce-Infrastruktur. Laut Metadata API Guide9 ist der API-Context-Server ein Beta-Service unter den Beta Services Terms, setzt eingerichtetes Hosted MCP in der Org voraus, und seine Aufrufe zählen auf Ihr API-Kontingent. Ihr Admin muss das einschalten. Rechtsabteilung und IT sollten also wissen, dass sie dabei einen Beta-Service freigeben.

Hosted MCP Server sind seit dem 29. April 2026 GA10, für Enterprise Edition und höher. Laut Security Best Practices11 sind sie standardmäßig aus, jeder Aufruf läuft mit den Rechten des Benutzers, der die Verbindung autorisiert hat, und Service Accounts gibt es nicht. Wer darüber welche Daten lesen darf, steht in Hosted MCP Server: wer darf welche Daten lesen, warum die Aufrufe zum Kostenposten werden, in MCP-Zugriffe auf Salesforce als Budgetrisiko.

Rechenbeispiel: drei Partner, ein Stichtag

Nehmen wir einen Maschinenbauer mit Service Cloud, Field Service für den Außendienst und SAP S/4. Drei Partner arbeiten auf denselben Orgs: einer für Service und Außendienst, einer für die SAP-Schnittstelle, eine Agentur für das Händlerportal. Alle Zahlen sind Annahmen, die das Vorgehen zeigen sollen.

Die IT-Leitung bittet jeden Partner um eine schriftliche Antwort auf eine Frage: Wo ist der DX MCP Server eingetragen? Die Antworten ergeben 14 Entwickler, neun davon mit dem Server in einer Konfigurationsdatei. Zwei starten ihn mit Zugriff auf alle Orgs des Rechners. Einer dieser beiden hat auch die Produktions-Org auf seinem Laptop angemeldet, weil er Hotfixes betreut. Der Servicepartner hat eine gemeinsame Konfigurationsdatei ins Repository des Kunden eingecheckt, die immer die neueste Version lädt, jeder neue Entwickler bekommt sie also automatisch. Die Portalagentur arbeitet mit Agentforce Vibes und hatte ihre MCP-Einstellungen nie angesehen.

Fahrlässig ist davon nichts. So sieht es aus, wenn sich ein Werkzeug in Partnerteams verbreitet und niemand auf Kundenseite dafür zuständig ist. Die Korrekturen sind kurz: Die gemeinsame Datei wird auf 0.30.15 gepinnt und bekommt feste Sandbox-Aliase, der Hotfix-Entwickler trennt seine Produktionsanmeldung von der Agentenarbeit, die Agentur prüft, was Vibes einschaltet. Danach testet der Servicepartner Plugin und Skills zwei Wochen in einer Entwicklungs-Sandbox, der Admin des Kunden aktiviert die Hosted Server dort und nur dort, und der alte Eintrag verschwindet aus dem Repository.

Am längsten dürfte die Frage dauern, wer Hosted Server in der Produktion freigibt. Ich würde die Produktion außen vor lassen, bis es einen konkreten Bedarf gibt.

Was sollten Sie Ihre Partner jetzt fragen?

1. Inventur. Lassen Sie sich von jedem Partner auflisten, auf welchen Rechnern, in welchen Repositories und in welchen Werkzeugen der DX MCP Server läuft. Jedes Werkzeug hält die Einstellung in einer eigenen Datei; wo Sie suchen, steht im Kasten unten.
2. Pinnen. Ersetzen Sie jeden Eintrag, der die neueste Version lädt, durch die feste Version 0.30.15 und legen Sie ein Datum für die Entfernung in den nächsten Wochen fest. Eine gepinnte Version hält die Übergangszeit stabil, Korrekturen hat aber niemand zugesagt.
3. Orgs festlegen. Nur benannte Sandboxes, kein Zugriff auf alle Orgs, keine Produktion. Deployments in die Produktion laufen über die Pipeline, wie in Partner coden mit KI: was in den Vertrag gehört beschrieben.
4. Hosted Server bewusst aktivieren. Zuerst in einer Sandbox, der lesende Server vor allem, was schreibt, mit einer External Client App, die auf ein Permission Set beschränkt ist.
5. Repository anpassen. Die gemeinsame MCP-Konfiguration und die KI-Regeldatei gehören in Ihr Repository und ändern sich nur über einen geprüften Pull Request, wie jeder andere Code. Claude Code unterstützt außerdem eine zentral verwaltete MCP-Konfiguration mit Allowlists, wenn Sie es selbst lizenzieren.

Für Entwickler

Wo der DX MCP Server eingetragen ist und wie Sie ihn pinnen

• Paket: @salesforce/mcp; @salesforce/mcp@0.30.15 eintragen statt @salesforce/mcp oder @salesforce/mcp@latest.
• Org-Zugriff: Startparameter --orgs mit festen Aliasen, nie ALLOW_ALL_ORGS oder DEFAULT_TARGET_ORG für Agenten.
• Claude Code: claude mcp list; projektweite Server (öffnet in einem neuen Tab) in der .mcp.json im Repository, lokale und benutzerweite in ~/.claude.json.
• Andere Werkzeuge: VS Code nutzt .vscode/mcp.json, Cursor und Cline eigene Dateien.
• Ersatz: npx skills add forcedotcom/sf-skills, das Plugin salesforce-development mit den Servern salesforce-api-context, salesforce-metadata-experts und salesforce-lsp, der Hosted Server sobject-reads.

Das ist normales Abhängigkeits- und Zugriffsmanagement, angewendet auf KI-Werkzeuge, und es gehört auf Kundenseite zu DevOps und Release-Management. Die übrigen Schnittstellen beschreibt Kapitel 3 der Masterclass.

Quellen11

1. 1forcedotcom/mcp (öffnet in einem neuen Tab)raw.githubusercontent.com
2. 2salesforcecli/mcp (öffnet in einem neuen Tab)raw.githubusercontent.com
3. 3npm-Registry (öffnet in einem neuen Tab)registry.npmjs.org
4. 4ohne Hinweis auf das Ende (öffnet in einem neuen Tab)developer.salesforce.com
5. 5Dokumentation von Agentforce Vibes (öffnet in einem neuen Tab)developer.salesforce.com
6. 6Richtlinie für Hosted MCP Server (öffnet in einem neuen Tab)developer.salesforce.com
7. 7Plugin-Ankündigung (öffnet in einem neuen Tab)developer.salesforce.com
8. 8sf-skills-README (öffnet in einem neuen Tab)raw.githubusercontent.com
9. 9Metadata API Guide (öffnet in einem neuen Tab)developer.salesforce.com
10. 1029. April 2026 GA (öffnet in einem neuen Tab)developer.salesforce.com
11. 11Security Best Practices (öffnet in einem neuen Tab)developer.salesforce.com