US Rx prices by pharmacy + free discount card; also US equivalents of foreign brands, 12 languages
Scored across 10 tools
Most tools have clearly distinct responsibilities: search vs. drug details vs. price matrix vs. card vs. email vs. locations vs. foreign equivalents. Minor overlap exists because get_drug, get_savings_card, and compare_prices all return savings-card or price data, so an agent might hesitate on which to call for a simple price query. The detailed descriptions mitigate most confusion.
Nine of ten tools follow a consistent verb_noun snake_case pattern (search_drugs, get_drug, compare_prices, email_savings_card, find_nearby_pharmacies, etc.). The outlier, foreign_brands_for_drug, lacks a verb and breaks the pattern; renaming it to something like find_foreign_brands would make the set fully consistent.
Ten tools is well-scoped for a consumer prescription assistant: drug search, drug details, price comparison, savings-card retrieval/emailing, pharmacy locations, foreign-equivalent lookups, prescription options, and dataset metadata. Each tool maps to a distinct user need with no obvious redundancy.
The tool surface covers the full consumer journey from identifying a drug to comparing prices, obtaining the savings card, emailing it, finding nearby pharmacies, and understanding foreign equivalents. Prescription-sourcing guidance and dataset attribution are also included, leaving no significant dead ends for the stated domain.
Compare FineRx prices for one package (an 11-digit NDC + quantity).
Use when you know the exact package. Returns the offer matrix — for each
pharmacy chain x savings program, the observed price and the date it was
observed (observedAt) — plus ``savingsCard`` (the free discount card, its
image, and the card price for this package when known). The cheapest offer is
flagged isLowest. Get an ``ndc`` from get_drug's packages or the search flow.
Do not call a price the lowest unless the offer says isLowest, and always give
the observation date. Offer the card whenever you quote a price here.
| Name | Required | Description | Default |
|---|---|---|---|
| ndc | Yes | ||
| locale | No | en | |
| channel | No | mcp | |
| quantity | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive hints. The description adds substantial behavioral context: the offer matrix structure, observedAt dates, the savingsCard field (including when it might be missing), the isLowest flag, and explicit guidance on how to interpret and present results. This goes well beyond the annotation safety profile and gives the agent operational rules.
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 front-loaded with the core purpose, then adds usage context, return structure, and behavioral rules in a logical order. Every sentence contributes – none are redundant. It's long but dense with necessary operational guidance, and the key info (purpose, when to use) appears early. No fluff or filler.
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?
Given the tool's moderate complexity and that an output schema exists, the description is quite complete. It explains the return structure (offer matrix, savingsCard, isLowest) and provides instructions on how to use the results. The main gap is the lack of explanation for locale and channel parameters, though they have defaults and are likely non-critical. For the required parameters and the output interpretation, it's thorough.
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 0%, so the description must compensate. It does clarify the ndc format ('11-digit NDC') and the quantity, and advises where to obtain an ndc. However, it does not mention the optional locale and channel parameters, which have defaults but still remain undocumented. Since two of four parameters are unexplained, the description only partially compensates for the missing schema descriptions.
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 opens with a precise verb+resource: 'Compare FineRx prices for one package (an 11-digit NDC + quantity).' It clearly distinguishes from siblings by specifying the input condition ('Use when you know the exact package') and referencing how to obtain the NDC (from get_drug or search flow), making it unambiguous what this tool does versus alternatives.
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?
Explicitly states when to use ('Use when you know the exact package') and directs the agent to get the NDC from get_drug or the search flow, implying when not to use it. It also adds concrete rules: don't call a price lowest unless isLowest, always give the observation date, and offer the card when quoting a price – these are precise usage conditions that prevent misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Email the free FineRx discount card to an address the person gave you.
Use ONLY after the person has given an email address AND confirmed they want the
card sent there — ask for both first, then set ``consent`` to true. The message
contains the card and nothing else; FineRx does not store the address.
Returns {"sent": true, "to": <masked address>} or {"sent": false, "error": ...}.
On an error, say what happened and offer the image or the link instead.
Do not call this without an explicit yes, do not guess or reuse an address, do
not retry a refusal, and do not read the full address back to the person.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | |||
| locale | No | en | |
| consent | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by disclosing consent handling, privacy ('FineRx does not store the address'), message content ('contains the card and nothing else'), exact return shapes, and the masked address. These are behavioral details not inferable from annotations alone. The description aligns with annotations: readOnlyHint=false is consistent with sending an email, and no contradiction exists.
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?
Every sentence earns its place: purpose, consent precondition, privacy note, return contract, error fallback, and prohibitions. It is front-loaded with the main action and uses compact paragraphs without unnecessary elaboration. This is appropriately sized for a tool with meaningful side effects and safety constraints.
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?
The description is complete given the annotations and output schema presence. It covers the return contract, error behavior, consent prerequisite, privacy implications, and alternative delivery methods. The locale parameter is the only omission, but its default and optional role mean the agent can still invoke the tool correctly.
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?
With 0% schema description coverage, the description compensates well for the two key parameters: email ('address the person gave you', 'do not guess or reuse') and consent ('set consent to true' after asking). However, the locale parameter is never mentioned; its default 'en' and optionality make this a minor gap, so the score is 4 rather than 5.
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 opens with a specific verb and resource: 'Email the free FineRx discount card to an address the person gave you.' It clearly distinguishes emailing from sibling tools like get_savings_card by focusing on the delivery action and recipient. The fallback phrase 'offer the image or the link instead' further differentiates it from non-email retrieval paths.
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?
Explicit when-to-use guidance is present: 'Use ONLY after the person has given an email address AND confirmed they want the card sent there.' It also gives clear exclusions and prohibitions such as 'do not call this without an explicit yes, do not guess or reuse an address, do not retry a refusal.' Error-handling guidance tells the agent to offer the image or link instead, covering the alternative path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the nearest pharmacy locations to a US ZIP code, per chain.
``zip`` is a 5-digit US ZIP. Optional ``chains`` is a comma-separated list of
chain codes (e.g. "walgreens,publix"); default is all chains. ``limit`` caps
locations per chain. Coordinates are OpenStreetMap-sourced (ODbL).
| Name | Required | Description | Default |
|---|---|---|---|
| zip | Yes | ||
| limit | No | ||
| chains | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds useful context: coordinates are OpenStreetMap-sourced (ODbL) and limit is per chain. It does not contradict annotations, and the added data provenance is valuable beyond the structured fields.
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 three sentences with zero waste. The primary purpose is front-loaded, and parameter explanations are compact and clear. Every sentence contributes value.
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?
All required and optional parameters are explained, the output schema exists, and the description includes data source and default behavior. An agent has everything needed to call the tool correctly without additional inference.
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 0%, so the description must fully explain parameters. It does: zip is a 5-digit US ZIP, chains is a comma-separated list with default all, and limit caps locations per chain. This completely compensates for the schema gap and adds meaningful semantic detail.
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 and resource: 'Find the nearest pharmacy locations to a US ZIP code, per chain.' This clearly distinguishes it from sibling tools like search_drugs or compare_prices, which focus on drugs or pricing rather than geolocation. The purpose is unambiguous.
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 implies when to use the tool (when a user needs pharmacy locations near a ZIP) but does not explicitly mention alternatives or exclusions. It provides clear context but no guidance on when not to use it, which is a minor gap given the sibling list includes many drug-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find out what a medicine from another country is in the US, and what it costs.
Use when the person names a medicine that is not a US product — a brand from
home (No-Spa, Nurofen, Dolo-Neurobion, 999 Ganmaoling), a name in another
script (Но-шпа, 泰诺), or an ingredient the US calls something else
(paracetamol) — or asks "what is this called in the US?". Optional ``country``
picks between brands of the same name sold in different places; ``locale`` is
a language code (leave it out and the host's own locale is used).
Returns the reviewed entry: ``usClass`` (``same_inn`` = the same active
ingredient is sold here, ``rx_alternative`` = it is not and the closest US
options need a prescription, ``no_equivalent`` = nothing here matches),
``guidance`` (ONE vetted sentence, written to be quoted word for word),
``inn``, ``usGeneric``, ``usBrands``, ``rxStatus``, ``notes``, ``components``,
``usDrug`` (slug, lowest observed price and the date it was observed),
``savingsCard`` when there is a US drug to fill, ``pageUrl``, and
``otherMatches`` when the same brand name exists in more than one country.
``found`` is false when nothing matched.
Next: quote ``guidance`` as written, then say ``guidanceDisclaimer``. With a
``usDrug``, call compare_prices (or get_drug) for its slug, give the price
WITH its observation date, and offer the free card.
Do not call the US drug the same product, do not suggest swapping one for the
other, and for ``rx_alternative`` or ``no_equivalent`` do not name a
substitute at all — send the person to a pharmacist or a doctor. Do not
translate or reword ``guidance``; it is reviewed text.
| Name | Required | Description | Default |
|---|---|---|---|
| brand | Yes | ||
| locale | No | ||
| channel | No | mcp | |
| country | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only/idempotent annotations, the description discloses reviewed-text status, exact usClass meanings, disambiguation behavior for country/locale, otherMatches behavior, savingsCard availability, and found=false edge case, with no contradiction to 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 dense but front-loaded with purpose, then flows from trigger conditions to parameters, return semantics, required follow-up, and safety constraints. No sentence is filler; length is justified by the tool's medical-safety complexity.
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?
The description covers trigger cases, parameter behavior, output classes, quoted guidance handling, downstream tool calls, and what not to say, which is complete for a high-stakes lookup tool. The presence of an output schema also covers raw return shape.
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?
With schema coverage at 0%, the description compensates by explaining country (brand disambiguation), locale (language code plus host-locale fallback), and brand (through examples and the medicine-name context). Only the internal 'channel' parameter is left undocumented, which is minor due to its default.
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 opens with a specific verb-resource pair ('Find out what a medicine from another country is in the US, and what it costs') and gives concrete trigger examples, which makes the tool's scope unmistakable and distinguishes it from reverse-lookup siblings.
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 explicitly states when to use the tool ('Use when the person names a medicine that is not a US product... or asks what is this called in the US?') and provides follow-up tool routing ('call compare_prices (or get_drug)'), along with explicit do-nots for unsafe substitutions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find what a US drug is called abroad — the reverse of find_us_equivalent.
Use when the person has the US name and wants the home-country one ("what is
lisinopril called in Mexico?"), or when naming a foreign brand would let them
recognise the medicine you are describing. ``slug`` comes from search_drugs.
Returns the reviewed brands that resolve to this drug: ``brand``,
``brandScript`` (the home-country spelling), ``countries``, ``inn`` and
``usClass``.
Next: name the brands from the person's own country first. An ``rx_alternative``
entry is a DIFFERENT medicine US clinicians use for the same complaint — say
so if you mention it. Brands with no US equivalent never appear here.
Do not present any of these as interchangeable with the US drug, and do not
tell anyone to buy or import one.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the readOnlyHint/idempotentHint annotations by describing the exact result set ('reviewed brands'), listing returned fields, and stating that brands with no US equivalent never appear. It also discloses important safety behaviors: do not present these as interchangeable and do not tell anyone to buy or import one. No contradiction with 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 organized into focused, front-loaded sections: purpose and use cases first, then parameter provenance, then return fields and clinical safety guidance. There is no filler, and the added length is justified by the medical safety context.
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?
The description covers purpose, when to use the tool, how to obtain the required slug, the returned fields, and important exclusions and safety constraints. Since the output schema exists, the description does not need to restate return shapes, and nothing needed to invoke the tool 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?
The schema only defines slug as a required string with no description. The description adds crucial meaning by stating that 'slug comes from search_drugs', telling an agent exactly how to obtain the correct value. With only one parameter this is sufficient, though the description does not independently define the slug format.
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 opens with a specific verb and resource: 'Find what a US drug is called abroad' and explicitly names the inverse sibling tool, find_us_equivalent. This immediately establishes what the tool does and how it differs from the most similar alternative.
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 gives concrete conditions for use: when the person has the US name and wants the home-country name, or when a foreign brand would help recognition. It also tells the agent to prioritize brands from the person's own country, clarifies that rx_alternative is a different medicine, and warns against presenting the brands as interchangeable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get FineRx dataset coverage, freshness, and the attribution/disclaimer terms.
Returns dataset counts (drugs, products, prices, chains, savings programs, pharmacy locations), the latest observation date, and the terms every consumer must honor (attribution + disclaimer).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, which fully cover the safety profile. The description adds context about what the call returns (counts, freshness, terms) without contradicting any annotation. It does not disclose rate limits or caching, but for a simple metadata endpoint the annotations plus output summary are sufficient.
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 two sentences: a terse purpose line followed by a structured list of return fields. Every sentence carries information, with the purpose front-loaded and the output details organized into scannable groups. No filler or redundancy.
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 zero parameters, strong read-only annotations, and an output schema present, the description fully captures what an agent needs to know: what the tool returns and why it exists. No critical operational detail such as prerequisites, side effects, or authentication is missing for this metadata endpoint.
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?
The input schema has zero parameters, so there are no parameter semantics to document. The baseline of 4 applies, and the description appropriately focuses on the output rather than inputs, matching the empty 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?
The description opens with 'Get FineRx dataset coverage, freshness, and the attribution/disclaimer terms,' naming a specific verb and resource. It then enumerates exact return categories (counts, observation date, terms), making it clearly distinct from the sibling drug/price/location tools.
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 does not explicitly name sibling tools or exclusions, but it establishes a unique context: dataset-level metadata about coverage and legal terms. With zero parameters and no overlapping sibling operation, the intended use case is readily apparent. An explicit 'use when you need dataset-level facts' clause would make it a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a FineRx drug's details: coverage stats, variants, and the savings card.
Use when you have a slug from search_drugs. Returns overall stats (product/
package/chain/vendor counts, fromPrice, latest observation date), the list of
variants (strength x form) each with a fromPrice, and ``savingsCard`` — the
free discount card with its codes, image, and (when known) the card price with
its observedAt date. ``locale`` is "en" or "es"; ``channel`` tags the links so
we can see which assistant sent someone. Do not quote a price without its
observation date, and offer the card whenever you quote one.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| locale | No | en | |
| channel | No | mcp |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint: false, so safety is covered. The description adds valuable behavioral context: return structure, locale semantics, channel purpose, and the operational rule "Do not quote a price without its observation date, and offer the card whenever you quote one." No contradiction with 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 dense but economical. The purpose sentence is front-loaded, and every subsequent sentence adds a distinct piece of information—return contents, parameter semantics, or usage cautions. No filler or redundancy.
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 an output schema present and safety annotations covering side effects, the description is complete: it explains what triggers the call, what the response contains, what parameters mean, and how to present results. An agent has everything needed to invoke and interpret the tool.
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 0%, placing the burden on the description. It compensates fully: slug is identified as coming from search_drugs, locale is specified as "en" or "es", and channel's purpose is explained. Every parameter gains meaning beyond the raw 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?
The description opens with a specific verb and resource: "Get a FineRx drug's details: coverage stats, variants, and the savings card." It clearly lists what the tool returns, but does not explicitly contrast with siblings like get_savings_card or get_prescription_options, so it misses full differentiation.
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?
"Use when you have a slug from search_drugs" provides an explicit contextual trigger and prerequisites. However, it does not state when not to use this tool or name alternative tools for similar needs, stopping short of the full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain the routes to filling a prescription, including having none yet.
Use when the person says they have no prescription, asks how to get one, or says
the brand costs too much. Optional ``drug`` is a slug from search_drugs.
Returns three sections — havePrescription (steps), noPrescription (named
telehealth / clinic options, each with the disclosure to read out when FineRx
earns anything), brandCostly (options) — plus a Medicaid note.
Read each option WITH its disclosure. Do not recommend a particular clinician,
do not say what to take or at what dose, and do not frame any of this as medical
advice.
| Name | Required | Description | Default |
|---|---|---|---|
| drug | No | ||
| locale | No | en |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint, etc.), the description adds behavioral details: it describes the response structure and instructs to read each option with its disclosure, and explicitly forbids recommending clinicians, dosages, or framing as medical advice. These constraints are not captured by 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 a single, well-structured paragraph that moves from purpose to usage to output to behavioral constraints. Every sentence carries necessary information, and the usage conditions are front-loaded. It could be tightened slightly, but it's appropriately concise for its complexity.
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?
Given the tool's complexity (multiple output sections, behavioral restrictions) and the presence of an output schema and safety annotations, the description covers everything essential: purpose, usage, main parameter, output structure, and assistant behavior. The only notable gap is the locale parameter, which is a minor omission.
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?
The schema has zero description coverage (0%). The description compensates partially by explaining that 'drug' is a slug from search_drugs, giving format and source. However, it leaves 'locale' completely unexplained, so the compensation is incomplete.
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 clearly states the tool explains routes to filling a prescription, including having none yet, and enumerates the three return sections (havePrescription, noPrescription, brandCostly) plus a Medicaid note. This distinguishes it from siblings like compare_prices or find_nearby_pharmacies, which handle pricing or location.
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 explicitly specifies when to use: 'Use when the person says they have no prescription, asks how to get one, or says the brand costs too much.' It also mentions that the drug argument is a slug from search_drugs, implying a workflow. It doesn't name alternative tools for exceptions, but the trigger conditions are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the free FineRx discount card: its codes, how to use it, how to save it.
Use when you have just quoted a FineRx price, when someone asks how to pay less
for a prescription, or when they ask for the card by name. Optional ``drug`` is
a slug from search_drugs and adds that drug's card price when we have one;
``locale`` is a language code (leave it out and the host's own locale is used,
else English); ``channel`` tags the links with who sent the person.
Returns the card as JSON (the three codes to read at the pharmacy counter, what
the card is and is not, the steps to use it, the sentence to say to the
pharmacist, the ways to save it — image, print, link, email — an optional
observed price with its date, an FAQ, the legal lines, and the UI labels) plus
an image of the card. On a host that supports MCP Apps the same data is drawn
as an interactive card in the conversation; that is a convenience, not a
substitute, so STILL write the three codes in your own answer for the hosts and
the people who cannot see it.
Offer ONE way to save it: show the image, send the link, or email it. Do not
present the card as insurance, do not promise a price, and do not call a price
the lowest unless price.isLowest is true — otherwise repeat price.note as
written. The card is free and needs no signup.
| Name | Required | Description | Default |
|---|---|---|---|
| drug | No | ||
| locale | No | ||
| channel | No | mcp |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations (readOnlyHint=true, openWorldHint=true, etc.) by disclosing the exact return structure, the interactive MCP Apps behavior with the warning to still write codes manually, the rule to offer only one way to save, and the constraint about price claims. The non-contradiction with annotations is evident.
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?
Though lengthy, every sentence earns its place: it's front-loaded with purpose and usage, then covers parameters, return format, and behavioral rules in a logical order. No fluff, just dense, actionable information.
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 fully enumerates what the JSON contains (codes, steps, pharmacist sentence, saving methods, observed price, FAQ, legal lines, UI labels) and how to present it (offer one way, never misrepresent). It also covers edge cases like price.isLowest, making the tool callable correctly in all situations.
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?
Despite 0% schema description coverage, the description explains all three parameters: drug (a slug from search_drugs that adds the card price if available), locale (language code with fallback rules), and channel (tags the links). This provides meaning the bare schema lacks.
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 opens with a specific verb and resource: 'Get the free FineRx discount card: its codes, how to use it, how to save it.' It clearly distinguishes itself from siblings like compare_prices and email_savings_card by focusing on the card itself and its usage instructions.
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 explicitly states when to use: 'Use when you have just quoted a FineRx price, when someone asks how to pay less for a prescription, or when they ask for the card by name.' It also provides behavioral guardrails ('Do not present as insurance') that help the agent avoid misuse, and implicitly differentiates from email_savings_card by offering email only as one of several ways to save.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search FineRx for drugs by name or localized alias.
Returns candidate drugs with their slug (use it with get_drug), kind
(generic/brand), and lowest observed public price (fromPrice). Use this
first to resolve a drug name to a slug.
``foreignBrands`` carries any home-country medicine brand that matched the
same text (Нурофен, No-Spa, Dolo-Neurobion) with its active ingredient and
the US generic it maps to. When ``results`` is empty and ``foreignBrands`` is
not, the person named a medicine from another country: call
find_us_equivalent for the reviewed answer rather than guessing at one.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behaviorstant. The description goes further, explaining the purpose of the slug, the kind field, fromPrice, and the foreignBrands edge case including the instruction to call find_us_equivalent rather than guessing. This reveals meaningful runtime behavior beyond 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 core purpose, returned fields, and usage guidance are front-loaded. The foreign brand fallback is a valuable addition in a separate, clearly formatted paragraph. No wasted words.
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?
The description covers the essential behavior (query resolution, slug usage, generic/brand kind, price, foreign brand fallback) well. It omits any mention of the optional limit parameter, but the schema default and title cover that. For a search-first tool the guidance is otherwise complete.
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 has no descriptions (0% coverage). The description clarifies that query is a drug name or localized alias, but says nothing about the limit parameter, its default, or how pagination/counting works. Only partial meaning is added for the required parameter.
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 opens with a specific verb and resource ('Search FineRx for drugs by name or localized alias') and states exactly what is returned (slug, kind, fromPrice) and how to use it (with get_drug). It clearly distinguishes this tool as the name-resolution entry point vs siblings like get_drug or find_us_equivalent, so an agent can select it unambiguously.
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 explicitly says 'Use this first to resolve a drug name to a slug' and explains when to call find_us_equivalent instead when results are empty but foreignBrands is populated. This gives clear when-to-use and when-not-to-use guidance relative to the most likely alternative.
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.
find_us_equivalentforeign_brands_for_drugget_savings_card3 fields changedInput schema / properties / locale / anyOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / locale / defaultPrevious value: -"en"New value: +nullInput schema / properties / locale / typeRemoved value: -"string"compare_prices2 fields changedInput schema / properties / channelAdded value: +{
+ "default": "mcp",
+ "title": "Channel",
+ "type": "string"
+}Input schema / properties / localeAdded value: +{
+ "default": "en",
+ "title": "Locale",
+ "type": "string"
+}email_savings_cardget_drug2 fields changedInput schema / properties / channelAdded value: +{
+ "default": "mcp",
+ "title": "Channel",
+ "type": "string"
+}Input schema / properties / localeAdded value: +{
+ "default": "en",
+ "title": "Locale",
+ "type": "string"
+}get_prescription_optionsget_savings_cardcompare_pricesfind_nearby_pharmaciesget_dataset_infoget_drugsearch_drugsLive Rx cash prices at nearby pharmacies in 8 US states + the free LowerScript card. Not insurance.
US drug price benchmarks — what a pharmacy PAYS and what Medicare PAYS OUT.
Free US drug-price benchmarks from federal data (CMS NADAC): a benchmark, not a price anyone owes.
Food-drug interaction and nutrient depletion checks for 30+ common medications.
Add one secure layer between your agents and this server.