By April 2025, the Model Context Protocol had emerged as a common way for AI applications to discover tools and context. For Salesforce architects, MCP suggested a less bespoke path to connecting agents with enterprise capabilities.
A standard protocol reduces interface friction. It does not decide which records an agent should see, which action is appropriate or who is accountable for the outcome.
Cloud Group point of view
MCP belongs at the discovery and invocation boundary. Business policy, least privilege and transaction integrity remain inside the enterprise service.
A practical playbook
The strongest next step is narrow enough to govern and useful enough to produce evidence. We would structure the work around these moves:
- Expose business capabilities, not raw database operations.
- Give every tool a narrow schema, clear description and bounded output.
- Authorize at invocation time using the acting identity and context.
- Treat external MCP servers as software supply-chain dependencies.
- Log tool selection, arguments, result and downstream transaction ID.
The architecture and operating implication
Wrap Salesforce Flows, Apex services and APIs behind curated tool contracts. Use an enterprise gateway for identity, allowlisting, rate limits and trace correlation. Preserve a channel-independent action catalog so Agentforce and external model platforms can share governed capabilities.
Measure what changes
Model activity is not a business result. Track a small set of indicators that connect behavior to accountable work:
- Tool reuse across agent experiences
- Unauthorized or malformed calls blocked
- Time to integrate a new agent client
- Incidents by server, tool and data class
MCP can make the edge of the enterprise more composable. The architecture still has to make the center accountable.
Primary sources
This field note is grounded in the product and market context available at the time of publication.
