From REST to MCP: what's changing

Published: (January 4, 2026 at 07:45 AM EST)
4 min read
Source: Dev.to

Source: Dev.to

Introduction

REST has been the standard for 20 years. Every API you use, every integration you build — it’s probably REST.
But something’s shifting. AI doesn’t want to call raw endpoints; it wants to call tools. That’s where MCP (Machine‑Callable Procedures) comes in.

REST: What It Was Designed For

  • Typical calls
GET /users/123
POST /orders
PUT /products/456
DELETE /comments/789
  • Predictable, stateless, works everywhere.
  • Assumes the caller knows exactly what it wants: you write code that calls specific endpoints with fixed parameters.

Why REST Is Awkward for AI

When you ask an LLM like Claude, “get me the user’s recent orders,” it thinks in actions, not endpoints:

  1. What do I need to do? → Get orders
  2. What information do I need? → User ID
  3. What constraints? → Recent ones

REST forces the AI to map natural language to rigid endpoints, which is possible but clunky.

MCP: A Tool‑Centric Model

Instead of exposing endpoints, you expose tools:

tools:
  - name: get_user_orders
    description: Get orders for a user, optionally filtered by date
    parameters:
      - name: user_id
        type: string
        required: true
      - name: since
        type: string
        description: ISO date to filter orders from

The AI reads the description, understands the parameters, and decides when to use the tool—no need to parse documentation or memorize endpoint paths.

Discovering Tools at Runtime

{
  "tools": [
    {
      "name": "get_user_orders",
      "description": "Get orders for a user",
      "inputSchema": { /* ... */ }
    },
    {
      "name": "create_order",
      "description": "Create a new order",
      "inputSchema": { /* ... */ }
    }
  ]
}

The AI asks, “what tools do you have?” and receives a list with clear descriptions, enabling dynamic discovery without hard‑coding.

Comparing REST and MCP Calls

REST Example

GET /api/v2/users/123/orders?status=completed&limit=10&sort=desc

You must know the exact path, query parameters, and API version.

MCP Example

{
  "tool": "get_user_orders",
  "arguments": {
    "user_id": "123",
    "status": "completed",
    "limit": 10
  }
}

The AI extracts arguments directly from natural language (“Show me John’s last 10 completed orders”).

Writing Effective Tool Descriptions

  • Bad – too vague, AI won’t know when to use it
- name: proc_txn
  description: Process transaction
  • Good – explicit use case and required parameters
- name: process_payment
  description: >-
    Charge a customer's saved payment method. Use this when the user wants
    to complete a purchase. Requires `order_id` and `payment_method_id`.

The richer the description, the smarter the AI behaves.

Streaming Results with MCP

MCP supports Server‑Sent Events (SSE) for incremental output:

AI: "Analyze this large dataset"
Tool: [streaming] Processing chunk 1/10...
Tool: [streaming] Processing chunk 2/10...
...
Tool: [complete] Analysis ready

This enables progress updates and handling of long‑running operations.

Maintaining Context Across Calls

REST is stateless; each request stands alone. MCP can maintain context, allowing multi‑step workflows:

  1. Call get_performance_metrics
  2. Identify the slowest endpoint
  3. Call get_logs with that endpoint
  4. Summarize findings

A single user request can trigger multiple coordinated tool calls, producing a coherent result.

Integration Model: REST + MCP

MCP does not replace REST. Your applications still call APIs the usual way. MCP sits on top as a wrapper:

Your REST API → MCP Server → AI Agent

Think in terms of tools rather than endpoints:

  • Endpoints – what operations exist?
  • Tools – what can AI do with this?

Write tool descriptions as if you’re explaining the system to a smart intern.

Benefits of the MCP Layer

  • Hide complexity behind simple tools
  • Add guardrails (e.g., read‑only, rate limits)
  • Shape how AI interacts with your system

Emerging Ecosystem

  • Now: Developers manually integrate REST APIs with AI.
  • Soon: MCP wrappers for popular services (Stripe, GitHub, etc.).
  • Later: APIs ship with MCP servers alongside REST.

Example: Wrapping a REST API with Gantz Run

tools:
  - name: get_weather
    description: Get current weather for a city
    parameters:
      - name: city
        type: string
        required: true
    http:
      method: GET
      url: "https://api.weather.com/current"
      query:
        q: "{{city}}"

In a few lines, a traditional REST endpoint becomes AI‑accessible.

Conclusion

This isn’t REST vs. MCP; it’s REST + MCP.

  • REST handles app‑to‑server communication.
  • MCP handles AI‑to‑tool communication.

If you’re building for an AI‑first world, the MCP interface is what matters.

Already wrapping REST APIs with MCP? Share your experience!

Back to Blog

Related posts

Read more »

The RGB LED Sidequest 💡

markdown !Jennifer Davishttps://media2.dev.to/dynamic/image/width=50,height=50,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%...

Mendex: Why I Build

Introduction Hello everyone. Today I want to share who I am, what I'm building, and why. Early Career and Burnout I started my career as a developer 17 years a...