Free US drug-price benchmarks from federal data (CMS NADAC): a benchmark, not a price anyone owes.
Scored across 1 tool
There is only one tool, so there is no possibility of misselection or overlapping purpose. Its scope (a single drug-price lookup returning match, candidates, or no_match) is clearly self-contained.
The lone name `drug_price` is clean snake_case and unambiguous, but it is a noun-only label rather than the verb_noun convention, and a single tool cannot demonstrate a consistent pattern across the set.
One tool is defensible here because the whole domain is a single lookup that folds generics, biosimilars, Medicare prices, and provenance into one response. It is still on the thin side—there is no separate way to browse, batch, or resolve candidates beyond re-querying.
The surface covers the lookup lifecycle well: exact match, multi-candidate disambiguation with total counts, no-match with did_you_mean fallbacks, and per-source freshness/staleness metadata. Minor gaps remain (no batch lookup, no reverse ingredient-to-drug listing, no way to enumerate the index).
Looks up what US pharmacies actually pay to acquire a drug (the CMS NADAC benchmark, per unit, with its date), a fair cash-price estimate range, FDA generic equivalents, and Medicare negotiated prices where they apply. The input is a drug name with optional strength and form. result_type is one of three values. match: one drug, with prices, provenance and honesty notes; a brand-name drug with no generic alternatives listed also carries generic_equivalence, a dated statement of what the FDA Orange Book shows for it. A brand-name match can also carry cms_generic_price, CMS's NADAC figure for the corresponding generic drug, with its effective date, a fair cash estimate where a fill quantity applies, and the generic's name when exactly one generic in the index has that price, strength and ingredient. A biologic that the FDA Purple Book lists biosimilars to also carries biosimilars (each with proprietary and proper names, interchangeable, marketing_status, file_month, and a NADAC price where one is indexed) and biosimilars_statement; a biosimilar carries reference_product, with the same kinds of fields and a statement. candidates: the query fits several drugs. Up to 12 are listed (generic drugs first, then alphabetical), each with its description and price hint. candidates_total gives how many drugs matched; when that is more than 12, message says the list was cut, and adding a strength or form narrows it. A query equal to one candidate's description returns that drug as a match. no_match: the index has no drug matching the query; this does not mean the drug lacks a fair price, since NADAC covers only drugs with enough pharmacy survey data. did_you_mean, where present, lists drug names to search next, and did_you_mean_basis gives the reason: spelling (names spelled like the query; for a trade name that is its only active ingredient plus more words, such as theophylline-sr, that ingredient) or same_ingredient (the index has no drug under the ingredient name in the query, and the names are priced brands whose only active ingredient in the FDA Orange Book is that ingredient; store brands of the ingredient may still be priced under their own names). Names that differ from the query by a letter or two appear only when the query is not recognized in the loaded FDA Orange Book or Purple Book names. These catalogs omit some drug names; a spelling hint is a search aid, not an equivalent medicine. Every result also carries freshness, one entry per source (nadac, orangebook, mfp, purplebook) giving as_of, the publisher's date on the file in use (for purplebook, which FDA dates by month, the first day of that month); checked, the date of our newest successful fetch of that source; expected, the publishing cadence (weekly, monthly or irregular); and stale, which is true when the NADAC file is more than 10 days old, the Orange Book file more than 45 days old or the month of the Purple Book file ended more than 60 days ago, or when our newest attempt to fetch that source failed (last_attempt_failed then gives that attempt's date, and the file in use is the newest good one we hold), and then statement says so in plain words. For mfp, whose updates are irregular, stale is true only after a failed fetch. A source we have not fetched yet has no as_of or checked.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Drug name with optional strength/form, e.g. "atorvastatin 20 mg" or "eliquis 5 mg tablet". Generic (ingredient) names match best. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, and closed-world behavior, but the description adds extensive behavioral context beyond them: the three result types, conditional fields for brand/generic/biologic/biosimilar matches, did_you_mean bases, and detailed freshness/staleness rules per source. No statement contradicts the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded, and the extensive return-value detail is partly justified because no output schema exists. However, the description is a single extremely dense paragraph that runs to hundreds of words, making it hard to scan and more verbose than necessary for a one-parameter lookup.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the full burden of explaining returned fields, result variants, conditional enrichment, candidate counts, did_you_mean behavior, and freshness/staleness semantics across all sources. It is complete enough for an agent to interpret the tool's behavior and likely outputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents the single query parameter with examples and the generic-name matching hint. The description repeats that the input is a drug name with optional strength and form but adds no parameter-level syntax, constraints, or formatting beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (looks up), a precise resource (US pharmacies' acquisition prices / fair cash price), and enumerates the concrete data returned (CMS NADAC benchmark, cash-price estimate range, FDA generic equivalents, Medicare negotiated prices). An agent can tell exactly what this tool does without needing sibling comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly specifies the required input shape (drug name with optional strength and form), advises that generic ingredient names match best, and explains that adding strength or form narrows candidate results. It does not name alternatives or when-not-to-use cases, but no sibling tools exist and the invocation guidance is otherwise direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
drug_priceLive US drug acquisition costs (CMS NADAC) for AI assistants. Free, no auth, weekly data.
US drug price benchmarks — what a pharmacy PAYS and what Medicare PAYS OUT.
US healthcare public data, one endpoint: prices, Medicare, MA benefits, Stars, Medicaid, providers.
CMS Medicare drug price negotiation: the Maximum Fair Price (MFP) for every drug CMS has selected…
Add one secure layer between your agents and this server.