F
licenseNot graded
qualityC
maintenanceProvides unified access to drug formulary data from US ACA marketplace health insurance plans, enabling drug search, coverage details, restriction info, and plan comparison across thousands of plans.
-
coverage-exception
Server Details
Why Medicare Part D restricts a drug, and the exception and appeal path to challenge it
If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP · MCP 2024-11-05
- URL
TDQS
A4.2/5.0
Scored across 2 tools
Disambiguation5/5
The two tools address clearly distinct Medicare Part D topics: one handles coverage restrictions, exceptions, and appeals; the other projects out-of-pocket spending against the annual cap. There is no overlap or realistic chance of selecting the wrong tool.
Naming Consistency5/5
Both tool names follow the same snake_case pattern with a medicare_ prefix and a descriptive noun phrase. Though the second tool inserts part_d as a topic modifier, the naming style is consistent and predictable.
Tool Count3/5
Two tools is on the thin side for a Medicare Part D server, but each tool covers a substantial subdomain. The count is borderline rather than excessive or severely deficient.
Completeness4/5
The coverage exception tool covers the main coverage problems and appeal paths, and the out-of-pocket cap tool addresses a major related cost question. Plan-specific clinical criteria and appeal deadlines are explicitly unavailable, which is a notable but intentional limitation rather than an accidental gap.
Available Tools
2 toolsmedicare_coverage_restriction_and_exceptionAInspect
For a drug on Medicare Part D, name the coverage problem — covered, prior authorization, step therapy, quantity limit, or not on formulary — and give the exception and appeal path with the CMS-named levels of appeal, who must submit the request, and what to ask the plan and the prescriber. Returns per-plan flag counts across plans held. Plan-specific clinical criteria and appeal deadlines are NOT held and are never inferred; they are returned in an explicit "unavailable" block rather than guessed.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| drug | Yes | Brand or generic drug name, e.g. "Humira", "adalimumab" | |
| state | No | Optional 2-letter US state code, e.g. "TX" |
TDQS
A4.1/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explicitly discloses that plan-specific clinical criteria and appeal deadlines are NOT held and are never inferred, and that they are returned in an explicit 'unavailable' block rather than guessed. It also discloses it returns per-plan flag counts across held plans, setting accurate expectations about output and limitations.
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?
Description is moderately long but information-dense, front-loading the primary purpose and specific outputs. The limitations clause is essential and placed at the end. No wasted words, though it could be tightened for brevity.
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 no output schema and no annotations, the description covers the tool's main function, return type (per-plan counts, unavailable block), and key limitations. It lacks explicit response format but adequately equips an agent to invoke the tool for coverage-restriction/appeal queries.
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 description coverage is 100% (both parameters documented). The description adds contextual framing (e.g., drug and state for Medicare Part D plans) but does not provide extra semantics beyond the schema. Baseline 3 is appropriate for high schema coverage.
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 exactly what the tool does: names the coverage problem for a Part D drug (covered, prior authorization, step therapy, quantity limit, or not on formulary) and provides the exception/appeal path with CMS levels, requester, and questions for plan and prescriber. The explicit list of coverage problems and appeal elements clearly differentiates it from the sibling out-of-pocket cap tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Does not explicitly mention when to use this vs. the sibling medicare_part_d_out_of_pocket_cap. However, the description clearly implies it is for coverage restrictions and exceptions, not cost caps, so usage can be inferred. Lacks explicit when-not or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
medicare_part_d_out_of_pocket_capAInspect
Project month-by-month Medicare Part D out-of-pocket spending against the statutory annual cap, identify the month the cap is reached, quantify what the cap itself saves, and compare normal payment timing against the Medicare Prescription Payment Plan — which spreads the SAME total across the year without reducing it. Supports plan years 2026 and 2027 and fails closed to 2026 for any unsupported year rather than extrapolating. This is a standard-benefit simulation, NOT a plan-specific pharmacy quote: plan negotiated prices and plan cost sharing are not held and are never inferred.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| drug | No | Optional drug name — checks formulary status and whether spending on it counts toward the cap | |
| join | No | Optional month (1-12) the payment plan would be joined | |
| year | No | Optional plan year: 2026 or 2027 | |
| monthly | Yes | Expected monthly out-of-pocket spend on covered drugs, in USD, e.g. "300" | |
| deductible | No | Optional plan drug deductible in USD, e.g. "615" or "0" |
TDQS
A4.4/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description carries the full disclosure burden and meets it: it reveals fallback behavior (fails closed to 2026 for unsupported years, never extrapolates), clarifies a likely misconception (the MPPP spreads the SAME total without reducing it), and discloses the simulation's hard limits (plan prices and cost sharing are not held or inferred). These are exactly the behavioral traits an agent needs before invoking a financial simulation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with every one earning its place: the computation summary, the year-scope/fallback rule, and the limitation disclaimer. The core functions are front-loaded in the first sentence, and there is no filler or repetition of schema content.
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?
For a five-parameter simulation with no output schema and no annotations, the description covers scope, supported years, fallback, limitations, and every output facet (projection, cap month, savings, MPPP comparison). The only real gap is return format — an agent knows what will be computed but not the shape of the result — which prevents a 5.
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 description coverage is 100%, so every parameter is already documented in the input schema; baseline 3 applies. The description adds only modest param-level context — 'standard-benefit simulation' frames what monthly represents, and the fail-closed statement clarifies behavior for unsupported year values — but this is mostly behavioral rather than semantic. It doesn't materially change how any parameter should be filled in.
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 opens with specific verbs and resourcs: projects month-by-month Part D out-of-pocket spend against the statutory annual cap, identifies the cap-reach month, quantifies cap savings, and compares payment timing against the Medicare Prescription Payment Plan. It goes well beyond the tool name by defining the exact computation scope and by explicitly bounding what it is not (a plan-specific pharmacy quote).
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 when-to-use context is clear — any need for a standard-benefit cap projection or an MPPP timing comparison. It also states an explicit exclusion, 'NOT a plan-specific pharmacy quote,' which tells an agent to avoid it when negotiated prices or plan cost sharing are at play. It doesn't name alternative tools, but with no siblings that exclusion is the best available guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
- First observed
medicare_coverage_restriction_and_exception - First observed
medicare_part_d_out_of_pocket_cap
Related MCP Connectors
Medicare Part D out-of-pocket cap: when you hit it, and what the payment plan changes
11US drug price benchmarks — what a pharmacy PAYS and what Medicare PAYS OUT.
Medicare coverage and fee-schedule amounts for CPT/HCPCS codes against a diagnosis
11Drug patent expiries ranked by the Medicare Part D spending exposed to them
11
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceEnables MCP-integrated prescription review with incomplete laboratory evidence, using deterministic rules and language-model guardrails to enforce approval authority boundaries.MIT
- AlicenseNot gradedqualityCmaintenanceUnifies five public US-government drug datasets into a single sourced page per GLP-1/cardiometabolic drug, providing cost, shortage, label, and alternatives. The MCP server exposes the same Drug contract as the UI for agent-native access.39,959,180 npmApache 2.0
- AlicenseNot gradedqualityBmaintenanceEnables searching and retrieving Medicare coverage policies including National and Local Coverage Determinations, National Coverage Analyses, and recent CMS coverage changes.4 npmMIT
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.