Skip to main content
Glama

Request a provider enrollment check

provider_check_request

Send a list of NPIs (up to 100) for a provider enrollment check. Each provider gets one row from public records: the national NPI registry, the Medicare revalidation due date, Medicare enrollment and group reassignments, the federal exclusion list, state license status and expiry, and the places those records disagree (name, license number, state). When the registry lists no license number, the board is searched by the provider's name. Every cell that was read has its source link and read time; a license whose board has not been read yet is queued, with no read time, and a record that could not be read is marked so in its own cell, never guessed. Results usually start in seconds, and while the check runs its status says what is being read and when to look again. State licenses are read in AK, AL, AR, CA, CO, CT, DC, DE, FL, ID, IL, IN, KS, KY, LA, MA, MD, ME, MI, MN, MO, MS, MT, ND, NJ, NM, NV, NY, OH, OK, OR, PA, RI, SD, TX, VA, VT, WA, WV and WY; one there that cannot be settled right away is read by a person, and a license in another state or of a type we do not read yet is marked not checked with the board's link. We email the full table when the check finishes. The first check is free. Each source is also its own part, called alone at its own price with capability_call (capabilities_list with q "provider records"): npi-registry-read, medicare-enrollment-read, oig-exclusion-check, sam-exclusion-check, state-license-read, state-medicaid-enrollment-read, and clinician-record-check for one NPI's whole record.

Input Schema

NameRequiredDescriptionDefault
npisNo10-digit NPIs, up to 100 valid ones; use instead of text. Entries that are not valid NPIs are listed back with a reason.
textNoPasted text with NPIs anywhere in it; use instead of npis.
emailYes
companyNo
ref_codeNo
contact_timeNoLeave empty.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / npis / description
      Previous value: -"10-digit NPIs, up to 500 valid ones; use instead of text. Entries that are not valid NPIs are listed back with a reason."New value: +"10-digit NPIs, up to 100 valid ones; use instead of text. Entries that are not valid NPIs are listed back with a reason."
  2. Added

TDQS

A4.3/5.0
Behavior5/5

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

Annotations only declare the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true, idempotentHint=false); the description adds substantial context beyond that: asynchronous execution, status reporting, email delivery of the full table, first-check-free pricing, queueing of unread boards, and an explicit never-guess policy on unreadable cells. The 41-state coverage list and the 'read by a person' fallback are the kind of limits an agent must know before sending 100 records.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is correctly front-loaded in the first sentence, and most content is substantive. But it is a single dense paragraph, and spelling out all 41 covered states plus the trailing per-source capability catalogue pushes it well past what an agent needs to make the call — both could be compressed or deferred to the named companion tools.

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?

There is no output schema, and the description compensates thoroughly: one row per provider, per-cell source link and read time, per-cell failure marking, human-review and not-checked states, and email delivery of the table. An agent knows what it will get back and how to interpret gaps without a return schema.

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 coverage is 50%, so the description should carry more of the load. It explains the NPI list and its cap and the email delivery outcome, but says nothing about `company`, `ref_code`, or `text` beyond what the schema already states. Also worth noting: the description says 'up to 100' while the schema sets maxItems 1000 and notes 100 valid NPIs, a mild mismatch an agent must reconcile from 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?

Opens with a specific verb and resource: 'Send a list of NPIs (up to 100) for a provider enrollment check.' The named purpose plus the enumerated data sources (NPI registry, Medicare revalidation, exclusion lists, state licenses) make it unmistakable against siblings like provider_check_status or vendor_check_request.

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?

It implies the polling companion ('while the check runs its status says what is being read and when to look again') and names capability_call with concrete capability names for callers who want a single source at its own price. That is real routing guidance. It never explicitly says 'use provider_check_status to poll' or when to prefer a single-source capability over the batch, so a small inference remains.

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.

Resources