Deploying Agentforce with MCP: A Practical Decision Guide for Enterprise Leaders

# Executive summary

Enterprises planning to operationalize AI agents should treat Agentforce as a platform decision plus an interoperability architecture decision. Salesforce’s Agentforce product family positions humans and agents on the same platform (Agentforce Builder, Voice, Dev Tools, AgentExchange, operations tooling), while the Model Context Protocol (MCP) defines a purpose-built protocol for how agents and applications exchange context, discover capabilities, and stream notifications. Use this insight to decide how to deploy Agentforce in a way that satisfies data residency, auditability, and developer velocity constraints today.

Why this decision matters now

• Agentforce is framed as a portfolio: builder, voice, developer tooling, marketplace and operations, meaning adoption is a cross-functional program, not a single-project point solution. (Source: Salesforce Agentforce product pages.)
• MCP provides a standardized data-layer protocol and two transport options (stdio and streamable HTTP) plus discovery, versioning, and notifications; these features materially affect choices about where context lives, how tools are discovered by agents, and how you prove behavior during audits. (Source: Model Context Protocol documentation.)

If you do not explicitly reconcile Agentforce product architecture with MCP-style context plumbing, you risk brittle integrations, heavyweight audit reviews, and slowed developer onboarding.

The current, concrete decision for enterprise leaders

Decision: Approve a two-phase, hybrid MCP-backed Agentforce deployment that (1) pilots Agentforce agents connected to local MCP servers (stdio transport) for regulated customer data and high-trust workflows, and (2) runs non-sensitive agent workloads via centralized MCP servers over Streamable HTTP for scale and shared tooling. Require that all production MCP endpoints implement discovery, capability versioning, and notifications so tools can be audited and governance tooling can subscribe to changes.

Why this is concrete and time-bound

• Local MCP servers using stdio keep sensitive context on-host and avoid network egress risk for regulated data — a defensible approach while policy and controls mature. (MCP supports stdio transport for local hosts.)
• Streamable HTTP is appropriate where centralized, multi-client services improve reuse (shared skills, common tool registries) and where the enterprise can satisfy authentication and network controls. (MCP supports Streamable HTTP with standard auth.)
• Requiring MCP discovery and versioning as part of deployment gives security, legal, and SRE teams explicit artifacts to validate agent capabilities and to detect changes over time.

Authorize: a 12–16 week pilot program under a single product owner, with named engineering, security, and business sponsors. End condition: go/no-go to expand from pilot to program based on integration velocity, traceability of context exchange, and compliance review outcomes.

Implementation checklist (practical steps)

1. Scope pilot use cases
2. - Select one high-value, high-trust use case (e.g., contact-center agent augmentation) and one low-risk, high-volume use case (e.g., marketing content suggestions).

1. Architect hybrid MCP topology
2. - Local: run MCP servers adjacent to Agentforce components using stdio for use cases that require on-host context.
3. - Centralized: run Streamable HTTP MCP servers for shared tools, agent registries, and analytics pipelines.

1. Require MCP primitives and features in deployment
2. - Enforce discovery responses in every MCP server so clients can enumerate capabilities and protocol versions.
3. - Require explicit tool and resource metadata so governance and SRE tooling can ingest capability lists.
4. - Enable notifications and progress-tracking channels so operations can subscribe to changes and long-running work.

1. Security & compliance controls
2. - Define allowed outbound transports (stdio vs Streamable HTTP) by data classification.
3. - Mandate OAuth or equivalent authentication for Streamable HTTP endpoints and keep local connectors in sealed execution environments.

1. Developer & operator playbooks
2. - Document how to register a new tool or resource in the MCP discovery exchange and how to push version changes.
3. - Add runbooks for incident response for agent misbehavior and for rolling back capability versions.

1. Observability & audit
2. - Instrument discovery responses, tool execution requests/responses, and notifications for retention consistent with compliance requirements.
3. - Require signed manifests for production tool registrations to create an auditable chain of custody.

Headless 360 operating-model point of view

Headless 360 views agentization as an operating-model transformation, not just a technology lift. The practical implication is to align three functions before broad rollout:

• Product: Owns use-case selection, ROI definition, and customer experience criteria. Every agent must map to a measurable customer outcome.
• Platform & Engineering: Owns MCP topology, registries, SRE playbooks, and developer experience for building Agentforce agents and skills.
• Risk & Compliance: Owns allowed transport patterns, data residency gates, and artifact retention for discovery and tool execution logs.

Organize a standing Agents Council (product, engineering, compliance, operations) to approve new tool registrations and protocol-version changes. This council’s charter should include a documented emergency rollback path for tool execution and a quarterly review of discovery manifests.

Implementation risks and mitigations

• Risk: Centralized MCP servers become a chokepoint for high-volume agent workloads. Mitigation: Use federated registries and tiered caching for discovery responses; keep high-throughput tools local.
• Risk: Version drift between client assumptions and server capabilities. Mitigation: Enforce capability versioning in discovery and block non-compliant client versions at the gateway.
• Risk: Insufficient telemetry to prove audit claims. Mitigation: Capture discovery and execution events into a tamper-evident log and retain per compliance policy.

Concise FAQ

Q: Do I have to use MCP to run Agentforce?
A: No vendor mandate in the supplied materials requires MCP, but MCP provides a standard protocol for discovery, context, and transport that solves many integration, governance, and observability problems when running agents at scale.

Q: When should we favor stdio over Streamable HTTP?
A: Prefer stdio for local, high-trust, or regulated contexts where you want context to remain on-host. Prefer Streamable HTTP for multi-client, shared services where centralized management, authentication, and scalability are required.

Q: How should we manage upgrades to agent capabilities?
A: Treat capability changes as versioned artifacts surfaced via MCP discovery. Require manifested version numbers, release notes, and a rollback plan. Make approvals part of the Agents Council workflow.

Q: What immediate metrics should leaders ask for from the pilot?
A: Integration lead time (from developer story to production agent), number of registered MCP tools and their owners, and evidence of traceable discovery and execution logs for audit reviews.

References

• https://www.salesforce.com/agentforce/mcp-support/
• https://modelcontextprotocol.io/docs/learn/architecture