Skip to main content
Glama

Find Drug Costs and Negotiated Prices

drug_money_drug
Read-onlyIdempotent

Look up Part D drugs in the Medicare Drug Money Register by a substring of a brand or generic name as CMS prints it, or of a negotiated drug's name as CMS lists it, optionally limited to one period the data carries (a year, YYYY, from CMS's annual file, or a preliminary period, YYYY or a quarter such as 2026Q1, from its quarterly file). Returns up to 10 brands, each with gross drug cost and claims by period, the gross cost per prescription for the preliminary periods (computed by the register from CMS's file, labelled as such) and its change, beside CMS's net estimate or the stated absence of one; for a drug CMS selected for negotiation, its cycle, CMS's negotiated prices by effective date from CMS's file, the discount from list price CMS's fact sheet prints, any deselection and the register's flag where the claims sit outside CMS's band; any White House sheet that names the drug (its direct-purchase prices are never shown); and the labelers rolled up to a parent that carry the brand, as CMS prints them, with the parent and the reviewed table's reason. Co-marketed drugs stay under the labeler CMS prints, and cost is never split or reassigned. Labelers are named as CMS prints them; a parent company comes only from the register's published, reviewed table, with the reason for each mapping. Each figure is named in its record's own words: "gross drug cost" (CMS), CMS's negotiated prices ("negotiated prices, which the statute refers to as maximum fair prices"), "announced an agreement" (the White House), "ad valorem duty rate" (the proclamation) and CMS's "estimated savings". Gross is never net: gross drug cost is before manufacturers' rebates, which CMS may not publish, so a lower gross cost per prescription is never called a saving; CMS's own net estimate is shown beside every claims-based price figure, or the answer says that CMS gives none. Annual years come from CMS's annual file; the later periods come from its preliminary quarterly file, are labelled preliminary and are never put in one series with the annual years. Every answer carries the register's question note: these records show Medicare's gross drug costs as CMS reports them, CMS's negotiated prices and estimates, and the government's announcements and proclamations; they do not show rebates paid, what any company agreed to beyond the published texts, or why any price or agreement was set. Every answer also carries the side-by-side caption, the as-of date, each file's date, the source page on morvs.ai and the data's licence. Institutions only: no prescriber, physician, official, signer or member of Congress is named; labeler strings that read as a person's name are withheld and appear only as counts. A name that matches only a withheld string answers exactly like a name that matches nothing. No party label is given.

Input Schema

NameRequiredDescriptionDefault
nameYesRequired case-insensitive substring of a Part D brand or generic name as CMS prints it, or a negotiated drug, for example Eliquis; at most 80 characters.
periodNoOptional period the data carries: a year (YYYY) from the CMS annual file, or YYYY or YYYYQn (e.g. 2026Q1) from its preliminary file; all when omitted.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.8/5.0
Behavior5/5

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

Beyond the annotations, the description discloses important behavior: it returns up to 10 brands, labels preliminary periods separately, never combines annual and quarterly periods, avoids treating gross cost as net savings, withholds labeler strings that read as person names, and says a withheld-only match answers like no match. These are substantive behavioral and data-limitation disclosures that an agent would not get from the annotations or schema alone.

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

Conciseness2/5

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

The purpose is front-loaded in the first sentence, but the description is a very long, dense paragraph with heavy repetition of CMS sourcing, naming conventions, and caveats. For a two-parameter lookup tool, much of the text is over-specified and hard to scan.

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?

Given the high domain complexity and the absence of an output schema, the description is contextually complete: it describes returned fields, gross-versus-net caveats, preliminary-period labeling, negotiated-price reporting, withholding rules, and answer metadata such as the question note and as-of date. An agent has enough information to understand what a correct answer should and should not contain.

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?

The schema already documents both parameters with 100% description coverage, including the name substring and period pattern. The description elaborates on the same semantics, such as annual versus preliminary periods, but adds little parameter-level meaning beyond the schema itself.

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 opens with a specific verb and resource: "Look up Part D drugs in the Medicare Drug Money Register by a substring of a brand or generic name... optionally limited to one period." This makes the tool's core purpose clear, but it does not explicitly differentiate itself from nearby siblings such as drug_money_company, drug_money_agreements, drug_money_summary, or drug_label.

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?

The description implies when the tool is appropriate by specifying lookup by name substring and optional period, but it never states when to choose this tool over sibling tools. There are no explicit exclusions or alternative-tool routing instructions.

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.