Introducing OIG Exclusion Search, with a Free API and MCP Server

Checking one name against federal and state exclusion lists means visiting the HHS OIG site, then SAM.gov, then the Medicaid program of every state the person might have worked in. Each state publishes in its own format on its own schedule, and some publish nothing at all. Repeat that for every clinician, vendor and subcontractor on a roster, every month, and you have the screening work that 42 CFR 455.436 requires of state Medicaid agencies.

Today we are launching OIG exclusion search, which runs that check as one query. It is free and needs no account. Everything the site does is also available as a public API and as an MCP server, so a script or an AI assistant can screen a list of names directly.

What it searches

The search tracks 53 lists: two federal lists, all 50 states and DC.

• The HHS OIG List of Excluded Individuals/Entities (LEIE), which OIG updates by the 10th of each month.
• SAM.gov, which carries every federal agency's debarments, not only health care ones.
• The 50 state Medicaid programs and DC.

Most states publish their own list, each in its own format and on its own schedule. Eight states publish no list of their own, so their providers appear only on the federal lists, which are searched. The current status of every source is at /api/coverage.

We update every list once a week, on Monday.

One search instead of fifty

The larger your footprint, the harder this gets. A clinic in one state checks the two federal lists and one state list. A health plan, staffing firm or vendor working in twenty states checks twenty-two sites, every month, each with its own format and schedule.

Some of those sites are not even open when you need them. Maine's list goes offline every night from about 8pm to 5am Eastern, and from Friday evening to Monday morning, so anyone checking after hours finds what looks like a dead site.

OIG exclusion search puts every list in one place, so you check once instead of fifty times.

What a result means

The government bulk files contain no Social Security Numbers, so a name match cannot prove that a record is the person you are checking. Every response, on every surface, carries this caveat in full:

These are potential name matches, not confirmed identities. Federal and state bulk files contain no Social Security Numbers, so a name match cannot establish that this is the same person. Confirm any match against the official source listed, and verify identity with HHS OIG at https://exclusions.oig.hhs.gov before acting.

An empty result is not a clearance either. It means no match in the lists we cover, and the coverage endpoint says exactly which those are.

Each result carries a status:

• currently_excluded: listed now and not reinstated.
• reinstated: was excluded and has since been reinstated.
• removed_from_list: no longer in the source file, most often because the party was reinstated.

It also carries a programScope. Read it before describing a result, because about a quarter of the corpus is not a health care action. SAM.gov publishes every federal agency's debarments, including 41,712 OFAC sanctions.

• health_care: an exclusion from a health care program.
• government_wide: a federal contracting debarment or sanction. It is not an exclusion from Medicare or Medicaid.
• unclassified: SAM.gov named no excluding agency, so neither reading can be asserted.

Pass health_care_only=true to drop the non-health-care records. matchScore is name similarity from 0 to 1, not a probability that the record is the same person. Where a record carries an NPI, searching by NPI is the only way to tell two people with the same name apart.

Results show city and state but never a street address. The address is ingested because it helps tell records apart, but no screening question needs someone's front door, so it is left off every response.

The API

The API lives at https://oig.tryharper.app/api. There is no key and no account. Add .json to an endpoint for JSON or .txt for compact plain text; without either, endpoints return JSON. A plain-text guide written for both people and models is at /api, the OpenAPI 3.1 spec is at /openapi.json, and /llms.txt points assistants at both.

GET /api/search?name=<name> searches by name. You can also pass npi=<10 digits> instead of a name, or alongside it. Optional parameters:

• state: a two-letter jurisdiction code, or US for the federal lists
• type: individual or entity
• include_inactive=true to include reinstated and removed records
• health_care_only=true to drop federal debarments and sanctions
• location_state: where the party is located, as distinct from which list names them
• excluded_from and excluded_to: an exclusion date range, YYYY-MM-DD
• require_npi=true to return only records that carry an NPI
• limit: 1 to 200

The JSON response puts caveat first, then jurisdictionsSearched, totalJurisdictions, statesCovered, statesWithOwnList, resultCount, truncated, matchedRecords, currentlyExcludedCount, results, coverageUrl and verifyIdentityUrl. Check truncated before treating a list as complete.

Each result includes id, sourceId, jurisdiction, jurisdictionCode, entityType, name, npi, upin, specialty, city, state, exclusionType, exclusionDate, reinstatementDate, waiverDate, scheduledEndDate, firstSeenAt, currentlyExcluded, status, programScope, matchScore and identityId.

The other endpoints:

• GET /api/exclusion/<id>: one record, with its source and reinstatement status.
• GET /api/coverage: every jurisdiction, marked ingested, broken, not yet ingested, or publishing no list, with the reason.
• GET /api/sources/<id>: one jurisdiction's source detail.
• GET /api/recent: records added to the corpus recently, with optional days (1 to 365), state and limit. firstSeenAt is our ingest date, not the government's exclusion date, which is exclusionDate.
• POST /api/subscribe: email updates, with kind set to feed_digest, coverage_alerts or product_interest. A filter can name a jurisdiction but never a person, so the service offers no way to monitor an individual.

A quick check from the command line:

curl "https://oig.tryharper.app/api/search.txt?name=john+smith&health_care_only=true"

Rate limits

The API and the MCP server share a limit of 240 requests per minute per IP address. Every response carries X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset, and a refused request returns HTTP 429 with Retry-After. A hosted assistant such as ChatGPT or Claude on the web calls the server from its provider's network, so its users share one allowance. A local client such as Claude Code, Codex or Cursor gets its own. If you need a higher limit or a bulk export, email prathik@tryharper.app with a rough description of what you are building.

The MCP server

The MCP server is at https://oig.tryharper.app/mcp. It speaks JSON-RPC 2.0 over streamable HTTP, protocol version 2025-06-18, with no authentication. It calls the same query functions as the API, so the two cannot disagree about what a match means. It has four tools:

• search_exclusions: search by name or npi, with optional state, type, include_inactive and health_care_only. Returns potential matches with their source, status and programScope.
• check_name_across_jurisdictions: given a name and optionally an npi, summarizes which jurisdictions list that name and how many listings are current versus reinstated.
• get_exclusion: one record by id, including its source, publication date, reinstatement status and programScope.
• list_coverage: every jurisdiction and whether its list is ingested. An assistant should call it before telling anyone a name is clear.

Every tool description and every response repeats the caveat about name matches. That is deliberate: a model relaying results should not be able to present a potential match as a confirmed finding.

To add it to Claude Code:

claude mcp add --transport http harper-oig https://oig.tryharper.app/mcp

To add it to Codex:

codex mcp add harper-oig --url https://oig.tryharper.app/mcp

For clients configured with JSON, such as Claude Desktop, Cursor or VS Code:

{
  "mcpServers": {
    "harper-oig": {
      "type": "http",
      "url": "https://oig.tryharper.app/mcp"
    }
  }
}

The connect page has a setup prompt you can paste into any assistant, which then configures its own client, and a first prompt for screening a short list of names.

Why Harper built it

A vendor agreement can require the vendor to screen its staff against these lists every month. Unless someone checks, the plan or health system is taking that on trust. Harper exists to track and verify obligations like that one, and this search is the piece of it anyone can use for free. You can read more about how Harper approaches obligation tracking.

Try it at oig.tryharper.app. If a source looks wrong or out of date, email founders@tryharper.app.