Every Service Is Going to Need an MCP Layer

Six months ago I tried to wire an AI agent into one of our healthcare data services. The service had a perfectly reasonable REST API — auth via OAuth, standard CRUD endpoints, OpenAPI spec, the works. I figured connecting an agent would be a weekend project.

Three weeks later I had something limping along that I was genuinely embarrassed to show anyone.

The API was fine. The problem was me — specifically, my assumption that an interface designed for a human-driven frontend would be equally usable by an agent trying to accomplish a goal autonomously. It is not. Not even close.

That experience cracked something open for me. It is the reason I now believe that every service that matters is going to need a dedicated layer designed for agent consumption. Not a wrapper. Not a proxy. A real architectural layer, purpose-built for the way agents actually work.

Here is what I figured out.

Why REST APIs Break for Agents

REST was designed for a specific interaction model: a human performs an action in a UI, the frontend calls an endpoint, the endpoint returns data, the UI renders it. The human provides the judgment, disambiguation, and error recovery. The API just needs to be correct and predictable.

Agents do not work this way. An agent has a goal and a set of tools. It has to figure out which tools to call, in what order, with what parameters, and how to interpret the results — without a human in the loop correcting it when it guesses wrong.

When I tried to connect an agent to our healthcare service, I hit four categories of failure almost immediately.

1. Parameter ambiguity kills agent reasoning.

Our patient search endpoint accepted name, dob, mrn, and facility_id in any combination. A human knows instinctively that if you have an MRN you use it and skip the other fields. An agent does not know this. It will try every plausible combination. It will pass name and mrn together and get confused when the response de-prioritizes the name match. It will omit facility_id and silently get results from the wrong facility context.

REST endpoints are designed to be flexible because humans are flexible. Agents need constraints. They need to know explicitly: if you have X, call endpoint A; if you have Y and Z, call endpoint B.

2. Error messages are written for engineers, not for reasoning systems.

400 Bad Request: Invalid filter combination tells a developer to go read the docs. It tells an agent nothing about how to self-correct. I watched our agent retry the same malformed request four times with minor variations before giving up and hallucinating an answer.

What an agent needs: Error: facility_id is required when searching by name alone. Provide facility_id or switch to MRN-based lookup. That is actionable. The agent can retry with corrected parameters.

3. Pagination and result set size are agent traps.

Our standard list endpoints returned 20 results with a next_cursor token. The agent would fetch the first page, find nothing matching its criteria, and conclude the data did not exist — never checking whether there were 14 more pages. Or it would fetch all 15 pages when it only needed the first match.

A human browsing search results brings judgment to pagination. An agent needs the API to do that work for it — return the best match with confidence, not a raw page of results ranked by insert order.

4. Context is stateless in REST, but agents need stateful workflows.

Healthcare queries are almost never one-shot. You look up a patient, then look up their recent encounters, then pull specific lab values from one of those encounters. In our REST API, those are three separate calls with no awareness of each other. The agent has to carry all that state itself, and if any call fails, it has to reason about which partial state to trust.

What MCP Actually Solves

The Model Context Protocol — MCP — is Anthropic's open standard for defining tools that agents can call. I want to be precise about what it does and does not do.

MCP does not magically make your API agent-friendly. What it does is give you a clean seam to put the right abstraction between your service and your agent.

Think of an MCP server as a translation layer. On one side: your service, which knows its domain and has the raw capabilities. On the other side: an agent, which has a goal and needs those capabilities presented in a way that supports autonomous reasoning. The MCP server is the adapter.

Specifically, an MCP server lets you:

• Define tools with explicit parameters, constraints, and descriptions that are designed to be read by an LLM, not by a human developer
• Return structured results that include not just data but metadata about what the agent should do next
• Expose resources that give agents persistent context without requiring them to fetch and re-fetch
• Handle error cases in ways that give agents a path to self-correction

This is not the same as just adding descriptions to your OpenAPI spec. The design intent is different. An OpenAPI spec documents what an endpoint does. An MCP tool definition teaches an agent how to use a capability to accomplish a goal.

