MCP vs API: The Complete Comparison

 

Introduction

If you've spent any time around AI tools recently, you've probably heard both terms thrown around: API and MCP (Model Context Protocol). They sound like competitors, and a lot of content online treats them that way — but that framing is misleading.

APIs are the foundation. MCP is a standardized way of using them.

This piece walks through the comparison in three layers — a holistic overview, a beginner-friendly breakdown, and an expert-level technical dive — so it works whether your audience is brand new to the topic or already building with it.

Part 1: The Holistic Picture

Before diving into detail, here's the core shift in one sentence:

APIs let two systems talk. MCP lets an AI model discover and use any number of systems without custom code for each one.

The Old World vs. The New World

Diagram 1 — Traditional API integrations (the N×M problem):

Every application that wants to talk to Slack, GitHub, Google Drive, a database, and Stripe needs five separate, custom-built integrations. Add a second application, and you're maintaining ten. This is the classic N×M integration problem — N applications × M services = a combinatorial mess of glue code.

Diagram 2 — The MCP architecture (standardized layer):

MCP inserts a common protocol layer in the middle. Any MCP-compatible application can talk to any MCP server, and any MCP server can expose its tool to any compatible application. The N×M problem becomes an N+M problem.

Quick Comparison Table

Aspect	API (Traditional)	MCP
What it is	A contract for two systems to exchange data	A standardized protocol for AI models to discover and use tools/data
Integration effort	Custom code per API, per app	Build once, reuse across any MCP-compatible app
Designed for	General software-to-software communication	AI models and agents specifically
Discovery	Manual — you read docs to know what's available	Dynamic — the AI can query what tools/resources exist at runtime
Authentication	Varies wildly per provider (keys, OAuth, tokens)	Still uses underlying auth, but exposed through one consistent interface
Maintenance	Breaks independently per integration	Centralized — update the server, all clients benefit
Best fit	Two known systems with a fixed, stable relationship	AI agents that need flexible, on-demand access to many tools

Part 2: For Beginners — Start Here

What is an API, really?

Think of an API (Application Programming Interface) like a restaurant menu. You (the app) don't walk into the kitchen (the other system) and cook the food yourself. You order from the menu, the kitchen prepares it, and a waiter (the API) brings it back. It's a defined, limited set of things you're allowed to ask for.

Example: A weather app calls a weather API. It sends "give me the forecast for Bengaluru," and gets back structured data — temperature, humidity, forecast. Nothing more, nothing less.

What is MCP, really?

MCP is like giving your AI assistant a universal adapter plug instead of needing a different plug shape for every country you visit. Instead of the AI needing custom wiring for Slack, custom wiring for GitHub, and custom wiring for your database, it plugs into one standard socket — and any tool that supports that socket just works.

Example: An AI assistant connected via MCP to your Google Drive, calendar, and Slack can look at all three, decide what it needs, and pull it — without a developer having written custom code specifically wiring the AI to each of those three services.

The Simplest Way to Remember It

• API = a specific doorway into one specific building.
• MCP = a master key system where the AI can be handed the right key to any building that supports the same lock.

MCP is actually built on top of APIs — an MCP server usually calls real APIs behind the scenes. So beginners shouldn't think "MCP replaces APIs." Think: "MCP standardizes how AI reaches APIs."

Part 3: Intermediate — How They Actually Work Together

At this level, it helps to see the layers:

1. The Service (e.g., GitHub) exposes an API — the raw functionality (create issue, list repos, merge PR).
2. The MCP Server wraps that API in a standard format: it declares "tools" (actions), "resources" (data), and "prompts" (reusable templates) that any MCP client can understand.
3. The MCP Client (built into the AI application) talks to that server using the same protocol regardless of which service is on the other end.
4. The AI Model decides, based on the user's request, which tool to call and with what parameters — it doesn't need to know GitHub's specific API shape, just MCP's shape.

Where the real value shows up

