Salesforce deployen vanuit Claude, Cursor en Agentforce: wat een native MCP-server verandert

Kort antwoord: een native MCP-server laat een AI-client zoals Claude, Cursor of Agentforce de echte release-acties van je DevOps-platform aanroepen: een deployment plannen, een pull request openen, een metadataconflict oplossen, een pipeline starten. Dat is een andere categorie dan een AI die Apex in een bestand schrijft. Serpent heeft de enige native MCP-server in Salesforce DevOps, en elke deployment die een agent start doorloopt nog steeds een preflight-controle en een menselijke goedkeuring voordat hij productie bereikt.

Wat is een native MCP-server in Salesforce DevOps?

Model Context Protocol is een open standaard om AI-applicaties te koppelen aan tools en databronnen. Salesforce kondigde in juni 2025 MCP-ondersteuning aan over de hele stack, te beginnen met de Salesforce DX MCP Server, de Heroku Platform MCP Server en de MuleSoft MCP Server.

Native is hier het dragende woord. Een native MCP-server wordt gebouwd en beheerd door het platform zelf, bovenop zijn eigen API, en ontsluit de acties die het toch al elke dag uitvoert. Een wrapper-script dat de CLI aanroept is iets heel anders: dat weet niets van je projecten, je omgevingen, je goedkeuringsregels of je audit trail.

Waarin verschilt deployen met een agent van coderen met een agent?

Het grootste deel van het AI-gesprek in het Salesforce-ecosysteem gaat over genereren. Een assistent schrijft een trigger, een LWC of een testklasse, en een mens leest het na voordat er iets mee gebeurt. Zit het model ernaast, dan vangt de code review dat op.

Releasewerk heeft die buffer niet. Een deployment is een toestandswijziging in een live org, en de schade raakt bedrijfsprocessen, niet een opmerking in een pull request. De vraag die telt is dus niet of een model goede Apex kan schrijven. De vraag is of de tools die de agent in handen krijgt veilig aan te roepen zijn, en wat er tussen de intentie van de agent en productie staat.

Dat is een tooling-vraag, geen modelvraag, en precies daar hoort een DevOps-platform in de lus te zitten.

Wat kunnen Claude, Cursor of Agentforce echt doen?

Serpent stelt zijn release-acties beschikbaar als MCP-tools. De vier kernacties:

• plan_deploy: bepalen wat er zou meegaan, van welke branch naar welke org, en de delta tonen voordat er iets draait.
• create_pull_request: de PR openen tegen de juiste branch, met de wijziging gekoppeld aan een work item.
• resolve_metadata_conflict: de botsingen in profiles, permission sets en flows afhandelen die Salesforce-merges zo pijnlijk maken.
• trigger_pipeline: de pipeline draaien zodra een mens heeft goedgekeurd.

Dezelfde server bedient Claude, Cursor, Windsurf, Agentforce, Codex, Cline en GitHub Copilot, want MCP is client-onafhankelijk. Je koopt geen assistent. Je geeft de assistent die je team al gebruikt een set release-tools die hij mag aanroepen.

Waar houdt de eigen MCP-ondersteuning van Salesforce op?

Salesforce is hier snel geweest, en de platformservers zijn oprecht nuttig. Met Salesforce Hosted MCP Servers kan een client sObjects lezen en schrijven, invocable actions uitvoeren en flows starten zonder lokale installatie, en Agentforce heeft een eigen MCP-client.

Wat die servers beschrijven is een org. Wat een release nodig heeft is de laag daarboven:

• Op welke branch deze wijziging staat, en welke omgevingen hij al is gepasseerd.
• Of de doelorg is afgedreven sinds de laatste deployment.
• Wie hem heeft goedgekeurd, en tegen welk work item.
• Hoe je hem terugdraait als het misgaat.

Geen enkele server op orgniveau draagt die context, want die zit niet in de org. Die zit in de pipeline.

Wat weerhoudt een agent ervan iets te deployen wat niet mag?

Vier dingen, en ze zijn bewust saai:

• Eerst preflight. Een deploy wordt gepland en gevalideerd voordat hij draait, dus de agent stelt een concrete change set voor in plaats van een zin.
• Verplichte menselijke goedkeuring. Geen enkele MCP-aanroep promoveert op eigen houtje naar productie. Die goedkeuringspoort is geen instelling waar de agent zich langs praat.
• Geen voetafdruk in je org. Serpent installeert niets in je Salesforce-org en werkt uitsluitend via standaard-API's.
• Een volledige audit trail. Elke actie wordt toegeschreven en gelogd, versleuteld in rust en onderweg met AES-256. Een deploy die een agent start is net zo controleerbaar als een deploy van een mens.

Hoe krijg je het draaiend?

1. Koppel je orgs en je repository aan een Serpent-workspace.
2. Voeg de Serpent MCP-server toe aan de MCP-configuratie van je client, net als elke andere server.
3. Authenticeer met een personal access token; dat koppelt elke agent-actie aan een herleidbare gebruiker.
4. Vraag het in gewone taal: plan de deploy van UAT naar productie voor dit work item.
5. Lees het plan, keur het goed en laat de pipeline lopen.

De MCP-server zit in elk plan, ook in het gratis Essentials-plan, dus je hoeft geen add-on te kopen om te ontdekken of releases via een agent bij je team passen. Bekijk wat Serpent doet.

FAQ

Deployt de AI zelfstandig naar productie?

Nee. Elke promotie naar productie vereist een menselijke goedkeuring, ongeacht welke MCP-client erom vroeg.

Moet ik Git kennen om dit te gebruiken?

Nee. Serpent draait Git op de achtergrond, en de MCP-tools spreken in work items, omgevingen en deployments in plaats van branches en rebases.

Welke AI-clients worden ondersteund?

Claude, Cursor, Windsurf, Agentforce, Codex, Cline en GitHub Copilot. Elke MCP-compatibele client kan verbinden, want het protocol is client-onafhankelijk.

Is dit hetzelfde als de Salesforce DX MCP Server?

Nee, en ze vullen elkaar aan. De Salesforce-servers werken op een org: records, metadata, flows. Serpent werkt op de release: plannen, pull requests, conflicten en pipelines.

Wordt er iets in mijn org geinstalleerd?

Nee. Serpent werkt via standaard Salesforce-API's en installeert geen package, dus het voegt niets toe aan de scope van je eigen security review.