Building an Eligibility-Verification Agent on MCP: A Reference Architecture from Clearinghouse API to Audit Log

The model is the least interesting part of an eligibility agent. What decides whether it survives production is the governed middle: one gateway brokering three payer rails, with a human checkpoint wherever the wire runs out of answers.

The stack at a glance

Most of this cluster is about what an eligibility agent should do. This article is about how to wire one. The hub piece on AI agents for insurance eligibility verification makes the case that the workflow is worth automating — 31.5 billion eligibility checks run every year, 51% of all medical administrative transaction volume, the single largest admin transaction in US healthcare [4] — and it is honest about the ceiling: part of the work automates cleanly, part needs a designed human checkpoint, and part depends on data the payer never puts on the wire. Take all of that as read. What follows is the reference architecture for the team that has decided to build.

The stack in one pass: a scheduling or practice-management system emits the trigger (a new appointment, a 72-hour pre-visit sweep, a monthly re-verification date); an agent runtime picks it up and plans the check; every tool the agent touches — clearinghouse eligibility API, payer FHIR endpoint, EHR, voice-vendor API — sits behind an MCP gateway that brokers credentials, enforces policy, and writes an audit record per call; results flow back into the PM system as structured fields with provenance; and human-in-the-loop checkpoints are marked at the specific points where automation confidence runs out.

Three architectural commitments hide in that table. First, the agent speaks to payers over three distinct rails — clearinghouse 270/271 APIs today, CMS-mandated FHIR endpoints from January 2027, and the phone for everything neither wire carries — and the rails have different auth models, different data semantics, and different failure modes. Second, nothing touches a payer-facing tool except through the gateway. If you take one thing from this article, take that. Third, human review is a designed state in the workflow, not an incident. The runtime itself can be any competent agent loop — the orchestration patterns are standard and the protocol layer is plain MCP. The engineering that determines whether this stack is still working in week six is the middle.

Rail 1: clearinghouse eligibility APIs as MCP tools

The eligibility transaction itself is old and settled: an X12 270 inquiry goes out, a 271 response comes back, and 96% of medical health plans answer fully electronically [4]. What changed in the last few years is the integration surface. You no longer need to parse raw X12, because clearinghouses now front the EDI rails with JSON APIs. Optum's Eligibility API accepts a 270 as a JSON object at /eligibility/v3 and returns the 271 translated to JSON, with an Enhanced variant that adds response normalization and asynchronous coverage discovery [9]. Availity wraps the same transaction behind a REST POST /v1/coverages endpoint, with OAuth 2.0 client-credentials auth on all of its REST APIs [10]. Stedi runs a developer-first clearinghouse with real-time 270/271 and payer-search APIs built for programmatic access [1].

In August 2025, Stedi took the step that matters for this architecture: it shipped the first MCP server from a clearinghouse — a thin wrapper over its real-time eligibility and payer-search APIs, positioned explicitly for use cases like checking patient eligibility before scheduling appointments [1]. Two details in that release matter more than the announcement itself. The server ships with built-in error-recovery guidance: when a payer returns AAA 75, "Subscriber/Insured Not Found," the documented pattern is for the agent to correct the demographics — member-ID transposition, name mismatch, DOB format — and retry, which turns a common eligibility failure mode into a handled branch instead of a dead end [2]. And the wrapper is deliberately thin: the intelligence lives in the agent and the policy lives in the gateway, not in the tool server. That is the correct shape for every tool in this stack.

What the 271 reliably gives back — and what it structurally cannot — is the territory of our EDI 270/271 data-gap analysis: visit limits and visits used, prior-auth and referral indicators, network status, COB primacy, and accumulator lag are the five gaps that keep forcing phone calls, because fields like the authorization indicator are optional and inconsistently populated [3]. For architecture purposes, internalize the consequence rather than the field list: the 271 is a partial answer by design, so the agent must treat "the wire responded" and "the question is answered" as different states.

The second design requirement on this rail is multi-clearinghouse failover. In February 2024, the ransomware attack on Change Healthcare — a clearinghouse that touches roughly one in three US patient records — knocked eligibility and claims traffic offline for weeks, ultimately affected about 192.7 million individuals, and cost roughly $2.457 billion by UnitedHealth Group's own earnings accounting [11]. After Change, single-clearinghouse dependency is an architecture smell. Register at least two eligibility tool servers behind the gateway, health-check both, and make payer-by-payer routing a configuration decision — with segmented credentials per clearinghouse so one compromise doesn't expose the other rail.