Scenario	With Raw APIs	With MCP
Add a new tool (e.g., Notion) to your AI assistant	A developer writes new integration code	Point the assistant at Notion's existing MCP server — often zero new code
AI needs to decide which tool to use for a task	Developer must hard-code logic/routing	The model sees all available tools' descriptions and chooses dynamically
Switching AI providers (e.g., Claude to another model)	Integration code may need to be rewritten per model's API-calling style	MCP servers stay the same; only the client changes
Debugging a broken connection	Have to check that one specific API's docs, auth, and rate limits	Consistent protocol errors and structure across all servers

Part 4: Expert — The Technical Details

Protocol Mechanics

MCP is a JSON-RPC 2.0-based protocol, typically transported over stdio (local processes) or HTTP/SSE (remote servers). It defines three primitives on the server side:

• Tools — model-callable functions with a defined input schema (the model can invoke actions, like create_issue(title, body)).
• Resources — addressable, read-only data the client can fetch (like a file, a database row, a document).
• Prompts — reusable, parameterized prompt templates the server can expose to guide how a client uses it.

Compare that to a typical REST API, which just defines endpoints, verbs, and response schemas — with zero built-in concept of "this is meant for an autonomous agent to reason about."

Where APIs still win

• Performance-critical, fixed integrations. If you're building a payment pipeline with Stripe and the relationship will never change, a direct API integration is leaner — no protocol overhead, no extra abstraction layer.
• Fine-grained control. Raw API access lets you handle retries, pagination, and rate-limiting exactly how you want. MCP servers add a layer you don't always control.
• Non-agentic software. If there's no AI model deciding what to call and when, MCP provides no benefit — it exists specifically to help models reason about and select tools.

Where MCP wins decisively

• Multi-tool agentic systems. Any system where an AI is expected to autonomously choose between many tools across many services.
• Ecosystem reuse. Once someone builds an MCP server for a service, every compatible AI application can use it — this is the same leverage that made USB or HTTP powerful as standards.
• Governance and auditability. Because tool calls flow through a consistent protocol, it's easier to log, permission, and sandbox what an AI is allowed to touch — critical for enterprise deployments.

Architectural Note

MCP does not eliminate APIs — it sits as an abstraction layer on top of them. An MCP server for Salesforce still ultimately calls Salesforce's API underneath. The skill shift for engineers isn't "learn MCP instead of APIs" — it's "learn to expose your existing APIs through an MCP server so agentic systems can use them safely and dynamically."

Summary Table: The Full Spectrum

Level	Core Idea
Beginner	API = a menu you order from. MCP = a universal plug so AI can order from many menus without custom wiring.
Intermediate	MCP standardizes how AI clients discover and call tools; it's built on top of existing APIs, not a replacement for them.
Expert	MCP is a JSON-RPC protocol exposing tools/resources/prompts specifically designed for model-driven tool selection; APIs remain better for fixed, high-performance, non-agentic integrations.

A good way to land this for viewers: "Don't ask whether to use MCP or an API — ask whether you're building for a human-defined fixed workflow (use an API directly) or an AI agent that needs to flexibly choose between many tools (wrap those APIs in MCP)."

lets Built a Multi-Agent Telecom AI Assistant on Salesforce — Then Gave Claude Access to It Too

Lets Built a Multi-Agent Telecom AI Assistant on Salesforce — Then Gave Claude Access to It Too

Most Agentforce demos you see online are a single agent answering FAQ questions. This is a capstone project I built to go further: a team of four coordinated agents that diagnose network outages, explain bills, walk customers through SIM replacement with real identity verification, and — the part I'm most excited to share — can be reached directly from Claude through a Salesforce MCP server. Here's the full build, architecture, and what I learned shipping it.

TL;DR: One customer-facing Orchestrator agent routes conversations to three specialists — Network Diagnostics, Billing & Plan Advisor, and Technical Support — all written in Agent Script, grounded in real Salesforce data, and backed by RAG for device manuals and policy documents. It's deployed two ways: as a live chat widget on an Experience Cloud self-service portal, and as a connector any Claude user can talk to via a Salesforce MCP server. Compliance isn't an afterthought — SIM replacement enforces KYC verification and OTP validation in the script itself, with mandatory human escalation on any failure.

