Skip to main content
Glama

NPPES NPI Registry MCP by usefulapi

Search individual providers

nppes_search_individuals
Read-only

Search for INDIVIDUAL healthcare providers (NPI-1: doctors, nurses, therapists, etc.) by name, specialty (taxonomy) and/or location. Provide at least one meaningful criterion beyond a location. Name fields support a trailing '*' wildcard (min 2 chars before it). NPPES Read API v2.1.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cityNoCity of the provider's address.
skipNoNumber of records to skip, for pagination (0–1000; combined with limit, up to 1200 records reachable).
limitNoMax number of records to return (1–200, default 10).
stateNoTwo-letter U.S. state/territory abbreviation, e.g. 'CA', 'NY', 'PR'.
last_nameNoProvider last name. A trailing '*' wildcard is allowed, e.g. 'Smi*'.
first_nameNoProvider first name. A trailing '*' wildcard is allowed, e.g. 'Jo*'.
postal_codeNoPostal (ZIP) code; a trailing '*' wildcard is allowed for prefix search, e.g. '941*'.
country_codeNoTwo-letter country code (default 'US'). Use 'US' for domestic addresses.
name_purposeNoWhich name to match: 'PROVIDER' (default) matches the provider's own name; 'AO' matches an authorized official.
address_purposeNoWhich address the city/state/postal_code filters apply to (LOCATION = practice address).
taxonomy_descriptionNoProvider taxonomy / specialty text, e.g. 'cardiology', 'Pediatrics', 'Social Worker'. Partial matches supported; a trailing '*' wildcard is allowed (min 2 chars before it).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. First observed

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnlyHint=true, so the description carries the rest: it adds the wildcard rules, the minimum 2-character prefix, and the practical constraint that a location alone is insufficient input. It does not mention result size or pagination behavior, but the added query-construction behavior is genuine value beyond the annotation.

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?

Three short sentences, front-loaded with the scope-defining first clause, followed by the usage constraint and wildcard rule. No filler; every sentence carries information the agent needs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and only a readOnlyHint annotation, the description must cover query semantics, which it does well for an 11-parameter search. It omits any mention of result-set size or pagination (skip/limit), which the schema covers, leaving a minor gap for an agent planning multi-page retrieval.

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?

Schema description coverage is 100% across all 11 parameters, so the schema already documents city, state, name_purpose, address_purpose, taxonomy, etc. The description only restates the wildcard behavior already present in the schema (adding a small note on the 2-char minimum), so it does not materially extend parameter meaning.

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?

States a specific verb and resource ('Search for INDIVIDUAL healthcare providers') and pins the scope to NPI-1 with concrete examples (doctors, nurses, therapists). The capitalized INDIVIDUAL and NPI-1 labeling clearly contrasts it with the sibling nppes_search_organizations, so an agent can distinguish them without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

"Provide at least one meaningful criterion beyond a location" gives actionable guidance on how to form a valid query. However, it never names alternatives or routing conditions (e.g. use nppes_lookup_npi when an NPI is already known, or nppes_search for a combined lookup), so when-to-use-vs-sibling is only implied.

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.