A
licenseNot graded
qualityC
maintenanceMCP server for looking up and searching US healthcare providers in the CMS NPPES NPI Registry.
MIT
npi-providers-mcp-server
Server Details
Search NPPES providers and resolve NUCC specialty codes via MCP over STDIO or Streamable HTTP.
If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- cyanheads/npi-providers-mcp-server
- GitHub Stars
- 1
- Server Listing
- npi-providers-mcp-server
Available Tools
3 toolsnpi_get_providerNpi Get ProviderARead-onlyIdempotentInspect
Fetch the complete 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 a fully populated provider profile: every taxonomy with its primary flag, license number and state; all practice and mailing addresses; credential, sex, sole-proprietor flag; enumeration and last-updated dates; active/deactivated status; secondary identifiers (Medicaid, etc.); and FHIR/Direct endpoints. The 10-digit NPI format is validated before any API call. Reports partial success: well-formed 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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| npis | Yes | A single 10-digit NPI, or an array of up to 10. Each is validated as exactly 10 digits before any API call. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| found | No | Fully decoded records for NPIs that resolved. |
| notice | No | Guidance when some or all NPIs returned nothing. |
| 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. |
| notFound | No | NPIs that were well-formed but 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
A4.4/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, openWorld, idempotent), the description discloses valuable behavioral details: 'The 10-digit NPI format is validated before any API call' and 'Reports partial success... well-formed NPIs with no registry record land in notFound, while NPIs whose lookup hit an upstream error land in errored — kept distinct from confirmed misses.' This adds error-handling context not present in the annotations, with no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but well-structured: it leads with the core purpose, then lists the returned data, and concludes with validation and error behavior. Each sentence serves a purpose, though the enumeration of output fields could be considered redundant if the output schema already documents them. It is appropriately front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a single parameter, full schema coverage, and annotations covering read-only/open-world/idempotent, the description is remarkably complete. It explains what it does, when to use it, how it validates input, and how it handles partial success—covering all operational aspects an agent needs. The output schema exists, so field-level details are not missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single parameter: it describes the type (string or array), pattern (10 digits), and maxItems (10). The description repeats these facts ('up to 10 per call', 'validated before any API call') without adding new meaning. Since schema coverage is complete, the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches the complete NPPES record for one or more NPIs (up to 10 per call), listing specific output fields like taxonomy, addresses, and credential. It differentiates itself from siblings by focusing on complete records by NPI, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: 'Decodes an NPI from a claim, prescription, or another health data source' tells the agent when to use this tool—when you have an NPI and want a full provider profile. However, it does not explicitly state when not to use it or mention sibling tools (npi_lookup_taxonomy, npi_search_providers) as alternatives, so it lacks exclusions.
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 taxonomy entries; mode get returns the full entry for an exact code; mode browse walks the hierarchy (grouping → classification → specialization), optionally filtered by grouping and by NPI section (Individual/NPI-1 vs Non-Individual/NPI-2). A resolved entry's specialization, or its classification when specialization is absent, maps directly to npi_search_providers.taxonomy_description.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON 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
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint=false, and idempotentHint. The description adds value by specifying 'fully offline (bundled)', which aligns with openWorldHint=false, and by outlining the behavior of each mode (resolve turns plain-language into entries, get fetches exact code, browse walks hierarchy). It also notes the fallback from specialization to classification, which is a useful behavioral detail not in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and offline nature, then efficiently lists the three modes and their behavior. No wasted words; every clause contributes to understanding. The structure is logical and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema (which presumably describes return values), the description covers all necessary operational aspects: modes, filters, offline status, and the mapping to a sibling tool. It explains the hierarchy and fallback behavior, addressing likely agent questions about how to use the tool. No critical information appears missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter described. The description adds semantic context beyond the schema by explaining what each mode does and the hierarchy (grouping → classification → specialization), which enriches the understanding of mode and section/grouping parameters. It clarifies the mapping of resolved entries to provider search, which the schema does not convey. Thus it adds meaningful value beyond the structured definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 Healthcare Provider Taxonomy. It names the exact resource (NUCC taxonomy) and explains three distinct modes (resolve, get, browse) with concrete examples. It also differentiates from siblings by specifying that it covers the taxonomy code set NPPES uses, and explicitly maps its output to npi_search_providers.taxonomy_description, making its role distinct from provider retrieval tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it: when you need taxonomy codes to populate npi_search_providers.taxonomy_description, or to browse the taxonomy hierarchy. It provides a direct mapping to a sibling tool, indicating a workflow. However, it does not explicitly list alternatives or state when not to use it (e.g., when you need provider records). Still, the context is clear enough for an agent to infer its role.
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. For specialty searches, returned providers are limited to the requested city/state/postal_code even when the registry includes providers outside that location. The registry never reports a true match total and only the first 1200 matches are reachable, so broad queries are capped.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Practice-location city. | |
| skip | No | 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. | |
| 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. 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 postal/ZIP code (5 or 9 digits). | |
| provider_type | No | Restrict to individuals (NPI-1) or organizations (NPI-2). Omit to search both. | |
| organization_name | No | Organization name (implies provider_type organization). 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
ParametersJSON 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 — pagination ceiling, page-size-not-total caveat, or how to broaden an empty result. |
| 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. |
| appliedTaxonomyDescription | No | The exact NUCC specialization or classification used as the specialty filter. |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, openWorldHint, and idempotentHint, but the description adds substantial behavioral context beyond these: the result row composition (NPI, name, primary specialty, city/state/ZIP, type, active/deactivated status), the registry's failure to report true match totals, the hard cap at 1200 matches, the 'skip beyond 1000 silently returns the same window' nuance, and the location-limited behavior for specialty searches. No contradictions 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence earns its place; the description is front-loaded with the core purpose, then systematically covers specialty resolution, location placement, return fields, sibling routing, and registry limitations. Despite its length, there is no redundant phrasing. The structure moves logically from what the tool does to how to use it correctly to edge-case caveats.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 12 parameters, no required fields, and an output schema, the description covers everything an agent needs to invoke it correctly: criteria, mutually-exclusive parameters, pagination constraints, location handling, and the link to the sibling for detailed records. The return content is summarized and the output schema supplies the exact fields, so nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% parameter description coverage, so the baseline is 3. The description adds meaningful cross-parameter guidance: it clarifies that 'Location belongs in the dedicated city/state/postal_code inputs, not inside specialty', explains how plain-language specialty terms resolve through the NUCC taxonomy and that taxonomy_description is for direct passthrough, and notes that specialty searches are limited to the requested location. These enrich the schema descriptions without merely repeating them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise verb and resource: 'Search the NPPES NPI registry for individual practitioners and healthcare organizations' and enumerates the searchable attributes (name, organization name, location, provider type, specialty). It explicitly differentiates from the sibling npi_get_provider by noting that the NPI is the input for that tool when the full record is needed. The purpose is unmistakable and distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Strong guidance is provided: 'At least one search criterion is required, and the registry rejects state-only searches' sets a hard usage constraint, and 'the NPI is the input for npi_get_provider when the full record is needed' names an explicit alternative. It also warns against placing location inside the specialty field. However, it does not explicitly mention when to use npi_lookup_taxonomy as opposed to the specialty resolution path, leaving some alternative-routing to inference.
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. Dates show when Glama detected each change.
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
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Connectors
Query SEC EDGAR filings, XBRL financials, and company data through MCP. STDIO & Streamable HTTP.
Search FDIC institutions, branches, failures, and peer analysis over 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
- 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 gradedqualityAmaintenanceLook up countries, timezones, periodic table elements, physical constants, units, HTTP status codes, and MIME types via MCP. STDIO or Streamable HTTP.3681Apache 2.0
- AlicenseNot gradedqualityAmaintenanceSearch and fetch ~800K Federal Reserve economic time-series from the FRED API via MCP, with STDIO or Streamable HTTP transport.1161Apache 2.0
Try in Browser
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
A4.7/5.0
Disambiguation5/5
Each tool has a distinct purpose: retrieving full records by NPI, browsing taxonomy codes, and searching providers. No overlap or ambiguity between them.
Naming Consistency5/5
All tools follow the same pattern: 'npi_' prefix + verb_noun (get_provider, lookup_taxonomy, search_providers). Perfectly consistent naming.
Tool Count5/5
Three tools cover the essential operations for an NPI/provider lookup service without unnecessary bloat. The count feels lean and purposeful.
Completeness5/5
The server provides a complete read-only workflow: search providers, resolve taxonomy terms, and fetch full records. No missing CRUD operations are expected for this domain, and all necessary dependencies are present.