The previous post of this series explained why LLMs need tools, why the agentic pattern matters, and how standards like MCP and A2A make tool‑calling safe and interoperable. But standards alone don’t guarantee usability—especially in healthcare, where clinicians and researchers need systems that “just work.” This is where DHTI steps in, transforming the complexity of MCP into something deployable, maintainable, and clinician‑friendly.
A key part of this transformation is DHTI’s integration with MCPX, a production‑ready gateway for managing MCP servers at scale. MCPX is powerful, but on its own it still requires engineering expertise. DHTI removes that barrier by packaging MCPX inside its own container environment and extending it with a new feature called docktor, which makes installing healthcare algorithms as simple as running a single command.
Let’s unpack how this works.
Image credit: sOER Frank, CC BY 2.0 https://creativecommons.org/licenses/by/2.0, via Wikimedia Commons
What MCPX Is and Why It Matters
MCPX is an open‑source, production‑grade gateway created by Lunar.dev to orchestrate and manage multiple MCP servers. It provides a unified gateway for an entire MCP ecosystem, giving teams centralized control over which tools are exposed to which agents, how they are configured, and how they perform. MCPX acts as an aggregator, meaning it can connect to many MCP servers and present them as a single, coherent interface to an LLM or agent.
Search results also highlight several key capabilities:
- MCPX dynamically manages multiple MCP servers through simple configuration changes, enabling zero‑code integration with MCP‑compatible services.
- It centralizes tool discovery, access control, call prioritization, and usage tracking, making it suitable for production‑grade agentic systems.
- It is designed for environments where the number of tools and servers grows rapidly, providing visibility and governance across all interactions.
In short, MCPX solves the “tool sprawl” problem: instead of wiring dozens of MCP servers manually, you point everything to MCPX and let it orchestrate the rest.
But MCPX is still a developer‑oriented platform. It assumes familiarity with Node.js, configuration files, environment variables, and container orchestration. That’s where DHTI changes the game.
How DHTI Makes MCPX Easy
DHTI embeds MCPX directly into its Docker‑based architecture. Instead of requiring users to install MCPX manually, configure it, and manage its lifecycle, DHTI:
- Deploys MCPX automatically inside its container environment
- Configures MCPX to work with DHTI’s FHIR, CDS‑Hooks, and agentic components
- Exposes MCPX to agents without requiring any user‑side setup
- Handles the installation of algorithms/calculators packaged as an MCP server with a single command.
For healthcare teams, this is transformative. MCPX becomes invisible infrastructure: powerful, flexible, and standards‑compliant, but never something clinicians need to touch.
Docker‑in‑Docker: Deploying Healthcare Algorithms as Tools
Healthcare algorithms and calculators increasingly ship as Docker containers. This is already common in research environments and many FHIR‑related tools. Docker packaging ensures reproducibility, version control, and portability across systems.
DHTI extends this model by enabling Docker‑in‑Docker deployments inside MCPX. In practice, this means:
- A research team packages an algorithm—say, a stroke‑risk calculator or EEG classifier—into a Docker container.
- They follow a simple standard:
- The container must accept a patient ID as input
- It must be able to access a FHIR server for structured data
- It must be able to read from a local folder for unstructured data (EEG, radiology images, PDFs, etc.)
- DHTI installs this container inside MCPX, where it becomes an MCP tool.
- Agents can now call the tool using MCP, passing only the patient ID.
This architecture ensures that algorithms remain isolated, reproducible, and easy to update—just replace the container with a new version.
Why Standards Matter for Healthcare Algorithms
Healthcare algorithms are not arbitrary scripts. They must follow predictable patterns so they can be safely integrated into clinical workflows. The most common requirements include:
- FHIR server access for structured data such as vitals, labs, medications, and encounters.
- Many FHIR servers—including Microsoft’s open‑source implementation—run as Docker containers, making them easy to integrate into DHTI’s environment.
- Local folder access for unstructured data such as EEG files, radiology images, or waveform data.
- Patient‑ID‑based invocation, which keeps the interface simple and consistent across tools.
By standardizing these expectations, DHTI ensures that any algorithm packaged by a research team can be installed and used by clinicians without custom engineering.
Introducing “Docktor”: One‑Command Installation for Clinicians
The most exciting part of this new architecture is docktor, a DHTI feature that lets clinicians install algorithms with a single command.
Instead of:
- cloning GitHub repositories
- configuring environment variables
- wiring MCP servers manually
- setting up Docker networks
- mapping volumes
- writing MCP configuration files
…a doctor simply runs:
dhti-cli docktor install <algorithm-name>
Behind the scenes, DHTI:
- Pulls the Docker image
- Deploys it inside MCPX using Docker‑in‑Docker
- Registers it as an MCP tool
- Grants it access to FHIR and local data folders
- Makes it available to agents immediately
The installed algorithm becomes a first‑class MCP tool, callable by any agent in the system.
This is the democratization of GenAI in action: clinicians gain the ability to extend their AI stack without needing a DevOps team.
Seamless Data Access and Agent Output
Once installed, these tools behave like native components of the agentic workflow. An agent can call a tool with:
patient_id: “12345”
The tool retrieves the necessary data from the FHIR server or local folders, runs the algorithm, and returns structured output to the agent. The agent can then:
- summarize results
- generate recommendations
- integrate findings into a CDS‑Hooks card
- write notes back into the EMR (if permitted)
The entire workflow becomes smooth, modular, and maintainable.
Why This Matters for Healthcare
Healthcare AI has long been held back by deployment friction. Researchers build algorithms, but clinicians struggle to use them. EMR vendors offer APIs, but integrating new tools requires engineering resources most hospitals don’t have.
DHTI + MCPX + docktor changes that equation:
- Researchers package algorithms as Docker containers
- DHTI installs them with one command
- MCPX orchestrates them as standardized MCP tools
- Agents call them using patient IDs
- Clinicians get actionable results inside their workflows
This is the missing layer that turns agentic AI from a prototype into a practical clinical platform.
What’s Next
In the next post, I’ll walk through practical examples of docktor in action—how a clinician might install a stroke‑risk calculator, a dermatology classifier, or a genomics pipeline, and how agents use these tools to deliver meaningful clinical insights.
Try the following command today!
npx dhti-cli docktor –help
- How DHTI Makes MCP Practical for Healthcare Through “Docktor” (Part IV) - February 4, 2026
- LLMs, Agentic Patterns, and Practical Healthcare: Why Tools Matter (Part III) - January 28, 2026
- Why DHTI Chains Matter: Moving Beyond Single LLM Calls in Healthcare AI (Part II) - January 20, 2026