Skip to main content
Glama

Which Medicare Part D plans in this county cover this drug, at what tier and cost? Every PDP and Medicare Advantage drug plan with tier, prior authorization, step therapy, quantity limit, premium and copay, plan years 2026 and 2027, computed by Distill from CMS’s monthly formulary files

medicare_partd_coverage
Read-only

Which Medicare Part D plans in this county cover this drug, at what tier and cost? Every PDP and Medicare Advantage drug plan with tier, prior authorization, step therapy, quantity limit, premium and copay, plan years 2026 and 2027, computed by Distill from CMS’s monthly formulary files. From CMS’s monthly Part D formulary public use file: every stand-alone (PDP) and Medicare Advantage drug plan sold in the county (by SSA county code, or state and county name), whether its formulary covers the drug (RxCUI, or the NDC the file lists), and on what terms: tier, prior authorization, step therapy, quantity limit, negotiated-drug flag, the plan’s premium and deductible, and the 30-day initial-coverage cost sharing for that tier at each pharmacy type. Covering plans come lowest tier first, then lowest premium. Pass plan_year=2027 for open enrollment. Employer and PACE plans are not in the file. Refreshed monthly (live freshness: /status). Price: $0.02 per call. Free tier: 3 free calls a day per IP, at most 3 rows per answer, taken by an unpaid call unless its _meta["distill/free-tier"] is "skip". Answers in a summary view of about 3,000 tokens; view: "full" for every row. Confidence: Freshness only (the plans and terms are read from the CMS file deterministically): 1 until 45 days after the served file’s date (CMS posts one a month), then halving every 30 days. Medicare Part D formulary and plan data as of the CMS public use file’s date (file_date), processed by Distill; the Medicare Plan Finder (medicare.gov/plan-compare) may have newer information. Not enrollment, coverage or medical advice; confirm with the plan. See /terms.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "medicare_partd_coverage"
  }
}

Input Schema

NameRequiredDescriptionDefault
ndcNoAn 11-digit NDC as the formulary file lists it (one per RxCUI); prefer rxcui.
kindNopdp, ma or all (default).
viewNosummary (the default): the answer a model needs, budgeted; full: every row (a free answer stays capped).
limitNoAt most this many plans (default 20).
rxcuiNoThe drug’s RxNorm concept id (RxCUI), e.g. 617311 for atorvastatin 40 mg oral tablet.
stateNoTwo-letter state code, with county.
countyNoCounty name, with state, e.g. Denver.
plan_yearNoThe plan (benefit) year, e.g. 2027 for open enrollment (default: the current year).
county_codeNoThe SSA state-county code, e.g. 06150 (Denver, CO).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / view
      Added value: +{
      +  "description": "summary (the default): the answer a model needs, budgeted; full: every row (a free answer stays capped).",
      +  "enum": [
      +    "summary",
      +    "full"
      +  ],
      +  "type": "string"
      +}
  2. Added

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the readOnlyHint/openWorldHint annotations, it discloses pricing ($0.02 per call), a free-tier quota with row caps and an unpaid-call rule, monthly refresh cadence with a /status freshness endpoint, a confidence-decay model tied to the CMS file date, output ordering (lowest tier, then lowest premium), and an explicit disclaimer that Plan Finder may be newer. That is unusually complete behavioral disclosure for a read-only tool.

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 key question is front-loaded, which is right, but the first two sentences restate the title almost verbatim, and pricing, free-tier mechanics, confidence decay and legal boilerplate are packed into one dense block. The information is useful but the definition is longer than it needs to be and would benefit from tighter structure.

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 9-parameter, no-output-schema tool, the description covers what is returned (tier, PA, step therapy, quantity limit, negotiated-drug flag, premium, deductible, 30-day cost sharing by pharmacy type), how results are ordered, the summary-vs-full answer sizing, and the data-freshness caveats. An agent has everything needed to call it correctly and interpret the response.

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, but the description adds cross-parameter meaning the schema cannot: the two alternative geography paths (SSA county code vs. state plus county name), the rxcui-preferred / NDC-as-listed relationship, and the plan_year default and open-enrollment intent. The view and limit parameters are explained mainly through output-budget behavior rather than input semantics.

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 opening sentence states a precise question — which PDP/MA-PD plans in a given county cover a given drug, at what tier and cost — with a concrete verb/resource pair and enumerated outputs (tier, prior auth, step therapy, quantity limit, premium, copay). It also names the data source and years, so an agent can immediately distinguish it from formulary-adjacent siblings like drug_nadac or medicare_pfs_rate.

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 actionable usage context: pass plan_year=2027 for open enrollment, prefer rxcui over ndc, supply either county_code or state+county, and use view="full" when every row is needed. It also states a scope exclusion (employer and PACE plans are not in the file). It does not explicitly compare against the sibling tools, which keeps it from a 5.

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