In the previous post, I walked through the security model that makes it safe for an AI assistant to call into a Salesforce org. Architecture diagrams are reassuring, but as a teacher I know the moment a concept actually lands: when you see it do something. So today, no theory. Let me show you what happened when I exposed two real Apex actions from my own org as MCP tools and handed them to Claude.
The org belongs to Urla Shoes — a demo business I use for realistic builds: a shoe company selling into Europe, with leads coming in from trade fairs and a reseller channel to manage. Two jobs in that business are repetitive, rule-based, and constantly needed. Perfect candidates.
The two Apex actions
LeadQualificationService: scoring leads the way the business actually thinks
The first action is a lead scorer. Nothing exotic — the kind of logic every org has somewhere, usually half in a flow and half in someone’s head. I wrote it as a single Apex class:
- It scores each lead as Hot, Warm, or Cold based on the signals the business cares about.
- It applies a DACH bonus: leads from Germany, Austria, or Switzerland get extra points, because that’s where Urla Shoes’ strongest reseller network is. A rule that lives in the sales team’s intuition, now living in code.
- For leads that score Hot, it automatically creates a call task so a human follows up while the lead is still warm — pun fully intended.
OnboardReseller: from “we have a deal” to a working account structure
The second action handles what happens after a lead becomes a partner. Onboarding a new reseller at Urla Shoes means creating a whole family of records, consistently, every time:
- It assigns the reseller a tier — Platinum, Gold, or Silver — with the matching commission rate.
- Then it creates the full structure in one pass: an Account for the reseller company, a Contact for the person, an Opportunity for the initial deal, and a Quote to go with it.
Anyone who has watched a new admin hand-create that chain of records — and forget the Quote, or mistype the commission — knows why this deserved to be automated.
The part that makes them MCP tools
Here’s the beginner-friendly secret: I didn’t write anything MCP-specific. Both classes are exposed with @InvocableMethod — the same annotation you’d use to make Apex callable from Flow. Clear method, typed inputs and outputs, and a plain-language description of what the action does.
That’s the whole trick. An invocable action with a good description becomes an MCP tool that an AI client like Claude can discover and call. The description does double duty: it used to be documentation for admins browsing Flow Builder; now it’s also how the AI decides when to use the tool. (If you’ve read my Agentforce posts, this rhymes — the planner reads descriptions too.)
And the security story from last week applies in full. When Claude calls these tools, it authenticates as me, through OAuth with PKCE, and the Apex respects my permissions. No back door was built for this demo.
One sentence in, a whole flow out
Now the moment I’d been building toward. With both tools connected, I typed a single plain-language request into Claude — the natural, slightly rambling way a real person would put it. Something like: qualify this new lead from Munich, and if they’re a fit, onboard them as a Gold reseller with their first opportunity and quote.
Then I watched.
Claude called LeadQualificationService first. The lead scored Hot — the Munich address triggered the DACH bonus, and the other signals were strong. The call task appeared, assigned and dated.
Then, without me re-explaining anything, it moved to OnboardReseller: Gold tier, the correct commission, and then the full chain — Account, Contact, Opportunity, Quote — created and linked. I opened the org and clicked through the records like a skeptical teacher grading homework. Everything was there. Everything was related correctly.
One request. Two tools. An end-to-end lead-to-deal flow that would normally be ten minutes of clicking, or a Flow I’d have to guide a user into finding.
What genuinely surprised me
I expected the tools to work — I wrote them, and invocable Apex is not new. What surprised me was the orchestration. I never told Claude “first call the scorer, then the onboarder.” It read the request, understood that qualification comes before onboarding, and sequenced the calls itself, passing the context from one to the next.
The second surprise was smaller but telling: the conversation around the tools. When information was missing, it asked. When the scoring result came back, it explained it in plain language before moving on. The tools provided the hands; the model provided the judgment about how to use them. My Apex got a better user interface than I ever built for it — a conversation.
The honest limits: where I still keep a human in the loop
Now the teacher’s duty: what I would not let this run unattended, even though it worked beautifully in the demo.
- Tier and commission decisions. The demo assigned Gold because I said Gold. In real life, deciding whether a reseller is Platinum or Silver is a negotiation with money attached. I want the AI to propose a tier with reasoning — and a human to approve it. This is exactly what the consent-before-consequential-actions pattern is for.
- Anything customer-facing. Creating internal records is recoverable. Sending a quote to a real reseller is not. A human reviews before anything leaves the building.
- The scoring rules themselves. The DACH bonus is a business judgment encoded in Apex. The AI applies it; it shouldn’t be the one deciding to change it. Rules evolve in code review, not in conversation.
- Edge cases I haven’t met yet. Duplicate accounts, half-onboarded resellers from last year, leads with conflicting data. The happy path is automated; the weird paths still deserve human eyes, at least until I’ve seen enough of them to codify the handling.
None of these limits are failures of MCP. They’re the same boundaries I’d draw around a talented new hire in week one: full speed on the routine work, a check-in before anything irreversible.
What this example is really teaching
Strip away the novelty and the lesson is very Salesforce-classic: well-designed invocable actions are the unit of automation, and they keep paying off in new contexts. The same class that serves a Flow today serves an AI tomorrow, with security and permissions intact.
If you have solid @InvocableMethod classes in your org right now, you are closer to this demo than you think. Next in the series, I’ll go one layer deeper — grounding the AI in real data with Data 360 and plain SQL, including the anomaly that a single Calculated Insight caught at +64.6%.