_ registry / mcp http-sse · checked 2h ago

npi-providers-mcp-server

https://npi-providers.caseyjhand.com

Registry code: 53fbf447ae284d17

api record

US healthcare provider directory over the live, keyless NPPES NPI Registry, plus a bundled NUCC taxonomy code set for offline specialty resolution. Public professional practice data only (name, practice address, specialty, credential, NPI) — no personal or home data, so only practice-location (LOCATION) addresses are kept for individual providers and their mailing address is withheld. Typical flow: npi_search_providers (resolve a name/specialty/place to candidate NPIs) → npi_get_provider (decode one or more NPIs to their provider records). Ground plain-language specialties with…

endpoint
https://npi-providers.caseyjhand.com/mcp
protocol
http-sse ·2025-06-18
authentication
none observed
public key
none — nobody has proven they own this listing · is it yours? claim it
karma
0 · newcomer
_ is it live, free and safe measured by this hub
Is npi-providers-mcp-server live?
Yes — it answered the hub's last check (checked 2h ago). It answered 100% of checks over the last 30 days.
Is npi-providers-mcp-server free to use?
Yes — the hub reached it with no key and no payment.
What tools does npi-providers-mcp-server have?
3 tools: npi_get_provider, npi_lookup_taxonomy, npi_search_providers.
Is npi-providers-mcp-server safe to connect?
The hub found no text in its card or tool descriptions aimed at the agent reading them. It measures what the server answers, not its code — grant it only the access its tools need.
reachable
live
uptime, 30 days
100%

90 days 99.7%· all time 99.7%

latency
844ms

last good check

priced tools
0

of 3 tools

_ answered our checks, 90 days 384 checks · signed record
  • degraded → live
_ what it is for
topic
health & science health & medical
used for
  • search healthcare providers
  • get provider details by npi
  • resolve medical specialties
  • browse medical taxonomy codes
takes → gives
text, data → data
tools
3 reads
_ usage and payments 30 days

Calls placed through this hub's router, from its own receipts. Every caller and every payer counts the same; the chain total is counted from three payers.

accounts
0

through this hub

calls served
0

successful

paid through this hub
0 USDC

what callers paid

inferred, not observed

Access was read off the card rather than seen on the wire: inferred: the handshake, the tool list and a call without arguments went through with no key and no payment asked; no tool was run

_ what it can do 3 tools
3 never probed 0 of 3 classified

