Loading ToolBench
Search NPPES providers and resolve NUCC specialty codes via MCP over STDIO or Streamable HTTP.
Three well-defined tools with comprehensive schemas, clear descriptions, and proper parameter typing. npi_search_providers and npi_lookup_taxonomy have excellent documentation with detailed constraints and use-case guidance. npi_get_provider is simpler but complete. All tools include descriptions (194 - 500+ chars, well above 20-char floor). Parameters are typed with enums, ranges, and descriptions. Output schemas are documented in descriptions. Error handling guidance is present but could be more explicit about recovery paths. Tool naming follows verb_noun convention (search_, get_, lookup_). No security issues detected (read-only operations, no secrets in params). Composition is sound: tools chain naturally (search → get, specialty resolution → search). Minor gaps: error responses lack structured categorization (retryable vs fatal), and some edge cases (e.g., 'skip beyond 1000 silently returns same window') could be clearer in error guidance.
Fetch the complete NPPES record for one or more NPIs (up to 10), fanning out one call per NPI with partial-success reporting.
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.
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.
Error responses lack structured categorization. Descriptions mention edge cases (e.g., 'skip beyond 1000 silently returns same window') but do not guide LLM on recovery: is this retryable? Should the agent narrow the query? Structured error classification (retryable, user-fixable, fatal) is missing.
npi_search_providers description mentions 'the registry rejects state-only searches' and 'broad queries are capped' but does not provide actionable error messages. When these constraints are violated, the tool should return a clear error like 'State-only search rejected. Provide at least one of: name, organization_name, specialty, or postal_code.' to enable LLM self-correction.
npi_get_provider description states 'partial-success reporting' but does not document the response structure for partial failures. When 5 of 10 NPIs fail, what does the response look like? Per-item success/failure is mentioned but not formalized in the output schema.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 70 | 2026-07-28+ | v2 |
npi_lookup_taxonomy 'resolve' mode accepts plain-language specialty but does not document fallback behavior if no match is found. Does it return an empty list? A 'no match' error? This ambiguity forces the LLM to guess and retry.
npi_search_providers and npi_lookup_taxonomy both accept 'limit' and 'skip' for pagination but do not document total count or next_cursor in the response. Without a total, the LLM cannot determine if more results exist or plan pagination efficiently.