Rail 2: the FHIR endpoints arriving January 2027

Nothing in CMS-0057-F replaces the eligibility transaction — worth stating first, because the rule gets routinely oversold. The January 2024 Interoperability and Prior Authorization final rule does not mandate a FHIR eligibility API; eligibility itself stays on X12 270/271. What the rule does mandate, for impacted payers — Medicare Advantage organizations, state Medicaid and CHIP programs, and Qualified Health Plan issuers on the federal exchanges — is four production FHIR APIs by January 1, 2027 [5]:

Source: [5]

For an eligibility agent, the Prior Authorization API is the one that changes the architecture. Today, "does this service need prior auth?" is among the questions the 271 answers least reliably [3], which is exactly why it drives phone calls. From 2027, for impacted payers, that question becomes a standardized tool call: PA-requirement discovery, documentation rules, electronic submission, and decision tracking with specific denial reasons. The operational provisions land even earlier — from January 1, 2026, impacted payers owe PA decisions within 72 hours expedited and seven calendar days standard, with specific denial reasons attached (QHP issuers on the federal exchanges are exempt from the decision-timeframe requirement) [5]. CMS projects roughly $15 billion in provider burden savings over ten years from the rule [6].

The standards underneath are FHIR R4 with the HL7 Da Vinci implementation guides recommended rather than mandated — CRD for discovering coverage requirements at the moment of ordering, DTR for auto-populating the payer's documentation questionnaires from the EHR record, PAS for the submission exchange itself [5]. HHS has granted enforcement discretion so that an all-FHIR prior-auth flow no longer needs an X12 278 behind it [7]. The commercial side is converging voluntarily too: 48-plus insurers, including UnitedHealthcare, Aetna, Cigna, and Humana, pledged FHIR-based PA submission by January 1, 2027, with real-time answers for at least 80% of complete electronic PA requests [8].

The design consequence: define the agent's tool boundary around questions, not transports. "Is this covered?", "Does it need PA?", "What documentation?" — each question maps to a rail today and may re-map in 2027, and a question-shaped tool interface lets you swap the rail underneath without touching the agent. One scope caveat belongs in every planning document: commercial ERISA plans and Original Medicare sit outside CMS-0057-F [5], so the 270/271 rail — and the phone — stay load-bearing indefinitely.

Rail 3: the phone fallback

Rail 3 is the one nobody wants on the diagram: the phone. Visits remaining, plan-specific carve-outs, behavioral-health benefit detail, contradictions between the portal and the 271 — the questions no wire answers today are precisely the ones covered in our analysis of voice AI agents that call payers, vendor accuracy claims and escalation reality included. Architecturally, the fallback trigger is already an established industry pattern: Salesforce's 2025 partnership with Infinitus wires Agentforce and MuleSoft so that when no API or portal can answer a benefit-verification or PA-status question, the workflow triggers an AI phone call to the payer [15]. In this reference stack, the voice vendor is just another tool server behind the gateway — same allowlist, same audit log — and its outputs land in the human review queue, not directly in the PM system. A call transcript is evidence, not truth.

The gateway layer: one credential broker, one policy layer, one audit log

Wire an LLM agent to those three rails directly and you get the naive topology: payer credentials living in prompt-adjacent config, every tool trusting the model, and no single place where policy or logging happens. The governed alternative starts from a different definition: an eligibility agent stack is not "an AI that can reach a clearinghouse" — it is an architecture that limits what the agent can access, validates what comes back, records how every result was produced, and refuses actions nothing authorized. That is the job description of an MCP gateway.

Concretely, the gateway owns four things. Credential brokerage: the OAuth client-credentials flows the clearinghouses require [10] terminate at the gateway, never inside the agent — our piece on MCP gateway auth and discovery covers the flows in depth, and clearinghouse client-credentials auth is a textbook case for them. Policy: per-agent tool allowlists (the eligibility agent may call check_eligibility and search_payer; it may not touch an EHR write API), rate limits, and schema validation on tool inputs and outputs, hardened along the lines of our MCP server security guide. A single audit log: one record per tool call with propagated end-user identity — which is what HIPAA's audit-control standard translates to for agents; the HIPAA-compliant AI agent architecture spoke maps that control set requirement by requirement, and this stack is the implementation of it. Content defense: 271 free-text fields, payer PDFs, and call transcripts are untrusted input to the model — the same threat class we cover in prompt injection defense for enterprise agents.

