MCP vs API: What's the Difference and When Does Each One Matter?

For decades, application programming interfaces (APIs) have been the gold standard for how software talks to other software.

Every online payment you’ve ever made. Every time you’ve checked the weather. Any time you’ve logged in to an enterprise application.

All of these things, and many more, are powered by APIs. These tools are used for sending and receiving information from other applications.

In the healthcare industry, for example, it’s not uncommon to have 30+ APIs all powering your technology infrastructure. So when AI agents came along, an interesting challenge came along with them.

"Each of these tools had different ways to call them, different parameters, different arguments, different protocols," explains Don Woodlock, President of InterSystems, in his Code to Care series. "Which made the task of building an agentic system complicated."

The Model Context Protocol was designed to solve that complexity. It doesn't replace the interfaces your systems already use. It builds a standardized layer on top of them so AI agents can discover and use tools without custom code for each one.

Whether you're building your first AI workflow or trying to understand why everyone in healthcare IT is talking about MCP, this is the practical breakdown: what MCP is, how it compares to traditional APIs, and when each one matters.

Playback requires functional cookie consent. Click the button below to update your cookie settings.

Cookie Settings

An API (application programming interface) is a set of rules that defines how one piece of software communicates with another. APIs are the foundation of software-to-software communication: one system sends a structured request, another returns a structured response.

POST https://hospital.example.com/api/appointments
  // Headers                                                                    
  Authorization: Bearer eyJhbGciOi ...
  Content-Type: application/json                                                
                                
  {                                                                             
    "patient_id": "MRN-00482916",  
    "provider": "Dr. Ramirez",   
    "department": "Cardiology",
    "date": "2026-04-15T10:30:00Z"
  }        

Response:                                                                     
  200 OK                           
        
  {
    "appointment_id": "APT-78291",
    "status": "confirmed",        
    "patient": "MRN-00482916",
    "provider": "Dr. Ramirez",                                                  
    "location": "Building C, Room 204"
  } 

In healthcare, APIs power everything from insurance eligibility checks to lab result exchanges. A scheduling application calls a hospital system's REST API to book an appointment. The API defines the endpoint, the required parameters, the authentication method, and the response format. The caller must know all of this in advance.

That requirement (knowing how the API works before you can use it) is both the strength and the limitation. APIs are predictable, fast, and well-suited for stable integrations where software-to-software communication follows a fixed pattern.

But they assume the caller is a developer who has read the documentation, written the integration code, and built error handling for every edge case.

The Model Context Protocol is a standard, introduced by Anthropic in late 2024, that defines how large language models and AI agents interact with external tools, data sources, and external services.

Where APIs are designed for software-to-software communication, MCP is AI-native, built from the ground up for AI systems and AI applications that need to discover and use tools dynamically.

An API assumes the caller can store secrets, make network requests, and handle failures. An AI model can do none of these things safely. It reasons with text and predicts the next token.

Giving it raw access to API endpoints with API keys and authentication tokens would be both dangerous and inefficient.

MCP creates a controlled layer between the AI agent and the external world. The AI never sees sensitive URLs or credentials. It calls tools through a standardized interface, and the MCP server handles everything underneath.

tools/list                                                                    
// No URL, no auth token, no docs required

[
    {
      "name": "schedule_appointment",
      "description": "Book a patient appointment",
      "inputs": { "patient_id", "provider", "department", "date" }              
    },                                                            
    {                                                                           
      "name": "get_lab_results",   
      "description": "Retrieve lab results for a patient",
      "inputs": { "patient_id", "test_type" }             
    },                                                                          
    { 
      "name": "check_insurance_eligibility",                                    
      "description": "Verify patient insurance coverage",
      "inputs": { "patient_id", "procedure_code" }       
    }
  ]

tools/call "schedule_appointment"
                                   
  {
    "patient_id": "MRN-00482916",
    "provider": "Dr. Ramirez",   
    "department": "Cardiology",
    "date": "2026-04-15T10:30:00Z"                                              
  }

{
    "appointment_id": "APT-78291",
    "status": "confirmed",        
    "location": "Building C, Room 204"                                          
  }

MCP is to AI tools what USB-C is to peripherals. Before USB-C, every device needed its own charger, its own cable, its own connector. USB-C standardized the interface so any peripheral could connect to any laptop through the same port.

