Meridian Veterinary Group's imaging partner runs its own external diagnostic AI model that flags abnormal chest X-rays. Meridian's Service agent needs to pull structured findings from that external model into a referral case, and the Salesforce admins want central control over exactly which tool calls and context are allowed to cross the org boundary. Which mechanism should the agent use to consume that external model as a controlled tool?

MCP (Model Context Protocol) is designed precisely for this situation: an Agentforce agent needs to consume an external model or tool as a first-class capability while giving administrators a governed, standardized boundary over what context and tool calls are exchanged. Configuring the agent as an MCP client against the imaging partner's MCP server gives Meridian that control without custom, one-off plumbing.

A custom Apex invocable action calling the partner's REST API directly is the closest-looking trap: it can technically move data, but it is a bespoke, point-to-point integration that has to be hand-built and hand-maintained for every new external system, and it does not give admins the standardized tool/context governance MCP provides out of the box. The Agent API runs the opposite direction from this scenario: it lets an external application call INTO a deployed Agentforce agent, not the reverse of an agent reaching OUT to consume someone else's model. The agent-to-agent protocol only applies when the other party is itself an Agentforce agent reasoning over its own topics and actions; the imaging partner's diagnostic model is a tool/model, not a peer agent, so A2A does not fit.

Remember for the exam: MCP is about an agent (or Salesforce generally) securely sharing context with, or drawing on, external models and tools.