Live Rx cash prices at nearby pharmacies in 8 US states + the free LowerScript card. Not insurance.
Scored across 3 tools
Each tool has a clearly distinct purpose: find_drug resolves drug names without pricing, get_card returns static discount card info, and get_prices provides live cash prices. The descriptions explicitly reinforce boundaries (e.g., find_drug says 'use get_prices for a price').
All names follow a snake_case verb_noun pattern, but the verb varies ('find' vs 'get'). This is a minor deviation that remains readable and predictable enough.
Three tools are well-scoped for a prescription discount service: one to resolve drugs, one for static card details, and one for live prices. Each earns its place without redundancy.
The core workflow (resolve drug, get card info, fetch prices) is fully covered. Minor gaps exist, such as no dedicated tool for listing supported states or pharmacies, but these are handled inline by existing tools or descriptions.
Use this when someone asks about buying prescription medicine from Canada, Canadian pharmacy prices versus U.S. prices, or what the October 22, 2026 change (the end of the "de minimis" shipping exemption) means for a Canadian mail-order refill. Give 1 to 5 medicine names (brand or generic, English or Spanish, any capitalization) from LowerScript's list of medicines people buy from Canada plus the caller's 5-digit ZIP in a state LowerScript serves (FL, TX, AZ, NC, SC, GA, IL, CA). For each medicine it returns the Canadian last-listed price exactly as captured (price, pack, strength, origin, source pharmacy, capture date; shipping not included), today's lowest LowerScript cash price near the ZIP for the brand and the generic when the exact same strength and quantity is priced (pharmacy and as-of date), a verdict (lower_here, lower_canada, same, compare_packs or no_price) computed only on exact matches and never scaled across strengths or packs, whether the medicine is on the Medicare-negotiated list, and links to the state's Canada page, the medicine's brand page (Florida example) and the price check. Names not on the list come back in not_found with a pointer to the price check. One internal price lookup per call. Cost information only: it refuses clinical questions (dose, safety, interactions, starting or stopping a medicine). LowerScript is a prescription discount program, not insurance.
| Name | Required | Description | Default |
|---|---|---|---|
| zip | Yes | 5-digit US ZIP code in FL, TX, AZ, NC, SC, GA, IL or CA. Used to find today's LowerScript prices nearby and to link the right state page. | |
| lang | No | Response language. Defaults to English. | |
| drugs | Yes | 1 to 5 medicine names, brand or generic (e.g. "Eliquis", "apixaban", "Januvia"). Matching is case- and accent-insensitive against the Canada comparison list. |
Resolve free-text drug wording (brand or generic, English or Spanish) to the canonical LowerScript/RxSense drug: its known dosage forms, strengths, and a typical fill quantity. Cost/availability lookup only — never a substitute drug, never a dose recommendation, never priced (use get_prices for a price). Returns a "try another name" message when nothing matches.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Drug name in English or Spanish, brand or generic (e.g. "metformin", "Ozempic", "amoxicilina"). | |
| language | No | Response language. Defaults to English. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behaviorais. The description adds valuable behavioral context beyond these: it returns a 'try another name' message on no match, resolves only to canonical drug data, and clarifies it is cost/availability lookup only. There is no contradiction with 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 description is compact and front-loaded: the main action and output are in the first sentence, followed by exclusions and the alternative tool, then the failure-mode message. Every sentence earns its place with no filler or repetition of the schema.
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 adequately conveys what the tool returns: canonical drug data including dosage forms, strengths, and fill quantity, plus a fallback 'try another name' message. It also covers the key limitation (no pricing) and routes to get_prices, so an agent has enough context to invoke the tool correctly without missing critical behavior.
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%, so the query and language parameters are already fully documented in the input schema. The description does not add much parameter-specific detail beyond stating the tool handles brands/generics and English/Spanish, which the schema also covers. This meets the baseline for fully documented schema parameters.
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 names a specific verb ('Resolve') and resource ('free-text drug wording' to 'canonical LowerScript/RxSense drug'), and enumerates what the resolution yields: dosage forms, strengths, and typical fill quantity. It also explicitly differentiates itself from get_prices by stating it is 'never priced' and directs the agent there for pricing.
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?
The description gives clear when-to-use context: resolving brand/generic drug wording in English or Spanish. It also provides explicit exclusions — 'never a substitute drug, never a dose recommendation' — and names the alternative tool get_prices for price lookups, making the routing decision unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The static LowerScript discount card: RxBIN/RxPCN/RxGRP codes, how to use it at the pharmacy counter, wallet-pass and card-page links, member support, and the exact compliance wording (not insurance, up to 80%). No lookup involved — always the same answer for a given language.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Card language / RxGRP network. Defaults to English. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds real value beyond that: it is "static," involves "no lookup," and is deterministic ("always the same answer for a given language"), reinforcing the idempotent hint with concrete behavior.
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?
It is a single front-loaded sentence led by the resource, with the determinism caveat closing it out. Dense but every clause maps to a distinct piece of returned content, with little waste.
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 burden of describing returns and does so thoroughly: codes, usage instructions, links, support, and exact compliance wording. Combined with rich annotations and a single optional parameter, nothing an agent needs to call it correctly is missing.
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%, so the language enum and English default are already documented in the schema. The description only gestures at language via "for a given language"/RxGRP and adds no syntax beyond the schema, so baseline 3 is appropriate.
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 names a specific resource and enumerates its contents (RxBIN/RxPCN/RxGRP codes, pharmacy-counter instructions, wallet-pass/card-page links, member support, compliance wording), so an agent knows exactly what it gets back. It also marks this as a static card distinct from lookups, separating it from find_drug and get_prices.
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?
"No lookup involved — always the same answer for a given language" tells the agent this is a deterministic static fetch needing no user-specific input, which is clear usage context. It stops short of explicit when-to-use/when-not routing, but the sibling tools (find_drug, get_prices) are functionally distinct, so alternatives are not really in play.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live cash prices for one drug at nearby pharmacies (up to 10, cheapest first, full spread shown — not just the lowest), using the LowerScript discount network (RxSense). Carries the LowerScript card codes, a wallet-pass link, and the lowerscript.com page for the same answer. One drug per call — no bulk lookups. Requires a 5-digit US ZIP in a state LowerScript currently serves (FL, TX, AZ, NC, SC, GA, IL, CA); city/state alone is not yet supported. Cost and pharmacy information only — refuses any clinical question (dose, safety, interactions, pregnancy, starting or stopping a medicine) with no price.
| Name | Required | Description | Default |
|---|---|---|---|
| zip | Yes | 5-digit US ZIP code. Required for a price — city/state alone cannot be geocoded by this tool yet. | |
| city | No | Optional city name, for context only. Does not replace zip — a price lookup still needs a 5-digit ZIP. | |
| drug | Yes | Drug name, English or Spanish, brand or generic. | |
| form | No | Optional dosage form, e.g. "tablet", "capsule", "pen", "inhaler". | |
| state | No | Optional 2-letter US state, for context only. Does not replace zip. | |
| language | No | Response language. Defaults to English. | |
| quantity | No | Optional fill quantity. Defaults to a typical fill size for the drug's own form (e.g. 30 tablets; 1 pen/inhaler). | |
| strength | No | Optional strength, e.g. "500 mg". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds real context beyond the annotations: it discloses the upstream network (LowerScript/RxSense), that results include card codes, a wallet-pass link and a lowerscript.com page, that the full price spread is shown rather than just the cheapest, and that it hard-refuses clinical questions. Safety profile is already covered by readOnlyHint/idempotentHint, so remaining gaps like auth or rate limits are minor.
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?
Three dense, front-loaded sentences that each carry information; the cheapest-first/not-just-lowest behavior and the state list are the kind of detail an agent needs. Slightly long, but no sentence is 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 does the work of explaining the return payload (prices spread, card codes, wallet link, web page) and the hard prerequisites (valid served-state ZIP). An agent has everything needed to call it correctly and to know when it will refuse.
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 coverage is 100%, so the baseline is 3, but the description usefully enumerates the eight served states (FL, TX, AZ, NC, SC, GA, IL, CA) — a constraint not present in the schema — and reinforces the ZIP-over-city/state rule. It adds genuine meaning beyond the schema.
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?
States a specific verb+resource (live cash prices for one drug at nearby pharmacies) plus scope detail (up to 10, cheapest first, full spread). An agent can immediately distinguish this from find_drug (name resolution) and get_card (card retrieval).
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?
Gives explicit constraints: one drug per call, no bulk lookups, requires a 5-digit ZIP in a served state, city/state alone unsupported, and refuses clinical questions. It does not explicitly point to find_drug for resolving an unknown drug name, which is the one routing gap.
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.
compare_canadafind_drugget_cardget_pricesUS Rx prices by pharmacy near you + free discount card; foreign-brand equivalents; 12 languages
Free US drug-price benchmarks from federal data (CMS NADAC): a benchmark, not a price anyone owes.
US drug price benchmarks — what a pharmacy PAYS and what Medicare PAYS OUT.
Search US hospital prices, compare costs, and find insurance-negotiated rates.
Add one secure layer between your agents and this server.