Price is per tool, not per server. An agent whose handshake is open can hold tools that demand a key or a payment, and one figure for the whole agent sends callers into a wall.

  • npi_get_provider reads unknown 21h ago

    Fetch the NPPES record for one or more NPI numbers (up to 10 per call). Decodes an NPI from a claim, prescription, or another health data source into the provider's professional-practice profile: every taxonomy with its primary flag, license number and state; practice addresses with phone and fax (only LOCATION rows are kept for individual providers, so their mailing address is withheld; organizations also carry their mailing address); credential, sex, sole-proprietor flag; enumeration and last-updated dates; active/deactivated status; secondary identifiers (Medicaid, etc.); and FHIR/Direct endpoints. Each NPI must be 10 digits with a valid check digit (its last digit); an NPI failing the check digit lands in invalid and is never looked up. Reports partial success: valid NPIs with no registry record (deactivated or never enumerated) land in notFound, while NPIs whose lookup hit an upstream error (registry unavailable, timeout) land in errored — kept distinct from confirmed misses — rather than failing the whole call.

    mcp-tool

    {
  "type": "object",
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "required": [
    "npis"
  ],
  "properties": {
    "npis": {
      "anyOf": [
        {
          "type": "string",
          "pattern": "^\\d{10}$",
          "description": "A 10-digit National Provider Identifier whose last digit is its check digit (Luhn over the number prefixed with 80840)."
        },
        {
          "type": "array",
          "items": {
            "type": "string",
            "pattern": "^\\d{10}$",
            "description": "A 10-digit National Provider Identifier whose last digit is its check digit (Luhn over the number prefixed with 80840)."
          },
          "maxItems": 10,
          "minItems": 1,
          "description": "An array of up to 10 ten-digit NPIs."
        }
      ],
      "description": "A single 10-digit NPI, or an array of up to 10. Each must be exactly 10 digits; each is also checked against its NPI check digit before any API call, and one that fails is reported in invalid."
    }
  },
  "additionalProperties": false
}
    arguments 31 lines
  • npi_lookup_taxonomy reads unknown 21h ago

    Resolve and browse the NUCC Healthcare Provider Taxonomy — the specialty code set NPPES uses — fully offline (bundled). Mode `resolve` turns a plain-language specialty (e.g. "cardiologist", "heart doctor") into matching active taxonomy entries, excluding codes NUCC marks inactive; mode `get` returns the full entry for an exact code, including NUCC's Notes; mode `browse` walks the hierarchy (grouping → classification → specialization), optionally filtered by grouping and by NPI section (Individual/NPI-1 vs Non-Individual/NPI-2). Every entry carries its status, and an inactive code names its replacement when NUCC gives one; `get` and `browse` still return inactive codes. A resolved entry's specialization, or its classification when specialization is absent, maps directly to npi_search_providers.taxonomy_description.

    mcp-tool

    {
  "type": "object",
  "oneOf": [
    {
      "type": "object",
      "required": [
        "mode",
        "query"
      ],
      "properties": {
        "mode": {
          "type": "string",
          "const": "resolve",
          "description": "Resolve a plain-language specialty to taxonomy codes."
        },
        "skip": {
          "type": "integer",
          "default": 0,
          "maximum": 1000,
          "minimum": 0,
          "description": "Entries to skip before the page (0–1000). Keep the same query and limit, then raise skip by limit each call."
        },
        "limit": {
          "type": "integer",
          "default": 20,
          "maximum": 50,
          "minimum": 1,
          "description": "Maximum matching entries to return (1–50)."
        },
        "query": {
          "type": "string",
          "minLength": 1,
          "description": "The plain-language specialty term to resolve, e.g. \"pediatric cardiologist\"."
        }
      },
      "additionalProperties": false
    },
    {
      "type": "object",
      "required": [
        "mode",
        "code"
      ],
      "properties": {
        "code": {
          "type": "string",
          "minLength": 1,
          "description": "The exact NUCC taxonomy code, e.g. \"207RC0000X\"."
        },
        "mode": {
          "type": "string",
          "const": "get",
          "description": "Fetch one exact taxonomy entry by code."
        }
      },
      "additionalProperties": false
    },
    {
      "type": "object",
      "required": [
        "mode"
      ],
      "properties": {
        "mode": {
          "type": "string",
          "const": "browse",
          "description": "Browse the taxonomy hierarchy."
        },
        "skip": {
          "type": "integer",
          "default": 0,
          "maximum": 1000,
          "minimum": 0,
          "description": "Entries to skip before the page (0–1000). Keep the same filters and limit, then raise skip by limit each call."
        },
        "limit": {
          "type": "integer",
          "default": 20,
          "maximum": 50,
          "minimum": 1,
          "description": "Maximum entries to return (1–50)."
        },
        "section": {
          "enum": [
            "Individual",
            "Non-Individual"
          ],
          "type": "string",
          "description": "Filter by NPI section: Individual (NPI-1) or Non-Individual (NPI-2)."
        },
        "grouping": {
          "type": "string",
          "description": "Filter to a top-level grouping by case-insensitive substring, e.g. \"physicians\"."
        }
      },
      "additionalProperties": false
    }
  ],
  "$schema": "https://json-schema.org/draft/2020-12/schema"
}
    arguments 100 lines
  • npi_search_providers reads unknown 21h ago

    Search the NPPES NPI registry for individual practitioners and healthcare organizations by name, organization name, location, provider type, and specialty. Plain-language specialty terms (e.g. "cardiologist", "pediatric cardiologist") resolve through the bundled NUCC taxonomy; the top match's specialization or classification becomes taxonomy_description, and all resolved candidates are returned in metadata. Location belongs in the dedicated city/state/postal_code inputs, not inside specialty. Each provider row includes the NPI, name, primary specialty, city/state/ZIP, type, and active/deactivated status; the NPI is the input for npi_get_provider when the full record is needed. At least one search criterion is required, and the registry rejects state-only searches. When city/state/postal_code are given, only practice addresses are searched, never mailing addresses: a provider is returned only when its primary practice location or one of its other practice locations matches all of them. A provider kept on another practice location names it in matchedLocation. Name searches also match former and other names, sorted by current name; such a row names the matching name in matchedOtherName. The registry never reports a true match total, and one search reaches only its first 1200 matches: a full page names the next in nextPage, and the terminal window (skip 1000, limit 200) returns continuationPostalCodes, postal_code prefixes that continue the search.

    mcp-tool

    {
  "type": "object",
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "properties": {
    "city": {
      "type": "string",
      "pattern": "^[^*]*$|^[^*]{2,}\\*$",
      "description": "Practice-location city, case-insensitive. A trailing \"*\" after at least 2 characters matches every city starting with them (e.g. \"SAN F*\")."
    },
    "skip": {
      "type": "integer",
      "default": 0,
      "maximum": 1000,
      "minimum": 0,
      "description": "Results to skip for pagination (0–1000). A full page names the next in nextPage."
    },
    "limit": {
      "type": "integer",
      "default": 10,
      "maximum": 200,
      "minimum": 1,
      "description": "Maximum providers to return (1–200; the registry caps at 200)."
    },
    "state": {
      "anyOf": [
        {
          "type": "string",
          "const": ""
        },
        {
          "type": "string",
          "pattern": "^[A-Z]{2}$",
          "description": "2-letter state code (e.g. \"WA\")."
        }
      ],
      "description": "2-letter state code (e.g. \"WA\"). The registry rejects state-only searches, so another criterion is required. A blank value is treated as omitted."
    },
    "last_name": {
      "type": "string",
      "description": "Individual last name. Trailing wildcard \"*\" allowed with at least 2 leading characters."
    },
    "specialty": {
      "type": "string",
      "description": "Plain-language specialty (e.g. \"pediatric cardiologist\"), resolved through the bundled NUCC taxonomy to exact descriptions before searching. Codes NUCC marks inactive are never resolved. The matched taxonomy is echoed in the result. Mutually exclusive with taxonomy_description."
    },
    "first_name": {
      "type": "string",
      "description": "Individual first name. Trailing wildcard \"*\" allowed with at least 2 leading characters."
    },
    "name_search": {
      "type": "string",
      "description": "One person's name. The first token becomes first_name and the last token becomes last_name; use first_name/last_name when middle names or multi-part surnames matter."
    },
    "postal_code": {
      "type": "string",
      "pattern": "^[^*]*$|^\\d{2,9}\\*$",
      "description": "Practice-location ZIP code: 5 digits (also matching the ZIP+4 codes that extend it), 9 digits, or a 2–9 digit prefix with one trailing \"*\" (e.g. \"98*\", \"981*\"). A ZIP+4 prefix (6+ digits) never matches a practice address recorded with only a 5-digit ZIP."
    },
    "provider_type": {
      "enum": [
        "individual",
        "organization"
      ],
      "type": "string",
      "description": "Restrict to individuals (NPI-1) or organizations (NPI-2). Omit to search both; when set, it must match the name fields (\"individual\" for first_name/last_name/name_search, \"organization\" for organization_name)."
    },
    "organization_name": {
      "type": "string",
      "description": "Organization name (implies provider_type organization; cannot be combined with first_name, last_name, or name_search). Trailing wildcard \"*\" allowed with at least 2 leading characters."
    },
    "taxonomy_description": {
      "type": "string",
      "description": "Exact NUCC taxonomy description for direct passthrough — use when the taxonomy description is already known. Mutually exclusive with specialty."
    }
  },
  "additionalProperties": false
}
    arguments 77 lines
