Approve a 90‑Day Headless 360 Pilot: Agentforce + MCP for Governed Agent Interoperability

# Executive Insight: Approve a 90‑day Headless 360 pilot to integrate Agentforce as an MCP client

Enterprises that want to move from bespoke agent integrations to composable, governed agent ecosystems face two immediate platform choices: adopt an open context-exchange standard for agent interoperability, and make that standard a first‑class capability in the CRM surface where agents act. Salesforce’s Agentforce and the Model Context Protocol (MCP) together define that path: Agentforce positions Salesforce as a native MCP client that will discover and consume tools, resources, and prompts from MCP servers; MCP defines the JSON‑RPC data model, primitives (tools/resources/prompts), and two transport options (stdio and Streamable HTTP) for that connectivity. (salesforce.com)

This Insight recommends one specific, time‑boxed decision for enterprise leaders: approve a 90‑day Headless 360 pilot that makes Agentforce the enterprise’s MCP client, prioritizes remote MCP servers over local stdio servers (Streamable HTTP), and operationalizes the governance constructs Agentforce exposes (central registry, auth, rate limits). The goal: validate agentic interoperability, secure cross‑org discovery, and measure integration effort vs. business outcomes before scaling.

Why this is a concrete decision now

• Agentforce intends to provide enterprise‑grade MCP support so agents can access external tools, data, and prompts from third‑party MCP servers — effectively turning Agentforce into a managed MCP client inside your CRM. This surface includes a centralized MCP server registry, fine‑grained access controls, and intelligent rate limiting. (salesforce.com)
• MCP is an open protocol that standardizes discovery, primitives (tools/resources/prompts), stateless per‑request metadata, and transport. It explicitly supports Streamable HTTP for remote MCP servers and stdio for local single‑process servers. That transport choice matters operationally for remote service management, authentication, and scale. (modelcontextprotocol.io)

These two sources together make the tradeoffs clear: if you want to unlock third‑party MCP capabilities at scale across business units you must plan for remote Streamable HTTP servers, a registry and governance layer, and telemetry for rate‑limit and trust enforcement. (salesforce.com)

Headless 360 operating-model point of view

Headless 360 treats the CRM as the agent orchestration plane and a thin execution surface. Concretely:

1. Platform role — Headless 360 will act as the enterprise MCP host coordinator: it registers trusted MCP servers, manages credentials, and enforces org policies at the discovery step. This mirrors Agentforce’s centralized registry and governance model. (salesforce.com)
2. Transport policy — Favor Streamable HTTP for external MCP servers to enable scalable multi‑client hosting, standard HTTP authentication (OAuth/bearer tokens), and server‑side observability; reserve stdio only for single‑machine developer workflows. MCP explicitly describes these transports and their operational tradeoffs. (modelcontextprotocol.io)
3. Primitives and contracts — Treat MCP primitives (tools, resources, prompts) as first‑class service contracts: catalogue them in the Headless 360 registry, version the contracts, and require per‑primitive access policies. MCP’s data layer makes these primitives discoverable via server/discover and per‑request _meta. (modelcontextprotocol.io)
4. Trust, rate limiting, and telemetry — Enforce the same enterprise security posture Agentforce promises: authenticated discovery, granular permissioning, and intelligent rate limiting to protect both CRM and third‑party providers. Surfacing rate‑limit events and discovery changes into Headless 360 monitoring is critical. (salesforce.com)

90‑day pilot plan (decision checklist)

• Scope: Select one high‑value use case (e.g., service agent using external logistics MCP server to resolve delivery ETA) and two MCP partners listed in your AgentExchange shortlist. Use AgentBuilder to assemble the agent workflow. (salesforce.com)
• Architecture: Configure Headless 360 as the MCP host/coordinator; connect Agentforce as the native MCP client; prefer Streamable HTTP connections to remote MCP servers and use stdio only for dev. Confirm the MCP version compatibility and per‑request metadata usage. (modelcontextprotocol.io)
• Governance: Provision a centralized MCP registry, implement OAuth/bearer token flows for MCP servers, and define per‑primitive RBAC and rate limits (Agentforce’s model). Add automated policy checks to the discovery sequence. (salesforce.com)
• Observability & ROI metrics: instrument discovery, tool execution latency, rate‑limit events, agent confidence / grounding signals, and business KPIs (time to resolution, % of cases requiring human escalation). Capture integration hours and developer effort to compare against expected ROI. (salesforce.com)
• Gates & scale: Gate scale‑up on (a) security audit pass, (b) <X integration days for partner connectors (define X locally), and (c) telemetry showing stable rate‑limit behavior. If gates pass, move to 6‑month rollout across additional business units.

Operational risks and mitigations

• Authentication complexity: Streamable HTTP requires enterprise token management (OAuth) — mitigate by reusing Headless 360 identity provider integrations and central secret rotation. MCP recommends OAuth for Streamable HTTP. (modelcontextprotocol.io)
• Over‑discovery / unauthorized access: Use the centralized MCP registry to whitelist servers and enforce cross‑org scoping and least privilege (Agentforce capability). (salesforce.com)
• Service overload: Enforce rate limits and backpressure at the Headless 360 gateway; Agentforce highlights optimized resource management through rate limiting. (salesforce.com)

Quick implementation checklist for the engineering lead

• Register Headless 360 in your org as the MCP coordinator and add initial MCP servers to the registry via AgentExchange. (salesforce.com)
• Configure Streamable HTTP endpoints for selected MCP partners; validate server/discover and tool/resource discovery flows per MCP spec. (modelcontextprotocol.io)
• Define RBAC, policy enforcement, and rate limits in Headless 360; add telemetry for discovery and tool execution. (salesforce.com)
• Run integration tests that validate per‑request _meta behavior and stateless discovery handling as described by MCP. (modelcontextprotocol.io)

Concise FAQ

Q: What is the immediate benefit of integrating Agentforce with MCP?
A: It unlocks standardized discovery and safe access to third‑party tools, data, and prompts so agents can act on enterprise and external capabilities without bespoke integrations. (salesforce.com)

Q: Which transport should we choose for production — stdio or Streamable HTTP?
A: For production, choose Streamable HTTP for remote MCP servers (scales to many clients and supports standard HTTP auth). Reserve stdio for single‑machine developer/debug use. (modelcontextprotocol.io)

Q: How does Headless 360 reduce integration effort?
A: By centralizing MCP server discovery and governance (registry, auth, rate limits), Headless 360 makes third‑party capabilities plug‑and‑play within Agentforce and reduces bespoke connector work. (salesforce.com)

References

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