The worked example I can speak to concretely is Jarvis Registry — flagged plainly: it is our product, built by ASCENDING, which publishes this site (see the disclosure banner above). Registry is a universal MCP and agent gateway with, in the company's words, "governance and observability included," and its composability claim describes exactly the property this stack depends on: "any client that speaks MCP can use any server that speaks MCP, with one credential broker, one policy layer, and one audit log." Because Registry implements MCP as its first-class protocol surface rather than a plugin, it "inherits whatever the community ships" — and that is the architectural reason MCP-native matters here. When a clearinghouse ships an MCP server, as Stedi did [1], a first-class gateway can register and govern it without waiting on a vendor connector roadmap. That is an implication of the design to validate in your own environment, not a claim that any specific payer integration comes prebuilt — ASCENDING does not claim prebuilt payer connectors.

The honesty boundary belongs in body copy, not a footnote: ASCENDING does not claim Jarvis holds HIPAA, SOC 2, or FedRAMP certification, and Jarvis has no telephony capability. A buyer verifies BAA terms, attestations, and subprocessor coverage for Jarvis exactly the way this cluster tells you to verify them for every other vendor — the compliance spoke is the checklist for doing that.

Two ecosystem signals say the gateway pattern is where healthcare MCP is heading rather than a niche preference. Innovaccer published HMCP — the Healthcare Model Context Protocol — an open spec extending MCP with healthcare-grade controls: OAuth2/OpenID authentication, data segregation and encryption, audit trails, and rate limiting [12]. And the tool-server side is going MCP-native from both ends of the stack: athenahealth previewed an MCP server for authorized AI-agent access to athenaOne at HIMSS26 [13], while Epic unveiled Agent Factory, a no-code platform for health systems to build, orchestrate, and monitor agents with traceable actions [14]. The more MCP endpoints the ecosystem ships, the more the governed control point in the middle becomes the architecture, not an accessory to it.

The staff surface: chat with RAG over payer policy documents

The stack needs a human surface for two reasons: someone has to clear the review queue, and the front desk's questions don't stop at structured fields. "Does this plan cover dry needling?" is a payer-policy-document question, not a 271 field. The pattern that works is an embedded chat surface with RAG over the documents staff actually consult — payer policy manuals, plan-specific carve-out notes, the clinic's own SOPs — grounded so every answer cites the document it came from.

Jarvis Chat is our worked example here, under the same disclosure. Its stated capabilities map onto this surface directly: multi-LLM routing across OpenAI, Anthropic, AWS Bedrock, Google Gemini, and DeepSeek behind one interface; access control via RBAC with SSO, SAML, and OAuth; PII detection running on inputs and outputs; a RAG-grounded enterprise knowledge base; and an embeddable JavaScript SDK — which is what lets the chat drop into the front-desk portal staff already use instead of becoming another tab. The architectural point is not the chat itself. It is that Chat and Registry ride the same Governed AI Layer, so the staff surface and the agent's tool calls land in one audit trail under one policy set rather than two systems with two logs. And for a clinic, deployment shape matters as much as features: private VPC deployment in the customer's own AWS account is, per ASCENDING, the path for healthcare and any account where data leaving your boundary is a contracting blocker.

Human-in-the-loop checkpoints and write-back

Human-in-the-loop is a design feature of this stack, not an apology for it. The vendors furthest along agree by revealed preference — every production voice vendor architects mandatory escalation paths and none publishes an unassisted completion rate — and the data gaps are structural until regulation forces the payer side to close them. So design the checkpoints in from the start, and be precise about which side of the line each step sits on.

Auto-completes without review: the 72-hour batch sweep and check-in re-verification; structured 271 fields — active status, plan dates, copay, coinsurance, deductible and out-of-pocket accumulators — written back with provenance; AAA-75 retries with corrected demographics [2]; scheduling the next re-verification.

