Healthcare data is scattered across many disparate sources, which means healthcare data communication happens via a complex combination of portals, APIs, faxes, and phone calls. This adds up to a major administrative burden for providers’ offices, as they work to ensure patients can get on the medications they need. The process is far from ideal – it’s messy, time-consuming, and frustrating for patients, payors, and providers alike. 

Now, imagine a different reality: one where AI agents support these workflows as soon as a patient is diagnosed and prescribed a course of treatment. The AI agents complete eligibility and benefits checks, follow up on prior authorizations and appeals so that patients can be scheduled to receive treatment, and are kept in the loop all along. This is the future that the Infinitus MCP server unlocks.

In this post, we will outline the importance of MCP (Model Context Protocol) in healthcare and why and how we chose to make an MCP server.

What is MCP?

Increased LLM (large language model) usage across various industries has led to demand for interoperability as people seek to expand their AI agents’ capabilities. MCP has emerged as a protocol developed by Anthropic, and it can be seen as “FHIR for AI applications.” Just as FHIR enforces standardization in communication between different healthcare systems, this standardizes communication between an AI model and people who provide services for the model to use. 

MCP enables agents to interact with the real world. It allows application developers to expose their capabilities to agents through MCP servers, which describe a set of tools that a particular agent may use. For example, let’s say that you want to scan a document or spreadsheet for a list of contacts to send outreach emails to on a weekly basis. An MCP server makes it easy for AI agents to access tools that make performing these actions easy. 

While getting started on an MCP journey can seem daunting, chances are you’re further along than you thought – especially if you already have APIs that you’ve built out. Read on for how we tackled this at Infinitus, along with some tips and “gotchas” to watch out for.

Our approach: OpenAPI + FastMCP

Several approaches may be taken to expose API endpoints as tools in an MCP server. One may opt for manual server creation, manually creating and exposing tools that call your API. However, we opted to develop our MCP server using our internal OpenAPI specification (supported by FastMCP). We have internally maintained OpenAPI documentation for our customer-facing APIs for many years and use it as a “source of truth” for API-related information. Using it for the MCP server would enable scalable and reliable tool creation: we wouldn’t have to manually add/edit endpoints upon updates to our API. 

The hard part: Upgrading from OpenAPI 2.0 

One big challenge encountered was the lack of library support for older OpenAPI specification versions. Our codebase used OpenAPI version 2.0, but only the latest versions (OpenAPI versions >3.0) are well-supported by libraries such as FastMCP. We had difficulty finding a reliable library that converted an OpenAPI version 2.0 specification to an MCP server, so we had to upgrade our specification to version 3.0.

This didn’t come without issues. Internally, we relied on this specification to generate a gRPC .proto file containing structures for microservice communication. We opted to use the OpenAPI Generator library to convert the new specification to the respective .proto file (upgrading from an older convertor). However, structural changes led to downstream issues with code compatibility. Some issues encountered included: 

  • The generated .proto file didn’t nest the definitions of the schemas, compared to the previous spec. For example, one old definition was:

which was later turned into:

The spec to .proto converter also didn’t properly handle type conversion for “nullable” fields, so we edited the .proto generation template to insert the Google well-known Protobuf types. Our file then looked something like:

Our Infinitus MCP server will provide powerful capabilities to chat-based LLMs: with a simple natural language query, users can unlock various features provided by Infinitus. The following flow shows a real example in which the user wishes to learn more about the payors supported by Infinitus:

User: Hi, can you get me all of the payors supported by the Infinitus API?

Claude Sonnet 4 (with access to the tools): I’ll help you get all the payors supported by the Infinitus API. Let me use the Infinitus API to retrieve this information…(tool call information)… Great! I’ve successfully retrieved all the payors supported by the Infinitus API. Here’s the complete list of 95 payors that are currently supported: Major National Payers Aetna (including Aetna PBM and Aetna Senior Supplemental) Cigna United Healthcare (including United AARP) Humana (including Humana Tricare East) Kaiser Permanente Blue Cross Blue Shield Plans (by State) Anthem Blue Cross (California) Anthem Blue Cross and Blue Shield (Colorado, Connecticut, Indiana, Kentucky, Maine, Missouri, Nevada, New Hampshire, Ohio, Virginia, Wisconsin)…

The road ahead

Infinitus is committed to staying ahead of the curve by leveraging the latest technologies to empower our customers. Our MCP server will enable healthcare organizations to automate tedious manual processes (such as benefit verification and prior authorization), saving administrative employees hours of tiring work. 

If you’re a current customer interested in learning more about how to enable this for your organization, please contact your account team. If you’re not yet a customer but would like to learn more about Infinitus, contact us here – we’re looking forward to sharing more about how we can help you deliver better outcomes for your clients.