MCP does the same for AI integration. The MCP host is the AI system managing connections. The MCP client handles the protocol. The MCP server is the external service: a database, a scheduling tool, a clinical system, an internet resource. One protocol, any tool.

An MCP server is simpler than most people expect. It implements two primary methods:

1. List tools - the AI agent asks, "What tools do you have available?"
2. Call tool - the AI agent says, "Call this tool with these arguments."

"The LLM can say 'what tools do you have available?'" Don explains. "And then it can say later, 'call this tool with these arguments.' And that's basically it."

Communication happens over JSON-RPC with persistent, bidirectional connections, a departure from the stateless request/response pattern of REST APIs.

The MCP server responds with machine-readable descriptions of each tool: its name, what it does, the inputs it accepts, the outputs it returns. The AI agent can adapt to new capabilities without anyone writing custom integration code.

The tools behind an MCP server can be built in any language. "The tool may be a Node app or an IRIS app or a Java app, and the client might be something else entirely," Don notes. That technology-agnostic design means MCP servers built today will still work as the underlying technology evolves.

At a glance, MCP and APIs look similar. Both pass data between systems. Both use structured requests and responses. The differences become clear when you examine what each assumes about the caller.

REST APIs follow a stateless pattern. Each API request is independent. The server doesn't remember what happened in the previous call. Context must be manually passed with every request.

The Model Context Protocol maintains state across interactions, including conversation history and prior tool results. An AI agent debugging a clinical workflow can query a patient record, check lab results, and review scheduling conflicts without losing context between steps.

This is the most consequential difference. Traditional APIs require the caller to know every endpoint in advance. Someone reads the documentation, writes the code, and hardcodes the integration. When the API changes, the code breaks until someone updates it.

MCP servers describe themselves at runtime. The AI agent sends a discovery request and receives a structured list of every available tool: names, descriptions, input schemas, output formats. No prior knowledge required. No custom code per tool.

Don frames this as a long-term advantage:

"For your very first project, it's not going to make that much sense. You're building your first agentic loop. You're adding three tools, wiring it up. And it's going to actually complicate your life. But play this out a few years - you might have 25, 75, 100 different tools. And when you need to build a new agentic workflow, you'll be able to draw upon all these tools because they'll all be written in the same way."

Dynamic discovery is what makes that scale possible. The 50th tool is as easy for the AI to use as the 5th.

APIs are built for developers and software systems that can safely make network calls, store secrets, and handle errors. The caller has full control over what happens.

MCP is built for AI models and large language models. These are intelligent but untrusted systems that reason with natural language but cannot hold API keys, execute arbitrary code, or make network requests on their own. The Model Context Protocol gives those models a structured, governed way to act on the world.

With APIs, security is enforced at the endpoint level through authentication tokens, API keys, OAuth flows, and rate limits. Each integration manages its own credentials.

MCP adds a governance layer above individual APIs. The MCP server controls which capabilities are exposed to AI systems, what inputs are acceptable, and what logging applies. The AI agent never touches raw credentials.

In regulated environments, this separation is valuable. It reduces credential sprawl, simplifies auditing, and keeps AI systems inside explicit operational boundaries.

Healthcare IT teams have already lived through this kind of standardization shift.

Don draws the parallel directly: "In our industry, you might think of this a little bit like a FHIR server. A FHIR server is just a REST server, but there's a particular way that you can ask for patient information, update patient information. The responses back have a certain format that you know how to digest. And so it's a standardized way that healthcare information can be talked about. And MCP is similar, it's a standardized way where tools are referred to and you can get results."

The parallel is precise:

• FHIR standardized how healthcare systems exchange clinical data. Before FHIR, every EHR had its own proprietary data format, its own API conventions, its own integration requirements. FHIR added a standardized layer on top of REST so any system could exchange patient data in a consistent format.

MCP standardizes how AI agents discover and use tools. Before MCP, every AI integration required custom code for each external service. MCP adds a standardized layer on top of existing APIs so any AI agent can interact with any tool through a consistent protocol.

Both FHIR and MCP sit on top of existing infrastructure. Neither replaces what came before. Both make the underlying systems interoperable in ways that compound over time.

