Skip to main content
Glama
CBLU2005

US Government Data

by CBLU2005

Search US healthcare providers (NPI registry)

search_healthcare_providers

Search the official CMS NPPES NPI Registry for US healthcare providers and organizations. Filter by specialty, location, or name to retrieve NPI numbers, addresses, and license details for verification or sales lists.

Instructions

Search the official CMS NPPES NPI Registry of all US healthcare providers and organizations. Returns NPI number, provider/organization name, specialty (taxonomy), state license, practice address with phone and fax, and for organizations the authorized official's name/title/phone. Filter by specialty, state, city, ZIP (wildcards like '331*'), or name. Great for healthcare sales lists, provider verification, and directory enrichment. Runs the paid Apify actor https://apify.com/cblu/npi-healthcare-providers-scraper on YOUR Apify account (requires APIFY_TOKEN; pay per result: $0.002 per provider record ($2.00 / 1,000), charged only for records actually returned).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cityNoPractice-location city, e.g. 'Austin'.
stateNoTwo-letter US state code of the practice location, e.g. 'TX'.
lastNameNoProvider last name (individual lookups). Trailing wildcard supported.
firstNameNoProvider first name (individual lookups). Trailing wildcard supported, e.g. 'jo*'.
maxResultsNoMax provider records to return (1-5000, default 25). Each returned record is billed at $0.002 per provider record ($2.00 / 1,000).
postalCodeNoPractice-location ZIP. Prefix wildcards supported: '331*' matches all ZIPs starting 331 (greater Miami).
enumerationTypeNo'individual' (NPI-1: physicians, dentists, nurses...) or 'organization' (NPI-2: clinics, hospitals, pharmacies...). Omit for both.
organizationNameNoOrganization name (NPI-2 lookups). Trailing wildcard supported, e.g. 'mayo*'.
taxonomyDescriptionNoProvider specialty / taxonomy, e.g. 'Dentist', 'Family Medicine', 'Chiropractor', 'Physical Therapist', 'Pharmacy'. Exact taxonomy codes also work.
Behavior4/5

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

No annotations provided, so the description carries full burden. It discloses the tool runs a paid Apify actor on the user's account, requires APIFY_TOKEN, and explains billing ($0.002 per record). This covers safety and cost implications well.

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 somewhat long but structured with key info upfront (what it is, what it returns, filters). Every sentence adds value: purpose, returned data, filters, use cases, and billing details. No redundancy.

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?

Given 9 parameters, no output schema, and no annotations, the description provides sufficient context: it lists return fields, explains all filter parameters, and covers cost. It lacks only explicit mention of pagination or error handling, but overall it is quite complete.

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 descriptive parameter definitions. The description adds value by explaining wildcard usage (e.g., '331*', 'mayo*') and billing implications of maxResults. This enhances the agent's understanding beyond the schema.

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 it searches the official CMS NPPES NPI Registry for US healthcare providers and organizations, listing returned fields and filter criteria. It distinguishes itself from sibling tools (building permits, federal contracts) by its specific domain.

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 explicit use cases: 'healthcare sales lists, provider verification, and directory enrichment.' It does not specify when not to use this tool, but the clear purpose and unrelated siblings make this adequate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/CBLU2005/us-govdata-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server