The Business Problem

Telecom support has a shape most industries don't: the same customer conversation can touch a network outage, a confusing bill, and a broken modem in the same five minutes — and somewhere in there they might also need to replace a lost SIM, which means real identity verification, not just a friendly chatbot. A single-purpose bot answers one of those well and shrugs at the rest. The brief behind this capstone was explicit about that: multi-agent orchestration for support, diagnostics, and billing; RAG grounding against device manuals and service policies; omnichannel delivery through an Experience Site; and Agent Script-driven workflows for identity verification, SIM replacement, and number portability — the exact places where a hallucinating agent would be a genuine liability, not just an inconvenience.

Architecture at a Glance

The design keeps one agent owning the whole conversation. Instead of bouncing the customer between bots, the Orchestrator delegates to specialists as tools and keeps the context and the relationship — so a customer can mention a network issue and a billing question in the same thread without repeating themselves.

Four layers, top to bottom:

• Channels — the Experience Site chat widget, Claude via MCP, and voice.
• Orchestrator — a single Agent Script file that greets the customer, verifies identity, classifies intent, and hands off.
• Specialist subagents — each scoped to one domain, each with its own reasoning instructions and its own action list.
• Actions and data — Apex invocable actions, Flow actions, and knowledge/RAG retrieval, all sitting on top of standard field-level security so the agent never sees more than the requesting user could.

Meet the Agent Team

Agent	Job	Guardrails baked in
Orchestrator (Agent Router)	Greets the customer, confirms identity, classifies intent, routes to the right specialist, logs every routing decision	Never exposes internal object or API names to the customer; never invents an answer instead of pulling real data
Network Diagnostics	Checks outages by zip code, walks through device-specific troubleshooting, opens a ticket only after a remediation attempt fails	Won't open a duplicate ticket for an outage already being tracked
Billing & Plan Advisor	Explains invoices line by line, recommends plans based on real usage history, executes plan changes	Only processes a change through the dedicated Flow action, and only after the customer explicitly confirms the new plan and price
Technical Support	Device setup, Wi-Fi/modem troubleshooting, broadband installation scheduling, SIM replacement and activation	Never bypasses KYC, never skips OTP, caps retries at three attempts, escalates every security failure to a human

The Data Model Behind It

Nothing here is fictional plan copy — every answer the agent gives is grounded in actual records:

Object	Purpose
Account (Person Account)	Subscriber profile, KYC status, fraud risk flag
Product2	Plan catalog — data limit, price, contract term
Subscription__c	The customer's current plan/line
Device__c	Registered devices, warranty, firmware version
SIM__c	SIM/eSIM status and replacement history
Invoice__c	Billing history, payment status, late fees
Case	Service tickets, including agent-created diagnostics
OTP_Verification__c	Hashed OTP storage for identity checks
Network_Outage__c	Outage data keyed by zip code

Inside the Agent Script

This is where the project earns the "engineering," not just "prompting." Here's a trimmed, cleaned-up look at the Orchestrator's router logic:

start_agent agent_router:
  label: "Agent Router"
  description: "Welcome the user and determine the appropriate subagent based on user input"

  reasoning:
    | - Always greet the customer and confirm their identity before discussing
    |   any account-specific detail.
    | - If the user asks about a network_issue -> hand off to Network_Diagnostics_Agent.
    | - If the user asks a billing_question or requests a plan_change ->
    |   hand off to Billing_Plan_Advisor_Agent.
    | - If the user asks about technical_support (device/Wi-Fi/modem) ->
    |   hand off to Technical_Support_Agent.
    | - If the user asks about sim_replacement or number_portability ->
    |   invoke the corresponding subagent.
    | - Never expose internal system names, DMO names, or raw API responses
    |   to the customer.
    | - Never answer from a generic assumption — always answer from real
    |   retrieved data.
    | - Log every routing decision via the Log_Interaction action before closing.

    actions:
      go_to_Network_Diagnostics_Agent: @utils.transition to @subagent.Network_Diagnostics_Agent
      go_to_Billing_Plan_Advisor_Agent: @utils.transition to @subagent.Billing_Plan_Advisor_Agent
      go_to_Technical_Support_Agent: @utils.transition to @subagent.Technical_Support_Agent

