Why MCP Could Become the REST API of the Agentic Era

AI applications are moving beyond simply answering questions.

Modern AI agents can search the web, query databases, interact with GitHub, send messages, create documents, call APIs, and execute multi-step workflows.

But as agents become more capable, another problem appears:

How should an AI agent communicate with all these different tools?

Today, developers can build custom integrations for every tool an agent needs. But as the number of tools grows, that approach becomes difficult to maintain.

This is where Model Context Protocol (MCP) comes in.

MCP is an open protocol designed to standardize how AI applications connect to external tools, resources, and capabilities.

And that raises an interesting question:

Could MCP become the REST API of the agentic era?

Not as a replacement for REST, but as a standardized interface between AI agents and the software they interact with.

The Problem Before MCP

Imagine you're building an AI-powered developer assistant.

Your agent needs access to:

• GitHub
• PostgreSQL
• Slack
• Jira
• Google Drive
• Internal APIs
• Local files

Without a common protocol, your application might look something like this:

                    ┌── GitHub Integration
                    │
AI Application ─────┼── Slack Integration
                    │
                    ├── Database Integration
                    │
                    ├── Jira Integration
                    │
                    └── Internal API Integration

Each integration may have its own:

• Authentication
• API format
• Tool definitions
• Error handling
• Permission model
• Discovery mechanism

Now imagine supporting multiple AI applications.

Claude ────────┐
               ├── GitHub
ChatGPT ───────┤
               ├── Slack
Custom Agent ──┤
               ├── Database
               └── Jira

The number of integrations can grow quickly.

This is a classic software engineering problem:

When every application builds its own integration, a common interface becomes extremely valuable.

What Is MCP?

Model Context Protocol, or MCP, provides a standardized way for AI applications to communicate with external capabilities.

At a high level:

                    ┌── GitHub
                    │
                    ├── PostgreSQL
AI Agent ── MCP ─────┼── Slack
                    │
                    ├── Jira
                    │
                    └── Internal APIs

An MCP server can expose capabilities such as:

Tools

Actions that an AI application can invoke.

For example:

search_github()
create_issue()
query_database()
send_slack_message()

Resources

Data that an AI application can retrieve.

For example:

database://customers
file://project/readme

Prompts

Reusable interaction templates that an MCP server can expose to an AI client.

The important idea is that the AI application doesn't need a completely custom integration for every MCP-compatible system.

It can communicate using the MCP protocol.

But Isn't MCP Just REST?

This is where the comparison gets interesting.

REST helped standardize how software applications communicate with web services.

A traditional API might expose:

GET    /users
GET    /users/123
POST   /users
DELETE /users/123

The client doesn't need to understand how the server internally stores its data.

It only needs to understand the API contract.

MCP is trying to solve a related problem for AI applications:

AI Agent
   ↓
MCP
   ↓
Tool / Resource
   ↓
External System

But there is an important distinction.

REST is a general architectural style for networked applications.

MCP is specifically designed around interactions between AI clients and external capabilities.

So the comparison isn't:

MCP will replace REST.

It's closer to:

REST standardized application-to-service communication. MCP aims to standardize agent-to-capability communication.

REST Made APIs Easier to Consume

Before standardized web API patterns became widespread, integrating different services could involve learning completely different interfaces.

REST introduced familiar concepts around:

• Resources
• HTTP methods
• URLs
• Representations
• Stateless requests

Developers could learn the general model and then work with many different APIs.

MCP is attempting something similar for agentic applications.

Instead of every AI application inventing its own mechanism for discovering and invoking tools, MCP provides a common protocol.

Traditional application
 
Application ──── REST API ──── Service
 
 
Agentic application
 
AI Agent ──────── MCP ──────── Tool

The key difference is the consumer.

A traditional application generally knows what operation it wants to perform.

An AI agent may need to discover available capabilities and decide which one to use.

The Consumer Is an AI Agent

Consider a traditional application:

await github.createIssue({
  title: "Authentication bug",
  body: "Login fails for certain users",
});

The developer explicitly programmed that operation.

Now consider an AI agent.

A user might say:

"Find the authentication bug, create a GitHub issue with the relevant details, and tell the team on Slack."

The agent needs to determine:

