The specialty hospital's own external research tool wants to securely query Meridian's Agentforce-configured org for read-only referral case status, using a standardized protocol rather than a bespoke point-to-point integration Meridian would have to build and maintain. What should Meridian configure?
Select an answer to reveal the explanation.
Short Explanation
MCP isn't a one-way street - Meridian can be the socket as easily as the plug. Standing up an MCP server here is like publishing an official, governed menu of what the outside tool is allowed to order, instead of handing over the keys to the whole kitchen.
Full Explanation
MCP works in both directions: an Agentforce agent can act as an MCP client consuming an external server, and Salesforce can just as validly stand up its own MCP server exposing specific, governed data and actions to an external MCP client. Since the specialty hospital's research tool wants standardized, read-only access to referral status rather than a bespoke integration, exposing an MCP server is the fit.
Issuing direct login credentials to an external tool is the closest-looking trap because it would technically grant access, but it hands over broad, ungoverned org access rather than a scoped set of capabilities, and it is not a standardized protocol at all. Registering the external tool as an Employee agent misunderstands what an agent type is - Employee agents are for Meridian's own internal staff-facing use cases, not a label to slap on an outside research tool. Building an Experience Cloud site for the tool to scrape is fragile, insecure, and not designed for machine-to-machine consumption; it also was not built for that purpose and would break with any UI change.
Exam takeaway: MCP can flow either direction - Salesforce as client consuming an outside server, or Salesforce as the server exposed to an outside client.