Notice the two rules that do the most work: never expose internal system names and never answer from assumption. Those two lines are the difference between a demo and something you'd actually let a paying customer talk to — they force every specialist to ground its answer in a real Apex or Flow action instead of the model's own guess.

Compliance You Can Trust: The SIM Replacement Walkthrough

SIM replacement is the highest-stakes flow in the whole agent — get it wrong and you've handed a stranger someone else's phone number. So it's scripted deterministically, not left to the model's judgment:

The rules that make this safe are stated explicitly in the script itself, not just implied by good intentions:

• Never bypass KYC verification. If KYC_Status__c isn't Verified, processing stops immediately and the case escalates to a human — no exceptions.
• Never skip OTP validation, and never generate a random OTP and hand it to the customer directly — it's only ever sent to the registered email.
• Cap retries at three attempts. A fourth failed OTP entry escalates automatically.
• Every security-related failure escalates. The agent is never the last line of defense on identity.

That's the pattern worth stealing for any regulated workflow you put behind an agent: let the LLM handle the conversation, but let hard-coded logic — not model judgment — own the parts where being wrong actually hurts someone.

Going Live: Two Ways In

1. The Experience Cloud Self-Service Portal

This is the channel real customers use:

1. Enable Messaging Settings in Setup.
2. Configure Routing Configuration.
3. Create a Queue with Messaging Session as a selected object.
4. Build and publish a site in Experience Builder.
5. Commit and activate the service agent you want to deploy.
6. Create a new channel under Messaging Settings.
7. Create and publish an Embedded Service Deployment.

Once that's live, the chat widget on the portal is the Orchestrator — customers never know how many specialist agents are working behind it.

2. Bringing the Agent to Claude via MCP

This is the part worth a second look, because it's not something most Agentforce tutorials show: the same agent, reachable from Claude through a standard Salesforce MCP server.

1. In Setup, go to External Client App Manager and create a new external client app (e.g., "Claude Integration").
2. Enable OAuth settings, and set the callback URL to Claude's standard MCP callback: https://claude.ai/api/mcp/auth_callback.
3. Grant the OAuth scopes that matter here: Perform requests at any time (refresh_token, offline_access) and Access Salesforce hosted MCP servers (mcp_api).
4. Under Security, require PKCE for supported authorization flows, and issue JWT-based access tokens for named users.
5. Copy the Consumer Key and Consumer Secret.
6. In Claude, go to Settings → Connectors → Add Custom Connector, and paste in the org's MCP URL along with the Client ID and Client Secret.
7. Set tool permissions to Always allow, start a new chat, and confirm the connector is enabled for that conversation.

From that point on, anyone with the right access can ask Claude a question and have it reach into the same Salesforce org — same data model, same guardrails — through the org's MCP server, instead of only through the chat widget on the portal.

What Building This Taught Me

A few things stood out that don't show up in the Trailhead version of Agentforce:

• Guardrails belong in the script, not the prompt. "Never bypass KYC" reads like an instruction, but it only works because it's enforced as a deterministic branch, not a polite request to the model.
• Multi-agent only feels seamless if one agent owns the conversation. The moment you let the customer talk to three separate bots instead of one Orchestrator quietly delegating, the experience falls apart.
• MCP turns an agent into a platform. Once the Orchestrator is reachable through a standard MCP server, it stops being "a chatbot on our website" and becomes a capability other tools — like Claude — can use directly.

What's Next

Number portability is the next workflow to script the same way SIM replacement was — same compliance shape, different regulatory checks. I'd also like to push Data Cloud further upstream, so the Network Diagnostics subagent is reasoning over live telemetry instead of a periodically-updated outage object.

If you're building something similar — or you've hit the same "guardrails in the script vs. the prompt" question — I'd love to hear how you approached it in the comments.