Billing companies
A Claude agent that works your AR list
Claude checks each claim, reads the payer's last answer and the denial, and drafts the appeal for a person to approve.
Build this with AIA brief with this use case's endpoints, events and rules, ready for your assistant to build it in your stack.
How it works
Add Daybook's MCP server to Claude, Claude Code or Cursor.
Hand the agent your AR list.
It runs check_claim_status, reads the last payer call with get_call and the denial with get_denial.
It drafts appeals with draft_appeal and leaves every approval to your team.
Built on
POST
/v1/claim-status/checksCheck claim statusGET/v1/calls/{id}Retrieve a callGET/v1/denials/{id}Retrieve a denialPOST/v1/appealsDraft an appealThe prompt
Paste it into Claude, Codex, Cursor or ChatGPT. It links the docs pages it needs, so your assistant builds against the real API.
I'm building on the Daybook API (healthcare billing: payer calls, payer portals, 270/271 eligibility, 276/277 claim status, 835 remits, denials and appeals). Help me build this end to end.
Use case: A Claude agent that works your AR list
For: Billing companies
Outcome: Claude checks each claim, reads the payer's last answer and the denial, and drafts the appeal for a person to approve.
What to build:
An agent setup over Daybook's MCP server (https://mcp.daybookhealthcare.com/mcp) that works an AR list I paste or attach: for each claim it runs check_claim_status, reads the last payer call with get_call when the claim is pending, reads the denial with get_denial when it is denied, drafts an appeal with draft_appeal when the cause is one we appeal, and ends with a table per claim: status, what the payer said, the next step and the appeal drafted, if any.
How it works:
1. Add Daybook's MCP server to Claude, Claude Code or Cursor.
2. Hand the agent your AR list.
3. It runs check_claim_status, reads the last payer call with get_call and the denial with get_denial.
4. It drafts appeals with draft_appeal and leaves every approval to your team.
Read these docs first (Markdown):
- https://daybookhealthcare.com/docs/workflows/claim-status.md
- https://daybookhealthcare.com/docs/workflows/payer-calls.md
- https://daybookhealthcare.com/docs/workflows/denials-and-appeals.md
- https://daybookhealthcare.com/docs/api-reference/claim-status/create-check.md
- https://daybookhealthcare.com/docs/api-reference/calls/get.md
- https://daybookhealthcare.com/docs/api-reference/denials/get.md
- https://daybookhealthcare.com/docs/api-reference/appeals/create.md
- https://daybookhealthcare.com/docs/mcp.md
- https://daybookhealthcare.com/docs/webhooks/verifying-signatures.md
- https://daybookhealthcare.com/docs/idempotency-and-errors.md
Endpoints (base https://api.daybookhealthcare.com/v1):
- POST /claim-status/checks: Check claim status
- GET /calls/{id}: Retrieve a call
- GET /denials/{id}: Retrieve a denial
- POST /appeals: Draft an appeal
Ground rules:
- Authenticate with the header Authorization: Bearer <key>, the key read from DAYBOOK_API_KEY. sk_test_ keys open a sandbox and sk_live_ keys reach real payers. Never hard-code a key. Details: https://daybookhealthcare.com/docs/authentication.md
- Send an Idempotency-Key on every POST: a fresh UUID per operation, reused only to retry that operation. A key reused with a different body answers 409 idempotency_conflict.
- Verify every webhook signature before trusting the event, answer 2xx at once and do the work after.
- Keep my own ids beside Daybook's, and pass them in metadata where an endpoint takes it.
- Money is integer cents.
- Tests and fixtures use made-up data only: the sample payers bayline, keystone and meridian, NPI 1999999984, member W000000001, claim ids like clm_8Hq2Lm. Never real patient data.
- Use only the fields, endpoints and events in the docs. If something is missing, ask me rather than guess.
Write the MCP setup for Claude Code and the agent's instructions, then run it on three made-up claims from the sample payers.Related use cases
Call the payer from your denial queueEvery denial a phone call settles gets one, and the rep's answer lands back on the same ticket.Nightly claim status sweep into your PM systemEvery unpaid claim checked over 276/277 overnight, and only the claims that moved come back to you.Appeal letters drafted from denial dataA drafted appeal waiting for every denial worth fighting, inside its deadline.Post finished payer calls to SlackYour team sees each payer's answer in a channel as a call ends, and a ping when a live rep is ready for a biller.