What the Right Architecture Looks Like

Here is the pattern I have landed on after rebuilding this properly.

Your existing REST API stays exactly as it is.

The REST API serves your frontend, your mobile clients, your integrations, your internal tooling. Do not touch it. It is not broken for its intended use cases.

The MCP server is a thin but intentional layer on top.

It calls your REST API (or your service layer directly, if you prefer). It does not contain business logic. But it does contain agent-specific logic: how to translate a goal-oriented request into the right sequence of API calls, how to present the results, how to surface errors in agent-recoverable ways.

Tool design is the core investment.

This is where most teams will underinvest. Designing an MCP tool is not like writing an API endpoint. You are writing something that an LLM will read and decide how to use. The description, the parameter names, the error messages — all of it has to be written for an AI reasoner, not for a human developer.

Some concrete rules I have developed:

• One tool, one intent. Do not create a search tool that handles five different search patterns based on which parameters are provided. Create searchByMRN, searchByName, searchByEncounterDate. The agent will pick the right one based on what it knows.
• Constraints in the schema, not the docs. If facility_id is required for name searches, enforce it in the tool schema, not in prose documentation an agent might or might not read.
• Return actionable context, not raw data. If a search returns zero results, tell the agent why and what to try instead. If it returns multiple matches, surface the confidence level, do not make the agent guess which match is right.
• Design for the failure path. What should an agent do if the patient is not found? If auth fails? If the service is degraded? The tool definition should answer these questions explicitly.

The MCP server handles auth and rate limiting, not the agent.

Agents should not be managing auth tokens. They should not be retrying with backoff. The MCP server handles all of that. From the agent's perspective, tools either succeed or return a structured error with recovery guidance. The messy infrastructure concerns live in the MCP layer.

What This Means for Healthcare Specifically

I build AI systems for healthcare, so let me be concrete about what this changes.

Healthcare data is deeply relational and context-dependent. A lab value means almost nothing without the encounter context. A medication order makes no sense without the diagnosis context. A prior auth decision is incomprehensible without the coverage and policy context.

A REST API exposes endpoints for individual resources. An agent working on a real clinical task needs to assemble those resources into coherent context. Right now, we make agents do that assembly work. It is error-prone and brittle.

The right MCP design for healthcare is not getPatient, getEncounter, getLabResult. It is tools built around clinical reasoning tasks: getPatientClinicalSummary, getRelevantEncountersForDiagnosis, getLabTrendForCondition. Tools that return assembled, contextualized answers, not raw data for the agent to assemble itself.

This is a fundamentally different way of thinking about what a service exposes. You are not exposing data. You are exposing reasoning capabilities.

The Action Plan

If you are building services that agents will need to consume — and by 2027 that will be most services — here is how I would approach this:

Step 1: Audit your existing APIs for agent failure modes. Walk through each endpoint and ask: what would an agent get wrong about how to call this? Where is the judgment requirement hidden? Where do errors fail to guide recovery? This audit will surface the design work you actually need to do.

Step 2: Design tools around agent tasks, not data resources. Map the goals an agent might be trying to accomplish with your service. Design tools around those goals. A tool should complete a coherent subtask, not expose a data type.

Step 3: Build the MCP server as a first-class service. Not a script, not a weekend prototype. It needs versioning, monitoring, evals, and a clear owner. The quality of your MCP layer is directly correlated with the quality of every agent that uses your service.

Step 4: Evaluate against real agent workflows. The only way to know if your MCP tools work is to run agents against them and watch where they fail. Build eval cases that cover the failure modes you found in Step 1. Run them continuously.

---

REST APIs democratized service-to-service communication in the 2010s. MCP — or something very much like it — is going to do the same thing for agent-to-service communication in this decade. The pattern is becoming clear enough that the only real question is how long it takes your team to build it deliberately versus stumbling into it through production failures.

I spent three weeks learning that the hard way. You do not have to.