Een Salesforce MCP-server opzetten in je DevOps-workflow

Kort antwoord: een Salesforce MCP-server opzetten kost drie beslissingen en ongeveer tien minuten configuratie. Kies de server (lokale Salesforce DX, een gehost Salesforce-endpoint, of die van je DevOps-platform), wijs je AI-client ernaar met een expliciete lijst van geautoriseerde orgs, en versmal daarna de toolsets tot de kleinste set die het werk doet. Wat langer duurt dan tien minuten, en wat de meeste handleidingen overslaan, is bepalen welke acties de agent zelfstandig mag uitvoeren en welke achter een mens blijven.

Wat is een Salesforce MCP-server?

Het Model Context Protocol is een open standaard om tools beschikbaar te maken aan een AI-client. Een MCP-server voor Salesforce zet handelingen die je normaal via de CLI of een UI doet om in tools die een assistent kan aanroepen: een org bevragen, metadata ophalen, Apex-tests draaien, een pull request openen, een deployment plannen. De client bepaalt wat hij aanroept, de server bepaalt wat er bestaat en wie het mag aanroepen.

Voor DevOps is dat kader belangrijk. De server is je beleidsgrens. Alles wat je blootstelt, zal het model uiteindelijk proberen.

Welke Salesforce MCP-server kies je?

• Salesforce DX MCP Server. Draait lokaal met credentials die je al via de Salesforce CLI hebt geautoriseerd. Het beste voor developers die met metadata, data en tests werken. Package: @salesforce/mcp.
• Gehoste Salesforce MCP-servers. Cloud-endpoints via OAuth, voor wie de CLI niet lokaal wil installeren. Zie de MCP-aankondiging van Salesforce voor de hele stack, inclusief Heroku- en MuleSoft-servers.
• De MCP-server van je DevOps-platform. Dit is degene die telt voor releasewerk, want daar leeft de deployment, niet in de org. De native MCP-server van Serpent biedt pipeline-acties als plan_deploy, create_pull_request, resolve_metadata_conflict en trigger_pipeline aan Claude, Cursor, Windsurf, Codex, Cline, GitHub Copilot en Agentforce.

De meeste teams draaien er uiteindelijk twee: een voor orgwerk, een voor releasewerk. Ze beantwoorden andere vragen.

Hoe zet je de Salesforce DX MCP-server op?

1. Autoriseer eerst de orgs. Draai sf org login web per org. De MCP-server kan alleen bij orgs die de CLI al kent, en dat is je eerste en goedkoopste controle.
2. Zet de server in de config van je client. Een minimale entry ziet er zo uit: {"mcpServers":{"Salesforce DX":{"command":"npx","args":["-y","@salesforce/mcp","--orgs","DEFAULT_TARGET_ORG","--toolsets","orgs,metadata,data"]}}}
3. Scope de orgs expliciet. De vlag --orgs is verplicht. Hij accepteert DEFAULT_TARGET_ORG, DEFAULT_TARGET_DEV_HUB, expliciete usernames of aliassen, en ALLOW_ALL_ORGS. De documentatie van Salesforce markeert die laatste waarde als iets om voorzichtig mee te zijn. Neem die hint aan.
4. Versmal de toolsets. --toolsets selecteert functionele groepen in plaats van alles te laden. Er zijn er meer dan vijftien, waaronder orgs, metadata, data, users, testing, devops en code-analysis. all aanzetten werkt en wordt afgeraden, want elke tool die je laadt kost context die het model kon gebruiken om na te denken.
5. Laat niet-GA-tools uit. Tools zijn gemarkeerd als GA of niet-GA, en de laatste vereisen --allow-non-ga-tools. Zet die vlag niet aan in een repo die anderen klonen.

Hoe regel je authenticatie?

Lokale servers erven CLI-credentials, wat handig is en betekent dat de blast radius van de agent gelijk is aan die van de developer. Gehoste servers gebruiken OAuth met PKCE via een External Client App, en dat is het juiste model als je een aparte identiteit met eigen scopes wilt.

De regel die in beide gevallen standhoudt: de MCP-identiteit mag geen gedeelde admin zijn. Geef hem een eigen user, een eigen permission set en niet meer objecttoegang dan de tools die je hebt aangezet echt nodig hebben. Als je agent een datatool kan aanroepen, ga er dan van uit dat hij dat een keer doet.

Welke acties horen achter menselijke goedkeuring?

Hierover hoor je in je team te discussieren, niet het uit een blog over te nemen. Een werkbare standaard:

• Veilig te automatiseren: metadata lezen, objecten beschrijven, SOQL tegen sandboxes, Apex-tests draaien, een deploymentplan genereren, een pull request openen, een samenvatting posten.
• Altijd menselijk goedgekeurd: deployen naar productie, een packageversie uitbrengen, massale databewerkingen, metadata verwijderen of overschrijven, een conflict oplossen op een manier die andermans wijziging weggooit.
• Helemaal niet blootstellen: credentialbeheer, gebruikersprovisioning, alles wat een productieorg raakt zonder rollbackpad.

Het belangrijkste ontwerppunt: goedkeuring hoort in de server te zitten, niet in de prompt. Een model dat is geinstrueerd om eerst te vragen, vraagt bijna altijd eerst, en "bijna altijd" is geen controle. De MCP-server van Serpent draait preflight checks en vereist menselijke goedkeuring voordat een deployment uitvoert, zodat de grens door het platform wordt afgedwongen en niet door goede manieren.

Hoe ziet dit eruit in een echte pipeline?

Een typische lus: de developer vraagt de assistent een release voor te bereiden. De agent leest de diff, roept de plantool aan en komt terug met de componenten, de tests die hij gaat draaien en de risico's die hij vond. Een mens leest dat plan en keurt het goed. De agent start de pipeline, kijkt mee en rapporteert het resultaat. Elke schrijfactie is auditbaar, en de mens was twee minuten kwijt in plaats van veertig.

Begin met een repo en een sandbox. Breid toolsets pas uit als een echte taak faalt bij gebrek aan een tool. Meer Salesforce DevOps-gidsen behandelen de pipelinekant hiervan in detail.

FAQ

Heb ik de Salesforce CLI nodig voor MCP?

Voor de lokale Salesforce DX MCP-server wel, want die gebruikt CLI-credentials. Gehoste MCP-servers gebruiken OAuth en vereisen geen lokale CLI-installatie.

Kan een MCP-server naar productie deployen?

Technisch wel, en juist daarom hoort hij dat niet onbewaakt te doen. Houd productiedeploys achter een goedkeuringsstap die de server afdwingt, niet de prompt.

Welke toolsets zet ik als eerste aan?

Begin met orgs, metadata en data. Voeg testing toe zodra je de agent Apex-tests wilt laten draaien, en devops-tooling zodra de read-only lus vertrouwd is.

Is MCP veilig voor gereguleerde omgevingen?

Dat kan, mits de agent een eigen identiteit, least-privilege-rechten, een audittrail en een menselijke poort op schrijfacties heeft. Behandel hem als elke andere integratiegebruiker, want dat is hij.