For organizations already running FHIR-based interoperability through platforms like InterSystems HealthShare, the MCP pattern will feel familiar. The same architectural instinct applies to both: standardize the interface, let the implementations vary underneath.

No. Most MCP servers are wrappers for existing APIs.

An MCP server that exposes a schedule_appointment tool might call a hospital's REST API underneath. An MCP server for issue tracking might translate tool calls into Jira's API requests. An MCP server for clinical data might query a FHIR endpoint behind the scenes.

APIs remain the execution layer, the actual mechanism that performs the operation. MCP becomes the interface layer for AI: the standardized way an agent discovers and invokes those operations.

Don describes the tools behind MCP servers as "just APIs like 'schedule an appointment.' They might be databases that you need to read and write to. They might be internet resources, websites. You might get some information from internal document sources, a PDF source or whatever."

MCP and APIs are complementary layers in the AI stack, not competing technologies.

The choice depends on who (or what) is doing the calling and how dynamic the workflow needs to be.

• The workflow is predefined, stable, and unlikely to change
• Performance is critical (every additional layer adds some latency)
• No AI agents are involved, this is system-to-system communication
• You're retrieving data from a pre-stored source like a data warehouse

• AI agents and AI applications need to orchestrate actions across multiple external services
• Workflows change frequently due to regulations, internal processes, or technology updates
• You need dynamic discovery, meaning the AI should adapt to new tools without writing custom code
• Rapid prototyping matters. MCP lets teams connect AI agents to new data sources and tools quickly, without building custom integrations for each one
• Security governance matters. You want to control what the AI can access without exposing raw API endpoints

Most mature architectures will combine direct APIs for stable backend integrations and MCP servers for AI-facing workflows. The APIs do the work. The MCP servers make that work accessible to AI agents in a controlled, standardized way.

This layered approach is where healthcare interoperability platforms earn their keep. The same infrastructure that harmonizes data across disparate systems can also power the MCP servers that AI agents rely on. This turns existing integrations into AI-ready capabilities without rebuilding from scratch.

The value of MCP isn't obvious on your first project. It becomes undeniable at scale.

A first agentic workflow might connect three tools: an EHR query, a scheduling check, and a notification system. Writing custom integration code for three tools is straightforward.

But healthcare organizations will accumulate tools quickly. Add billing verification, insurance eligibility, pharmacy systems, lab orders, clinical decision support, imaging, patient communication, revenue cycle management.

Each new tool that follows the MCP standard is as easy to connect as the last, because they all speak the same protocol.

"You'll be able to draw upon all these tools because they'll all be written in the same way. They'll all talk the same way," Don explains.

MCP adoption is accelerating beyond early adopters. " If you use Salesforce as a CRM or Jira as an issue tracking system, these are shipping with MCP servers," Don notes. "Your vendor-supplied system that you use will start to be shipped with MCP servers, allowing you to take those systems and plug them into your agentic workflows."

Healthcare vendors will follow the same trajectory. EHR platforms, population health systems, revenue cycle tools, and clinical analytics services will ship MCP servers. This makes it straightforward to plug them into agentic workflows without writing custom integration code for each one.

InterSystems IRIS, for example, can serve as the backend for MCP servers that expose clinical workflows, patient queries, or analytics in whatever language the development team prefers. The arms-length relationship between the MCP client and the underlying technology means tools built today will continue to work as the stack evolves.

The pattern extends beyond internal systems. Don points to Context7, this is a MCP server that provides LLM-friendly documentation about technologies which is an example of internet-scale MCP resources.

The healthcare equivalent could be drug interaction databases, clinical practice guidelines, or formulary data exposed as MCP-compatible tools that any AI agent can discover and use. The protocol enables rapid prototyping of AI-native workflows that connect large language models to real clinical data sources without writing custom code for each integration.

APIs are the execution layer. MCP is the AI-native interface layer. They work together.

For healthcare teams, the closest parallel is the shift from proprietary data formats to FHIR. Organizations that adopted FHIR early didn't just solve an interoperability problem. They built a foundation that compounded in value as more systems came online. MCP is the same pattern, applied to AI integration.

The value isn't in your first agentic project with three tools. It's in what happens when you have a hundred tools and they all speak the same protocol. The organizations that standardize how their AI agents interact with external systems now will have a structural advantage that grows with every tool they add.