Queues for human review: any field driving a patient-facing cost estimate where the payer disclaimed the quote; contradictions between rails (the 271 says no PA required, the policy document says otherwise); low-confidence extractions from calls or documents; COB conflicts; anything that would change what a patient is told at check-in.

The write-back discipline borrows the extract→cite→write-back pattern from our insurance defense legal intake case study: no value lands in the PM system as bare text. Every field carries provenance to its source — which 271 benefit loop, which FHIR resource, which call-transcript timestamp — so the person clearing the queue, and the auditor reviewing the quarter, can see where each number came from. Review is cheap when evidence is attached and expensive when it isn't. The audit trail underneath is the same one the gateway is already writing: per-tool-call, identity-propagated, retained on the multi-year horizon HIPAA's documentation rules expect — the compliance spoke covers the retention math.

Build order: eight steps from first 270 to production

The sequence I would actually ship, each step complete before the next starts:

1. Pick your rails. Inventory the front desk's real question list and map every question to the rail that answers it — 271 structured fields, post-2027 FHIR PA endpoints, or the phone. The unmapped remainder is your human-work baseline; be honest about its size.
2. Wire the gateway before the first tool. Stand up the MCP gateway and register the first clearinghouse tool server behind it. No direct agent-to-API path, even in the prototype — prototypes have a way of becoming production auth.
3. Scope credentials per tool. Separate OAuth client-credential grants per clearinghouse and per tool server, brokered at the gateway and segmented so one compromised credential exposes one rail — the Change Healthcare lesson applied at stack scale [11].
4. Define escalation before automation. Write the review-queue rules — disclaimed quotes, cross-rail contradictions, low-confidence fields, COB conflicts — while the agent still does nothing. A case that matches no rule queues by default.
5. Log everything with identity. Per-tool-call audit records with propagated end-user identity, and per-field provenance on every write-back, from the first test call onward. Retrofitting audit is the most expensive way to build it.
6. Evaluate accuracy against a human baseline. Run the agent in shadow against staff-verified benefits for a labeled patient sample; measure per-field agreement, not per-check completion. A check that returns fast but wrong is a denial with a delay.
7. Pilot one payer cohort. Start with the handful of payers that dominate your volume, run the 72-hour sweep plus check-in re-verification, and track the front-end denial-rate delta — that is the number that justifies the project.
8. Expand rail by rail. More payers first; then the FHIR PA endpoints as impacted payers ship them through 2026–2027 [5]; the phone fallback last, because it is the rail with the widest error bars and the most human review.

FAQ

What is a healthcare MCP server?

An MCP server that exposes a healthcare system's API — clearinghouse eligibility, payer FHIR endpoints, an EHR — as tools an AI agent can call under governance. The point is not connectivity but control: the server, and the gateway in front of it, define what an agent can access, validate what comes back, and record how each result was produced. The category is real and moving fast: Stedi shipped the first clearinghouse MCP server in August 2025, athenahealth previewed one for athenaOne at HIMSS26, and Innovaccer's HMCP spec extends MCP with healthcare controls like OAuth2/OpenID, data segregation, encryption, and audit trails.

Can an AI agent call clearinghouse APIs directly, without a gateway?

Technically yes — Optum, Availity, and Stedi all expose REST APIs that any agent framework can call. Architecturally it is the mistake this reference design exists to prevent: direct wiring puts payer credentials in agent configuration, leaves tool access ungoverned, and scatters audit evidence across per-tool logs, which becomes a real problem the day HIPAA's audit-control standard requires you to reconstruct who accessed what. A gateway collapses credentials, policy, and logging into one layer with one log. Hence the build-order rule: wire the gateway before the first tool, even in the prototype.

Do the 2027 FHIR APIs replace EDI 270/271 eligibility checks?

No. CMS-0057-F mandates four FHIR APIs — Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization — for impacted payers by January 1, 2027, but none of them is an eligibility API; the eligibility transaction itself remains X12 270/271. What changes for an eligibility agent is adjacent and significant: prior-auth discovery, documentation requirements, and decision status become standardized tool calls instead of portal scraping and phone calls. Scope matters too — commercial ERISA plans and Original Medicare are outside the rule, so the 270/271 rail and the phone fallback stay load-bearing well past 2027.

Where do humans stay in the loop in an eligibility-verification agent?

