Skip to main content
Glama

Tx Medical Exclusions

by io.github.pipeworx-io
OverviewDiscussionsAdmin

Tx Medical Exclusion Coverage

tx_medical_exclusion_coverage
Read-onlyIdempotent

What the Texas HHSC OIG Medicaid Provider Exclusions data covers and how current it is: total exclusions ever recorded, how many are currently excluded vs. reinstated, how many carry an NPI or license number, how many distinct occupations appear, the oldest and newest exclusion dates, and when this pack's copy was captured. Use to check the screening data is fresh enough to rely on before a compliance decision, and to see the one-line notes on the free-text reason field and the ever-vs-currently-excluded distinction. Pass year (e.g. 2025) or start_date/end_date to instead COUNT how many exclusions have an effective date in that year or range, counted over the whole 13,000+ row list, not a page — answers "how many Texas HHSC OIG exclusions took effect in 2025". The response names the date field counted (excluded_since / HHSC's StartDate — never added_date, which answers a different question and gives a different number). Sourced from the Texas HHSC OIG Exclusions Database File, keyless.

Input Schema

NameRequiredDescriptionDefault
yearNoCount records whose date field falls in this calendar year (e.g. 2025), counted over the WHOLE list, not a page. Ignored if start_date/end_date are given.
end_dateNoInclusive range end, YYYY-MM-DD. Use with start_date for a custom date range instead of a calendar year.
start_dateNoInclusive range start, YYYY-MM-DD. Use with end_date for a custom date range instead of a calendar year.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the annotations, it discloses key operational traits: the data is keyless, counts are over the whole 13,000+ row list rather than a page, and the response names the exact date field counted (`excluded_since` / HHSC's `StartDate`) while warning that `added_date` answers a different question. This adds meaningful context beyond `readOnlyHint`/`openWorldHint`.

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 dense and front-loads the coverage overview before explaining the counting mode and date-field caveat. It is longer than necessary in places, but most sentences carry useful information.

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?

For a read-only coverage/count tool with no output schema, it explains the key metrics returned, freshness context, source system, and date-field semantics. An agent has enough information to invoke and interpret the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is already 100%, the description adds semantic meaning not fully captured there: `year` and `start_date`/`end_date` switch the tool into whole-dataset counting mode, and it specifies which date field is counted. It also clarifies the important distinction between `excluded_since`/`StartDate` and `added_date`.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that this tool reports coverage/freshness metadata and can count exclusions by date, which is specific enough to distinguish it from a provider-level exclusion check in practice. It does not explicitly name the sibling tool `tx_medical_check_exclusion`, so sibling differentiation is implied rather than stated.

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 gives clear usage contexts: checking whether the screening data is fresh enough before a compliance decision, and counting exclusions by year or date range. It does not explicitly say when not to use it or name the sibling tool for checking a specific provider.

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

All Tx Medical Exclusions toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources