Skip to main content
Glama

Nc Medical Check Exclusion

nc_medical_check_exclusion
Read-onlyIdempotent

Is this healthcare provider excluded from the North Carolina Medicaid program? Screens a person or business name, an NPI, and/or an atypical (non-NPI) Medicaid provider ID against NC Medicaid's (Division of Health Benefits, Office of Compliance and Program Integrity) State Excluded Providers List — the state-level counterpart to the federal HHS OIG LEIE (see the leie pack) for North Carolina specifically, and the sibling of ny_omig_check_exclusion (New York), ca_medical_check_exclusion (California), tx_medical_check_exclusion (Texas), fl_medical_check_exclusion (Florida), pa_medical_check_exclusion (Pennsylvania), ga_medical_check_exclusion (Georgia), oh_medical_check_exclusion (Ohio) and nj_medical_check_exclusion (New Jersey). Answers "is this provider excluded from North Carolina Medicaid" or pre-payment/credentialing screening for an NC Medicaid provider. An NPI or atypical-ID match is an IDENTIFICATION (both are exact, provider-specific identifiers); a name match against the EXCLUDED ENTITY field — even an exact one — is a CANDIDATE lead only, since this list carries no date of birth to tell same-named providers apart. A name that matches only the OWNERSHIP field (not the excluded entity) comes back as ownership_only_match with excluded:false — NC Medicaid's own note says an owner/principal name is NOT itself excluded unless separately listed. This dataset is a CURRENT SNAPSHOT (no history of lifted exclusions), so every match is currently_excluded:true. Pass npi or atypical_id to turn a name lead into an identification. Sourced from the NC Medicaid State Excluded Providers List, keyless.

Input Schema

NameRequiredDescriptionDefault
npiNoThe provider's 10-digit NPI, if known. An NPI match is an identification rather than a name lead — always pass it when known.
nameNoProvider or business name to screen, e.g. "Jane Doe" or "Acme Home Health LLC". Matched against the excluded entity name first, then the ownership field.
limitNoMaximum matches to return (default 10, max 50).
atypical_idNoNC Medicaid's non-NPI "atypical" provider ID, if known (used for some providers instead of an NPI). A match is an identification.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), but the description adds material behavior the annotations cannot: NPI/atypical matches are identifications while name matches are candidate-only leads (no DOB to disambiguate), ownership-only hits return excluded:false, and the dataset is a current snapshot so every match is currently_excluded:true. That is rich, decision-relevant context.

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?

The question is front-loaded and the functional content is dense, but the eight-state sibling enumeration is padding that could be compressed to a single clause. Roughly a third of the text is enumeration rather than instruction, so it is informative but not tight.

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, yet the description explains the return semantics anyway: excluded:true/currently_excluded:true for matches and the special ownership_only_match shape with excluded:false. Combined with the sourcing note (keyless, NC DHB Office of Compliance), an agent has everything needed to call and interpret results.

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%, so the baseline is 3. The description still adds meaning beyond the schema by ranking the identifiers (npi/atypical_id are exact provider-specific identifiers; name is matched against the excluded-entity field first, then the ownership field) and by stating the name-vs-NPI lead semantics that the schema only alludes to.

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 (screen) and resource (NC Medicaid State Excluded Providers List) and immediately frames the question it answers. It explicitly differentiates itself from the federal LEIE and names its sibling state packs (ny_omig, ca_medical, tx_medical, etc.), so an agent can route 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 Guidelines5/5

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

Gives concrete use cases (is-this-provider-excluded questions and pre-payment/credentialing screening for NC Medicaid) plus an explicit call strategy: pass npi or atypical_id when known to convert a name lead into an identification. Alternatives (LEIE for federal, other state packs for other states) are named so the when-not is inferable.

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.