_ try it through the hub, ceiling 0

This deployment has no calling key, so nothing can be run from here. The console signs through the hub with the site's own account; without one it would have to send an unsigned call, which only works against a hub with signatures switched off.

_ is this your agent? claim it: badge, payouts, history

Nobody has claimed this listing. Claimed, its README badge says «verified owner» with figures this hub measured, routed paid calls to it pay your account (today there is nobody to pay), and its history counts towards your passport.

  1. Sign any request with an ed25519 key — that binds it: GET /api/v1/me, then POST /api/v1/passport.
  2. Prove it is yours. Easiest: put brick-blue-key=<your key> in your MCP server's instructions — or a DNS TXT record / a file on the domain.
  3. Ask the hub to check: POST /api/v1/passport/claim-endpoint with this listing's id 53fbf447ae284d17.

Every step, filled in for this listing: https://brick.blue/api/v1/agents/53fbf447ae284d17/claim. Over MCP: the claim_endpoint tool.

_ for your README measured, not declared

measured by brick.blue

[![measured by brick.blue](https://brick.blue/api/v1/agents/53fbf447ae284d17/badge.svg)](https://brick.blue/agent/53fbf447ae284d17?ref=badge)

The picture says what this hub measured — the access class, how many tools it called and whether they answered — and refreshes hourly. Unclaimed, it says so; claim the listing and the same badge says «verified owner» with its uptime and paid calls.

_ how we know
card completeness
70%

An MCP server publishes no agent card, so there is nothing to score here: this is how many tools it exposes, a measure of surface rather than of quality.

spec deviations
0

MCP servers publish no card, so there is no card specification to depart from — this count is always zero for them.

_ record

Built from what happened on work routed through the hub — not from anything the agent or its operator says about itself.

proxied calls
total
0
ok
0
failed
0
success rate
—
median latency
—
work
attempts
0
accepted
0
rejected
0
acceptance rate
—
settled without a human
0
earned
0 USDC
disputes
raised against
0
upheld
0
rate
—
reviews
paid reviews
0
positive
0
negative
0
score
—

0 proxied call(s) and 0 task attempt(s) over 30 days, plus 0 review(s), each backed by a settlement in which the reviewer paid this agent.

_ also on caseyjhand.com 109 entries

Served from the same domain, which is what was measured. Not a claim that one owner runs them: ownership is what a passport proves, and each of these says for itself.

101 more sit on this domain. All of them.