1. What tools are available?
2. Which tools are relevant?
3. What arguments do they require?
4. Which tool should be called first?
5. What information should be passed to the next tool?
6. Which actions require authorization?

That is a different interaction model.

The software isn't simply sending predefined API requests.

The AI is reasoning about which capabilities to use.

MCP Makes Capabilities Discoverable

One of the interesting ideas behind MCP is capability discovery.

An MCP client can discover the tools exposed by a server.

Conceptually, a tool might look like:

{
  "name": "create_issue",
  "description": "Create an issue in a repository",
  "inputSchema": {
    "type": "object",
    "properties": {
      "repository": {
        "type": "string"
      },
      "title": {
        "type": "string"
      },
      "body": {
        "type": "string"
      }
    }
  }
}

The AI application can use this information to understand what the tool does and what inputs it expects.

So instead of hard-coding every possible capability into the AI application:

AI Application
     │
     ├── Custom GitHub code
     ├── Custom Slack code
     ├── Custom Jira code
     └── Custom Database code

we can move toward:

AI Application
     │
     ▼
    MCP
     │
     ├── GitHub tools
     ├── Slack tools
     ├── Jira tools
     └── Database tools

This separation can make agent architectures easier to extend.

MCP Doesn't Replace Your Existing APIs

This is an important point.

You don't have to throw away your REST APIs because you're adopting MCP.

Instead, MCP can sit above your existing services.

For example:

                    ┌── PostgreSQL
                    │
MCP Server ─────────┼── GitHub API
                    │
                    ├── Internal REST API
                    │
                    └── Redis

Your existing backend can continue serving your web application.

The MCP layer provides an additional interface designed for AI clients.

You can think of it as adding an agent-facing interface to your system.

Your Application May Have Two Interfaces

For years, we've mostly designed applications around human users:

Human
  ↓
UI
  ↓
Backend
  ↓
APIs
  ↓
Database

Agentic applications introduce another type of consumer:

Human
  ↓
AI Agent
  ↓
Tools / APIs / Data

That could lead to architectures like:

                 Your Application
                       │
             ┌─────────┴─────────┐
             │                   │
          Humans              AI Agents
             │                   │
             UI                 MCP
             │                   │
             └─────────┬─────────┘
                       │
                    Backend
                       │
                  Database

This is one of the most interesting implications of MCP.

Your software doesn't only need to be understandable to humans anymore.

It increasingly needs to expose capabilities that agents can understand and safely use.

Why This Matters for Developers

Imagine you're building a SaaS platform.

Your application already has APIs like:

/api/projects
/api/tasks
/api/users
/api/reports

You could expose agent-oriented capabilities such as:

list_projects
get_project
create_task
search_users
generate_report

Now an AI agent could potentially interact with your application through MCP.

This creates a new architectural pattern:

                       Your SaaS
                          │
             ┌────────────┴────────────┐
             │                         │
          REST API                MCP Server
             │                         │
             ▼                         ▼
         Web / Mobile              AI Agents

The same underlying business logic can serve both interfaces.

MCP and the Security Problem

There is a major catch.

Giving an AI access to information is one thing.

Giving an AI the ability to perform actions is another.

Consider:

AI Agent
   ↓
GitHub
   ↓
Create repository
   ↓
Push code
   ↓
Deploy production

Or:

AI Agent
   ↓
Database
   ↓
DELETE FROM users

The important question isn't only:

"Can the AI call this tool?"

It is:

"What is the AI authorized to do?"

This introduces a new security boundary.

Agentic systems need to think carefully about:

• Authentication
• Authorization
• Tool permissions
• User consent
• Input validation
• Prompt injection
• Data access
• Audit logs
• Rate limiting
• Isolation
• Secrets management

An MCP server shouldn't blindly trust the model simply because the model requested an action.

MCP Could Become an Agent Permission Boundary

This is where MCP becomes more interesting from a security perspective.

Imagine an MCP server exposing:

read_customer()
create_customer()
update_customer()
delete_customer()

You might not want every agent to have access to every operation.

Instead:

                    MCP Server
                        │
            ┌───────────┼───────────┐
            │           │           │
          READ        WRITE       DELETE
            │           │           │
          Agent A     Agent B     Admin

