Skip to main content
Glama
Sign In

Distill

by com.spencermcw.data
OverviewDiscussionsAdmin

Which NDCs match this drug name, and what do pharmacies pay for them? NADAC search by name (e.g. “atorvastatin 40”) with NDC counts and current per-unit cost ranges, from CMS’s weekly NADAC file

drug_nadac_search
Read-only

Which NDCs match this drug name, and what do pharmacies pay for them? NADAC search by name (e.g. “atorvastatin 40”) with NDC counts and current per-unit cost ranges, from CMS’s weekly NADAC file. Matches the words of a name (each as a prefix, e.g. "atorvastatin 40") against the NDC descriptions in the latest weekly NADAC file, best match first, and gives each description’s pricing unit, classification, number of NDCs, current per-unit NADAC range and up to five NDCs to look up with drug.nadac. Refreshed weekly (live freshness: /status). Price: $0.01 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 values are CMS’s, read deterministically): 1 until 9 days after the latest weekly file’s as-of date, then halving every 14 days. National Average Drug Acquisition Cost as CMS publishes it weekly: a survey average of what retail pharmacies pay per unit, not a retail price, a reimbursement rate, a quote or medical advice. See /terms.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

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

Input Schema

NameRequiredDescriptionDefault
nameYesDrug name words, e.g. "atorvastatin 40" or "insulin glargine".
viewNosummary (the default): the answer a model needs, budgeted; full: every row (a free answer stays capped).
limitNoAt most this many descriptions (default 10).

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?

Annotations only say readOnly and closed-world; the description adds substantive behavior: each name word is matched as a prefix, results are best-match-first, each row carries pricing unit, classification, NDC count, current range and up to five NDCs, and the file refreshes weekly. It also discloses cost ($0.01/call), the free-tier mechanics (3 calls/day per IP, 3-row cap, consumed unless _meta "distill/free-tier" is "skip"), the ~3,000-token summary budget, and a concrete confidence-decay rule.

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 leading sentence duplicates the title verbatim, so the opening is repetition rather than added signal, and the body is a dense run-on mixing matching semantics, output shape, pricing, quota rules, token budgets and legal disclaimers. All of that content is useful, but it is not front-loaded or separated into scannable units.

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 read-only search with no output schema, the definition covers everything an agent needs: how matching works, what each row contains, a token-budget estimate, freshness and confidence decay, quota and cost, and an explicit disclaimer that NADAC is a survey acquisition cost, not a retail price or reimbursement rate. Nothing material is left implicit.

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 baseline would be 3, but the description adds real meaning beyond the schema: it explains that "name" is tokenized and each word matched as a prefix with best match first, which the schema does not say, and it clarifies that view:"full" can still be row-capped on a free answer.

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?

States a specific verb and resource ("NADAC search by name", matched against "NDC descriptions in the latest weekly NADAC file") and immediately distinguishes itself from the sibling drug.nadac, which is described as the NDC-level lookup for the five sample NDCs returned. An agent can pick between the two without opening either schema.

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 clearly frames the use case (you have a drug name, you want matching NDCs and per-unit cost ranges) and hands off to drug.nadac for follow-up lookups, plus gives an example query. What is missing is an explicit when-not-to-use, i.e. what to do when the caller already holds an NDC — that is only implied by the sibling pointer.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Distill toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources