US Rx prices by pharmacy near you + free discount card; foreign-brand equivalents; 12 languages
Scored across 19 tools
The tools cover distinct actions (single vs. multi-drug pricing, foreign-to-US and US-to-foreign lookup, card delivery, transfer steps, nearby stores) and the descriptions include explicit routing hints like 'One medicine only: use compare_prices'. The singular/plural pairs (find_us_equivalent/find_us_equivalents, compare_prices/compare_basket) and the internal ui_* tools marked 'not for the model' could still tempt misselection, but boundaries are largely clear.
Names are overwhelmingly consistent snake_case with a predictable verb_noun shape (compare_prices, get_savings_card, find_nearby_pharmacies, search_drugs, email_savings_card). Minor deviations are the noun-first foreign_brands_for_drug and the ui_* internal group, both still readable and intentional.
19 tools sounds heavy, but five are internal ui_* tools called by the card rather than the model, leaving ~14 model-facing tools for a genuinely broad domain (pricing, drug resolution, foreign equivalents, card, transfers, pharmacies). Slightly over-scoped but each tool earns its place, with no obvious redundancy.
The surface covers the full lifecycle for this read-only domain: search/resolve a drug, get packages, compare single and basket prices, find pharmacies, obtain/email the card, get prescription and transfer guidance, plus reverse foreign-brand lookup and dataset metadata. Gaps are minor (e.g., no price-history or insurance-specific comparison), not workflow-breaking.
Card prices for several medicines at once: which pharmacy chain was seen pricing the whole list, and the sum there.
Use when the person names two or more medicines and asks what they cost
together, or which one pharmacy to use for all of them. ``drugs`` is two to
six names as typed or slugs; a dose and a pack size may ride in each name
("atorvastatin 40 mg 90"). ``zip`` is a 5-digit US ZIP — pass it only when
the person gave one; without it the host's approximate location is used
when there is one, else the chains are listed nationally.
Returns the package used for each medicine, then one row per chain: its
card price for each medicine with the observation date, and — only when
every medicine was seen with a price there — their sum with the dates the
prices were observed. When taking each medicine at a different chain comes
to less than every one-chain sum, that is given too. Names that matched no
medicine are counted and left out. A sum is an addition of observed card
prices, never a quote: the pharmacy sets the final price.
Next: read out the chains with a sum and its dates; then the card sentence
and codes. One medicine only: use compare_prices.
| Name | Required | Description | Default |
|---|---|---|---|
| zip | No | ||
| drugs | Yes | ||
| locale | No | ||
| channel | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior, but the description still adds substantive context: the location fallback when no ZIP is given, that unmatched names are counted and excluded, and that a sum is an addition of observed card prices rather than a quote. It stops short of describing latency, rate limits, or caching.
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?
Front-loaded with the purpose, then organized into usage, parameters, and return-shape sections, closing with actionable "Next" guidance. Some phrasing is wordy (the parenthetical about dose and pack size, the dashes around the conditional sum clause), but each block earns its place.
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?
There is no output schema, so the description carries the return-shape burden and does so thoroughly — package per medicine, per-chain rows with observation dates, conditional sums, cross-chain comparison, and omitted unmatched names. The only gap is the unexplained locale and channel parameters.
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 0%, so the description must carry the load. It documents drugs well (two to six names, raw or slug, with optional dose and pack size riding in the string) and zip (5-digit US ZIP, passed only when the user supplies one), but locale and channel are left completely unexplained, so half the parameters remain opaque.
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 and resource — returning card prices for several medicines at once and identifying the chain that priced the whole list plus the sum. It explicitly distinguishes itself from the sibling compare_prices by noting that tool is for a single medicine.
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 an explicit trigger (person names two or more medicines and asks total cost or which single pharmacy to use) and an explicit exclusion with the named alternative ("One medicine only: use compare_prices"). It also tells the agent when to pass zip versus omitting it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Price of one medicine with the free FineRx card at US pharmacy chains, near a place.
Use when the person asks what a medicine costs, where it costs less, or its
price near them or in a ZIP code. ``drug`` is a name as typed or a slug from
search_drugs; ``strength`` ("10 mg"), ``form`` ("tablet") and ``quantity``
are optional (the package with the most chains priced is used). ``zip`` is a
5-digit US ZIP — pass it only when the person gave one; without it the host's
approximate location is used when there is one, else the answer is national
and asks for a ZIP. ``ndc`` (+ ``quantity``) is accepted for older callers.
``compare_to`` is a dollar amount the person named for THIS package — their
insurance copay, what they pay now, or a price they want to hear about —
and the answer then says how many chains were seen below it.
Returns the package, every chain's card price with its observation date
(Walmart per state), the nearest store of each chain with a store nearby,
chains with a card price but no store nearby, coverage (``other_quantities``
lists the pack sizes that were seen), and the card: codes, the dated price
with the card, and the card sentence.
Next: quote each price with its date and chain; say the price is set per
chain; then the card sentence and codes.
| Name | Required | Description | Default |
|---|---|---|---|
| ndc | No | ||
| zip | No | ||
| drug | No | ||
| form | No | ||
| locale | No | ||
| channel | No | ||
| quantity | No | ||
| strength | No | ||
| compare_to | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive, closed-world behavior, and the description adds real operational detail beyond them: the ZIP fallback chain (explicit ZIP -> host location -> national answer asking for a ZIP), the ndc-backcompat path, and the compare_to comparison semantics. This is unusually rich behavioral context for an agent.
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?
Front-loads the one-line purpose, then parameter semantics, then returns, then the answer-construction step, so it is easy to scan. It is long and somewhat conversational in places (e.g., the compare_to aside), but nearly every sentence adds invoke-relevant information rather than padding.
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 and 9 loosely described parameters, the description compensates by enumerating the return payload (chain prices with observation dates, nearest stores, other_quantities coverage, card codes/sentence) and the fallback behaviors. An agent has enough to call it and to render the answer.
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 0%, so the description carries the burden and does most of it: drug (name or search_drugs slug), strength, form, quantity, zip (5-digit, only if given), ndc+quantity, and compare_to are all explained with formats and intent. locale and channel remain undocumented, which keeps it from a 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?
States a specific verb+resource+scope: prices of one medicine with the FineRx card at US pharmacy chains near a place. This clearly separates it from siblings like find_nearby_pharmacies (stores, not prices) and ui_prices (a UI surface, not a data fetch).
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 clear triggering conditions: the person asks what a medicine costs, where it costs less, or its price near them or by ZIP. It does not name an explicit alternative or state when not to use it (e.g., baskets vs. single drug), so it stops short of a 5.
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 with the masked address, or ``sent`` false with the
reason. On an error, say what happened and offer the printable card or the
link instead. Do not retry a refusal or read the full address back.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | |||
| locale | No | ||
| consent | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description states that FineRx does not store the address, that the message contains only the card, that the response includes a masked address, and that the full address should not be read back. This is useful behavioral and privacy context that annotations do not provide.
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 action, then preconditions, then return behavior and error handling. Every sentence adds operational value and none are redundant or overly verbose.
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?
Since there is no output schema, the description fully explains the return contract: sent true with a masked address or sent false with a reason. It also covers consent, privacy, error handling, and fallback options, making it complete for an agent to invoke 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 email and consent: it explains email as the person-provided address and consent as a required flag set to true only after confirmation. However, the locale parameter is not mentioned at all, leaving a small semantic gap.
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.' This clearly identifies the action and distinguishes it from siblings like get_savings_card, which would retrieve or generate a card rather than send it.
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 explicit preconditions: use ONLY after the person has provided an email and confirmed they want it sent, and it instructs setting consent to true. It also defines fallback behavior on error by offering the printable card or link and says not to retry a refusal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pharmacy stores within 30 miles, per chain — with the card price when a drug is given.
Use when the person asks where the pharmacies are near a ZIP or near them.
``zip`` is a 5-digit US ZIP (leave it out to use the host's approximate
location when there is one). ``family`` is a comma-separated list of chain
codes: walmart, cvs, walgreens, kroger, albertsons, costco, publix, heb,
hyvee, meijer, wegmans, shoprite, bigy, gianteagle, kinney (``chains`` is the
older name of the same filter). With ``drug`` (+ optional strength, form,
quantity) each store carries its chain's card price and observation date.
Returns stores (chain, address, city, distance, whether it is a pharmacy or a
store with a pharmacy inside — not verified) and the card. Stock is not
visible: suggest calling ahead. Coordinates © OpenStreetMap contributors.
| Name | Required | Description | Default |
|---|---|---|---|
| zip | No | ||
| drug | No | ||
| form | No | ||
| limit | No | ||
| chains | No | ||
| family | No | ||
| locale | No | ||
| quantity | No | ||
| strength | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description correctly adds non-contradictory behavioral details: returns store fields and card info, explicitly states 'Stock is not visible: suggest calling ahead,' and flags that pharmacy-vs-store-with-pharmacy is 'not verified.' It also attributes map data, which is helpful context beyond 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 front-loaded with a one-sentence summary, then flows into usage, parameter details, and return behavior. Each sentence adds unique value (chain codes, caveats, attribution) with no filler. It is longer than the bare minimum but appropriate for the 9-parameter surface.
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?
For a 9-parameter tool with no output schema, the description explains return contents (stores fields, card price, observation date) and the stock visibility limitation. It leaves minor gaps (limit behavior, locale meaning) but overall provides enough for an agent to call correctly and set user expectations about stock and verification.
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 carries the burden and compensates well: it explains zip (5-digit, optional with host location), family (with chain codes and the chains alias), and drug plus optional strength/form/quantity. However, limit and locale are not explained, leaving two parameters underdocumented. The coverage is substantial but not complete.
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 precisely states the action and scope: 'Pharmacy stores within 30 miles, per chain — with the card price when a drug is given.' This distinguishes it from siblings like search_drugs or get_savings_card by specifying the geographic and chain-filtering behavior. The 'Use when' clause reinforces the exact user intent (near a ZIP or near them), making the tool's role 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 explicitly says 'Use when the person asks where the pharmacies are near a ZIP or near them,' giving a clear trigger condition. It does not, however, name alternative tools or state when not to use this tool, leaving some routing judgment to the agent. This is clear context without exclusions, matching the score 4 criterion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What a medicine from another country is in the US, and its card price here.
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.
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, to be quoted word for word),
``guidanceDisclaimer``, ``inn``, ``usGeneric``, ``usBrands``, ``rxStatus``,
``usDrug`` (slug and the card price from which it was seen, with the date),
``otherMatches`` for the same brand name in other countries, and the card.
``found`` is false when nothing matched.
Next: quote ``guidance`` as written, then ``guidanceDisclaimer``. With a
``usDrug``, compare_prices for its slug. Do not call the US drug the same
product or suggest swapping; for ``rx_alternative`` and ``no_equivalent``
name no substitute — send the person to a pharmacist or a doctor.
| Name | Required | Description | Default |
|---|---|---|---|
| brand | Yes | ||
| locale | No | ||
| channel | No | ||
| country | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description reveals essential behaviors: guidance must be quoted word for word, guidanceDisclaimer is returned, found is false when no match, and agents must never call the US drug the same product or suggest a substitute for rx_alternative/no_equivalent. This is substantial behavioral context annotations cannot convey.
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 longer than average, but each block earns its place: trigger conditions, return fields, and post-processing instructions. It is front-loaded with purpose and structured with plain-language punctuation, though the dense output-field paragraph could be slightly easier to scan.
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 explaining return values and does so thoroughly: usClass semantics, guidance usage, usDrug slug for compare_prices, otherMatches, and found. The only notable gap is the unexplained locale and channel parameters, which keeps this from a perfect score.
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 supply parameter meaning. It adds strong meaning for brand (foreign medicine name with examples) and country (same brand sold in different places), but locale and channel are left entirely unexplained. Partial compensation across four 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 opens with a clear statement of what the tool does ('What a medicine from another country is in the US, and its card price here') and gives extensive examples of non-US products and scripts. It makes the foreign-to-US mapping obvious, but it does not explicitly differentiate against sibling tools such as foreign_brands_for_drug, so it lacks the final comparative push for a 5.
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 is an explicit 'Use when...' section with concrete triggers (foreign brand, other script, paracetamol, 'what is this called in the US?'), and country is described for disambiguation. However, it does not name alternative tools or state when not to use it, so it stops short of explicit when-not/alternatives guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What several medicines from another country are in the US — the list a person brought from home.
Use when the person names two or more medicines that are not US products
(brands from home, names in another script) and asks what they are here.
``brands`` is two to six names as typed; optional ``country`` picks between
brands of the same name sold in different places. One medicine: use
find_us_equivalent.
Returns one entry per medicine found, each exactly as find_us_equivalent
gives it: ``usClass``, the reviewed ``guidance`` sentence (quote it word for
word), the US product and where its card prices start ONLY when it has the
same active ingredient, and the card. Names that matched nothing are
counted and left out — never guess what they are.
Next: for each entry quote ``guidance``; name no substitute for
``rx_alternative`` and ``no_equivalent``; then offer compare_basket for the
US products that have the same active ingredient.
| Name | Required | Description | Default |
|---|---|---|---|
| brands | Yes | ||
| locale | No | ||
| channel | No | ||
| country | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds real behavioral context beyond them: unmatched names are 'counted and left out — never guess,' and it discloses what each entry contains and where prices appear only when active ingredients match.
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?
Front-loaded with the core purpose and the routing rule, then the return shape, then next steps. Backticked field names aid scanning. The 'Next:' workflow block is slightly verbose but each line adds routing value, so it largely earns its place.
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?
There is no output schema, but the description compensates by enumerating the per-entry fields (usClass, guidance, US product, price start condition, card) and the unmatched-name behavior. Only 'locale' and 'channel' remain unexplained for a four-parameter 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%, so the description must carry the load. It documents 'brands' (two to six names as typed) and 'country' (disambiguates brands of the same name sold in different places), but says nothing about 'locale' or 'channel', leaving half of the four parameters undocumented in both places.
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 and resource ('What several medicines from another country are in the US') and immediately distinguishes the batch scope from the singular sibling: 'One medicine: use find_us_equivalent.' An agent can tell it apart from find_us_equivalent 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use ('person names two or more medicines that are not US products... asks what they are here') and an explicit alternative plus its selecting condition ('One medicine: use find_us_equivalent'). It also specifies the follow-up path (offer compare_basket), leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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?"). ``slug`` comes from search_drugs. Returns the
reviewed brands that resolve to this drug: ``brand``, ``brandScript``,
``countries``, ``inn`` and ``usClass`` (an ``rx_alternative`` entry is a
DIFFERENT medicine used for the same complaint — say so if you mention it),
and the card. 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond that: it discloses that results include reviewed brands, that an rx_alternative entry is a different medicine, and it imposes explicit safety constraints on how results may be presented (not interchangeable, no buy/import advice). This is valuable behavioral guidance that annotations cannot convey.
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 first sentence states the core purpose and the reverse relationship. Every subsequent sentence earns its place by adding usage routing, return-field context, or safety guardrails. No filler or repetition of schema/annotation content.
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?
For a single-parameter read-only tool with no output schema, the description covers the key things an agent needs: what the tool does, when to use it, where the parameter comes from, what the response contains, and how to handle a potentially confusing field (rx_alternative). It doesn't describe pagination or exact response formatting, but the listed return fields and the safety constraints make it complete enough for correct invocation and safe use.
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 for the single parameter, slug. It does: it states that slug comes from search_drugs, which tells the agent where to obtain the value and implies it is a drug identifier. It doesn't give format details, but for a single required parameter with a clear provenance instruction, this is adequate compensation.
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: it returns foreign brand names for a US drug, and explicitly frames it as the reverse of find_us_equivalent. It also gives a concrete example ('what is lisinopril called in Mexico?'), which makes the tool's purpose unmistakable and distinguishes it from 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?
The description explicitly says when to use this tool: when the person has the US name and wants the home-country one. It also names the sibling alternative (find_us_equivalent) and explains the relationship. It further instructs that slug comes from search_drugs, giving a clear prerequisite and routing an agent to the correct upstream tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What FineRx covers: pharmacy chains with card prices, how fresh they are, stores on the map, terms.
Use when the person asks what FineRx is, how big or current the data is, or
how to cite it. Returns the pharmacy chain families we hold card prices for,
their store banners, the newest observation date, how many stores we can
place on a map, the catalog size, and the attribution terms.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the tool's safety profile is known. The description adds meaningful behavioral context by enumerating what the tool returns (chain families, store banners, newest observation date, store count, catalog size, attribution terms), which goes beyond 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?
Two compact paragraphs with no filler. The first line summarizes coverage, and the second gives concrete use cases and return contents. Every sentence contributes 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 parameters and no output schema, the description provides all necessary context: what the tool is for, when to call it, and what it returns. Nothing critical is missing for an agent to select and invoke it 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?
The tool has zero parameters, so there is no parameter-level meaning to add. The description compensates by clarifying the returned information content, which is the only semantic surface area available.
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 clear purpose: returning metadata about the FineRx dataset, including pharmacy chains, freshness, store counts, and citation terms. It is easily distinguished from sibling tools like get_drug or search_drugs, which focus on drug-level lookups.
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 the tool: when the person asks what FineRx is, how big/current the data is, or how to cite it. This gives an agent actionable selection criteria even without comparing to siblings in depth.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Strengths, forms and pack sizes of one medicine that have a card price, and its default package.
Use when you have a slug and need to know which strengths and quantities
exist before quoting a price. Returns ``configs`` (strength × form, each
with quantities, where the card prices for that pack start, with the date,
and how many chains priced it), ``defaultConfig`` (the package the most chains
price), ``fromCardPrice``, the card prices of the default package per chain,
and the card. Next: compare_prices for the package the person takes.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| locale | No | ||
| channel | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds value by detailing the return fields (configs, defaultConfig, fromCardPrice, card) and their semantics. It does not contradict annotations and provides additional behavioral context beyond safety.
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 paragraphs, front-loads the purpose, and is reasonably structured. It is not overly verbose, though the return-field explanation is a bit dense. It earns its place without 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 no output schema, the description must explain return values, which it does by enumerating the fields. It also provides usage context and a clear next step. It lacks explicit handling of optional parameters or error scenarios, but overall it is complete for a read-only lookup.
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 only hints at the slug parameter ('Use when you have a slug') but does not explain the locale and channel parameters. This is a significant gap for a tool with 3 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 states a specific verb and resource: it retrieves strengths, forms, and pack sizes for one medicine that has a card price, plus its default package. It clearly distinguishes itself from siblings like compare_prices by noting it is the preliminary step before quoting a price.
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 it: 'Use when you have a slug and need to know which strengths and quantities exist before quoting a price.' It also names the next step ('Next: compare_prices') which provides an alternative and context for when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 (a name works too). Returns three sections — havePrescription
(steps), noPrescription (clinics and telehealth, each with the disclosure
to read out when FineRx earns anything), brandCostly — plus a Medicaid
note, where the drug's card prices start (dated), and the card. For
controlled or age-restricted medicines it returns only ``restricted:
true``: FineRx shows card prices and the card for them, nothing else. Not
medical advice: never say what to take or at what dose.
| Name | Required | Description | Default |
|---|---|---|---|
| drug | No | ||
| locale | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral context beyond the readOnly/idempotent annotations: it details the three returned sections, the restricted-only response for controlled/age-restricted medicines, the disclosure requirement when FineRx earns anything, the Medicaid note, and the non-medical-advice guardrail. This is rich, non-redundant disclosure.
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 purpose and usage, then packs necessary output, exception, and safety behavior into a dense but non-redundant paragraph. Every sentence carries meaningful information; no 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?
With no output schema, the description compensates well by enumerating return sections and the restricted branch. The main gap is the unexplained 'locale' parameter, which prevents full contextual completeness for an agent deciding what to pass.
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 description usefully explains the 'drug' parameter as a slug from search_drugs and notes that a name also works, adding meaning beyond the schema. However, the 'locale' parameter is never mentioned, leaving one of the two parameters unexplained despite 0% schema description coverage.
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 a specific action—routing to filling a prescription—and covers the no-prescription case. It names concrete output sections and implicitly distinguishes itself from price/comparison siblings by focusing on prescription acquisition steps.
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 states when to use the tool: when the person has no prescription, asks how to get one, or says the brand costs too much. It does not explicitly name alternatives or state when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The free FineRx discount card: its codes, how to use it, how to keep it.
Use when the person asks for the card, how to pay less at the pharmacy, or
right after you quoted a card price. Optional ``drug`` (a slug from
search_drugs) adds that drug's card price for its most-priced package, with
the date it was observed. ``locale`` is a language code (the host's own is
used when left out).
Returns the three codes to read at the counter, the steps, the sentence to
say to the pharmacist, the links to the card page and the printable sheet,
and the card sentence with the small print. Hosts with MCP Apps show it as an
interactive card; write the three codes in your answer anyway. The card is
free, needs no signup and is not insurance.
| Name | Required | Description | Default |
|---|---|---|---|
| drug | No | ||
| locale | No | ||
| channel | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds valuable behavioral context: it returns three codes, steps, a sentence to say, links, and the card sentence with small print. It also warns that 'Hosts with MCP Apps show it as an interactive card; write the three codes in your answer anyway' and clarifies the card is free, requires no signup, and is not insurance. 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 a single paragraph that front-loads the purpose, then gives usage triggers, explains parameters, lists return contents, and adds extra notes. Every sentence carries information; there is no fluff. It is compact yet sufficiently detailed for the tool's 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 tool is relatively simple, with no output schema and three optional parameters. The description covers the main return values, usage conditions, and parameter semantics for two of three parameters. It also notes the interactive card behavior. The only missing piece is the 'channel' parameter and any error or edge-case handling, but overall the description is sufficient for an agent to call 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?
Schema description coverage is 0%, so the description must explain all parameters. It explains 'drug' (a slug from search_drugs, adds the card price for the most-priced package with the observation date) and 'locale' (a language code, defaults to host's own). However, the 'channel' parameter is not mentioned at all, leaving a gap for an agent deciding whether to set it. Since two of three parameters are well described but one is omitted, a score of 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 opens with 'The free FineRx discount card: its codes, how to use it, how to keep it,' which clearly states the tool's purpose as providing card details. It also specifies trigger conditions ('Use when the person asks for the card, how to pay less at the pharmacy, or right after you quoted a card price') that differentiate it from sibling tools like email_savings_card or compare_prices, making its scope 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?
Explicit usage triggers are given ('Use when...') that tell an agent exactly when to invoke the tool. It also explains the optional parameters' effect (drug adds price, locale defaults to host's own). However, it does not explicitly mention when NOT to use it or compare to alternatives, though the triggers are clear enough to avoid misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How to move a prescription from the pharmacy that has it to the one the person wants to use.
Use when the person says their prescription is at another pharmacy, asks
how to switch pharmacies, or picked a chain from the card prices and their
prescription is elsewhere. ``chain`` is the chain they want to move TO, as
a code: walmart, cvs, walgreens, kroger, albertsons, costco, publix, heb,
hyvee, meijer, wegmans, shoprite, bigy, gianteagle, kinney. Optional
``drug`` (+ strength, form, quantity) adds that chain's card price with its
date. ``zip`` is a 5-digit US ZIP — pass it only when the person gave one.
Returns the steps in order (what to say and what to have ready), three
notes (it is free; no refills left means a new prescription; some medicines
have stricter rules), the nearest stores of that chain when a place is
known, and the card. For controlled or age-restricted medicines it returns
only ``restricted: true``. Not medical advice.
Next: read the steps out as written; then the card sentence and codes.
| Name | Required | Description | Default |
|---|---|---|---|
| zip | No | ||
| drug | No | ||
| form | No | ||
| chain | No | ||
| locale | No | ||
| quantity | No | ||
| strength | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), yet the description adds substantial behavior: the ordered return of steps, the three notes, nearest stores, the card, the special 'restricted: true' path for controlled/age-restricted medicines, and the explicit 'not medical advice' disclaimer. That is real value 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?
Front-loaded with the one-line purpose before triggers, parameters, and returns, and it closes with a practical 'Next:' instruction. It is longer than strictly necessary and the parameter prose runs together, but nearly every sentence carries usable 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?
For a tool with no output schema and no required parameters, the description fully describes the return payload (ordered steps, three notes, nearest stores, card, restricted flag) and covers 6 of 7 inputs, so an agent has everything needed to call and consume it 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 across 7 parameters, the description carries the full burden and does most of it: it defines chain as the destination chain with an explicit value list, explains drug (+strength/form/quantity) as adding that chain's card price with its date, and constrains zip as a 5-digit US ZIP passed only when supplied. Only locale is left undocumented.
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 first line states a specific action and resource: moving a prescription from its current pharmacy to the desired one. It is immediately distinguishable from price-comparison siblings like compare_prices and search_drugs, though it never names or contrasts with the closer siblings get_prescription_options or get_savings_card.
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 three concrete triggering conditions (prescription is at another pharmacy, user asks how to switch, user picked a chain while their prescription is elsewhere), which is strong 'when to use' guidance. It stops short of stating when not to use it or which alternative tool to pick instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open the FineRx search inside the card, so the person can look a medicine up themselves.
Use when the person asks to open FineRx, wants to search or browse on their
own, or is not sure of the name. Optional ``query`` pre-fills the search
(a medicine, a brand from another country, a misspelling). The card then
suggests matches as they type, each with where its card prices start and
the date, and a pick shows card prices by chain near a place they choose.
Returns the matches for ``query`` (if any), foreign brands that matched,
a few often-searched medicines, and the card. What the person picks in the
card reaches you as context. Hosts without MCP Apps get the matches as text.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| locale | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context: the interactive nature (card suggestions as the user types), the return of matches and foreign brands, and how user picks become context. It also notes the text fallback for non-MCP hosts, which goes beyond annotations. No contradiction found.
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 opens with the core purpose, then usage, then detailed behavior and return values. It is slightly long but every sentence adds value. The information is logically ordered and front-loaded with the main purpose.
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 return content (matches, foreign brands, often-searched medicines, the card), the interactive flow, and the text fallback. However, it omits explanation for the 'locale' parameter, which is a notable gap given there is no output schema and the schema itself provides no descriptions. The absence of locale guidance makes the tool incomplete for an agent.
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 explain both parameters. It thoroughly explains 'query' with examples (a medicine, a foreign brand, a misspelling) and its pre-fill effect. However, 'locale' is never mentioned in the description, leaving a required parameter unexplained. This partial coverage prevents a higher score.
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 opens the FineRx search UI so the user can browse. It specifies the resource ('FineRx search inside the card') and distinguishes it from direct search tools by emphasizing the self-service browsing aspect. This clearly separates it from siblings like search_drugs or ui_suggest.
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 lists when to use: when the person asks to open FineRx, wants to search/browse on their own, or is unsure of the name. It also mentions the behavior for hosts without MCP Apps, hinting at a fallback. However, it does not explicitly name alternative tools or state when not to use it, which is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find a medicine by name (brand, generic, misspelled or in another script) and get its slug.
Not needed before compare_prices, compare_basket or get_transfer_steps:
they take a name as typed. Use it when the person asks what FineRx has, or
a name is ambiguous.
Returns candidates with ``slug`` (for get_drug and compare_prices), ``kind``
(generic/brand) and ``fromCardPrice`` — where its card prices start: the
amount, the package it is for and the observation date. ``foreignBrands``
lists home-country brands that matched the same text (Нурофен, No-Spa): when
``results`` is empty and ``foreignBrands`` is not, call find_us_equivalent.
Several candidates: ask which one — brand and generic are different products.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| locale | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's added value is the return shape: slug, kind, fromCardPrice (amount, package, observation date) and foreignBrands. It also discloses the empty-results/foreignBrands fallback behavior. It omits auth requirements or limits, keeping it at 4.
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?
Front-loads the core purpose in the first sentence, then usage, then return details and fallback logic in a logical order. Slightly long with several backticked field names, but each sentence carries distinct information (when-not, usage, returns, next steps), so most of it earns its place.
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 appropriately documents the return fields and the fallback-to-find_us_equivalent path, plus disambiguation guidance. It is nearly complete for a search tool; the only gap is the undocumented limit/locale parameters.
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 0% with 3 parameters, so the description must compensate. It gives rich semantics for query (brand, generic, misspelled, other scripts) but never mentions the limit or locale parameters, leaving a third of the parameters undocumented in both schema and description.
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 ('Find a medicine by name... and get its slug') and clarifies the input accepts brand, generic, misspelled or non-Latin script names. It also distinguishes itself from get_drug/compare_prices by naming the slug it produces for them, so an agent can differentiate it from siblings without opening schemas.
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 it is NOT needed ('Not needed before compare_prices, compare_basket or get_transfer_steps: they take a name as typed') and when it IS ('when the person asks what FineRx has, or a name is ambiguous'). It further routes the agent to find_us_equivalent when results is empty but foreignBrands is populated, and advises asking which candidate when several match.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The same list of medicines for another place — called by the FineRx card itself.
``slugs`` with their packages in parallel lists (an empty string or 0 = not
set). ``where`` is the place as typed in the card: used for this one
request, never stored. Not for the model.
| Name | Required | Description | Default |
|---|---|---|---|
| zip | No | ||
| forms | No | ||
| slugs | Yes | ||
| where | No | ||
| locale | No | ||
| strengths | No | ||
| quantities | No |
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 behavioral context beyond that: 'where' is 'used for this one request, never stored' (no persistence), and 'an empty string or 0 = not set' discloses how unset values are represented in the parallel lists.
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 short and front-loads the main scope statement, but the backtick-heavy phrasing and the trailing 'Not for the model' aside make it read awkwardly rather than cleanly structured. It is adequate but not especially well-organized.
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?
For a 7-parameter tool with no output schema and 0% schema description coverage, the description leaves most parameters unexplained and gives no sense of what is returned. The 'never stored' and list-convention notes are helpful but insufficient for the tool's complexity.
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 carry the burden. It does explain the parallel-list convention across the array parameters and the empty-string/0 sentinel, which is useful, but 'zip', 'forms', 'strengths', and 'locale' are never addressed, leaving several parameters undocumented in both schema and description.
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 conveys the resource (a list of medicines for a place) but only vaguely implies the action, and the phrasing 'called by the FineRx card itself' is the closest thing to a clear scope statement. The annotation title 'Refresh the medicines list card' clarifies intent more than the description itself, so purpose is discernible but not cleanly stated as verb+resource.
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?
'Not for the model' and 'called by the FineRx card itself' are genuine when-not-to-use signals that route the agent away from this tool. However, no alternatives are named and no positive use condition is described, leaving the guidance implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One foreign brand the person picked in the FineRx search — called by the card itself.
The same answer as find_us_equivalent for exactly that brand (its
``brandSlug`` from ui_suggest): the reviewed guidance, word for word, and
the US product only when it has the same active ingredient. Not for the model.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | ||
| brand_slug | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey readOnlyHint, idempotentHint, and destructiveHint, so the description's burden is lower. The description adds meaningful behavioral context: the result mirrors find_us_equivalent exactly for that brand, guidance is returned word-for-word, and the US product is included only under the same-active-ingredient condition. There is 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 compact and front-loads the essential purpose, then adds the comparison to find_us_equivalent. The phrasing is somewhat cryptic ('called by the card itself', 'Not for the model') but every sentence earns its place, and the backtick-wrapped brandSlug reference is helpful.
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 simple two-parameter schema and helpful annotations, the description covers the key return behavior (guidance plus conditional US product) and the input provenance (brandSlug from ui_suggest). It lacks detail on locale semantics and error/edge cases, but it is adequate for a UI-helper 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%, so the description must compensate. It does clarify that brand_slug should come from ui_suggest's brandSlug value, which is useful. However, the optional locale parameter is never explained, leaving a gap for an otherwise undocumented 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 identifies the tool's role as returning the same result as find_us_equivalent for a specific foreign brand, including reviewed guidance word-for-word and the US product only when the active ingredient matches. It also clearly scopes it as a card/UI-level call ('called by the card itself'), distinguishing it from a general model-facing lookup. It lacks a crisp standalone verb phrase, relying on the sibling comparison plus annotations, so it is clear but not maximally self-contained.
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 provides useful routing context: it names find_us_equivalent as the source of the same answer, specifies that the input comes from ui_suggest's brandSlug, and explicitly excludes the model ('Not for the model'). This implies when to prefer other tools, but it does not fully articulate alternate conditions such as 'use find_us_equivalent when the model needs this answer' or 'use another tool for other brands'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pharmacies near a place for the package on screen — called by the FineRx card itself.
``where`` is the place as typed in the card (a ZIP, a city or an address):
used for this one request, never stored. Not for the model.
| Name | Required | Description | Default |
|---|---|---|---|
| zip | No | ||
| form | No | ||
| slug | No | ||
| where | No | ||
| family | No | ||
| locale | No | ||
| quantity | No | ||
| strength | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey read-only, idempotent, non-destructive behavior. The description adds meaningful context beyond that: `where` is used for only this request and never stored, and the call is tied to the FineRx card. This is useful behavioral information not present in 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 short, front-loaded with the purpose, and mostly free of filler. The trailing 'Not for the model' line is slightly ambiguous and could be better integrated, but overall the structure is efficient.
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?
While the purpose and privacy note are helpful, the tool has eight optional parameters with no descriptions, no output schema, and no clear relationship to `find_nearby_pharmacies`. An agent would struggle to know how to populate most parameters or what the response shape is.
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 description explains only the `where` parameter, noting it is a ZIP, city, or address used transiently. With 0% schema description coverage and eight parameters total, the description was expected to compensate but leaves the other seven parameters entirely undocumented.
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 first sentence states that the tool provides pharmacies near a place for the package on screen, which is a specific resource and outcome. However, it does not explicitly distinguish itself from the similarly named sibling `find_nearby_pharmacies`, so cross-tool differentiation is missing.
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 clearly says the tool is called by the FineRx card itself and includes 'Not for the model,' giving an agent context about when this tool is appropriate. It does not name alternatives such as `find_nearby_pharmacies`, but the invocation context is fairly explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Card prices for another dose, quantity or place — called by the FineRx card itself.
Same answer as compare_prices, for the package and place picked inside the
card. ``where`` is the place as typed in the card (a ZIP, a city or an
address): used for this one request, never stored. Not for the model.
| Name | Required | Description | Default |
|---|---|---|---|
| zip | No | ||
| form | No | ||
| slug | Yes | ||
| where | No | ||
| locale | No | ||
| quantity | No | ||
| strength | No | ||
| compare_to | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description adds a genuine privacy trait not covered elsewhere: `where` is 'used for this one request, never stored'. It also states output parity with compare_prices. Return format details are absent but annotations carry the safety profile.
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?
Front-loads the core purpose in the first sentence, then adds usage and a parameter note. Slightly prose-heavy with the parenthetical aside, but every clause contributes 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?
The UI-calling context and privacy behavior of `where` are covered, and no output schema exists so return values needn't be explained. However, with 8 parameters at 0% schema coverage, most arguments are left semantically undefined.
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 0% across 8 parameters, so the description must compensate. It only clarifies `where` (ZIP/city/address, not persisted) and loosely hints at dose/quantity/place; zip, form, slug, locale, strength, and compare_to remain undocumented in both schema and description.
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 (card prices) and scopes it to 'another dose, quantity or place', explicitly equating it to compare_prices for the in-card package/place. It distinguishes itself from siblings by identifying itself as the card-invoked variant, though 'Card prices' is slightly ambiguous about which card/prices without context.
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 says it is 'called by the FineRx card itself' and 'Not for the model', which is a direct when-not-to-use instruction, and it names compare_prices as the equivalent surface. Routing is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Medicines matching what the person is typing in the FineRx search — called by the card itself.
Up to eight matches with where their card prices start (dated), and foreign brands that matched. Not for the model.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | ||
| locale | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it readOnly/idempotent/non-destructive, and the description adds useful output behavior: up to eight matches, dated card-price starts, and foreign-brand matches. This goes beyond the annotation set, though it omits details such as locale handling.
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 short and front-loaded: purpose first, then result details, then caller restriction. The line break after the em dash is slightly awkward, but there is no wasted wording.
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?
For an internal UI suggest tool with no output schema, the description communicates the result count and key result content. Locale behavior and matching semantics are absent, so it is not fully self-contained for an agent.
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 0%, so the description must explain parameters; it does clarify q as the text the person is typing. The locale parameter is never mentioned, and no format or constraints are provided, leaving a gap.
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 identifies a specific behavior: returning medicines matching the text typed into FineRx search, and it notes who calls it ('called by the card itself'). It does not explicitly contrast with sibling ui_* tools, which keeps it from a 5.
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 provides a clear exclusion ('Not for the model') and a clear caller context ('called by the card itself'), telling an agent that this is a UI-internal tool rather than an API to choose directly. It names no alternative tool, so it earns 4 rather than 5.
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_basketcompare_prices1 field changedInput schema / properties / compare_toAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Compare To"
+}find_us_equivalentsget_transfer_stepsui_basketui_prices1 field changedInput schema / properties / compare_toAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Compare To"
+}open_price_finderui_equivalentui_nearby1 field changedInput schema / properties / whereAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Where"
+}ui_prices1 field changedInput schema / properties / whereAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Where"
+}ui_suggestcompare_prices18 fields changedInput schema / properties / channel / anyOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / channel / defaultPrevious value: -"mcp"New value: +nullInput schema / properties / channel / typeRemoved value: -"string"Input schema / properties / drugAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Drug"
+}Input schema / properties / formAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Form"
+}Input 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"Input schema / properties / ndc / anyOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / ndc / defaultAdded value: +nullInput schema / properties / ndc / typeRemoved value: -"string"Input schema / properties / quantity / anyOfAdded value: +[
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / quantity / defaultAdded value: +nullInput schema / properties / quantity / typeRemoved value: -"number"Input schema / properties / strengthAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Strength"
+}Input schema / properties / zipAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Zip"
+}Input schema / requiredRemoved value: -[
- "ndc",
- "quantity"
-]Output schema / (root)Previous value: -{
- "additionalProperties": true,
- "title": "compare_pricesDictOutput",
- "type": "object"
-}New value: +nullemail_savings_card4 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"Output schema / (root)Previous value: -{
- "additionalProperties": true,
- "title": "email_savings_cardDictOutput",
- "type": "object"
-}New value: +nullfind_nearby_pharmacies11 fields changedInput schema / properties / drugAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Drug"
+}Input schema / properties / familyAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Family"
+}Input schema / properties / formAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Form"
+}Input schema / properties / localeAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Locale"
+}Input schema / properties / quantityAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Quantity"
+}Input schema / properties / strengthAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Strength"
+}Input schema / properties / zip / anyOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / zip / defaultAdded value: +nullInput schema / properties / zip / typeRemoved value: -"string"Input schema / requiredRemoved value: -[
- "zip"
-]Output schema / (root)Previous value: -{
- "additionalProperties": true,
- "title": "find_nearby_pharmaciesDictOutput",
- "type": "object"
-}New value: +nullfind_us_equivalent4 fields changedInput schema / properties / channel / anyOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / channel / defaultPrevious value: -"mcp"New value: +nullInput schema / properties / channel / typeRemoved value: -"string"Output schema / (root)Previous value: -{
- "additionalProperties": true,
- "title": "find_us_equivalentDictOutput",
- "type": "object"
-}New value: +nullforeign_brands_for_drug1 field changedOutput schema / (root)Previous value: -{
- "additionalProperties": true,
- "title": "foreign_brands_for_drugDictOutput",
- "type": "object"
-}New value: +nullget_dataset_info1 field changedOutput schema / (root)Previous value: -{
- "additionalProperties": true,
- "title": "get_dataset_infoDictOutput",
- "type": "object"
-}New value: +nullget_drug7 fields changedInput schema / properties / channel / anyOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / channel / defaultPrevious value: -"mcp"New value: +nullInput schema / properties / channel / typeRemoved value: -"string"Input 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"Output schema / (root)Previous value: -{
- "additionalProperties": true,
- "title": "get_drugDictOutput",
- "type": "object"
-}New value: +nullget_prescription_options4 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"Output schema / (root)Previous value: -{
- "additionalProperties": true,
- "title": "get_prescription_optionsDictOutput",
- "type": "object"
-}New value: +nullget_savings_card3 fields changedInput schema / properties / channel / anyOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / channel / defaultPrevious value: -"mcp"New value: +nullInput schema / properties / channel / typeRemoved value: -"string"search_drugs2 fields changedInput schema / properties / localeAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Locale"
+}Output schema / (root)Previous value: -{
- "additionalProperties": true,
- "title": "search_drugsDictOutput",
- "type": "object"
-}New value: +nullui_nearbyui_pricesfind_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.
Free health AI: drug interaction checks, medicine facts and health questions in 90+ 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.
Add one secure layer between your agents and this server.