← All insights

APIs, Microservices & MCP: How Software Talks to Software — and Now to AI Agents

Aravind Naidu, Partner / CTO, ToolTwist5 min readAI delivery

The short version: the familiar terms haven't been replaced — they've been layered. APIs and microservices are still the foundation. What's new is a layer on top called MCP (Model Context Protocol) that lets AI agents plug into those same systems safely.

If you've sat in a meeting where someone said "we'll just expose it over MCP" and quietly wondered whether that meant your API strategy was obsolete: it doesn't. Here is the whole picture in plain language.

The four terms that matter

TermWhat it actually is
APIThe standard way one piece of software asks another for something. The contract: "send a request like this, get an answer like that." Still the umbrella term for all programmatic interfaces.
MicroserviceHow we break a large system into small, independently-run pieces — each owned by a team, each doing one job well (payments, inventory, customers). Each microservice exposes its own APIs.
MCP ServerThe new adapter layer for AI. It sits in front of existing APIs and presents them to AI agents as tools — task-shaped actions like "create an invoice" — with plain-language descriptions the AI reads and understands at runtime.
AI AgentSoftware powered by a model (like Claude) that decides for itself which tools to use to complete a goal, rather than following a script a developer wrote in advance.

The power-socket analogy

The cleanest mental model we've found: your APIs are the wiring inside the wall, powered by your microservices. The MCP server is the socket — a standard, deliberately simple opening in that wall. The AI agent is the appliance. It doesn't need to know how your building was wired; it just needs a plug that fits.

The power-socket analogy: an AI agent is the appliance that plugs in, the MCP server is the standard socket in the wall, and the APIs are the wiring behind it, powered by microservices.

The value of a standard socket is that you only have to install it once. Any agent — Claude, an internal copilot, a partner's assistant — plugs into the same opening without anyone rewiring the wall.

One-liner for a slide: "Our microservices expose APIs for system-to-system integration, and an MCP server so AI agents can use those same capabilities safely."

One backend, stacked layers

Nothing gets thrown away. MCP is an adapter on top of what you already have. Requests flow down the stack, and each layer translates for the one above it.

The stack from top to bottom: an AI agent reasons at runtime; an MCP server exposes task-shaped, self-describing tools such as create_invoice, check_balance and pay_supplier; REST and gRPC APIs carry the precise technical contracts; and microservices for payments, inventory and customers do the work.

Read it top-down. The agent starts with a goal — "pay this supplier's invoice" — and works out which tools it needs. The MCP server offers a small set of task-shaped tools and translates the chosen one into API calls. The APIs carry the precise technical contracts. The microservices, each owned by a different team, do the actual work.

The important part for anyone worried about a rewrite: only the top box is new.

Why a separate layer for AI?

A traditional API assumes a developer read the documentation and wrote code in advance. An MCP server assumes an AI agent is figuring out what to do on the fly. That single difference changes the design:

  • Descriptions do the work — the agent reads them like documentation, at runtime. Naming and wording are functional requirements, not politeness.
  • Tools match tasks, not endpoints — "create an invoice", not five low-level API calls the agent has to sequence correctly.
  • Errors explain themselves — helpful prose, not just an error code. The agent has to be able to recover on its own.

This is also why an MCP server is not simply a generated wrapper around your OpenAPI spec. Auto-generating one tool per endpoint gives an agent hundreds of low-level options and no idea which to reach for. The design work is in deciding which tasks are worth exposing.

Who talks to your systems now

The most useful modern framing: your backend now serves three kinds of consumers, each through the interface designed for it. Same capabilities underneath — three different "front doors".

Three consumers and one backend: people reach a human-facing website or app, other systems reach machine-facing REST and gRPC APIs, and AI agents reach an agent-facing MCP server — all three sitting on top of the same backend of microservices, business logic and data.

People get a UI. Other systems get APIs. AI agents get an MCP server. One source of truth underneath all three — which is exactly why the pattern holds up: you are not maintaining three implementations of your business logic, only three ways in.

Terms you'll hear (and what they mean)

  • Tool — one action an agent can take; an MCP server offers many tools.
  • Agent-facing / MCP-native / agent-ready — designed for AI consumption from the start.
  • Tool surface — everything an agent is allowed to do (deliberately smaller and more task-shaped than the full API surface).
  • MCP gateway — the control point for security, permissions and audit across many MCP servers, like an API gateway for the AI layer.
  • A2A (agent-to-agent) — when the thing on the other end is another AI agent, not a fixed system.

The takeaway

APIs and microservices remain the foundation. MCP is the standard socket that lets AI agents plug into them — say all three, because each does a different job.

If someone tells you MCP replaces your API strategy, they've got the layers upside down. And if you don't have clean APIs and clear service boundaries underneath, MCP won't rescue you — it will just give an AI agent a faster route to the mess.