All 22 chapters
  1. Part 01 — Your First Day with AI
  2. Part 02 — The Developer's Toolkit
  3. Part 03 — Building Your First Project
  4. Part 04 — Leveling Up
  5. Part 05 — The Agent Era
  6. Part 06 — The Big Picture
Chapter 12 Part 04 — Leveling Up

MCP vs API

Two ways AI connects to the world — and when to use which.

Dennis Vorobyov
Dennis Vorobyov
Founder & CEO, EltexSoft

Here’s a problem I kept running into.

I’d set up Claude Code to work on a project. It could read and write files. It could run commands. But the moment I needed it to check our Supabase database, or look at a Vercel deployment log, or create a GitHub issue, it was blind. I had to leave the terminal, open a browser, find the information, copy it back, and paste it into the conversation. I was the world’s most overqualified copy-paste clerk.

MCP fixes this. It gives AI tools a standardized way to connect to external services and use them directly. Instead of copy-pasting a deployment error from the Vercel dashboard, I ask Claude Code “why did the last deploy fail?” and it reads the logs itself.

That might sound like a small convenience. It’s the difference between an AI assistant that can only read your files and one that can operate your entire development stack.

What MCP is

MCP stands for Model Context Protocol. Anthropic released it in November 2024 as an open standard for connecting AI models to external tools and data. By April 2026, it’s been adopted by OpenAI, Google, Microsoft, and AWS, and is governed by the Linux Foundation’s Agentic AI Foundation. Over 10,000 public MCP servers exist, with 97 million monthly SDK downloads.

The best analogy: MCP is USB-C for AI. Before USB-C, every device had its own connector. Before MCP, every AI tool needed its own custom integration for every service. If you had M AI applications and N services, you needed M × N custom integrations. MCP standardizes the connector. GitHub builds one MCP server. Every AI tool that speaks MCP can use it. M × N collapses to M + N.

Three roles: the host is your AI application (Claude Code, Cursor, ChatGPT). The server is a small program exposing capabilities from an external service. The client is the piece inside the host maintaining the connection.

Servers expose three types of capabilities. Tools are actions the AI can take — create an issue, query a database, deploy a project. The AI decides when to call them. Resources are data the AI can read — schemas, documentation. Prompts are reusable templates the user triggers explicitly. The critical distinction: tools are model-controlled, resources are application-controlled, prompts are user-controlled.

MCP vs API: the real difference

Most explanations get this wrong by framing MCP as replacing APIs. It doesn’t. MCP sits on top of APIs. The GitHub MCP server literally calls the GitHub REST API internally. They’re wrappers, not replacements.

With a traditional API, the developer decides everything in advance. You write code that calls specific endpoints. Deterministic. Predictable.

With MCP, the AI model decides at runtime. You describe intent in natural language, and the model figures out which tools to call, in what order, with what parameters. You’re the director describing the outcome. The AI figures out the steps.

When this is a superpower: open-ended tasks where the AI needs to explore. “Why is our production deploy failing?” might require checking Vercel logs, then GitHub commits, then Supabase migration status. I watched Claude Code debug a failing deploy this way. It checked Vercel, saw a database connection error, pivoted to Supabase, discovered a NOT NULL column without a default, then found the offending commit via GitHub. Four services, eight tool calls, thirty seconds. I would have taken fifteen minutes.

When this is a problem: deterministic workflows. “Run payroll at midnight every Friday” needs hand-written code, not an AI deciding at runtime whether to process your payroll.

The decision rule: use APIs when a developer is the consumer and the workflow is deterministic. Use MCP when an AI model is the consumer and the workflow is exploratory.

Using MCP in practice

Adding a server to Claude Code takes one command. Once added, Claude can see and use the tools without you specifying which one. “Check if my latest Vercel deploy succeeded” → Claude calls the deployment status tool. “Create a table called invoices” → Claude calls the SQL execution tool. The servers persist across sessions.

The first time I connected the Supabase MCP and asked Claude Code “what tables do we have and which ones are missing RLS policies,” it listed every table, flagged the two without RLS, and offered to write the policies. That query would have taken me ten minutes in the dashboard. Claude did it in three seconds. That was the moment MCP stopped being a concept.

MCP works in Claude Desktop, Cursor, VS Code with Copilot, and ChatGPT. The whole point of a standard is configuring the server once and using it from whichever tool you prefer.

The servers that matter

Supabase — query your database, run migrations, manage tables. The most useful MCP server for development. GitHub — create issues, open PRs, check workflow runs. Vercel — check deployment status, read logs. Render — manage services and databases. Cloudflare — manage Workers, KV, R2, and DNS. Filesystem — give Claude Desktop access to project files. Plus official servers from Notion, Linear, Slack, Stripe, and Google services.

With over 10,000 public servers, be selective. A quality survey found only about 13% score above 70 on trust metrics. Stick to official vendor servers and well-maintained projects.

Building your own

When you need to connect an internal API or proprietary service, building a server is simpler than you’d expect. FastMCP is the standard Python approach — define your tools as decorated functions with clear descriptions, and FastMCP handles the protocol. The key: write specific tool descriptions. “Look up client information by name” is much better than “get client.”

We built a small server at EltexSoft that wraps our internal time-tracking API. Three tools: hours by project, by person, and by week. Now I ask Claude “how many hours did we log on the healthcare project last month?” without opening Clockify. Forty lines of Python. Took about an hour to build. Saves more time each week than I spent building it.

Security

MCP gives AI tools the ability to take real actions. That power comes with real risks.

Tool poisoning: Malicious MCP servers can contain hidden instructions in their descriptions that manipulate AI behavior. About 5.5% of public servers were found to contain suspicious metadata. I made the mistake of trying a random server from an aggregator early on — it worked for a day, then started timing out. I checked the GitHub repo and found three unresolved security issues. Now I only install servers with active maintenance.

Context window bloat: Every tool’s name, description, and schema gets injected into the AI’s context. Three servers loaded together can consume 72% of available context before the AI does any work. I hit this wall with six servers connected simultaneously. Claude’s responses got vague and missed details. I was starving it of context. Now I keep a maximum of three active at any time.

The broader lesson: Treat MCP servers like any dependency. Use official vendor servers. Scope permissions narrowly. Review before approving tool calls. Pin versions. Audit installed servers regularly.

MCP vs API vs function calling

APIs (REST, GraphQL) are for app-to-app communication. Developer decides everything. Deterministic. Function calling is for giving an AI structured actions within a single API request. Tools live in your application code. MCP is for giving an AI discoverable actions across multiple standalone services. Tools live in external servers.

The relationship: MCP servers often wrap APIs, and MCP clients often translate tool calls into function calling under the hood. They’re layers in a stack, not competing alternatives.

The bottom line

MCP is the most important protocol shift in AI tooling since function calling. It solves the M × N integration nightmare and has real industry adoption. But it’s not magic and it’s not a replacement for APIs. It’s a standardized adapter layer that makes APIs accessible to AI models at runtime.

Install the MCP servers for the tools you already use. See how it changes your workflow. Then build a small server for your internal tools when you need one. Keep permissions narrow. Review what the AI is doing. Remember that every MCP server you install is software you’re trusting with access to your systems.

MCP makes AI tools dramatically more capable. That capability is only as safe as your judgment about when to use it.


This is the free web edition of Chapter 12. The full text — with MCP server installation walkthroughs, FastMCP and TypeScript SDK examples, security audit checklists, and custom server build tutorials — is available in 42: The AI Builder’s Stack, coming Q3 2026 on Amazon in hardcover, paperback, and digital.