DEV Community

Cover image for How to give Claude a US healthcare-provider verification tool with the Apify MCP server
Michael
Michael

Posted on • Originally published at scrapers.lat

How to give Claude a US healthcare-provider verification tool with the Apify MCP server

#ai #mcp #apify #healthcare

AI agents are good at reasoning and terrible at facts. Ask Claude whether "Mayo Clinic" holds an active NPI, what entity type it is, and which taxonomy it bills under, and it will give you a confident answer from its training data that may be months or years stale, or simply wrong. For anything that touches a claims system or a payer contract, "probably correct" is not good enough.

In this guide we fix that. We connect Claude to the official Apify MCP server, expose a single Actor that reads the NPPES NPI Registry (the national directory of every US healthcare provider), and turn "is this NPI real, active, and the right type?" from a guess into a live lookup against the source of record. By the end you will have a working provider-verification tool that Claude, Cursor, or any MCP client can call during a conversation, and you will understand exactly where in the run the tool fires and what it returns.

Everything below is a real setup with real output. No mocked responses.

What is the Apify MCP server?

Model Context Protocol (MCP) is an open standard that lets AI clients call external tools. The Apify MCP server (https://mcp.apify.com) implements that standard on top of the Apify platform, which means every one of the thousands of Actors in the Apify Store becomes a tool an agent can invoke.

Why route an Actor through MCP instead of hard-coding an API call?

  • The agent decides when to fetch. Claude reads the conversation, notices it needs a fact it does not have, and calls the tool on its own. You do not write glue code for every question.
  • Structured input and output. The MCP server hands Claude the Actor's input schema, so the model fills in the parameters correctly, and returns a clean dataset it can reason over.
  • One connection, many tools. The same MCP endpoint exposes search-actors, fetch-actor-details, and call-actor, so an agent can discover and run any Actor without new configuration.
  • No infrastructure. The server is hosted. You add a few lines to a config file and you are done.

The Actor we will use

We will expose the NPPES NPI Healthcare Provider Data Scraper. It searches the national NPI registry and returns the full provider record: the 10-digit NPI, enumeration type (individual clinician vs. organization), active/deactivated status, legal name, primary taxonomy code and description, practice address and phone, the authorized official for an organization, and the enumeration and last-updated dates.

That field set is exactly what a payer network team, a credentialing analyst, or a revenue-cycle group needs to validate a provider before a claim ever moves. The registry is public, authoritative, and has no login wall.

The tool searches three ways:

  • by organization name plus state (what we use below for Mayo Clinic),
  • by an individual clinician's first and last name plus state and taxonomy, for example a taxonomyDescription of "Dentist", and
  • by one or more exact NPI numbers, when you already have the ID and just need to confirm status and taxonomy.

The NPPES NPI Healthcare Provider Data Scraper on the Apify Store

Step 1: Get your Apify API token

Sign in to the Apify Console, open Settings → Integrations, and copy your personal API token. The MCP server uses it to authenticate and to bill Actor runs to your account.

📌 Note: the token is a secret. Keep it in the client config only, never in a prompt or a committed file.

Step 2: Point Claude Desktop at the Apify MCP server

Open Claude Desktop's config file (Settings → Developer → Edit Config, or ~/Library/Application Support/Claude/claude_desktop_config.json on macOS) and add the Apify server. The tools query parameter is the important part: it tells the server which Actor to expose, so Claude gets one focused tool instead of the entire Store.

{
  "mcpServers": {
    "apify": {
      "url": "https://mcp.apify.com?tools=scrapers_lat/nppes-npi-scraper",
      "headers": {
        "Authorization": "Bearer YOUR_APIFY_TOKEN"
      }
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

Cursor uses the same JSON in .cursor/mcp.json. If you prefer to run it locally over stdio instead of the hosted endpoint:

{
  "mcpServers": {
    "apify": {
      "command": "npx",
      "args": ["-y", "@apify/actors-mcp-server", "--tools", "scrapers_lat/nppes-npi-scraper"],
      "env": { "APIFY_TOKEN": "YOUR_APIFY_TOKEN" }
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

Restart Claude Desktop so it picks up the new server.

Step 3: Confirm the tool is loaded

After the restart, the Actor shows up as a callable tool. If you list the tools the Apify server exposes, you will see the storage helpers plus the Actor itself, named after its Store handle:

get-actor-run, get-dataset-items, get-key-value-store-record,
abort-actor-run, scrapers_lat--nppes-npi-scraper
Enter fullscreen mode Exit fullscreen mode

That last entry, scrapers_lat--nppes-npi-scraper, is our provider-verification tool. Claude now knows it exists, what it does (from the Actor's README), and what inputs it takes (from the input schema the server passes along).

Step 4: Ask Claude to verify a provider

Now the payoff. In a normal chat, ask a question that requires ground truth:

"Look up Mayo Clinic in Minnesota in the NPI registry. What is its NPI, is it active, what entity type is it, and what taxonomy does it bill under?"

Claude recognizes it cannot answer this reliably from memory, selects the NPPES tool, and fills in the input from your question. Under the hood the client sends a tools/call with the Actor's parameters:

{
  "name": "scrapers_lat--nppes-npi-scraper",
  "arguments": {
    "organizationName": "Mayo Clinic",
    "state": "MN"
  }
}
Enter fullscreen mode Exit fullscreen mode

The Apify MCP server starts the Actor, waits for it to finish, and returns the dataset. Here is the real run metadata it produced:

{
  "runId": "Qpuzebqtd3q20FYHJ",
  "actorName": "scrapers_lat/nppes-npi-scraper",
  "status": "SUCCEEDED"
}
Enter fullscreen mode Exit fullscreen mode

A live lookup against the national registry, resolved inside the chat.

Step 5: Read the real output

The dataset the tool returns is structured registry data. This is an actual record from the run (trimmed to the fields that matter for verification):

{
  "npi": "1881018208",
  "enumerationType": "NPI-2 (Type 2 Organization)",
  "status": "Active",
  "organizationName": "MAYO CLINIC",
  "primaryTaxonomyCode": "261QM1300X",
  "primaryTaxonomyDesc": "Clinic/Center, Multi-Specialty",
  "practiceAddress": "200 1ST ST SW, ROCHESTER, MN",
  "practicePhone": "507-284-2511",
  "authorizedOfficial": { "name": "DENNIS DAHLEN", "title": "Chief Financial Officer" },
  "enumerationDate": "2014-02-05",
  "lastUpdated": "2021-04-12"
}
Enter fullscreen mode Exit fullscreen mode

Claude reads that and answers in plain language: yes, NPI 1881018208 is Active, it is an NPI-2 (Type 2 Organization) for MAYO CLINIC, it bills under taxonomy 261QM1300X (Clinic/Center, Multi-Specialty), its practice location is 200 1st St SW, Rochester, MN, and its authorized official is Dennis Dahlen, Chief Financial Officer. The record was enumerated on 2014-02-05 and last updated on 2021-04-12. Every one of those facts is traceable to the official registry, not the model's memory.

Claude verifying a provider's NPI against the NPPES registry

The distinction between a Type 1 individual and a Type 2 organization matters here. A claim that lists an organizational NPI where an individual rendering provider is required, or bills a taxonomy the provider is not enumerated for, is a downstream rejection waiting to happen. The tool surfaces the exact entity type and taxonomy; the model alone would not.

A real use case: a payer network-validation agent

Put this in context. A payer's provider-network team receives a roster of providers to load into the claims system. Before that roster goes live, every row has to be confirmed:

  1. the NPI exists and is Active, not deactivated,
  2. the entity type is the one the contract expects (individual vs. organization), and
  3. the primary taxonomy matches what the provider claims to practice.

Get any of those wrong and the claims system rejects encounters after the fact, which means rework, appeals, and delayed payment. Without a tool, an analyst opens the NPPES website, types each name, clicks into the record, and copies fields into a spreadsheet, once per provider. With the tool wired into Claude, the analyst pastes the roster into the chat and asks the agent to verify each one. Claude calls the Actor per provider, confirms the status is Active, checks the enumerationType against the expected entity type, compares primaryTaxonomyCode against the taxonomy the provider claims, and flags any NPI that is deactivated or mismatched, right there in the conversation, with the registry record as evidence.

The mechanical lookup step disappears; the credentialing judgment stays with the human. That is the shape of every good agent tool: it removes the fetch, not the decision.

Going further: chain a second tool

Provider verification rarely stops at the NPI. Many organizations you validate are also legal business entities, and for a US payer that often means confirming the corporation behind the practice. The same MCP connection can expose more Actors by extending the tools parameter:

https://mcp.apify.com?tools=scrapers_lat/nppes-npi-scraper,scrapers_lat/sunbiz-florida-scraper
Enter fullscreen mode Exit fullscreen mode

Now, for a Florida-based provider organization, the agent can confirm the NPI in NPPES and verify the underlying business entity, its status, and its officers against the Florida Division of Corporations registry, in the same conversation, then combine both results into one summary. Because each Actor is a separate tool, the agent picks the right one for each step on its own.

🏹 Troubleshooting: if the tool does not appear in Claude, the two usual causes are a missing or misspelled Actor handle in the tools parameter (it must be the exact username/actor-name from the Store URL) and a config that was edited while Claude was running. Fix the handle, save, and fully restart the client.

📌 Note: each tool call is a real Actor run billed to your Apify account (this Actor is pay-per-result). For one-off verification the cost is a fraction of a cent; if you plan to validate a full roster of thousands on a schedule, run the Actor directly through the Apify API or a scheduled task instead of one call per chat message.

Wrapping up

You now have an AI agent that can verify a US healthcare provider against the national NPI registry, on demand, mid-conversation, with the status, entity type, and taxonomy detail a network or credentialing check actually needs. The pattern is reusable: pick an Actor that returns authoritative structured data, expose it through the Apify MCP server with the tools parameter, and let the agent decide when to call it.

To take it further:

  • Verify individual clinicians by name, state, and taxonomy, or confirm a batch of exact NPIs, by changing the input the agent sends. The setup is identical.
  • Add business-registry, sanctions, or licensing Actors to build a multi-step provider-integrity agent.
  • Read the Apify MCP server docs for OAuth setup, resource reads, and the search-actors / call-actor tools that let an agent discover Actors it was not preconfigured with.

The Actor used in this guide: NPPES NPI Healthcare Provider Data Scraper.

Top comments (0)