Skip to main content
Glama

Get Medicare Drug Money Totals

drug_money_summary
Read-onlyIdempotent

Totals from the Medicare Drug Money Register, built from CMS's Part D and Part B spending files, CMS's negotiated-price file and fact sheets, the Federal Register, the White House's fact sheets and annexes, and, side by side, FEC, LDA and two MORVS registers' records. Returns Medicare Part D gross drug cost for all drugs by year (annual and preliminary kept apart), the 10 largest parent companies with their shares and the cost not rolled up to any parent, by class; the share of Part D gross drug cost in the earliest preliminary year held by the companies the White House listed (computed here from CMS's file, labelled as such); the negotiated drugs' gross cost per prescription in the register's baseline and latest preliminary periods by cycle, each beside CMS's net estimate or the stated absence of one, with the drugs outside CMS's band flagged as the register flags them; Proclamation 11020's ad valorem duty rates and the zero rate for companies with pricing agreements, as printed; CMS's GLOBE estimates proposed and final, like for like, and its GUARD and GENEROUS estimates; Part B drug spending without skin substitutes, and skin-substitute totals; the counter-findings; the register's headlines with their basis; and what is excluded (pharmacy benefit managers, plan sponsors, cash prices, Medicaid by drug) and withheld (counts only). 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. The blocks (Part D gross drug cost by company, negotiated prices and the negotiated drugs' claims, the 2025-26 agreements, tariffs and CMS's payment models, Part B drug spending, and skin substitutes as totals only) are never added together. The side columns (connected-PAC money from the FEC bulk files, 2025 lobbying reports from lda.gov, the 2025 inaugural committee's report and its LD-203 cross-check, and super PAC membership) are separate records shown side by side: never added to drug cost or to each other, and never put in date sequence with an agreement, a tariff or a price. 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. Where FEC figures appear, the answer quotes the FEC's restriction on the sale or use of individual contributor information (52 U.S.C. 30111(a)(4)). 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. No party label is given.

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.6/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/openWorld, and the description goes well beyond them: gross is never net, preliminary and annual years are never merged into one series, blocks are never added together, side-columns are never summed with drug cost, and specific items are excluded or withheld. It also discloses governance behaviour (question note, as-of dates, licence, FEC 30111(a)(4) restriction) and the institution-only rule for labeler strings, which an agent could not learn from annotations.

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?

It is one enormous run-on block of semicolon-chained clauses; the useful front-load ('Totals from the Medicare Drug Money Register') is followed by dozens of nested caveats with no headings or paragraph breaks. Much of the content is substantive, but the packing makes it hard to scan and the core instruction is buried.

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?

With no output schema and no parameters, the description must carry the entire return-value burden, and it does so exhaustively, including exclusions, withholding, and labelling conventions. What it omits is the routing dimension (which sibling answers a narrower question) and any hint about response size or pagination, which matter for a tool aggregating this many blocks.

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?

The tool takes no parameters, so the schema carries no semantics to supplement and the baseline of 4 applies. The description instead specifies what the zero-argument call returns, which is the only meaningful 'parameter' context here.

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 opening sentence states a specific resource (the Medicare Drug Money Register) and a specific output shape (totals/aggregates), then enumerates the blocks returned, so an agent can tell this is the aggregate view rather than a per-entity lookup. It never names its obvious siblings (drug_money_company, drug_money_drug, drug_money_agreements), so the differentiation is inferred from the word 'Totals' 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 Guidelines2/5

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

The description never says when to call this instead of drug_money_company, drug_money_drug, drug_money_agreements, or media_money_summary. An agent must guess from the tool name alone that this is the overview/rollup endpoint, and there are no prerequisites, exclusions, or routing conditions given.

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.