NPI Registry MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Server capabilities have not been inspected yet.
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_npi_registryA | Search the National Provider Identifier (NPI) registry. The NPI registry contains information about healthcare providers and organizations in the United States. You can search by various criteria including name, NPI number, location, and specialty. WILDCARD SUPPORT: Most text fields support wildcard searches using '' after at least 2 characters for fuzzy matching (e.g., 'smith', 'hosp*', 'cardi*'). Args: first_name: Provider's first name (supports wildcards: 'john*' matches 'John', 'Johnny', etc.) last_name: Provider's last name (supports wildcards: 'smith*' matches 'Smith', 'Smithson', etc.) organization_name: Organization name (supports wildcards: 'hosp*' matches 'Hospital', 'Hospice', etc.) npi: Specific 10-digit NPI number to look up (exact match only) city: City name (supports wildcards: 'san*' matches 'San Francisco', 'San Diego', etc.) state: State abbreviation (e.g., 'CA', 'NY', 'TX') - exact match only postal_code: ZIP/postal code (supports wildcards: '902*' matches '90210', '90211', etc.) specialty: Provider specialty or taxonomy (supports wildcards: 'cardi*' matches 'Cardiology', 'Cardiac Surgery', etc.) limit: Maximum number of results to return (1-200, default: 10) Examples: - Find all Smiths: last_name='smith*' - Find hospitals: organization_name='hosp*' - Find cardiologists: specialty='cardio*' - Find providers in San cities: city='san*' - Find providers in 90210 area: postal_code='902*' Returns: Dictionary containing search results with provider information |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 1 tool
With only one tool, there is no ambiguity or overlap between tools. The single tool has a clear, distinct purpose of searching the NPI registry, so an agent cannot misselect between multiple tools.
With only one tool, naming consistency is inherently perfect. The tool name 'search_npi_registry' follows a clear verb_noun pattern that would be consistent if more tools existed.
A single tool for an NPI registry server feels too thin for the apparent scope. The registry likely supports more operations beyond search, such as retrieving specific records by ID or filtering by additional criteria, making the tool count insufficient for comprehensive coverage.
The tool surface is severely incomplete for an NPI registry domain. While search is well-implemented with various criteria, there are obvious gaps such as no tools for retrieving a specific provider by NPI number (get_npi), updating records, or managing provider data, which limits agent workflows.