API vs MCP: When Should You Use Each?

AI engineering3 min read

Use the interface that matches who's reading — humans, software, or agents.

REST APIs expose resources.

MCP exposes capabilities to agents.

That's the simplest way I've found to decide which one to use.

They can serve the same underlying data, but they're designed for different consumers.

An API is for software that already knows what it wants.

MCP is for an AI agent that needs to decide which capability helps with the user's task.

What an API is good at

An API works best when the client already knows exactly what it needs.

The client knows the endpoint, parameters, and what it'll do with the result.

Examples:

  • a dashboard fetching /api/v1/products
  • a script pulling /api/v1/notes
  • a search index reading /api/v1/projects
  • a mobile app requesting /api/v1/me
  • a server job syncing structured public data

In these cases, REST is usually enough.

The request is explicit:

GET /api/v1/projects?tag=ai&status=active

The response is predictable JSON.

The client handles the rest.

What MCP is good at

MCP is useful when the client is an AI agent.

The agent isn't only fetching a known resource. It's interpreting a user request, choosing from available tools, deciding what inputs to provide, and using the result in a larger reasoning flow.

Examples:

  • "Summarize Orlando's active products."
  • "Which projects show backend/API experience?"
  • "Find notes about AI agents and turn them into a recruiter brief."
  • "What has Orlando built with TypeScript?"
  • "Compare ResistGate and Amethyst as products."

Those are natural-language tasks.

The user didn't specify an endpoint.

The agent needs capabilities, not just URLs.

That's where MCP fits.

A real example from my site

My personal hub has both:

GET /api/v1/projects
POST /api/mcp

The API exposes resources:

/me
/projects
/products
/notes

The MCP server exposes tools:

get_orlando_bio
get_projects
get_project
get_products
get_product
get_product_status
get_notes
get_note

Both can return the same data. But the way you talk to them is completely different.

If a script wants all notes, the API is cleaner.

If an agent wants to answer a question about my work, MCP is cleaner.

API strengths

APIs are strong when you need:

  • predictable URLs
  • simple caching
  • app-to-app integration
  • public data access
  • stable response contracts
  • compatibility with existing tools
  • low-friction debugging in a browser or terminal

APIs are also easier to document for developers who aren't working inside an agent environment.

Worth keeping in mind: not everything needs to become an MCP tool.

MCP strengths

MCP is strong when you need:

  • model-selected tools
  • natural-language-driven workflows
  • structured inputs chosen by an agent
  • tool descriptions that explain intent
  • a shared interface across AI clients
  • agent access to data or actions without custom glue code

MCP is less about transport and more about agency.

The model can inspect a tool list and decide:

  • which tool to call
  • when to call it
  • what arguments to pass
  • how to combine results

That's different from a normal client calling a known endpoint.

Where people get confused

The confusion happens because both APIs and MCP tools can return JSON.

That makes them look similar.

But the real difference is who's making the decision.

With an API, the developer decides:

Call /api/v1/products, parse the response, render a list.

With MCP, the agent decides:

The user is asking about shipped products, so I should call get_products.

That decision layer changes the design.

MCP tools need descriptions, schemas, and boundaries that help the model choose correctly.

APIs need resource paths, parameters, and response contracts that help software integrate reliably.

When I'd use an API

Use an API when:

  • you know the client
  • the workflow is predictable
  • caching matters
  • the output should be consumed by many kinds of software
  • the consumer is a script, app, search index, dashboard, or backend service

On my personal hub, /api/v1 is the right interface for public structured data.

It's boring in the best way.

When I'd use MCP

Use MCP when:

  • the consumer is an AI assistant or agent
  • the user asks in natural language
  • the model needs to choose the right capability
  • the tool should be discoverable inside agent clients
  • the workflow benefits from semantic tool names

On my personal hub, /api/mcp is the right interface for questions like:

Which of Orlando's projects best demonstrate AI product engineering?

That's not just a fetch. It's a task.

The best answer is often both

For an agent-readable personal hub, the best answer isn't API or MCP.

It's both.

The API gives the website a durable software interface.

The MCP server gives agents an intent-based tool interface.

They share the same source of truth, but serve different kinds of consumers.

That's the pattern I'd bet on long term:

Website  →  for humans
API      →  for software
MCP      →  for AI agents

Use the interface that matches the reader.

Notes from the build

More from the AI engineering trenches

Evals, observability, prompt design, and real lessons from shipping AI products. No fluff.

By subscribing, you agree to receive Orlando's emails. No spam. Unsubscribe anytime.

API vs MCP: When Should You Use Each? | Orlando Ascanio