Every fee for service practice in the US has billers checking claim status today: has this claim been received, is it adjudicated, was it denied, and why?
When possible this is done by your PM system, and when that fails, it falls back to manual. It can mean a few minutes of clicking, and sometimes a phone call. Only about 500 payers support the 276/277 EDI transaction designed for exactly this question. This means a lot of manual work.
Today we're releasing the Substrate Claim Status MCP, an authenticated connector that gives an AI client the same claim status capability our agents use in production. You give it a minimal claim identity. It resolves the payer, works out which route to use (EDI, payer portal or direct API), asks you for anything the payer needs, and hands back a normalized result. This builds on the Substrate API we launched several months back: https://www.substrateai.com/blog/the-substrate-api
What you can do with it
There are two tools, claim_status and claim_status_get.
These are designed for practices already using PHI-safe versions of ChatGPT and Claude.
Check a single claim. Give your assistant the payer, patient, member ID, billing NPI and service date, and it starts an inquiry. You get back an operation ID to follow.
Let the payer ask for what it needs. If a payer wants one more field, the response comes back as requires_input, saying exactly which one. Supply it, resubmit, and the same inquiry carries on. This helps solve cases where the payer doesn't specify that a specific field is required (or you don't know that a specific field is required for that payer).
Poll to an answer. claim_status_get returns the current state until the work stops being working. The final outcome is one of claim_found, claim_not_found or payer_rejected, or unable_to_process when there is no supported route.
Retry without double work. Every inquiry carries an idempotency key, so a retry after a timeout never creates a duplicate. This helps in case payers are down.
Work a list. Because it is a tool, an agent can walk a short aged-AR worklist for you: check each claim, then summarize which were found, which were rejected and which need a human.
If you're already working your AR Backlog using Claude or ChatGPT, this one's for you. You can set up your portals (eg Availity or UHC) in the Substrate dashboard, and the MCP will trigger the Substrate Claim Status Agent to log in and check claim status on your behalf.
This solves a few problems
- Portal time. Billers spend around three minutes per claim logging into payer portals, and up to 45 minutes on hold when it goes to phone (our launch release).
- Payer coverage. The agent behind this already covers 3,500+ payers, including portal-only ones, not just the roughly 500 that answer EDI.
- Acknowledgments instead of answers. The goal is the real adjudication detail from the source, not just a "received" message. The Claim Status Agent iterates through these on your behalf.
- Context switching. If you're already using Claude or ChatGPT to work claims, you can get claim status context directly into it from here.
How to use it
This MCP invokes the same Claim Status Agent we use for enterprise clients including payer-specific routing and learned strategies.
Because it handles patient information, it sits behind sign-in, unlike our free Payer MCP:
- Add
https://mcp.substrateai.com/claim-statusto your MCP client. - Sign in to Substrate with OAuth and choose an account.
- Approve two scopes:
claim_status:submitandclaim_status:read.
Before connecting a production account, test with synthetic data in MCP Inspector:
npx @modelcontextprotocol/inspector@latest https://mcp.substrateai.com/claim-status
Security
Substrate is SOC 2 Type 2 Certified. For this MCP, opperation IDs are opaque and account-scoped, and every lookup is re-checked against your account. Our gateway doesn't persist request or response bodies, and logs carry account and operation identifiers, not patient identity. Use it only with an AI product configuration suited to PHI. Our trust and security page covers SOC 2 and HIPAA.
This is v0. The patient must also be the subscriber, and one service date is accepted per inquiry. Eligibility, payer portals and appeals tools are in development. If your use case needs one of them, tell us.
