Community MCP servers for Salesforce: what to check

A community MCP server for Salesforce is third-party code that runs with a Salesforce login, so I would approve it like an integration, not like a browser plugin. Before saying yes, check whose identity it uses, where its credentials sit, who maintains it and whether the version is pinned, which tools it exposes, what else runs in the same AI client and which org it reaches. For a person working with Claude, ChatGPT or Cursor on an Enterprise Edition org, Salesforce Hosted MCP is the safer route. Nightly jobs belong in a classic integration.

Why is a community MCP server a different risk?

MCP (Model Context Protocol) lets an AI client call tools in other systems; the basics are in MCP for IT leads. A community server is one that neither Salesforce nor your AI vendor operates: an npm package, a GitHub project or a commercial gateway that connects several systems through one OAuth app.

Nobody reviews these servers for you. Anthropic writes in its Claude Code security page1 that it “does not security-audit or manage any MCP server” and encourages “either writing your own MCP servers or using MCP servers from providers that you trust”. The Hosted MCP security best practices2 from Salesforce cover only its own servers.

Two incidents outside Salesforce show what can go wrong:

• A fake package. The Hacker News reported in September 20253 that the npm package postmark-mcp copied the name of the official Postmark library. According to Koi Security, which found it, version 1.0.16 quietly sent a BCC of every email to the author’s server. It had 1,643 downloads before it was removed.
• A flaw in a bridge. The mcp-remote package, which connects local clients to remote servers, had a vulnerability rated CVSS 9.6, found by JFrog and reported by The Hacker News4. A malicious server could run commands on the developer’s machine. Versions 0.0.5 to 0.1.15 were affected, the package had more than 437,000 downloads, and 0.1.16 fixed it.

I found no published incident with a Salesforce community server. The risk is the same, though, because a developer laptop with a Salesforce login is exactly what such a package reaches.

The tool descriptions add a quieter risk. Simon Willison, citing Invariant Labs, describes tool poisoning5, where “malicious instructions are tucked away in the tool descriptions themselves”, and quotes Elena Cross: “MCP tools can mutate their own definitions after installation.” A server you reviewed in March can behave differently after an update in May.

Approval needs six written answers first

I would ask the partner or developer for written answers to six questions before anyone installs the server.

Check	Question	Red flag
Identity	Which Salesforce user does the server act as?	One shared integration user for many people, or an admin
Credentials	How does it log in, and where is the secret stored?	Username, password and security token in a .env file
Maintainer and version	Who maintains it, and which exact version is installed?	One maintainer, no security policy, @latest
Tools	Which tools does it offer, and which of them write or delete?	Free SOQL, Apex execution, delete tools
Combination	What else runs in the same client?	Web access or email tools next to CRM data
Target org	Sandbox or production, with which data?	Production login on a developer laptop

Identity. Hosted MCP runs every call as the named user, so the audit trail shows a person. A server or gateway that logs in once with a technical user turns this around: your logs show “integration user read 4,000 cases”, and nobody can say on whose behalf.

Credentials. A server that logs in with username, password and security token has two problems. The secret sits on a laptop, and according to Salesforce Time6 Salesforce enforces the retirement of the OAuth username-password flow on 20 February 2027. More on that deadline in password-based integrations end in 2027. A gateway that stores refresh tokens for your org is a third party holding long-lived access, the pattern behind the Salesloft Drift breach covered in connected apps and OAuth lessons.

Maintainer and version. Pin an exact version and review the change before every update. The postmark case shows why: the harmful code came with one specific version.

Tools. Get the full tool list with descriptions. A server that offers one read tool for open cases is a different decision from one that runs arbitrary SOQL or anonymous Apex.

Combination. Willison’s lethal trifecta7 is private data, untrusted content and a way to send data out. He writes that MCP “encourages users to mix and match tools from different sources”. At a machine builder, case descriptions from the dealer portal or warranty forms are untrusted content, see prompt injection in dealer portals.

Target org. Coding agents work in sandboxes. Production changes go through the pipeline, which belongs in the contract, see partners using AI coding: contract rules.

For developers

How does Claude Code help with pinning and new servers?

