Stop Rebuilding for AI Integrations: Use Your Existing REST APIs with MCP

A few weeks ago, I shared an insight on LinkedIn that sparked a conversation. I’ve since built a POC to test the feasibility — here’s what I discovered.

TL;DR

✅ Make existing REST APIs AI-accessible — no rebuilding required
✅ Protocol adapter pattern — one service translates MCP ↔ REST
✅ Minimal overhead — standard HTTP
✅ Working POC available — try it here

The Problem That Started Everything

After analyzing the Model Context Protocol (MCP), I had a nagging feeling that we were making AI integration harder than it needed to be. Everyone was talking about building “MCP servers” from scratch, but I kept thinking:

What if MCP servers are just microservices with a protocol wrapper?

So I decided to put the idea to the test. What I built is a working example that brings the concept to life — and it could change the way we think about connecting AI to existing systems.

We’re Solving the Wrong Problem

Everyone was asking: “How do we build MCP servers?”

But the better question is: “How do we make existing systems MCP-compatible?”

The Real Comparison

Without MCP (traditional):

AI Agent → Custom Integration Code → REST API → Tool

With MCP (current approach):

AI Agent → MCP Client → MCP Server → Tool

With MCP → REST pattern (my approach):

AI Agent → MCP Client → MCP Adapter → Existing REST APIs → Existing Microservices

The insight: an MCP server is often just a protocol wrapper around an existing REST-based microservice.

What I Built: The MCP → REST Pattern

Instead of a theoretical discussion, let me show you what happened when I took this seriously.

The MCP Adapter acts as a bidirectional protocol translator that enables seamless communication between AI agents (speaking MCP/JSON-RPC) and your existing microservices (speaking REST/HTTP).

Each process runs independently, communicating through standard HTTP protocols. The adapter translates between MCP and REST without any process coupling.

Request Flow Example: Real AI in Action

User query: “Show me all orders for customer John Doe and their shipping status.”

Step 1: Auto-discovery. The adapter discovers your services and generates tools automatically — zero configuration required.

Step 2: The AI agent’s sequential tool execution:

search_customers(name="John Doe") → MCP Adapter → GET /customers/search?name=John+Doe → Customer Service → customer_id: "cust-456"
get_customer_orders(customer_id="cust-456") → MCP Adapter → GET /orders?customer_id=cust-456 → Order Service → orders: [1001, 1002, 1003]
get_shipping_status(order_ids=[1001,1002,1003]) → MCP Adapter → GET /orders/shipping?ids=1001,1002,1003 → Order Service → shipping: ["shipped","in_transit","processing"]
Final synthesis: “John Doe has 3 orders: Order #1001 shipped, Order #1002 in transit, Order #1003 processing.”

Step 3: The magic — no changes needed. Your existing services handle these requests exactly as they always have. Zero modifications required.

Try It Yourself: Real curl Example

# Call the MCP adapter to list customers
curl -X POST http://localhost:8000/mcp \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 3,
    "method": "tools/call",
    "params": {
      "name": "customer_list_customers_customers_get",
      "arguments": {}
    }
  }'

Response:

{
  "jsonrpc": "2.0",
  "id": 3,
  "result": {
    "content": [{
      "type": "text",
      "text": "[ { \"id\": \"cust-001\", \"name\": \"John Doe\", \"email\": \"john@example.com\", \"status\": \"active\" }, { \"id\": \"cust-002\", \"name\": \"Jane Smith\", \"email\": \"jane@example.com\", \"status\": \"active\" } ]"
    }],
    "isError": false,
    "_meta": { "status_code": 200, "service": "customer" }
  }
}

Behind the scenes: the adapter translated this MCP call to GET /customers on your existing customer service, then wrapped the response in MCP format.

Key Takeaways

The MCP Adapter is a focused, single-purpose component with clearly defined boundaries:

✅ Does: protocol translation between MCP and REST
❌ Does NOT: business logic, data storage, authentication, service-mesh functions

This focused scope is what makes the pattern so powerful — it does one thing exceptionally well: making existing REST APIs accessible to AI agents.

Avoid the Rebuild: Leverage What You Already Have

Your existing infrastructure provides the foundation:

✅ Business logic — already implemented in microservices
✅ Security foundation — AuthN/AuthZ systems provide the base
✅ Monitoring — observability stack can extend to AI interactions
✅ Reliability — services are battle-tested in production
✅ Compliance — audit trails and governance frameworks exist

The MCP → REST pattern leverages these proven foundations rather than rebuilding them.

The MCP Adapter is just like any other microservice in your stack — same operational patterns (Docker, Kubernetes), same monitoring tools (Prometheus, Grafana), same scaling strategies, same security models. Your ops team already knows how to manage this.

The Bottom Line

In many cases, MCP servers are just microservices with a schema wrapper. For teams that already have REST APIs, this insight can unlock fast, scalable AI integration with minimal effort.

Of course, this is not a one-size-fits-all solution. Use this pattern where it fits best:

✅ Exposing existing business logic to AI agents
✅ Leveraging proven infrastructure and security
❌ Not ideal for AI-native workflows, real-time streaming, or vector data

When the use case fits, the MCP → REST pattern can replace months of effort with a single, focused translation layer. Explore it, share your feedback, and help evolve the pattern — the code is on GitHub.

Originally published on LinkedIn.