This series started with Claude building a hospital org through six MCP tools, and continued with the loop engineering that made it trustworthy. Today I want to close it with the question I get most often when I show that demo:
“Wait — isn’t this what Agentforce actions are for? Why do you have both?”
It’s a fair question, because on the surface the two look identical: in both cases, an AI decides to call a piece of your Apex, passes it inputs, and uses the outputs. The difference isn’t the Apex. The difference is where the agent lives. Once you see that, the choice becomes easy — and you’ll also see why it’s often not a choice at all.
The one-sentence version
Agentforce actions are for an agent that lives inside Salesforce. MCP tools are for an AI client that lives outside and reaches in.
Everything else in this article is just unpacking that sentence.
When the agent lives inside Salesforce: Agentforce
An Agentforce action is Apex — a class with an @InvocableMethod — that an Agentforce agent can call. The agent runs in your org. It’s a Salesforce citizen.
That citizenship comes with things you don’t have to build:
- The Einstein Trust Layer sits between the model and your data — grounding, masking, guardrails.
- Your service channels are already there. The agent can sit in chat on your website, in your service console, wherever your customers already talk to you.
- Your data is already there. No integration hop to reach the records the agent needs to reason over.
My concrete example: the HanseWatt service agent I run live. It’s an Agentforce agent grounded in Data 360, answering customer questions against real data, inside the org, on Salesforce’s rails. Nobody outside Salesforce ever calls it — customers just talk to it. Its custom skills are exactly this pattern: @InvocableMethod Apex the agent invokes when the conversation needs it.
If your sentence starts with “our customers should be able to…” or “our service team needs an agent that…”, you’re almost certainly describing Agentforce. The agent belongs where the conversation and the data already are.
When the AI lives outside: MCP
Now flip it. In the Hospital Org project, the intelligence wasn’t in the org at all. Claude was the agent — an external AI client — and it needed to reach into Salesforce to deploy objects, run tests, and create records.
That’s what MCP, the Model Context Protocol, is for. With Salesforce Hosted MCP, you expose your Apex as MCP tools, and external clients like Claude can discover and call them. The org stops being where the agent lives and becomes something the agent uses — one tool source among possibly many.
This matters for a class of work Agentforce was never meant for:
- Development and ops loops, like the six deployment tools from this series. The agent orchestrating deploy → test → fix isn’t a service agent; it’s a builder that happens to need org access.
- Cross-system reasoning. An external client can hold tools from Salesforce, your file system, your CI, and your docs in one session. The Hospital Org loop only worked because Claude could plan across all of it.
- Your AI of choice. If your team already works in Claude, MCP brings your org to where the team is — instead of bringing the team into the org.
If your sentence starts with “I want Claude to be able to…”, you’re describing MCP.
The part people miss: it’s the same Apex
Here’s the detail that turns this from a rivalry into an architecture: the same @InvocableMethod can serve both.
An invocable method is just well-described Apex — a name, typed inputs, typed outputs, a description of what it does. Agentforce consumes that shape as an agent action. Hosted MCP exposes that shape as a tool for external clients. One class, two doors.
So the real question is never “should I write this as an Agentforce action or an MCP tool?” Write the invocable method once, describe it honestly, and then decide — per use case — which door to open. Maybe both. A “check room availability” method could serve the HanseWatt-style service agent talking to a patient and a Claude session where an admin is bulk-planning admissions. Same logic, same tests, same governor limits, two callers.
The business logic is the asset. The exposure is a routing decision.
The decision table
When someone asks me which to use, I walk them through this:
| Question | Agentforce action | MCP tool |
|---|---|---|
| Where does the agent live? | Inside Salesforce | Outside (Claude or another AI client) |
| Who is the user? | Customers, service teams — people in your channels | Developers, admins, analysts working in an AI client |
| What’s the interface? | Your service channels (chat, console) | The AI client’s own interface |
| Trust and grounding? | Einstein Trust Layer, grounded in your org’s data (e.g. Data 360) | The client’s context plus whatever your tool enforces |
| Typical job | Answer, resolve, act within a conversation | Build, deploy, analyze, orchestrate across systems |
| What you write | @InvocableMethod Apex | The same @InvocableMethod Apex |
That last row is the punchline. The table isn’t asking you to choose a technology. It’s asking you to name your caller.
An honest caveat
Because the same method can serve both, it’s tempting to expose everything both ways. Don’t — at least not by reflex. Think about each door separately. An external client calling deployment tools is wonderful in a dev sandbox and a very different conversation in production. Ask, for each tool: who can reach this door, and what’s the worst thing they could do through it? The Apex being shared doesn’t mean the exposure decisions are.
Closing the series
Three articles, one arc:
- The demo — Claude built a hospital org through six MCP tools: seven objects in dependency order, three trigger handlers, 92/100/90 coverage, live rules firing.
- The discipline — it worked because of an objective verifier, a binary definition of done, and root-cause diagnosis instead of blind retries.
- The map — Agentforce when the agent lives in your org and serves your channels; MCP when the AI lives outside and reaches in; one
@InvocableMethodserving both.
What’s next for me is pushing on that last idea: taking the invocable methods behind my live agents and opening the second door on the ones that make sense — so the same tested Apex serves a customer in a chat window and a Claude session building the next thing. If you’re starting out, start smaller than I did: one invocable method, honestly described, one caller. The loops can come later.
Thanks for following along. If you build something with either door — or both — I’d genuinely like to hear how it went.