Lately, we have been in many conversations around Model Context Protocol, and one question keeps coming up:

What’s the use case? Who’s asking for this? It is a fair question. On the surface, MCP can look like a backend protocol discussion meant only for architects and engineers.

But this is not just a conversation about infrastructure. It is a fundamental shift in how software is designed and consumed. And MCP sits at the center of that shift.

From Clicking to Talking

We are moving away from users clicking buttons to users expecting to talk to software.

Across industries, and especially in healthcare, there is a growing assumption that applications should understand intent in natural language. Users increasingly expect software to respond to what they mean, not what they select from a dropdown.

This is the LLM-ification of apps. Conversational UX is rapidly becoming the new baseline. But that evolution introduces a challenge.

The Limits of LLMs

Large language models are powerful, but they are limited.

They do not have real-time access to data by default
They can only act on the context provided in the prompt
When context is incomplete, they hallucinate

An LLM alone is not enough for clinical, operational, or enterprise-grade healthcare workflows. So how do we solve that? You MCP-ify the LLM.

What MCP Actually Does

MCP connects LLMs to tools, data, and services in a structured way.

It enables a model to:

Pull additional context
Invoke external systems
Act through defined functions
Decide when more information is required
Respond with grounded, contextual outputs

The key is not just access. It is structured, discoverable access. MCP does not hard-code every integration into the model. Instead, it exposes tools and lets the LLM determine when to use them. That “when” is the breakthrough. You do not manually feed the LLM every possible detail. You expose the right capabilities, and the model reaches for them as needed.

Where Does Structured Context Come From? This leads to the next question:

Where does the structured context originate?

You FHIR-ify your data.

FHIR provides standardized, structured access to clinical information. Without structured data, tools cannot reliably retrieve or act on patient context.

When data is FHIR-ified, it becomes usable. When apps are LLM-ified, they become conversational. When LLMs are MCP-ified, they become capable of acting responsibly within real systems.

The Stack

The architecture looks like this:

FHIR-ify your data → So tools have structured access to clinical information
LLM-ify your apps → To deliver a natural, conversational experience
MCP-ify your LLM → So it knows what tools exist and when to use them

Each layer depends on the other.

Without FHIR, there is no reliable structured context.
Without LLM-ification, there is no modern interaction layer.
Without MCP, there is no scalable, governed bridge between reasoning and execution.

Together, they define the next generation of healthcare software.

Watch the Architecture in Action

We recently recorded a walkthrough explaining how this stack works in practice.

▶ Watch the video below to see:

What MCP is and the problem it is designed to solve
The lifecycle of a prompt when an MCP server is involved
Real-world examples of MCP interacting with a FHIR server

[Introduction to MCP Servers on MeldRx (ft. Dr. Pawan Jindal)]

Why This Matters

This is not about adding another protocol to the stack.

It is about recognizing that software is no longer consumed purely through screens and forms. It is consumed through conversation.

And conversation without structured context is unreliable.

FHIR structures the data.
LLMs transform the interface.
MCP connects reasoning to action.

At Prompt Opinion, we are building and collaborating at the intersection of AI, healthcare, and interoperability. If this architecture resonates with what you are building or exploring, we would welcome the opportunity to connect.

FHIR-ify Your Data. LLM-ify Your Apps. MCP-ify Your LLM.