Free US drug-price benchmarks from federal data (CMS NADAC): a benchmark, not a price anyone owes.
Scored across 1 tool
With only one tool, there is no possibility of confusion between tools. The single tool's purpose is clearly stated and unambiguous.
The lone tool name 'drug_price' is clear and follows a consistent snake_case convention. With only one tool, there is no inconsistency to evaluate.
A single lookup tool is appropriate for a narrow domain like drug price benchmarking, but the tool is heavily overloaded with many result branches. It slightly under the typical 3-15 range but remains reasonable.
The tool covers a full lookup lifecycle: match, candidates, no_match, with provenance, generic equivalents, Medicare prices, biosimilars, and freshness metadata. No obvious gaps for the stated purpose.
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, with close drug names in did_you_mean where any exist; this does not mean the drug lacks a fair price, since NADAC covers only drugs with enough pharmacy survey data. 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, and then statement says so in plain words. stale is false for mfp, whose updates are irregular. 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 cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), yet the description adds substantial context beyond them: the freshness/stale model with per-source cadence and thresholds, the caveat that NADAC only covers drugs with sufficient survey data, and the honesty/provenance notes. Much of this is genuinely useful behavioral disclosure an agent could not infer from the annotations alone.
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 opening is front-loaded and on-point, and most sentences convey real, non-redundant detail about output fields. However it is one dense, run-on paragraph with nested clauses that is hard to parse — structure and scannability suffer even though little of the content is truly wasted.
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 must describe the return shape, and it does so thoroughly across the match, candidates and no_match branches plus the shared freshness block. It is essentially complete for an agent to call and interpret results; only minor edge cases (e.g., error handling) are left unstated.
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 there is a single optional-strength/form parameter, so the schema already carries the input semantics and the baseline is 3. The description confirms the input shape ('a drug name with optional strength and form') and adds matching behavior, but nothing 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 opening sentence states a specific verb and resource: it looks up what US pharmacies pay (NADAC), a fair cash-price range, FDA generic equivalents, and Medicare negotiated prices. The three result_type branches (match, candidates, no_match) further pin down the tool's scope. With no siblings to distinguish from, this is as clear as a purpose statement gets.
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?
There are no sibling tools, so no alternative to route against, but the description still never states plainly when to reach for this tool. It gives adjacent guidance — that adding strength or form narrows a candidate list, and that a no_match does not imply the drug lacks a fair price — which is implied usage rather than explicit when/when-not guidance.
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 Rx prices by pharmacy near you + free discount card; foreign-brand equivalents; 12 languages
US healthcare data for AI agents: prices, Medicare Advantage, Medicaid, providers, drugs. Receipted.
Add one secure layer between your agents and this server.