Skip to main content
Glama

npi-providers-mcp-server

Npi Search Providers

npi_search_providers
Read-onlyIdempotent

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cityNoPractice-location city.
skipNoResults 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.
limitNoMaximum providers to return (1–200; the registry caps at 200).
stateNo2-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_nameNoIndividual last name. Trailing wildcard "*" allowed with at least 2 leading characters.
specialtyNoPlain-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_nameNoIndividual first name. Trailing wildcard "*" allowed with at least 2 leading characters.
name_searchNoOne 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_codeNoPractice-location postal/ZIP code (5 or 9 digits).
provider_typeNoRestrict to individuals (NPI-1) or organizations (NPI-2). Omit to search both.
organization_nameNoOrganization name (implies provider_type organization). Trailing wildcard "*" allowed with at least 2 leading characters.
taxonomy_descriptionNoExact NUCC taxonomy description for direct passthrough — use when the taxonomy description is already known. Mutually exclusive with specialty.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
capNoThe limit that was applied.
errorNoPresent when the call failed. Absent on success.
shownNoNumber of providers returned.
noticeNoGuidance — pagination ceiling, page-size-not-total caveat, or how to broaden an empty result.
providersNoMatching provider rows (up to limit).
truncatedNoTrue when the NPPES page contained at least cap providers before location constraints were applied; more may match even when shown is below cap.
resolvedTaxonomiesNoTaxonomy candidates ranked for the specialty term. The first candidate supplies appliedTaxonomyDescription; a different candidate can be selected through taxonomy_description.
appliedTaxonomyDescriptionNoThe 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.

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.