In Claude Code, an allowlist entry for a local server must match the exact command and arguments (opens in a new tab), so an entry with pkg@1.4.2 blocks any other version. That is my reading of the matching rule, and it turns pinning into something you can enforce.

Claude Code asks for trust verification when a new MCP server appears, but its security page notes this is disabled in non-interactive runs with -p, so a server added to a CI job gets no prompt.

When is Salesforce Hosted MCP the safer route?

Salesforce Hosted MCP Servers are generally available since 29 April 20268 for every Enterprise Edition org and above. For a person who works interactively with Claude, ChatGPT or Cursor, they answer most rows of the table: no third-party code on the laptop, every call under the named user, OAuth with PKCE, servers off until an admin enables them, MCP traffic filterable in the API logs, and an mcp_api scope that gives “access to MCP, but not our existing REST APIs”. What each user may read is covered in hosted MCP servers and data access.

Hosted MCP has limits that drive people to community servers:

• No machine-to-machine access. The security guide says: “There are no service accounts, no machine-to-machine flows”. A nightly agent cannot use it.
• Edition and cost. The overview9 says the servers are “intended only for customers with Flex Credits and you may be billed for server usage”. Why that becomes a budget line is in MCP calls as a budget risk.

Neither limit makes a community server the answer. A nightly job is an integration with its own user and the client credentials or JWT flow. When Agentforce is the client, Trailhead10 describes registering third-party servers in Agentforce Registry, selecting tools and limiting calls through Agentforce Gateway. That governs the agent’s side; the server behind it still needs the six checks.

Worked example: three requests from the partner team

Assume a machine builder with Sales Cloud, Service Cloud, a dealer portal and SAP, Enterprise Edition with Flex Credits, and an implementation partner with six developers. All numbers are assumptions.

Request 1. A developer wants a community Salesforce server from npm in Claude Code, logged in with the integration user’s password, to analyse duplicate assets in the full-copy sandbox. Decision: no to the password and the shared user. He gets sobject-reads through Hosted MCP in that sandbox under his own sandbox user.

Request 2. The service back office wants a commercial gateway that connects ChatGPT to Salesforce and SAP through one OAuth app. Decision: deferred. The gateway would hold refresh tokens for the org, and all 25 users would appear as one technical user. The Salesforce part runs through Hosted MCP, and the SAP part waits for the contract review of the gateway vendor.

Request 3. The partner proposes a community server for a nightly agent that compares dealer stock with SAP. Decision: no MCP. This is an integration with a run-as user and client credentials, built like the order status in Agentforce and SAP order status.

All three needs get met, and no community server reaches the org.

Inventory the MCP servers at every partner

1. Inventory. Ask every partner which MCP servers are configured in their clients for your orgs, including versions. The DX MCP server deadline is a good occasion, see the end of the Salesforce DX MCP Server.
2. Put the rule in writing. Hosted or Salesforce-operated servers by default; community servers only after the six checks, in sandboxes, with a pinned version.
3. Enforce it where you can. If you license Claude Code centrally, managed settings11 with allowedMcpServers and allowManagedMcpServersOnly block every server that is not on your list.
4. Review on every update. A new version is a new approval.

For the inventory, a table with partner, server, version, user and target org is enough. Steering partners on tools like this is part of my partner governance work, and the interface overview is in chapter 3 of the masterclass.

Sources11

1. 1Claude Code security page (opens in a new tab)code.claude.com
2. 2Hosted MCP security best practices (opens in a new tab)developer.salesforce.com
3. 3reported in September 2025 (opens in a new tab)thehackernews.com
4. 4reported by The Hacker News (opens in a new tab)thehackernews.com
5. 5tool poisoning (opens in a new tab)simonwillison.net
6. 6Salesforce Time (opens in a new tab)salesforcetime.com
7. 7lethal trifecta (opens in a new tab)simonwillison.net
8. 8generally available since 29 April 2026 (opens in a new tab)developer.salesforce.com
9. 9overview (opens in a new tab)developer.salesforce.com
10. 10Trailhead (opens in a new tab)trailhead.salesforce.com
11. 11managed settings (opens in a new tab)code.claude.com