Now the MCP layer isn't simply transporting requests.

It can become part of the authorization architecture surrounding agent actions.

That makes MCP security an important area for developers to understand.

MCP Is Evolving Beyond Simple Tool Calls

It would be easy to think of MCP as:

AI → Function Call → API

But the protocol is broader than that.

MCP includes concepts around:

• Tools
• Resources
• Prompts
• Client/server communication
• Authorization
• Extensions
• Tasks and long-running workflows

The protocol has also continued evolving toward production infrastructure, including a more stateless protocol core and additional capabilities for scalable deployments.

That matters because production agent systems can't always behave like a local developer experiment.

They need:

Load balancing
      ↓
Multiple MCP servers
      ↓
Authentication
      ↓
Authorization
      ↓
Observability
      ↓
Reliable execution

A Simple MCP Architecture

A production AI application could eventually look something like this:

                         User
                           │
                           ▼
                     AI Application
                           │
                           ▼
                      MCP Client
                           │
              ┌────────────┼────────────┐
              │            │            │
              ▼            ▼            ▼
         MCP Server    MCP Server    MCP Server
              │            │            │
              ▼            ▼            ▼
           GitHub       Database       Internal API

Each MCP server can expose a focused set of capabilities.

This creates a modular architecture where tools can be added without rewriting the entire AI application.

MCP vs REST

Here's a simplified comparison:

The important thing is not to treat these technologies as competitors.

A more realistic architecture is:

AI Agent
   │
   ▼
  MCP
   │
   ▼
Your Backend
   │
   ▼
 REST APIs / Database / Services

MCP can use existing infrastructure rather than replacing it.

Why MCP Could Become So Important

There are several reasons MCP has the potential to become an important part of agentic software.

1. Standardization

Developers don't have to invent a completely different tool interface for every AI application.

2. Discoverability

Agents can discover available capabilities instead of relying entirely on hard-coded integrations.

3. Modularity

New capabilities can be exposed through MCP servers without rebuilding the entire agent.

4. Interoperability

A standardized protocol can make it easier for different AI clients and tool providers to communicate.

5. Separation of concerns

The AI application can focus on reasoning while MCP servers expose controlled capabilities.

6. A growing ecosystem

As more tools and platforms support MCP, the value of having a common interface increases.

This is similar to how standard interfaces become more useful as more participants adopt them.

But Will MCP Actually Become the "REST of AI"?

That's still an open question.

REST became foundational because of a combination of:

Simple concepts
      +
Developer adoption
      +
Tooling
      +
Industry adoption
      +
Ecosystem effects

MCP has some of the characteristics that make the comparison interesting.

But the future of agent communication isn't predetermined.

Other protocols and architectures may emerge.

The important question isn't:

"Is MCP guaranteed to win?"

It's:

"Is standardized communication between AI agents and external capabilities becoming necessary?"

The answer appears increasingly relevant as agents gain access to more tools and more powerful actions.

The Bigger Shift

The most interesting thing about MCP isn't the protocol itself.

It's the architectural shift behind it.

For decades, we've primarily built software around:

Human
  ↓
Interface
  ↓
Application
  ↓
API
  ↓
Data

The agentic era adds another path:

Human
  ↓
AI Agent
  ↓
Tools
  ↓
APIs
  ↓
Data

That means developers may increasingly need to design software for two types of consumers:

                 Application
                     │
          ┌──────────┴──────────┐
          │                     │
        Humans                Agents
          │                     │
         UI                    MCP
          │                     │
          └──────────┬──────────┘
                     │
                  Backend
                     │
                  Database

That's a significant change in how we think about application architecture.

Final Thoughts

MCP probably shouldn't be described simply as "the next REST."

A better way to think about it is:

REST helped standardize how applications communicate with services. MCP is attempting to standardize how AI applications discover and interact with capabilities.

Whether MCP becomes the dominant protocol for agentic systems remains to be seen.

But the underlying problem is unlikely to disappear.

As AI agents gain access to more APIs, databases, applications, and real-world workflows, developers need a reliable way to expose those capabilities.

MCP is one approach to solving that problem.

And if the agentic era really does become the next major application paradigm, the interface between an AI agent and the tools it controls could become just as important as the APIs that connected the web.