Salesforce opens its AI agents to MCP and Slack

On 21 August, Tech in Asia reported that Salesforce is expanding access to its AI agents through MCP and Slack (Salesforce expands AI agent access via MCP, Slack). The headline sounds corporate, but the technical shift is concrete: the agent stops living inside the Salesforce interface and becomes something another client can call from outside.

Anyone who has built a CRM integration knows why this is not cosmetic. The expensive part was never the model, it was the glue: authentication, object mapping, profile-based permissions, control over what an automated process may write and a record of what it did. MCP moves much of that work from the integrator side to the vendor side.

What exposing agents over MCP means

MCP (Model Context Protocol) is the standard Anthropic published so a model can call external tools through a common contract. An MCP server exposes tools, resources and prompts, and any compatible client discovers and uses them without knowing the API behind them in advance. The practical difference is clear: instead of one connector per pair of systems, one server that works for every client of the standard.

Applied to a CRM, the system stops being a destination the user logs into and starts behaving like a layer of data and actions that gets called. An agent in Claude Code, an assistant inside the IDE or a custom flow can ask for the account, the opportunity or the case without anyone opening a tab.

The Slack side

The other half of the move is Slack, owned by Salesforce since 2021. Bringing the agent into the channel where the team already works solves an adoption problem no demo shows: almost nobody opens the CRM unless they have to. When the answer appears in the thread where the account is being discussed, friction drops sharply.

Risk goes up too, and that is worth saying. An agent with write permissions wired into a channel is an agent anyone with access to that channel can ask for things. Governance stops being a configuration checkbox and becomes design: which scopes, which actions require human confirmation and what gets logged.

Who this is useful for

RevOps teams with data spread across CRM, support and billing: cross queries no longer need a custom report.
Product and engineering teams already living in Claude Code or an IDE with MCP support who want customer context without switching tools.
* Consultancies and integrators: the work shifts from building connectors to designing permissions, limits and approval flows.

For a small team that does not use Salesforce the news still says something: it sets direction. When a vendor this size ships MCP servers, the standard stops being an enthusiast thing and starts showing up in procurement documents.

What we would watch

Three things before taking this to production. Permission granularity: if the server inherits the user profile, fine; if it runs on a service identity with broad rights, it needs to be narrowed by hand. Rate limits and latency, because an agent makes many more small requests than a person and quotas run out sooner than expected. And traceability: knowing which agent wrote what, when and from which instruction is not optional in a system of record.

At ElephantPink we have spent months building custom MCP servers and the pattern repeats: the integration takes days and the weeks go into deciding what the agent is allowed to touch. Salesforce shipping its own saves the first part, not the second.