
Backwork
io.github.tylergibbs1Published by GitHub account tylergibbs1v2.1.6Updated Nov 1, 2026
Medicare and commercial payer policies, prior auth, claim risk, and medical codes from Backwork.
Overview
Backwork's official MCP server for Medicare and commercial payer policies, medical codes, prior authorization, claim risk and drug formulary evidence.
- What you can do
- Look up coverage for procedure codes, combining code details, policy evidence, prior auth, claim risk, jurisdiction comparison and spending evidence
- Search, fetch and compare medical policies, extracted criteria, recent policy changes and MAC jurisdictions
- Validate claims for coverage, documentation requirements and denial risk, and research prior authorization including public payer website searches
- Search commercial pharmacy-benefit formulary evidence from major PBMs
- Review compliance stats and unreviewed policy changes, and manage webhook endpoints with a write-scoped key
- Check Backwork API health and dependency status
- When to use it
- Useful for healthcare billing, coding, revenue-cycle and compliance work where an assistant should answer coverage, prior-auth, denial-risk or formulary questions with cited policy sources. The hosted read-only connection covers research; a local key connection is needed for webhook management and compliance acknowledgements.
- Requirements
- Either the hosted remote endpoint with OAuth browser sign-in, or the local npm package run with npx (Node.js 18.14.1 or newer) using a Backwork API key in BACKWORK_API_KEY. A Backwork organization account is required; calls draw on the organization's request credits. A test key works only against the sandbox base URL set via BACKWORK_API_BASE.
Installation
In SourceWeft
- Open Backwork in the dashboard and add it to a workspace.
- Connect the required credentials. They are stored privately and never shown on public pages.
- Enable the server for the chats that should use its tools.
Web executable via Streamable HTTP. Remote servers run from the web runtime once configured in a workspace.
Use with an agent
Paste this prompt into Claude Code, Codex, Cursor or another agent — or into SourceWeft chat. The agent reads this server's install guide, shows you its publisher, endpoint and sign-in, and adds it to your client once you agree. Keys never go into a command.
Read https://sourceweft.com/mcp/io.github.tylergibbs1%2Fbackwork-mcp/install.md and connect the MCP server it describes to my client. Before changing any config, show me its publisher, endpoint and sign-in method and wait for my OK. Never put an API key in a command or in a file I would commit; ask me where it should come from.Other MCP clients
Add this to your client's mcpServers config. The client completes OAuth sign-in on first connect.
{
"mcpServers": {
"backwork": {
"type": "http",
"url": "https://backworkhealth.com/mcp"
}
}
}README
Backwork MCP Server
Official Model Context Protocol (MCP) server for the Backwork API. It gives AI assistants controlled access to Medicare and payer medical policies, medical code intelligence, prior authorization checks, claim validation, compliance review, drug formulary evidence, and webhook operations.
Quick start
The fastest way in is the hosted server with Claude Code:
There are two ways to connect:
The hosted endpoint only accepts OAuth. Do not send a Backwork API key as a bearer token to https://backworkhealth.com/mcp. The OAuth grant is read-only (backwork:mcp read), so the hosted server offers only read actions: no webhook management and no compliance acknowledgements. Use local stdio with a write-scoped live key for those.
Calls draw on your organization's request credits, like any other /api/v1 call. A bwk_test_ key works only on the sandbox (https://backworkhealth.com/api/sandbox/v1), which covers policy search, code lookup, prior-auth check and coverage evaluation; to use it, set BACKWORK_API_BASE to that URL.
Setup for each client is in Connect your client. Agent-oriented install notes are in llms-install.md.
How it works
The server exposes eight workflow-level tools rather than one tool per endpoint. Each tool calls the Backwork API only through the operation catalog in src/api-operations.ts, returns readable text plus structuredContent, and cites the policy sources it used. Which tools and actions you see depends on how you connect (see Production availability).
Tools
Tool names use the backwork_ prefix for discoverability when this server is installed alongside other MCP servers. The default surface is intentionally workflow-level rather than a 1:1 API wrapper, so agents see fewer choices and common tasks require fewer tool calls.
Response format
Every tool accepts:
Use "markdown" for readable output or "json" to make the text content mirror the returned structuredContent.
Example prompts
Connect your client
Claude Code
Add --scope user to make it available in every project. Then run claude, open /mcp, select backwork, and finish the browser login and Backwork consent screen. Check it with claude mcp get backwork.
If OAuth discovery needs to be pinned explicitly, add the same server as JSON:
Local stdio:
Claude Code plugin
The backwork plugin bundles the hosted MCP server with four research skills: prior authorization, coverage checks, policy changes, and denial appeal prep. Install it from this repository's plugin marketplace:
Then run /mcp, select plugin:backwork:backwork, and finish the OAuth sign-in. New accounts start with 100 free credits. See plugins/backwork/README.md for the skills and the /backwork:pa and /backwork:coverage commands.
The marketplace manifest is .claude-plugin/marketplace.json. npm test checks the manifests and every SKILL.md. CI also runs claude plugin validate --strict on the marketplace and the plugin.
Claude Desktop
Hosted remote: open Settings > Connectors > Add custom connector, name it Backwork, and enter https://backworkhealth.com/mcp. Claude Desktop runs the OAuth login when you connect.
Local stdio: add this to claude_desktop_config.json (Settings > Developer > Edit Config) and restart Claude Desktop:
Cursor
Add to ~/.cursor/mcp.json (all projects) or .cursor/mcp.json (one project). Cursor opens the OAuth login the first time it connects:
Local stdio:
VS Code
Or add it to .vscode/mcp.json in a workspace. VS Code asks you to sign in when the server starts:
Local stdio, with the key prompted for once and stored by VS Code:
Codex
ChatGPT
ChatGPT connects to the hosted server as a custom MCP connection in developer mode. Three tools return a small card that ChatGPT renders inline above its answer.
- In ChatGPT, open Settings → Security and login and turn on Developer mode. Your plan or workspace admin may need to allow it.
- Go to chatgpt.com/plugins and select the + button.
- Name it
Backwork, add a short description, and under Connection enterhttps://backworkhealth.com/mcp. Choose OAuth for authentication. - Select Create. ChatGPT opens Backwork's sign-in page; approve the read-only
backwork:mcp readgrant. - Check the discovered tools, then start a new chat, add Backwork from the tools menu, and ask something like "Is CPT 76942 covered in Texas, and does it need prior auth?"
After a server update, open the connection at chatgpt.com/plugins and select Refresh so ChatGPT picks up new tool and component metadata.
ChatGPT loads a tool's card for every call of that tool. A result with nothing to show, such as a search with no matches or an error, collapses the card to zero height and asks ChatGPT to close it, so no empty card is left in the conversation.
A code that a policy lists only because its title names the drug is labelled Inferred from policy title, in the card and in the text. Confirm it against the document before relying on it.
The cards follow ChatGPT's light or dark theme, load nothing from the network (their CSP allows no domains), and open links through the host. They are MCP Apps resources (text/html;profile=mcp-app), so other MCP Apps hosts can render them too. Clients without UI support ignore the _meta keys that link tools to cards and get the same markdown text as before; structuredContent.widget carries the card's data.
Claude.ai skills
The same four skills work in claude.ai. They need the Backwork connector to call tools.
-
Add the connector: Settings > Connectors > Add custom connector, name it
Backwork, and enterhttps://backworkhealth.com/mcp. Finish the OAuth sign-in. -
Build one zip per skill. The zips go to
dist/claude-skills/, which git ignores:Each zip holds the skill folder at its root, for example
coverage-check.zipcontainscoverage-check/SKILL.md. The build fails if aSKILL.mdbreaks the claude.ai rules (name matches its folder, description 200 characters or fewer). -
Upload each zip: open Customize > Skills (in older versions, Settings > Capabilities > Skills), click Add, and select the zip. Custom skills need a Pro, Max, Team, or Enterprise plan with code execution turned on. Each user uploads their own copy.
Other MCP clients
Clients that run local commands can use the stdio config shown for Claude Desktop. Clients that support remote URLs with OAuth can use https://backworkhealth.com/mcp directly.
For clients that support only remote URLs with static headers, deploy a private self-hosted server in API-key or dual-auth mode (see Self-Hosting) and send the key as a bearer header:
Tool output reference
All tools include title, description, inputSchema, outputSchema, and MCP annotations. Each tool states its own annotations; the server refuses to start if a tool marked read-only offers a write-scope operation, or one marked non-destructive offers a DELETE. Successful calls return readable text plus structuredContent with message, and when available, Backwork API data and meta.
data and meta are projections: they carry only the response fields src/api-operations.ts lists for the operation (reads and metaReads). Request IDs, response timestamps, record timestamps, research-job cost and polling URLs, idempotency keys, and model names are dropped. Policy effective and last-reviewed dates, source fetch times, and source audit sample times are kept. The server logs the request ID of a failed API call.
Tool-level failures return isError: true. Billing and rate-limit failures are reported in plain terms and never repeat the API's hint, plan names, or pricing links: a feature outside the organization's plan, no remaining request credits, or a rate limit with when to retry. test/output-guard.test.mjs runs every tool action against fixture responses and those errors, and fails on upsell wording, trace IDs, timestamps, cost, or model fields.
Sources and currency
When the Backwork API response cites policy documents, structuredContent.provenance carries what an agent needs to cite them, and the text output ends with a short --- Sources --- block:
Values come from the API response. source_check.source_url and source_check.last_fetched_at take precedence over legacy source metadata. An explicit unknown fetch time stays null; legacy retrieved_at, last_verified_at, or crawled_at are fallback values only when the source-check block is absent. Known fetch times remain available in sources[] when another cited source has an unknown time. The shape matches the provenance block on Backwork agent tool results.
Policy evidence also retains the API's source_check: source URL, last fetch time, fetched-content SHA-256, and source_accuracy audit samples. Each audit reports the field measured, sample date and size, share of sampled records that matched, 95% Wilson interval, and method. These samples measure records from a source; they do not measure certainty for the individual policy or a coverage decision. Missing audits stay null. Cards show fetch dates and expandable source sample audits.
Policies with explicit applicability also retain the optional applicability_scope, applicability_markets, applicability_evidence and applicability_note fields. Shared-market documents and indexed singleton documents are listed in the publisher's state indexes; that discovery evidence does not establish the member's plan or product coverage. A document_scoped policy with no state, line of business or indexed markets has unknown applicability. The cards and text show the API's note, and cards provide publisher index links and source-exact quotes with page numbers. Legacy responses without these fields keep their existing shape.
Applicability evidence is limited to a document SHA-256, up to 16 HTTPS publisher index listings and up to 16 statements of the three supported kinds (non_medicare_disclaimer, commercial_policy_header, member_type_branch). Quotes are bounded to 4,000 characters, index URLs to 2,048 characters, and pages must be positive integers. Unknown fields are dropped; malformed evidence becomes null. Market codes and notes are bounded as well. The MCP preserves API confidence and manual-review outputs; index listings do not raise confidence or resolve authorization.
Code matches retain grounding separately from their extraction source:
Text and cards label these checks without treating a grounded code as a coverage guarantee. An older response that omits grounding remains unknown, and an unrecognized future value is preserved and labelled.
Production availability
Which actions a server offers depends on two things:
- Availability. The Backwork OpenAPI document can mark an operation
x-backwork-availability: unavailable-in-production. Against the production API (https://backworkhealth.com) the server withholds those actions. None is marked today: production serves every/api/v1operation these tools call to an organization's live key. - Access. Operations that need
writescope (x-backwork-required-scopes) are withheld from a read-only OAuth grant. On the hosted server this hidesbackwork_webhook_managementand theacknowledgeandbulk_acknowledgeactions ofbackwork_compliance_review. A read-only connection also gets nobackwork_system_healthdiagnostics, noidempotency_keyinput onbackwork_claim_validation, and abackwork_compliance_reviewwith no acknowledgment inputs (diff_id,diff_ids,notes) and no diff IDs in its results. A Backwork API key (stdio, or HTTP with abwk_bearer) is offered every tool and action, and the API enforces the key's own scopes. An OAuth grant counts as read-only unless its scopes includewrite.
A tool with no offered action is hidden. A partly offered tool drops the withheld actions from its action input; actions withheld as unavailable in production are also named in its description. A server pointed at another Backwork deployment with BACKWORK_API_BASE ignores availability markers, and BACKWORK_MCP_EXPOSE_UNAVAILABLE_TOOLS=true does the same against production. Neither lifts the write-scope rule.
Self-hosting
Run a Streamable HTTP server:
Defaults:
HTTP mode requires Authorization: Bearer per request. By default this bearer is a Backwork API key. For hosted remote MCP deployments, enable OAuth protected-resource discovery so Claude-compatible clients can authenticate users through your authorization server:
The server publishes OAuth Protected Resource Metadata at /.well-known/oauth-protected-resource and includes that URL in WWW-Authenticate challenges. If your Backwork API accepts OAuth access tokens directly, no extra mapping is needed; the MCP server forwards the OAuth bearer downstream. If your authorization server exposes a Backwork API key in token introspection, set BACKWORK_MCP_OAUTH_INTROSPECTION_URL and BACKWORK_MCP_OAUTH_API_KEY_CLAIM to validate the access token and map it to the downstream Backwork credential.
For a private single-tenant deployment where the server environment supplies the key, set:
Only use BACKWORK_MCP_ALLOW_ENV_KEY=true on loopback or private-network deployments protected by network access control. Public deployments should require a bearer token per request, set BACKWORK_MCP_ALLOWED_HOSTS/BACKWORK_MCP_PUBLIC_HOST, and set BACKWORK_MCP_ALLOWED_ORIGINS only to exact browser origins that may connect.
Vercel Hosting
This repo can deploy as an API-only Vercel project. The production project uses:
The Vercel functions expose:
The Backwork web app that issues OAuth tokens must also be configured:
Production OAuth discovery fails closed unless BACKWORK_OAUTH_SIGNING_SECRET is at least 32 characters and Redis or Vercel KV is configured for one-time consent and authorization-code storage.
Health check:
Environment variables
Troubleshooting
Missing API key
For stdio, set BACKWORK_API_KEY in the MCP client configuration. For HTTP API-key mode, send Authorization: Bearer <key>. For HTTP OAuth mode, configure BACKWORK_MCP_OAUTH_AUTHORIZATION_SERVERS and send Authorization: Bearer <access_token>.
401 from HTTP MCP
The remote server did not receive a bearer token. Configure your MCP client to authenticate with OAuth or send an Authorization header. OAuth-enabled deployments include resource_metadata in the WWW-Authenticate header to point clients at /.well-known/oauth-protected-resource.
Claude Code OAuth
If Claude Code does not open the browser, run /mcp, select backwork, and choose the authenticate action. If it gives you a URL instead of opening a browser, copy that URL into your browser.
If the browser redirect back to Claude Code fails after consent, copy the full callback URL from the browser address bar and paste it into the Claude Code prompt.
This server does not hold OAuth tokens. It validates each request's access token by introspection and forwards it (or the mapped API key) to the Backwork API. Refreshing an expired access token is the MCP client's job: when introspection reports a token inactive, the server answers 401 with error="invalid_token", and the client can use its refresh token with the Backwork authorization server.
If Claude Code keeps using an old token, open /mcp, select backwork, clear authentication, then authenticate again. You can also remove and re-add the server with:
If discovery returns 503, the Backwork web app is intentionally refusing to advertise OAuth because production signing or Redis/KV state storage is missing.
If tool calls authenticate but fail with invalid_token or invalid_target, check that BACKWORK_MCP_RESOURCE, BACKWORK_MCP_OAUTH_RESOURCE, and BACKWORK_MCP_OAUTH_EXPECTED_AUDIENCE all use:
Rate limits
Wait for the reset window or use a higher-capacity API plan.
Development
Local setup
Useful commands:
Requires Node.js 18.14.1 or newer.
Testing and evaluations
Run the build and MCP metadata smoke test:
The smoke test starts the built stdio server with a dummy key, verifies the 8 workflow tools, checks titles, schemas, annotations, output schemas, response_format, and verifies local validation failures are reported with isError: true. The HTTP smoke also completes authenticated MCP initialization, lists the read-grant tools, and calls a tool with invalid arguments. The test/ suite covers production availability, the hosted server's OAuth-only, read-only tool set, provenance, description quality and a lexical tool-selection check (no model calls), the registry manifest, and the ChatGPT cards: their templates in the tool list, the resources and mime type, each card's structuredContent against its schema, markdown for clients without UI, and a render of each card page in a stub browser for every action of every tool with a card, which must show a card or collapse to zero height.
Before publishing, run npm run verify:package. It installs the packed tarball in a temporary consumer without repository overrides or a lockfile, then runs both transports on the current runtime and Node 18.20.8. CI runs the same check. Additional exact Node versions can be passed after --.
API contract
Every Backwork endpoint this server calls is listed in src/api-operations.ts, with the request fields it sends and the response fields it reads. Tools can only call the API through that catalog. Each entry also mirrors the operation's availability marker and required scope. npm test checks the catalog against the vendored openapi/backwork-openapi.json, and asks the server's own exposure rule which tool actions it would offer on production, for a read-only OAuth grant and for an API key. An action offered for an operation that production does not serve, marks unavailable, or (for the OAuth grant) guards with write scope fails.
CI runs npm run contract:live, which runs the same checks against https://backworkhealth.com/openapi.json and fails when the vendored copy differs from it anywhere except descriptions, summaries and examples.
When the Backwork API changes, refresh the vendored copy and review the diff:
The evals/ directory includes a tool-discoverability evaluation and a read-only data evaluation built from fixed source-backed policy/code records. Refresh the read-only answers intentionally when Backwork source data is updated.
SDK migration follow-up
Release 2.1.4 bundles the v1 SDK 1.32.1, Zod, and their production dependencies from the committed lockfile. This carries the patched Hono Node adapter 1.19.15 into consumer installs and preserves Node 18 support (minimum 18.14.1). npm only honors overrides in the consumer's root package, so an override in this package cannot provide that guarantee. Use npm ci to reproduce the release tree and rerun package verification after updating the lockfile. The official v2 migration guide requires a separate compatibility change:
- Raise the supported Node.js runtime from 18 to at least 20, including the hosted deployment and release workflow.
- Replace monolithic SDK imports with
@modelcontextprotocol/server,@modelcontextprotocol/nodefor Node HTTP transport, and@modelcontextprotocol/clientfor clients and tests; use@modelcontextprotocol/corefor public protocol schemas where needed. - Upgrade the declared Zod range to at least 4.2 and wrap tool input/output schemas as Standard Schema objects, preserving field descriptions and structured-output validation.
- Verify tool discovery, stdio, stateless HTTP lifecycle, OAuth discovery and scopes, widgets, output minimization, and the live OpenAPI contract before publishing that migration.
MCP registry
server.json describes this server for the official MCP registry as io.github.tylergibbs1/backwork-mcp: the hosted Streamable HTTP remote at https://backworkhealth.com/mcp (OAuth, discovered from the protected-resource metadata) and the @backwork/mcp npm package over stdio. package.json carries the matching mcpName that the registry uses to verify npm ownership. npm test validates server.json against the registry schema and checks that its versions match package.json.
Release
Releases publish @backwork/mcp to npm with Trusted Publishing (GitHub OIDC, no npm token) and then publish server.json to the MCP registry.
npm version minor(orpatch/major). Theversionscript copies the new version intoserver.jsonandSERVER_VERSIONinsrc/index.ts.- Merge that change to
main. - Push a matching tag from
main, for examplegit tag v2.1.0 && git push origin v2.1.0.
The Release workflow then:
- Fails unless the tag equals
v+ thepackage.jsonversion. - Runs
npm ci,npm test(build, smoke tests, unit tests, OpenAPI contract),npm run verify:package(clean consumer and Node 18 transports), andnpm pack --dry-run. - Publishes to npm with provenance, in the
npmenvironment. A version already on npm is skipped, so a failed run can be re-run. - Waits for the version to appear on npm, then runs
mcp-publisher login github-oidcandmcp-publisher publish.
One-time npm setup: on npmjs.com, open @backwork/mcp > Settings > Trusted publishing, choose GitHub Actions, and enter user tylergibbs1, repository backwork-mcp, workflow release.yml, environment npm.
Support
- Documentation: https://backworkhealth.com/docs
- Issues: https://github.com/tylergibbs1/backwork-mcp/issues
- Email: [email protected]
License
MIT. See LICENSE.
Source: README.md at commit 994f0d1
Tools
0Version history
5- v2.1.6LatestOct 11, 2026
- v2.1.5Oct 10, 2026
- v2.1.4Oct 9, 2026
- v2.1.2Oct 1, 2026
- v2.1.1Oct 1, 2026
Score
85% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
- Reached in the last 30 daysRequired25 pts
- Auth declaredRequired10 pts
- Tools listed15 pts
Answer tools/list without a credential, or ship a package that starts in a sandbox without one.
- DescriptionRequired15 pts
- Logo10 pts
- Documentation15 pts
- License10 pts