MCP or API? Let Your Tools Decide
MCP or REST API? The right integration for healthcare AI depends on what you're building. Here's how to choose — and why FHIRfly supports both.
The healthcare AI community is debating whether Model Context Protocol (MCP) or traditional APIs are the right way to connect AI agents to clinical data. A recent LinkedIn discussion at HIMSS 2026 captured the tension perfectly: Perplexity AI's CTO announced a move away from MCP toward standard APIs and CLIs, prompting one commenter to declare "Skills + APIs > MCP!" while others worried about ecosystem fragmentation.
The debate is real, but the framing is wrong. This isn't an either/or question. The right integration depends on what you're building — and more specifically, on what your tools can already do.
Two Integration Paradigms, One Data Problem
MCP and REST APIs solve the same fundamental problem — getting accurate, structured healthcare data into your application — but they serve different interaction patterns.
MCP is designed for AI agents that discover and invoke tools dynamically. An LLM reads tool descriptions, decides which ones to call, and interprets the results. The developer doesn't write explicit API calls; the agent figures it out.
REST APIs and SDKs are designed for direct execution — by humans or by AI agents that can run code. A developer (or an AI coding agent) writes a curl command or SDK call, executes it, and gets structured data back. The behavior is explicit, testable, and debuggable.
Neither approach is inherently better. They serve different contexts.
When MCP Is the Right Choice
MCP shines when the consumer is an AI agent working in a conversational context without the ability to execute arbitrary code:
-
AI assistants in clinical workflows — A clinician asks their AI assistant "What are the interactions for this patient's medications?" The agent discovers the right FHIRfly tools, looks up each NDC, pulls FDA label interactions, and synthesizes a response. No developer wrote that specific query path.
-
Chat-based AI products — A patient-facing health app powered by an LLM. The model has no shell, no filesystem, no ability to run curl. MCP gives it structured access to healthcare data through tool definitions it can invoke.
-
Exploratory research — An analyst asks an AI to "find all vaccine codes related to COVID-19 boosters and check which manufacturers produce them." The agent chains cvx_search → mvx_get calls on its own.
In these scenarios, the agent needs tool discovery — the ability to see what's available and decide what to call. That's exactly what MCP provides. FHIRfly's MCP server exposes 40+ tools across NDC, NPI, RxNorm, LOINC, ICD-10, SNOMED, FDA Labels, and Claims Intelligence, each with descriptions that help the agent understand when and how to use them.
Here's what setup looks like for Claude Desktop:
{
"mcpServers": {
"fhirfly": {
"command": "npx",
"args": ["-y", "@fhirfly-io/mcp-server"],
"env": {
"FHIRFLY_API_KEY": "ffly_your_key_here"
}
}
}
}
Once configured, the agent can look up any medical code, check drug interactions, validate claims bundling — all without the user writing a single line of integration code.
When APIs and SDKs Are the Right Choice
Here's what the HIMSS debate is really about: a growing class of AI agents don't need MCP because they can execute code directly.
Consider an AI coding agent like Claude Code, Cursor, or Devin. When it needs to look up an NDC, it doesn't need a protocol layer to discover tools. It can read the SDK documentation, install the package, and call it:
npm install @fhirfly-io/terminology
import { Fhirfly } from "@fhirfly-io/terminology";
const client = new Fhirfly({ apiKey: process.env.FHIRFLY_API_KEY });
const med = await client.ndc.lookup("0069-0151-01");
Or it can skip the SDK entirely and go straight to curl:
curl -H "x-api-key: $FHIRFLY_API_KEY" \
https://api.fhirfly.io/v1/ndc/0069-0151-01
No MCP server to configure. No tool discovery protocol. The agent already has the most powerful integration tool there is: a shell. It can read docs, write code, execute it, inspect the response, and iterate — exactly like a human developer would. This is the core of the "Skills + APIs > MCP" argument. When your AI agent can execute code, a well-documented API is all it needs.
This same directness applies to traditional software development:
-
Web applications — A patient portal that displays medication details from a prescription feed. Deterministic calls, typed responses, explicit error handling.
-
Backend pipelines — An ETL system enriching clinical documents with standardized terminology. Each step is auditable.
-
Validation engines — A claims processor checking NCCI bundling edits before submission.
The FHIRfly TypeScript SDK gives you typed responses, a clear error hierarchy (RateLimitError, NotFoundError, ValidationError), and batch operations for efficiency:
// Batch lookups — up to 500 NDCs per call
const meds = await client.ndc.lookupMany([
"0069-0151-01",
"0069-0770-01",
"0002-4462-01"
]);
// Claims validation with explicit error handling
try {
const edit = await client.claims.validateNcci("99213", "36415");
if (edit.modifier_allowed) {
// Apply modifier and proceed
}
} catch (err) {
if (err instanceof RateLimitError) {
// Back off and retry
}
}
Every call is explicit in your codebase, reviewable in a PR, and coverable by a test — whether a human or an AI agent wrote it.
The Hybrid Reality
In practice, many healthcare AI systems use both patterns. Consider a clinical decision support platform:
-
MCP layer: A physician asks a chat-based AI assistant about a complex drug regimen. The assistant uses MCP tools to explore interactions, check dosing, and pull relevant clinical codes. No code execution needed — just tool invocation.
-
API layer: The development team (human and AI coding agents alike) uses the SDK to build the application's backend — pre-populating formulary data, validating insurance claims, maintaining a synchronized medication database. Direct code, direct execution.
Same data. Same accuracy. Same provenance. Different integration patterns for different capabilities.
FHIRfly supports this by design. Both the MCP server and the REST API hit the same data layer, return the same response shapes, and use the same authentication. The MCP server defaults to full response shape (with provenance metadata for AI citations), while the REST API defaults to standard — but either can be configured for any shape.
What About the "MCP Is Dead" Argument?
The Perplexity announcement sparked concern that MCP might be abandoned in favor of simpler integrations. It's a fair concern — developer ecosystems consolidate around what works, and unnecessary protocol layers add friction.
But the real question isn't whether MCP survives as a spec. It's whether your AI agent can execute code.
If it can — like Claude Code working in a terminal, or Devin spinning up a development environment — then a well-documented REST API and a clean SDK are the most natural integration path. The agent already knows how to curl, how to npm install, how to read a README. No bridge protocol required.
If it can't — like a chat model responding to a patient's question about their medications, or an assistant embedded in an EHR — then it needs a structured tool interface. Today, that's MCP. Tomorrow, it might be OpenAPI-based function calling or something else entirely. The pattern of AI tool discovery isn't going anywhere.
FHIRfly's approach is pragmatic: support both, because both are real. The healthcare data underneath doesn't change regardless of how you access it.
Key Takeaways
- MCP is ideal for AI agents that can't execute code — chat assistants, embedded copilots, conversational interfaces where tool discovery matters
- APIs and SDKs are ideal for AI agents that can execute code (Claude Code, Cursor, Devin) and for traditional application development — anywhere you can run
curl or npm install
- The HIMSS debate boils down to capability: agents with a shell don't need a bridge protocol; agents without one do
- Most production systems will use both — MCP for the chat-facing layer, APIs for everything else
- The integration protocol is a delivery mechanism; what matters is the accuracy and provenance of the underlying data
- FHIRfly supports both paradigms against the same data, so your architecture can use whichever fits
Get Started
Whichever integration path fits your use case, FHIRfly provides the same healthcare reference data — NDC, NPI, RxNorm, LOINC, ICD-10, SNOMED CT, FDA Labels, and Claims Intelligence — with daily updates and full provenance tracking.