At the points where confidence or data runs out — by design, not as a stopgap. Structured 271 fields auto-complete with provenance attached. The human review queue catches disclaimed benefit quotes, contradictions between rails, low-confidence extractions from calls and documents, COB conflicts, and anything that changes what a patient is told about cost. The payer's own quote disclaimers and the 271's structural gaps mean a fully hands-off pipeline is not an engineering milestone you eventually reach — it is a claim the underlying data doesn't support. Design the queue first; automate around it.

References

1. Introducing the Stedi MCP server — first clearinghouse MCP server, wrapping real-time 270/271 eligibility and payer search — Stedi changelog (2025): https://www.stedi.com/changelog/introducing-the-stedi-mcp-server
2. Stedi healthcare MCP server documentation — built-in error-recovery guidance, including AAA 75 "Subscriber/Insured Not Found" retry handling — Stedi docs (2025): https://www.stedi.com/docs/healthcare/mcp-server
3. What you can reliably get from a 271 eligibility response — reliable fields vs. optional indicators and structural gaps — Stedi blog (2025): https://www.stedi.com/blog/what-you-can-reliably-get-from-a-271-eligibility-response
4. 2024 CAQH Index Report — eligibility transaction volume, share of admin transactions, and electronic adoption rates — CAQH (2025): https://www.caqh.org/hubfs/Index/2024%20Index%20Report/CAQH_IndexReport_2024_FINAL.pdf
5. CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) fact sheet — impacted payers, the four FHIR APIs, 2026 operational provisions, and recommended Da Vinci implementation guides — CMS (2024): https://www.cms.gov/newsroom/fact-sheets/cms-interoperability-prior-authorization-final-rule-cms-0057-f
6. CMS finalizes rule to expand access to health information and improve prior authorization — ~$15B ten-year provider burden-savings estimate — CMS press release (2024): https://www.cms.gov/newsroom/press-releases/cms-finalizes-rule-expand-access-health-information-improve-prior-authorization-process
7. HIPAA transaction enforcement discretion for FHIR-only prior authorization (X12 278) — CMS (2024): https://www.cms.gov/priorities/burden-reduction/overview/interoperability/frequently-asked-questions/hipaa-transaction-enforcement-discretion
8. Inside payers' latest plans to streamline prior authorization — the June 2025 AHIP-CMS pledge: 48+ insurers, FHIR PA by Jan 1, 2027, ≥80% real-time answers — American Medical Association (2025): https://www.ama-assn.org/practice-management/prior-authorization/inside-payers-latest-plans-streamline-prior-authorization
9. Optum Medical Network Eligibility v3 API — 270/271 as JSON, Enhanced Eligibility normalization and coverage discovery — Optum developer docs (2025): https://developer.optum.com/eligibilityandclaims/reference/medical-network-eligibility-v3-overview
10. Availity API guide — REST coverages endpoint over 270/271 and OAuth 2.0 client-credentials auth — Availity developer blog (2025): https://developer.availity.com/blog/2025/3/25/availity-api-guide
11. Change Healthcare data breach — ~192.7M individuals affected, ~$2.457B in costs per UHG earnings, one-in-three patient-record reach — The HIPAA Guide (2025): https://www.hipaaguide.net/change-healthcare-data-breach/
12. Introducing HMCP: a universal open standard for AI in healthcare — MCP extended with OAuth2/OpenID, data segregation, encryption, audit trails, rate limiting — Innovaccer (2025): https://innovaccer.com/blogs/introducing-hmcp-a-universal-open-standard-for-ai-in-healthcare
13. HIMSS26 highlights shift toward agentic AI across healthcare IT workflows — athenahealth MCP server preview for athenaOne — Digital Health News (2026): https://www.digitalhealthnews.com/himss26-highlights-shift-toward-agentic-ai-across-healthcare-it-workflows
14. At HIMSS26, Epic highlights no-code Agent Factory and other AI advances — Healthcare IT News (2026): https://www.healthcareitnews.com/news/himss26-epic-highlight-no-code-agent-factory-and-other-ai-advances
15. Infinitus deepens partnership with Salesforce — Agentforce/MuleSoft triggering voice AI payer calls when no API exists — PR Newswire (2025): https://www.prnewswire.com/news-releases/infinitus-deepens-partnership-with-salesforce-to-accelerate-ai-agent-adoption-in-healthcare-and-life-sciences-302490302.html