F
license-
qualityC
maintenanceProvides unified access to drug formulary data from US ACA marketplace health insurance plans, enabling drug search, coverage details, restriction info, and plan comparison across thousands of plans.
FineRx
Server Details
US Rx price comparison + foreign-brand US-equivalent lookup. Observed prices, read-only.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
MCP client
Glama
MCP server
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
100% free. Your data is private.
Tool Definition Quality
A4.4/5.0
Tool DescriptionsA
Average 4.4/5 across 5 of 5 tools scored.
Server CoherenceA
Disambiguation5/5
Each tool serves a distinct function: searching drugs, getting drug details, comparing prices, finding pharmacies, and retrieving dataset metadata. There is no overlap in purpose.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., search_drugs, compare_prices, get_drug), making the set predictable and easy to navigate.
Tool Count5/5
With 5 tools, the server is well-scoped for a drug pricing API. Each tool addresses a specific step in the typical workflow (search, details, price comparison, location, metadata), and the count is neither too small nor excessive.
Completeness4/5
The toolset covers the core workflow: search drugs, retrieve drug details, compare prices, find pharmacies, and obtain dataset info. A minor gap is that the mechanism to obtain an NDC from a drug is implied but not explicitly detailed, though the flow likely works.
Available Tools
5 toolscompare_pricesARead-onlyIdempotentInspect
Compare FineRx prices for one package (an 11-digit NDC + quantity).
Returns the offer matrix: for each pharmacy chain x savings program, the
observed price and the date it was observed (observedAt). The cheapest offer
is flagged isLowest. Get an ``ndc`` from get_drug's packages or search flow.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ndc | Yes | ||
| quantity | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds value by detailing the output structure (offer matrix with pharmacy chain x savings program, observedAt, isLowest), providing behavioral 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, front-loading the purpose and input, then efficiently describing the output. Every sentence adds essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with an existing output schema, the description fully covers input format, output structure, and data sourcing. There are no missing details that would hinder correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by specifying that NDC should be an 11-digit string and that quantity is required. It also clarifies that the input represents a 'package,' adding meaning absent from the schema's parameter definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Compare FineRx prices for one package (an 11-digit NDC + quantity).' It distinguishes from sibling tools like search_drugs and get_drug by focusing on price comparison for a specific drug package.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises to 'Get an ``ndc`` from get_drug's packages or search flow,' providing a clear workflow context. However, it does not explicitly state when not to use this tool or list alternatives beyond the hint about sourcing the NDC.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_nearby_pharmaciesARead-onlyIdempotentInspect
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).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| zip | Yes | ||
| limit | No | ||
| chains | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, indicating safe, non-destructive behavior. The description adds value by noting that coordinates are OpenStreetMap-sourced (ODbL), providing data provenance context. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loads the main purpose, and includes necessary parameter details without verbosity. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, the description doesn't need to detail return values. It covers parameters, defaults, and data source. It could mention sorting by distance or error handling, but it is largely complete for its purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden. It explains each parameter: 'zip' is a 5-digit US ZIP, 'chains' is a comma-separated list with an example and default, 'limit' caps per chain. This goes well beyond the schema's type/default info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource combination ('Find the nearest pharmacy locations') and scopes it to a US ZIP code per chain. It clearly distinguishes from sibling tools like search_drugs or compare_prices, which focus on drug information or pricing, not location.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose is clear enough that an agent can infer when to use it (geographic pharmacy search). However, there is no explicit guidance on when not to use it or mention of alternative tools, which would push it to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_dataset_infoARead-onlyIdempotentInspect
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).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint. Description adds what is returned (counts, latest date, attribution/disclaimer terms) and that terms are mandatory for consumers. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Front-loaded with purpose, then lists specific return elements. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the main functionality for a metadata tool with no parameters and an existing output schema. Could mention that it's read-only or idempotent, but annotations already cover that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in input schema and schema coverage is 100%. Description doesn't need to add parameter details. Baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves FineRx dataset metadata including coverage, freshness, and terms. It distinguishes from siblings which focus on prices, pharmacies, and drugs. Verb 'Get' and resource 'dataset info' match the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage for obtaining dataset coverage and terms, but no explicit when-to-use or when-not-to-use guidance. Siblings are listed but no direction on choosing this over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_drugARead-onlyIdempotentInspect
Get a FineRx drug's details: coverage stats and its strength/form variants.
``slug`` comes from search_drugs. Returns overall stats (product/package/
chain/vendor counts, fromPrice, latest observation date) and the list of
variants (strength x form) each with a fromPrice.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds value by detailing the return structure (overall stats and variants), going beyond the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the purpose and immediately useful details. Every sentence adds value with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input (one param), rich annotations, and existence of an output schema, the description covers the main purpose and output well. Could mention error handling or pagination, but not necessary for this scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for the slug parameter, but the description explains that slug comes from search_drugs, providing important semantic context about its origin. This compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (Get) and resource (FineRx drug's details), listing specific outputs (coverage stats, strength/form variants). It distinguishes from siblings by mentioning that the slug comes from search_drugs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions that the slug parameter comes from search_drugs, guiding the user to use this tool after a search. This provides clear context and links to a sibling tool, though it does not explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_drugsARead-onlyIdempotentInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds value by specifying the return fields (slug, kind, fromPrice) and search scope, which are not in annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: first states purpose, second lists outputs, third gives usage guidance. No unnecessary words, and the structure is front-loaded with the most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, good annotations, and presence of an output schema, the description is complete. It covers what, how, and when, and the return fields are described even though the output schema exists, adding practical context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It explains that 'query' is the drug name or alias, but does not mention the 'limit' parameter or its default. Partial compensation; could be improved by noting limit restricts results.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches FineRx for drugs by name or localized alias, specifying the resource (drugs) and scope (FineRx). It distinguishes from siblings like get_drug (for retrieving a specific drug by slug) and compare_prices (pricing comparison).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs 'Use this first to resolve a drug name to a slug', providing clear when-to-use guidance and implying the alternative (get_drug) for subsequent steps. This leads the agent to the correct workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Servers
costkits-mcpofficial
AlicenseAqualityAmaintenanceProvides live US healthcare cost data including procedure cost estimates, provider pricing, insurance coverage rules, and medical bill analysis using real hospital transparency and CMS data.12120MIT- Alicense-qualityCmaintenanceUnifies five public US-government drug datasets into a single sourced page per GLP-1/cardiometabolic drug, providing cost, shortage, label, and alternatives. The MCP server exposes the same Drug contract as the UI for agent-native access.51,375,378Apache 2.0
- Alicense-qualityFmaintenanceProvides comprehensive pharmaceutical intelligence by integrating real-time openFDA data with locally-cached Orange Book and Purple Book databases. It enables users to analyze drug safety, patents, generic equivalents, biosimilars, and regulatory information through natural language queries.3MIT