npi-providers-mcp-server
Server Details
Search NPPES providers and resolve NUCC specialty codes via MCP over STDIO or Streamable HTTP.
- Status
- Healthy
- Uptime
- 99.9% over 40 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- Repository
- cyanheads/npi-providers-mcp-server
- GitHub Stars
- 1
- Server Listing
- npi-providers-mcp-server
TDQS
Scored across 3 tools
Each tool has a clearly distinct purpose: fetching a provider record by NPI, resolving/browsing taxonomy codes, and searching providers. There is no functional overlap between them.
All tool names follow the same npi_<verb>_<noun> pattern with consistent verb choices (get, lookup, search). The naming is predictable and easy to navigate.
Three tools is slightly lean but appropriate for a focused NPI provider data server. Each tool covers a distinct core operation and there are no redundant or filler tools.
The domain is well covered: get provider by NPI, search providers, and explore the taxonomy used in searches. Minor gaps exist, such as no direct search by raw taxonomy code, but the existing tools form a complete workflow for typical NPI lookups.
Available Tools
3 toolsnpi_get_providerNpi Get ProviderARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| npis | Yes | 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. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| found | No | Decoded records for NPIs that resolved. |
| notice | No | Guidance when some NPIs failed the check digit, returned no record, or hit an upstream error. |
| errored | No | NPIs whose lookups failed with an upstream/transport error (service unavailable, timeout) — distinct from a confirmed miss in notFound. These are unresolved, not absent; retry them. |
| invalid | No | NPIs that failed the NPI check digit — not valid NPIs, usually a typo. They were never looked up, so they are neither confirmed misses nor upstream failures. |
| notFound | No | NPIs with a valid check digit that returned no record (deactivated or never enumerated). A confirmed absence, not a failure. |
| totalCount | No | Number of provider records that resolved from the requested NPIs. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral detail beyond the readOnlyHint, openWorldHint, and idempotentHint annotations: check-digit validation before any registry call, invalid NPIs never being looked up, partial-success reporting with invalid/notFound/errored buckets, and the distinction between confirmed misses and upstream errors. It also reveals the subtle rule that individual providers' mailing addresses are withheld while organizations' are kept. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description front-loads the core purpose and then flows through input constraints, address-handling nuances, and failure categories. It is longer than strictly necessary, and the detailed field enumeration partially overlaps with the available output schema, but nearly every clause carries behavioral or scoping information that an agent needs. It is structured and dense rather than rambling.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the annotations, full input schema coverage, and presence of an output schema, the description covers everything needed for correct invocation: the exact input shape, validation semantics, partial-success buckets, and a key data-shaping nuance (LOCATION-only addresses for individuals). No critical selection or invocation information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers 100% of the single parameter, including the 10-digit pattern, check digit rule, and maxItems=10. The description adds behavioral meaning beyond that by specifying that an NPI failing the check digit lands in 'invalid' and is never sent to the registry, and by restating the up-to-10 limit. This exceeds the baseline 3 justified by complete schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Fetch the NPPES record for one or more NPI numbers') and clarifies the batch limit and the use case of decoding an NPI from claims or prescriptions. Although it never names the sibling tools, the operation is clearly distinct from taxonomy lookup and provider search because it is keyed by exact NPI numbers and returns the full NPPES profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: whenever an NPI is already known from a claim, prescription, or other health data source. It does not explicitly name sibling alternatives or state when not to use them, so it falls short of a 5, but the intended usage scenario is unmistakable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
npi_lookup_taxonomyNpi Lookup TaxonomyARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The limit that was applied. |
| error | No | Present when the call failed. Absent on success. |
| shown | No | Number of entries returned. |
| notice | No | Guidance — how to page a truncated result with skip, or how to broaden when nothing matched. |
| matches | No | Matching taxonomy entries. For mode "get" this is the single requested entry; for "resolve"/"browse" it is the ranked/sorted matches up to limit. |
| truncated | No | True when the list was capped at `limit` (more entries may match). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false; the description adds significant context beyond these. It discloses that the tool works offline (bundled), that it excludes inactive codes in `resolve` but includes them in `get`/`browse`, and that inactive entries may name replacements. It also explains the status field and the linkage to NPI sections, providing richer behavioral details than annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is comprehensive yet tightly written, covering all modes, behaviors, and usage guidance in a single paragraph. It front-loads the core purpose and mode descriptions, then adds details in a logical order. Every clause earns its place, providing high information density without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple modes, hierarchical data, relations to NPI sections) and the presence of an output schema, the description is exceptionally complete. It explains mode-specific behaviors, edge cases (inactive codes, replacements), and how to map results to sibling tools. The output schema likely covers return fields, so the description does not need to restate them, allowing the description to focus on decision-making and behavioral nuances.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. However, the description adds critical meaning: it explains the purpose of each mode's parameters (e.g., mode-specific query vs code vs grouping/section), clarifies the `section` parameter's relationship to NPI-1/NPI-2, and provides concrete examples. It goes beyond the schema by elaborating on the hierarchy (grouping → classification → specialization) and the mapping logic for resolved entries.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: resolving and browsing the NUCC taxonomy code set. It enumerates three distinct modes (`resolve`, `get`, `browse`) with specific actions and examples, making it immediately clear what the tool does. It also differentiates from siblings by mentioning its use in `npi_search_providers.taxonomy_description`, establishing a distinct role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use each mode: `resolve` for plain-language terms, `get` for exact codes, and `browse` for hierarchy exploration. It also references sibling `npi_search_providers` and explains how to map resolved entries to its taxonomy_description field, giving clear routing context. It explicitly notes that `get` and `browse` return inactive codes, which helps the agent choose the right mode based on need.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
npi_search_providersNpi Search ProvidersARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Practice-location city, case-insensitive. A trailing "*" after at least 2 characters matches every city starting with them (e.g. "SAN F*"). | |
| skip | No | Results to skip for pagination (0–1000). A full page names the next in nextPage. | |
| limit | No | Maximum providers to return (1–200; the registry caps at 200). | |
| state | No | 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 | No | Individual last name. Trailing wildcard "*" allowed with at least 2 leading characters. | |
| specialty | No | 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 | No | Individual first name. Trailing wildcard "*" allowed with at least 2 leading characters. | |
| name_search | No | 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 | No | 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 | No | 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 | No | 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 | No | Exact NUCC taxonomy description for direct passthrough — use when the taxonomy description is already known. Mutually exclusive with specialty. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The limit that was applied. |
| error | No | Present when the call failed. Absent on success. |
| shown | No | Number of providers returned. |
| notice | No | Guidance — the page-size-not-total caveat, the next page or terminal-window continuation procedure, other-name and location-filter counts, or how to broaden an empty result. |
| nextPage | No | The next page: re-run the same arguments with this skip and limit. Present after a full page while rows remain reachable. When skip + limit passes 1000 it is skip 1000, limit 200, whose leading rows repeat rows already returned (the notice says how many) — dedupe by NPI. |
| providers | No | Matching provider rows (up to limit). |
| truncated | No | True when the NPPES page contained at least cap providers before location constraints were applied; more may match even when shown is below cap. |
| resolvedTaxonomies | No | Taxonomy candidates ranked for the specialty term. The first candidate supplies appliedTaxonomyDescription; a different candidate can be selected through taxonomy_description. |
| continuationPostalCodes | No | Present only at the terminal window (a full page at skip 1000, limit 200): postal_code prefixes that continue the same search, each re-run from skip 0 with the same arguments — the notice gives the full procedure. Empty when no postal split remains (postal_code is already a 5-digit ZIP, a full ZIP+4, or not a numeric ZIP prefix). |
| appliedTaxonomyDescription | No | The exact NUCC specialization or classification used as the specialty filter. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only, open-world, and idempotent; the description adds substantial behavioral context beyond that: the registry never reports true match totals, one search reaches only 1200 matches, continuationPostalCodes handles the terminal window, mailing addresses are never searched, and former/other names are matched with matchedOtherName. This is exactly the kind of non-obvious behavior an agent needs to present accurate results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Although long, the description is dense and every sentence carries operational weight. It is front-loaded with the core purpose, then progresses through matching behavior, address semantics, name behavior, and pagination. For a tool with this many quirks, the size is appropriate and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers matching rules, address filtering, name-search behavior, taxonomy resolution, pagination limits, continuation tokens, and the presence of matchedLocation/matchedOtherName. Given the output schema exists and annotations are present, nothing critical is missing for correct invocation and result interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description still adds real semantic value: name_search token splitting, the mutual exclusivity of specialty and taxonomy_description, organization_name implying provider_type, ZIP+4 matching nuance, and the rule that provider_type must agree with the name fields used. This goes well beyond the baseline expected from schema descriptions alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Search the NPPES NPI registry' and enumerates the exact search criteria (name, organization name, location, provider type, specialty). It also differentiates from the sibling tool by noting that the NPI is the input for npi_get_provider when the full record is needed, so the agent can disambiguate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: at least one search criterion is required, state-only searches are rejected, location must go in dedicated fields rather than specialty, and provider_type must match the chosen name fields. It also names the alternative for full records (npi_get_provider), giving clear routing between siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
- Changed
npi_lookup_taxonomy1 field changed- changed
Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `no_match`: A get code matched no taxonomy entry, or a resolve query matched no active one (the message names any inactive codes it matched). `missing_argument`: The required query or code was present but blank after trimming. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `no_match`: A get code matched no taxonomy entry, a resolve query matched no active one (the message names any inactive codes it matched), or a resolve query was made only of generic words (\"doctor\", \"M.D.\", \"specialist\") that name no specialty. `missing_argument`: The required query or code was present but blank after trimming. Other values are possible when a failure originates below the handler."
- Changed
npi_search_providers13 fields changed- changed
Input schema / properties / city / descriptionPrevious value: -"Practice-location city."New value: +"Practice-location city, case-insensitive. A trailing \"*\" after at least 2 characters matches every city starting with them (e.g. \"SAN F*\")." - added
Input schema / properties / city / patternAdded value: +"^[^*]*$|^[^*]{2,}\\*$" - changed
Input schema / properties / organization_name / descriptionPrevious value: -"Organization name (implies provider_type organization). Trailing wildcard \"*\" allowed with at least 2 leading characters."New value: +"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." - changed
Input schema / properties / postal_code / descriptionPrevious value: -"Practice-location postal/ZIP code (5 or 9 digits)."New value: +"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." - added
Input schema / properties / postal_code / patternAdded value: +"^[^*]*$|^\\d{2,9}\\*$" - changed
Input schema / properties / provider_type / descriptionPrevious value: -"Restrict to individuals (NPI-1) or organizations (NPI-2). Omit to search both."New value: +"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)." - changed
Input schema / properties / skip / descriptionPrevious value: -"Results to skip for pagination (0–1000). Only the first 1200 matches are reachable; skip beyond 1000 silently returns the same window — narrow the query instead of paging further."New value: +"Results to skip for pagination (0–1000). A full page names the next in nextPage." - added
Output schema / properties / continuationPostalCodesAdded value: +{ + "description": "Present only at the terminal window (a full page at skip 1000, limit 200): postal_code prefixes that continue the same search, each re-run from skip 0 with the same arguments — the notice gives the full procedure. Empty when no postal split remains (postal_code is already a 5-digit ZIP, a full ZIP+4, or not a numeric ZIP prefix).", + "items": { + "description": "A trailing-\"*\" postal_code prefix.", + "type": "string" + }, + "type": "array" +} - changed
Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `no_search_criteria`: No effective search criterion was provided. `conflicting_specialty`: Both specialty and taxonomy_description were supplied. `unresolved_specialty`: The specialty term matched no active NUCC taxonomy (the message names any inactive codes it matched). `invalid_search_field`: The registry returned a field error (e.g. wildcard under 2 characters, bad provider type). Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `no_search_criteria`: No effective search criterion was provided. `conflicting_specialty`: Both specialty and taxonomy_description were supplied. `mixed_provider_criteria`: Individual criteria (first_name, last_name, name_search) were combined with organization criteria (organization_name), directly or through provider_type. `unresolved_specialty`: The specialty term matched no active NUCC taxonomy (the message names any inactive codes it matched), or was made only of generic words (\"doctor\", \"M.D.\", \"specialist\") that name no specialty. `invalid_search_field`: The registry returned a field error (e.g. wildcard under 2 characters, bad provider type). Other values are possible when a failure originates below the handler." - changed
Output schema / properties / error / properties / data / properties / reason / examplesPrevious value: -[ - "no_search_criteria", - "conflicting_specialty", - "unresolved_specialty", - "invalid_search_field" -]New value: +[ + "no_search_criteria", + "conflicting_specialty", + "mixed_provider_criteria", + "unresolved_specialty", + "invalid_search_field" +] - added
Output schema / properties / nextPageAdded value: +{ + "additionalProperties": false, + "description": "The next page: re-run the same arguments with this skip and limit. Present after a full page while rows remain reachable. When skip + limit passes 1000 it is skip 1000, limit 200, whose leading rows repeat rows already returned (the notice says how many) — dedupe by NPI.", + "properties": { + "limit": { + "description": "The limit to send for the next page.", + "type": "number" + }, + "skip": { + "description": "The skip to send for the next page.", + "type": "number" + } + }, + "required": [ + "skip", + "limit" + ], + "type": "object" +} - changed
Output schema / properties / notice / descriptionPrevious value: -"Guidance — pagination ceiling, page-size-not-total caveat, or how to broaden an empty result."New value: +"Guidance — the page-size-not-total caveat, the next page or terminal-window continuation procedure, other-name and location-filter counts, or how to broaden an empty result." - added
Output schema / properties / providers / items / properties / matchedOtherNameAdded value: +{ + "additionalProperties": false, + "description": "The other (former, professional, DBA, or alternate) name this row matched the name search through. Present only when the current name fails a requested last_name, organization_name, or wildcard first_name and this other name satisfies it (case-insensitive, ignoring punctuation and spaces, trailing \"*\" as a prefix). An exact first_name alone never marks a row: the registry also matches first-name variants (Bob for Robert).", + "properties": { + "name": { + "description": "The other name as \"First Middle Last\", or its organization name.", + "type": "string" + }, + "type": { + "description": "Registry name type, e.g. \"Former Name\", \"Professional Name\".", + "type": "string" + } + }, + "required": [ + "name" + ], + "type": "object" +}
2 tool updates
- Changed
npi_lookup_taxonomy5 fields changed- changed
Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `no_match`: A resolve query or get code matched no taxonomy entry. `missing_argument`: The required query or code was present but blank after trimming. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `no_match`: A get code matched no taxonomy entry, or a resolve query matched no active one (the message names any inactive codes it matched). `missing_argument`: The required query or code was present but blank after trimming. Other values are possible when a failure originates below the handler." - added
Output schema / properties / matches / items / properties / notesAdded value: +{ + "description": "NUCC Notes: sources, revision history, and status remarks. Returned by mode \"get\" only, when NUCC records a note.", + "type": "string" +} - added
Output schema / properties / matches / items / properties / replacedByAdded value: +{ + "description": "For an inactive code, the active replacement code NUCC names, when it names one.", + "type": "string" +} - added
Output schema / properties / matches / items / properties / statusAdded value: +{ + "description": "NUCC status. Inactive codes are no longer maintained: mode \"resolve\" excludes them, while \"get\" and \"browse\" return them.", + "enum": [ + "active", + "inactive" + ], + "type": "string" +} - changed
Output schema / properties / matches / items / requiredPrevious value: -[ - "code", - "grouping", - "classification", - "displayName", - "section" -]New value: +[ + "code", + "grouping", + "classification", + "displayName", + "section", + "status" +]
- Changed
npi_search_providers2 fields changed- changed
Input schema / properties / specialty / descriptionPrevious value: -"Plain-language specialty (e.g. \"pediatric cardiologist\"), resolved through the bundled NUCC taxonomy to exact descriptions before searching. The matched taxonomy is echoed in the result. Mutually exclusive with taxonomy_description."New value: +"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." - changed
Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `no_search_criteria`: No effective search criterion was provided. `conflicting_specialty`: Both specialty and taxonomy_description were supplied. `unresolved_specialty`: The specialty term matched no NUCC taxonomy. `invalid_search_field`: The registry returned a field error (e.g. wildcard under 2 characters, bad provider type). Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `no_search_criteria`: No effective search criterion was provided. `conflicting_specialty`: Both specialty and taxonomy_description were supplied. `unresolved_specialty`: The specialty term matched no active NUCC taxonomy (the message names any inactive codes it matched). `invalid_search_field`: The registry returned a field error (e.g. wildcard under 2 characters, bad provider type). Other values are possible when a failure originates below the handler."
2 tool updates
- Changed
npi_get_provider19 fields changed- changed
Input schema / properties / npis / anyOfPrevious value: -[ - { - "description": "A 10-digit National Provider Identifier.", - "pattern": "^\\d{10}$", - "type": "string" - }, - { - "description": "An array of up to 10 ten-digit NPIs.", - "items": { - "description": "A 10-digit National Provider Identifier.", - "pattern": "^\\d{10}$", - "type": "string" - }, - "maxItems": 10, - "minItems": 1, - "type": "array" - } -]New value: +[ + { + "description": "A 10-digit National Provider Identifier whose last digit is its check digit (Luhn over the number prefixed with 80840).", + "pattern": "^\\d{10}$", + "type": "string" + }, + { + "description": "An array of up to 10 ten-digit NPIs.", + "items": { + "description": "A 10-digit National Provider Identifier whose last digit is its check digit (Luhn over the number prefixed with 80840).", + "pattern": "^\\d{10}$", + "type": "string" + }, + "maxItems": 10, + "minItems": 1, + "type": "array" + } +] - changed
Input schema / properties / npis / descriptionPrevious value: -"A single 10-digit NPI, or an array of up to 10. Each is validated as exactly 10 digits before any API call."New value: +"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." - changed
Output schema / anyOfPrevious value: -[ - { - "not": { - "required": [ - "error" - ] - }, - "required": [ - "found", - "notFound", - "errored", - "totalCount" - ] - }, - { - "required": [ - "error" - ] - } -]New value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "found", + "notFound", + "errored", + "invalid", + "totalCount" + ] + }, + { + "required": [ + "error" + ] + } +] - changed
Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `none_found`: Every requested NPI returned a confirmed no-record response — none failed with an upstream error (those surface as the underlying service/timeout error instead). Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `none_found`: Every requested NPI with a valid check digit returned a confirmed no-record response — none failed with an upstream error (those surface as the underlying service/timeout error instead). `invalid_npi_format`: Every requested NPI failed the NPI check digit, so none was looked up. Other values are possible when a failure originates below the handler." - changed
Output schema / properties / error / properties / data / properties / reason / examplesPrevious value: -[ - "none_found" -]New value: +[ + "none_found", + "invalid_npi_format" +] - changed
Output schema / properties / found / descriptionPrevious value: -"Fully decoded records for NPIs that resolved."New value: +"Decoded records for NPIs that resolved." - changed
Output schema / properties / found / items / descriptionPrevious value: -"A fully decoded NPPES provider record."New value: +"A decoded NPPES provider record — the registry's professional-practice data. Only LOCATION address rows are kept for individual providers." - changed
Output schema / properties / found / items / properties / addresses / descriptionPrevious value: -"All practice and mailing addresses."New value: +"Registry addresses. Only LOCATION (practice) rows are kept for individual providers — their mailing address is withheld; organizations carry both LOCATION and MAILING rows." - changed
Output schema / properties / found / items / properties / addresses / items / descriptionPrevious value: -"A practice or mailing address."New value: +"A practice (LOCATION) address, or an organization mailing address." - changed
Output schema / properties / found / items / properties / addresses / items / properties / purpose / descriptionPrevious value: -"Address purpose (LOCATION or MAILING)."New value: +"Address purpose: LOCATION (practice) or MAILING. Only LOCATION rows are kept for individual providers; organizations also carry MAILING." - added
Output schema / properties / found / items / properties / endpoints / items / properties / contentOtherDescriptionAdded value: +{ + "description": "The content the endpoint carries when the content type is OTHER (e.g. \"C-CDA\"), when present.", + "type": "string" +} - added
Output schema / properties / found / items / properties / endpoints / items / properties / endpointDescriptionAdded value: +{ + "description": "Free-text description of the endpoint (e.g. \"Carequality\"), when present.", + "type": "string" +} - added
Output schema / properties / found / items / properties / endpoints / items / properties / line2Added value: +{ + "description": "Endpoint address line 2, when present.", + "type": "string" +} - added
Output schema / properties / found / items / properties / endpoints / items / properties / useOtherDescriptionAdded value: +{ + "description": "What the endpoint is used for when the use code is OTHER, when present.", + "type": "string" +} - changed
Output schema / properties / found / items / properties / practiceLocations / items / descriptionPrevious value: -"A practice or mailing address."New value: +"A practice (LOCATION) address, or an organization mailing address." - changed
Output schema / properties / found / items / properties / practiceLocations / items / properties / purpose / descriptionPrevious value: -"Address purpose (LOCATION or MAILING)."New value: +"Address purpose: LOCATION (practice) or MAILING. Only LOCATION rows are kept for individual providers; organizations also carry MAILING." - added
Output schema / properties / invalidAdded value: +{ + "description": "NPIs that failed the NPI check digit — not valid NPIs, usually a typo. They were never looked up, so they are neither confirmed misses nor upstream failures.", + "items": { + "additionalProperties": false, + "description": "A requested NPI that failed the NPI check digit.", + "properties": { + "npi": { + "description": "The requested NPI that failed the check digit.", + "type": "string" + }, + "reason": { + "description": "Why the NPI was rejected.", + "type": "string" + } + }, + "required": [ + "npi", + "reason" + ], + "type": "object" + }, + "type": "array" +} - changed
Output schema / properties / notFound / descriptionPrevious value: -"NPIs that were well-formed but returned no record (deactivated or never enumerated). A confirmed absence, not a failure."New value: +"NPIs with a valid check digit that returned no record (deactivated or never enumerated). A confirmed absence, not a failure." - changed
Output schema / properties / notice / descriptionPrevious value: -"Guidance when some or all NPIs returned nothing."New value: +"Guidance when some NPIs failed the check digit, returned no record, or hit an upstream error."
- Changed
npi_search_providers4 fields changed- changed
Output schema / properties / providers / items / properties / city / descriptionPrevious value: -"Practice-location city when present."New value: +"Primary practice-location city when present." - added
Output schema / properties / providers / items / properties / matchedLocationAdded value: +{ + "additionalProperties": false, + "description": "The additional practice location that satisfied the requested city/state/postal_code. Present only when the primary practice location is elsewhere.", + "properties": { + "city": { + "description": "City of the matching practice location.", + "type": "string" + }, + "postalCode": { + "description": "Postal/ZIP code of the matching practice location.", + "type": "string" + }, + "state": { + "description": "State of the matching practice location.", + "type": "string" + } + }, + "type": "object" +} - changed
Output schema / properties / providers / items / properties / postalCode / descriptionPrevious value: -"Practice-location postal/ZIP code when present."New value: +"Primary practice-location postal/ZIP code when present." - changed
Output schema / properties / providers / items / properties / state / descriptionPrevious value: -"Practice-location state when present."New value: +"Primary practice-location state when present."
3 tool updates
- Changed
npi_get_provider6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "found", + "notFound", + "errored", + "totalCount" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `none_found`: Every requested NPI returned a confirmed no-record response — none failed with an upstream error (those surface as the underlying service/timeout error instead). Other values are possible when a failure originates below the handler.", + "examples": [ + "none_found" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "found", - "notFound", - "errored", - "totalCount" -]
- Changed
npi_lookup_taxonomy8 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / oneOfAdded value: +[ + { + "additionalProperties": false, + "properties": { + "limit": { + "default": 20, + "description": "Maximum matching entries to return (1–50).", + "maximum": 50, + "minimum": 1, + "type": "integer" + }, + "mode": { + "const": "resolve", + "description": "Resolve a plain-language specialty to taxonomy codes.", + "type": "string" + }, + "query": { + "description": "The plain-language specialty term to resolve, e.g. \"pediatric cardiologist\".", + "minLength": 1, + "type": "string" + }, + "skip": { + "default": 0, + "description": "Entries to skip before the page (0–1000). Keep the same query and limit, then raise skip by limit each call.", + "maximum": 1000, + "minimum": 0, + "type": "integer" + } + }, + "required": [ + "mode", + "query" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "code": { + "description": "The exact NUCC taxonomy code, e.g. \"207RC0000X\".", + "minLength": 1, + "type": "string" + }, + "mode": { + "const": "get", + "description": "Fetch one exact taxonomy entry by code.", + "type": "string" + } + }, + "required": [ + "mode", + "code" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "grouping": { + "description": "Filter to a top-level grouping by case-insensitive substring, e.g. \"physicians\".", + "type": "string" + }, + "limit": { + "default": 20, + "description": "Maximum entries to return (1–50).", + "maximum": 50, + "minimum": 1, + "type": "integer" + }, + "mode": { + "const": "browse", + "description": "Browse the taxonomy hierarchy.", + "type": "string" + }, + "section": { + "description": "Filter by NPI section: Individual (NPI-1) or Non-Individual (NPI-2).", + "enum": [ + "Individual", + "Non-Individual" + ], + "type": "string" + }, + "skip": { + "default": 0, + "description": "Entries to skip before the page (0–1000). Keep the same filters and limit, then raise skip by limit each call.", + "maximum": 1000, + "minimum": 0, + "type": "integer" + } + }, + "required": [ + "mode" + ], + "type": "object" + } +] - removed
Input schema / propertiesRemoved value: -{ - "code": { - "description": "For mode \"get\": the exact NUCC taxonomy code (e.g. \"207RC0000X\").", - "type": "string" - }, - "grouping": { - "description": "For mode \"browse\": filter to a top-level grouping by case-insensitive substring (e.g. \"physicians\").", - "type": "string" - }, - "limit": { - "default": 20, - "description": "Maximum entries to return for resolve/browse (1–50). Ignored for get.", - "maximum": 50, - "minimum": 1, - "type": "integer" - }, - "mode": { - "description": "resolve: plain term → codes. get: exact code → entry. browse: walk the hierarchy.", - "enum": [ - "resolve", - "get", - "browse" - ], - "type": "string" - }, - "query": { - "description": "For mode \"resolve\": the plain-language specialty term to resolve (e.g. \"pediatric cardiologist\").", - "type": "string" - }, - "section": { - "description": "For mode \"browse\": filter by NPI section — Individual (NPI-1) or Non-Individual (NPI-2).", - "enum": [ - "Individual", - "Non-Individual" - ], - "type": "string" - }, - "skip": { - "default": 0, - "description": "Entries to skip before the page, for paging past a truncated resolve/browse result (0–1000). Keep the same query/filters and limit, raise skip by limit each call. Ignored for get.", - "maximum": 1000, - "minimum": 0, - "type": "integer" - } -} - removed
Input schema / requiredRemoved value: -[ - "mode" -] - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "matches" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `no_match`: A resolve query or get code matched no taxonomy entry. `missing_argument`: The required query or code was present but blank after trimming. Other values are possible when a failure originates below the handler.", + "examples": [ + "no_match", + "missing_argument" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "matches" -]
- Changed
npi_search_providers12 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Input schema / properties / name_search / descriptionPrevious value: -"Convenience shortcut: a single person's name, split into first/last heuristically. For precise control use first_name/last_name."New value: +"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." - changed
Input schema / properties / state / descriptionPrevious value: -"2-letter state code (e.g. \"WA\"). The registry rejects state-only searches — pair it with another criterion. Blank values from form-based clients are treated as omitted."New value: +"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." - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "providers" + ] + }, + { + "required": [ + "error" + ] + } +] - changed
Output schema / properties / appliedTaxonomyDescription / descriptionPrevious value: -"The single taxonomy_description sent to the registry (from specialty resolution or the raw escape hatch)."New value: +"The exact NUCC specialization or classification used as the specialty filter." - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `no_search_criteria`: No effective search criterion was provided. `conflicting_specialty`: Both specialty and taxonomy_description were supplied. `unresolved_specialty`: The specialty term matched no NUCC taxonomy. `invalid_search_field`: The registry returned a field error (e.g. wildcard under 2 characters, bad provider type). Other values are possible when a failure originates below the handler.", + "examples": [ + "no_search_criteria", + "conflicting_specialty", + "unresolved_specialty", + "invalid_search_field" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - changed
Output schema / properties / resolvedTaxonomies / descriptionPrevious value: -"The taxonomy candidates the specialty term resolved to; the first was sent to the registry. Re-run with taxonomy_description to pick a different one."New value: +"Taxonomy candidates ranked for the specialty term. The first candidate supplies appliedTaxonomyDescription; a different candidate can be selected through taxonomy_description." - changed
Output schema / properties / resolvedTaxonomies / items / properties / description / descriptionPrevious value: -"The taxonomy description (specialization or classification) the registry matched on — the value sent as taxonomy_description."New value: +"Search-compatible NUCC specialization or classification for this candidate." - changed
Output schema / properties / truncated / descriptionPrevious value: -"True when the returned page hit the limit — more may match."New value: +"True when the NPPES page contained at least cap providers before location constraints were applied; more may match even when shown is below cap." - removed
Output schema / requiredRemoved value: -[ - "providers" -]
1 tool update
- Changed
npi_lookup_taxonomy2 fields changed- added
Input schema / properties / skipAdded value: +{ + "default": 0, + "description": "Entries to skip before the page, for paging past a truncated resolve/browse result (0–1000). Keep the same query/filters and limit, raise skip by limit each call. Ignored for get.", + "maximum": 1000, + "minimum": 0, + "type": "integer" +} - changed
Output schema / properties / notice / descriptionPrevious value: -"Guidance when nothing matched — suggests broadening or browsing the hierarchy."New value: +"Guidance — how to page a truncated result with skip, or how to broaden when nothing matched."
2 tool updates
- Changed
npi_get_provider24 fields changed- added
Output schema / properties / erroredAdded value: +{ + "description": "NPIs whose lookups failed with an upstream/transport error (service unavailable, timeout) — distinct from a confirmed miss in notFound. These are unresolved, not absent; retry them.", + "items": { + "additionalProperties": false, + "description": "A requested NPI whose lookup failed with an upstream error.", + "properties": { + "npi": { + "description": "The requested NPI whose lookup failed operationally.", + "type": "string" + }, + "reason": { + "description": "The upstream failure reason (service unavailable, timeout, etc.).", + "type": "string" + } + }, + "required": [ + "npi", + "reason" + ], + "type": "object" + }, + "type": "array" +} - added
Output schema / properties / found / items / properties / authorizedOfficial / properties / namePrefixAdded value: +{ + "description": "Authorized official name prefix, when present.", + "type": "string" +} - added
Output schema / properties / found / items / properties / authorizedOfficial / properties / nameSuffixAdded value: +{ + "description": "Authorized official name suffix, when present.", + "type": "string" +} - added
Output schema / properties / found / items / properties / createdEpochAdded value: +{ + "description": "Record creation timestamp, epoch milliseconds, when present.", + "type": "number" +} - changed
Output schema / properties / found / items / properties / endpoints / items / descriptionPrevious value: -"A FHIR or Direct messaging endpoint."New value: +"A FHIR or Direct messaging endpoint with its routing address and context." - added
Output schema / properties / found / items / properties / endpoints / items / properties / addressTypeAdded value: +{ + "description": "Endpoint address type (DOM/FOR), when present.", + "type": "string" +} - added
Output schema / properties / found / items / properties / endpoints / items / properties / affiliationAdded value: +{ + "description": "Whether the endpoint is affiliated with an organization (Y/N), when present.", + "type": "string" +} - added
Output schema / properties / found / items / properties / endpoints / items / properties / affiliationNameAdded value: +{ + "description": "Name of the affiliated organization, when present.", + "type": "string" +} - added
Output schema / properties / found / items / properties / endpoints / items / properties / cityAdded value: +{ + "description": "Endpoint city, when present.", + "type": "string" +} - changed
Output schema / properties / found / items / properties / endpoints / items / properties / contentType / descriptionPrevious value: -"Endpoint content type, when present."New value: +"Endpoint content type code, when present." - added
Output schema / properties / found / items / properties / endpoints / items / properties / contentTypeDescriptionAdded value: +{ + "description": "Endpoint content type description, when present.", + "type": "string" +} - added
Output schema / properties / found / items / properties / endpoints / items / properties / countryCodeAdded value: +{ + "description": "Endpoint ISO country code, when present.", + "type": "string" +} - added
Output schema / properties / found / items / properties / endpoints / items / properties / countryNameAdded value: +{ + "description": "Endpoint country name, when present.", + "type": "string" +} - added
Output schema / properties / found / items / properties / endpoints / items / properties / line1Added value: +{ + "description": "Endpoint address line 1, when present.", + "type": "string" +} - added
Output schema / properties / found / items / properties / endpoints / items / properties / postalCodeAdded value: +{ + "description": "Endpoint postal/ZIP code, when present.", + "type": "string" +} - added
Output schema / properties / found / items / properties / endpoints / items / properties / stateAdded value: +{ + "description": "Endpoint state, when present.", + "type": "string" +} - changed
Output schema / properties / found / items / properties / endpoints / items / properties / use / descriptionPrevious value: -"Endpoint use, when present."New value: +"Endpoint use code (e.g. \"HIE\"), when present." - added
Output schema / properties / found / items / properties / endpoints / items / properties / useDescriptionAdded value: +{ + "description": "Endpoint use description, when present.", + "type": "string" +} - added
Output schema / properties / found / items / properties / lastUpdatedEpochAdded value: +{ + "description": "Record last-update timestamp, epoch milliseconds, when present.", + "type": "number" +} - added
Output schema / properties / found / items / properties / otherNames / items / properties / middleNameAdded value: +{ + "description": "Middle name, for individuals, when present.", + "type": "string" +} - added
Output schema / properties / found / items / properties / otherNames / items / properties / prefixAdded value: +{ + "description": "Name prefix, when present.", + "type": "string" +} - added
Output schema / properties / found / items / properties / otherNames / items / properties / suffixAdded value: +{ + "description": "Name suffix, when present.", + "type": "string" +} - changed
Output schema / properties / notFound / descriptionPrevious value: -"NPIs that were well-formed but returned no record (deactivated or never enumerated)."New value: +"NPIs that were well-formed but returned no record (deactivated or never enumerated). A confirmed absence, not a failure." - changed
Output schema / requiredPrevious value: -[ - "found", - "notFound", - "totalCount" -]New value: +[ + "found", + "notFound", + "errored", + "totalCount" +]
- Changed
npi_search_providers5 fields changed- added
Input schema / properties / state / anyOfAdded value: +[ + { + "const": "", + "type": "string" + }, + { + "description": "2-letter state code (e.g. \"WA\").", + "pattern": "^[A-Z]{2}$", + "type": "string" + } +] - changed
Input schema / properties / state / descriptionPrevious value: -"2-letter state code (e.g. \"WA\"). The registry rejects state-only searches — pair it with another criterion."New value: +"2-letter state code (e.g. \"WA\"). The registry rejects state-only searches — pair it with another criterion. Blank values from form-based clients are treated as omitted." - removed
Input schema / properties / state / patternRemoved value: -"^[A-Z]{2}$" - removed
Input schema / properties / state / typeRemoved value: -"string" - added
Output schema / properties / providers / items / properties / postalCodeAdded value: +{ + "description": "Practice-location postal/ZIP code when present.", + "type": "string" +}
3 tool updates
- First observed
npi_get_provider - First observed
npi_lookup_taxonomy - First observed
npi_search_providers
Related MCP Connectors
Query SEC EDGAR filings, XBRL financials, and company data through MCP. STDIO & Streamable HTTP.
Query U.S. Census Bureau data, variables, and geography via MCP.
Query FDA data on drugs, food, devices, and recalls via openFDA. STDIO or Streamable HTTP.
Search and compare attributed recipe records through a public read-only remote MCP endpoint.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceMCP server for looking up and searching US healthcare providers in the CMS NPPES NPI Registry.MIT
- FlicenseNot gradedqualityBmaintenanceSource-provenanced US federal healthcare provider data over MCP. Resolve any NPI or CCN across NPPES, OIG LEIE, SAM.gov, state Medicaid exclusions, CMS PECOS, Care Compare, and Open Payments — every field carries a 14-field provenance contract, and an "excluded or compromised anywhere" check runs on every lookup.-
- AlicenseNot gradedqualityCmaintenanceEnables querying the NPPES NPI Registry for provider searches, specialty lookups, NPI format validation, and referral-eligibility checks over MCP.MIT
- AlicenseNot gradedqualityAmaintenanceLook up countries, timezones, periodic table elements, physical constants, units, HTTP status codes, and MIME types via MCP. STDIO or Streamable HTTP.277 npm1Apache 2.0
Glama MCP Gateway
Add one secure layer between your agents and this server.