Medicare rates, hospital quality, and dispute scenarios from six federal public-domain datasets.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
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.
Average 4.3/5 across 5 of 5 tools scored.
Each tool targets a distinct resource/action: audit, dispute scenario lookup (singular and list), CPT rate lookup, hospital lookup. The list/get pair is clearly differentiated as list vs single item, and the lookups differ by target. No overlapping boundaries.
All tool names follow a verb_noun snake_case pattern (audit_medical_bill, get_dispute_scenario, list_dispute_scenarios, lookup_cpt_rate, lookup_hospital). The verbs vary appropriately (audit, get, list, lookup) but the structure is consistent.
5 tools is a well-scoped set for a medical bill audit service: one primary audit action, three supporting lookups/reference tools, and one discovery/index tool. No redundancy or bloat.
The core audit workflow is present, but there is no way to retrieve a previously generated audit report or the full paid report content; the audit tool only returns a preview and an external payment URL. Missing a tool to fetch the full report or manage audit history, which creates a minor gap.
audit_medical_billAudit a medical bill against six federal data sourcesAInspectRuns a full audit on a medical bill — cross-references every charge against six federal data sources (CMS PFS, NADAC, HPT, NCCI, Hospital Compare, IRS Pub 78) and identifies potential billing errors plus the federal statutes the patient can cite. Returns a free preview (severity, totals, issue count). The full report with line-by-line breakdown and up to 5 ready-to-mail dispute letters requires payment ($19.97 single audit, or covered under Family/Pro subscription). Returns a unique unlock URL for completing payment.
| Name | Required | Description | Default |
|---|---|---|---|
| billText | Yes | Plain-text bill content. Include line items, charges, dates, hospital name if visible. Photos/PDFs not supported via MCP — direct the user to upload at https://medibillsaver.com/scan for image/PDF support. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It transparently explains the free preview (severity, totals, issue count), the paid full report (line-by-line breakdown and up to 5 dispute letters), and the unique unlock URL for payment. This gives the agent critical behavioral context that payment is required.
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 well-structured paragraph with no redundant sentences. It front-loads the core function, then explains the preview, payment requirement, and unlock URL. Every sentence earns its place, providing necessary information for an agent deciding whether and how to invoke the tool.
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?
Despite lacking an output schema, the description adequately characterizes return values: the free preview contents, the full report breakdown, and the unlock URL. It also indirectly conveys the tool's moderate complexity. It does not go into failure modes or detailed data source nuances, but it is sufficient for the agent to set user expectations.
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 single parameter billText is fully described in the input schema (100% coverage), including its content and the unsupported image/PDF types. The tool description itself does not add parameter-specific details, but the schema already does the heavy lifting, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Runs a full audit on a medical bill' — a specific verb and resource — and enumerates the six federal data sources cross-referenced. This clearly differentiates it from the sibling lookup tools (get_dispute_scenario, lookup_cpt_rate, lookup_hospital), which handle narrower 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?
The description clearly implies its use case: comprehensive bill auditing via phrases like 'full audit' and 'cross-references every charge against six federal data sources.' However, it does not explicitly name alternatives or state when not to use it, so it lacks the explicit when/when-not guidance of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_dispute_scenarioGet summary of a medical-bill dispute scenarioAInspectReturns a summary of one MediBill Saver dispute scenario: title, category, the federal statute backing the patient's right to dispute, and a link to the full scenario page (which contains the how-to-spot checklist and sample dispute language). Useful when a patient asks 'how do I dispute X' or 'what is HIPAA §164.524'. Free, no authentication required.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Scenario slug (e.g. 'upcoded-er-visit', 'duplicate-charges'). Use list_dispute_scenarios first if unsure. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral context itself. It states the operation is free and requires no authentication, which is important context. It also discloses what the response contains, effectively describing the read-only nature without explicitly stating 'read-only'. While it doesn't explicitly say it makes no modifications, the verb 'Returns' and the absence of any write-related language make that clear enough, though a direct statement would push this to 5.
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 sentences, each earning its place. The first states the output; the second gives usage context and authentication info. No redundant or filler language.
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 there is no output schema, the description compensates by enumerating the response fields (title, category, statute, link) and even describes the linked page's content. It also covers the intended use cases and authentication requirements, making it a complete description for a simple one-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?
The schema description covers 100% of the single parameter, including examples and guidance to use list_dispute_scenarios first. The tool description does not add any additional parameter-level meaning, so it stays at the baseline of 3.
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 ('Returns') and identifies the resource ('one MediBill Saver dispute scenario') and the exact content of the summary (title, category, statute, link). It distinguishes itself from sibling list_dispute_scenarios by focusing on a single scenario selected by slug, and includes example user queries that clarify its purpose.
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?
Provides explicit usage triggers: 'when a patient asks how do I dispute X or what is HIPAA §164.524'. Additionally, the parameter description in the schema directs the agent to use list_dispute_scenarios first if unsure about the slug, giving a clear alternative path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_dispute_scenariosList all available dispute scenariosAInspectReturns the full index of dispute scenarios MediBill Saver covers — slug, title, category, and the federal statute. Useful to discover which scenarios exist before calling get_dispute_scenario. Free, no authentication required.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool is 'Free, no authentication required' and describes the response content (slug, title, category, federal statute). This is useful behavioral context beyond a bare 'list' label, though it does not mention potential pagination, rate limits, or error behavior—acceptable for a simple list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core function ('Returns the full index...') followed by practical usage guidance and auth note. Every sentence contributes value; there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, zero-parameter list tool with no output schema, the description is complete: it states what is returned, lists the returned fields, explains when to use it, and mentions authentication requirements. It gives the agent enough to decide and invoke correctly without needing extra details.
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 the baseline is 4. The description adds no parameter semantics because none are needed; it instead clarifies what the returned index will contain, which is appropriate given the absence of an output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Returns the full index of dispute scenarios' and lists the exact fields (slug, title, category, federal statute). It also distinguishes itself from the sibling 'get_dispute_scenario' by positioning this as the discovery step before fetching a specific scenario.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly recommends using this tool 'to discover which scenarios exist before calling get_dispute_scenario', providing a clear use case and a named alternative. However, it does not explicitly state when not to use it or compare against other siblings like lookup_cpt_rate, so it stops short of a full when/when-not/alternatives breakdown.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_cpt_rateLook up Medicare rate for a CPT/HCPCS codeAInspectReturns the Medicare national-average non-facility allowed amount for a CPT or HCPCS procedure code from the CMS Physician Fee Schedule. Useful for benchmarking what a hospital or clinic billed against what Medicare reimburses. Free, no authentication required. For the patient-facing description and disputes information, link the user to the returned pageUrl.
| Name | Required | Description | Default |
|---|---|---|---|
| cpt | Yes | 5-character CPT or HCPCS code, uppercase (e.g. '99285', 'J7030', 'G0008'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosure. It explicitly states 'Free, no authentication required' and describes the output (allowed amount) and a return field (pageUrl). This adds meaningful behavioral context beyond the schema, though it does not cover error handling or return format.
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?
Four concise sentences, each serving a distinct purpose: defining the output, providing a use case, stating access requirements, and giving result-handling guidance. No redundancy, and the primary function is front-loaded.
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 simple one-parameter lookup with no output schema and no annotations, the description is adequate. It covers output definition, use case, access, and a key return field. It omits potential error scenarios or return structure details, but these are less critical for this complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with a clear pattern and description for the cpt parameter. The tool description adds background about the CMS Physician Fee Schedule but does not add parameter-specific syntax beyond what the schema already provides.
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 verb ('Returns') and resource (Medicare national-average non-facility allowed amount for CPT/HCPCS codes). It distinguishes from sibling tools like lookup_hospital and audit_medical_bill by focusing on rate benchmarking.
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?
Provides a clear use case: benchmarking what a hospital or clinic billed against Medicare reimbursement. Also gives guidance for using the pageUrl for patient-facing disputes information. Does not explicitly name alternative tools, but context strongly implies when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_hospitalLook up a U.S. hospital by CCN or nameAInspectReturns hospital metadata from CMS data: name, location, ownership type, CMS overall rating (1-5 stars), and 501(c)(3) charity-care eligibility. Useful when a patient mentions a specific hospital and wants to know the facility's federally-published quality profile and whether charity care is available. Free, no authentication required.
| Name | Required | Description | Default |
|---|---|---|---|
| ccn | No | CMS Certification Number (Provider Number) — 6 character identifier (e.g. '050625'). | |
| name | No | Hospital name (partial match supported). Use when CCN is not known. | |
| state | No | Two-letter U.S. state code (e.g. 'CA'). Optional, narrows name search. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the transparency burden. It discloses that the tool is 'Free, no authentication required' and lists the data source (CMS) and returned fields. However, it does not disclose whether multiple matches are returned (given 'partial match supported' on name) or any limitations like pagination or error behavior. This is a notable gap for a lookup tool with optional parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and output fields. The second sentence adds use-case context and access details. Every sentence contributes value with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should clarify the return shape (single hospital vs. list). It lists fields but doesn't state whether the result is a single object or an array, nor what happens on no match. The tool's complexity is low, but these missing details leave some ambiguity for agents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for all three parameters (ccn, name, state). The description adds minimal param-specific context beyond what the schema already says. It does not expand on parameter usage or relationships, so the schema carries the weight, making a baseline score of 3 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 clearly states the tool's function: 'Returns hospital metadata from CMS data' with a specific list of fields. It distinguishes the tool from siblings (which deal with billing, disputes, CPT rates) by focusing solely on hospital information.
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 a clear use case: 'Useful when a patient mentions a specific hospital and wants to know the facility's federally-published quality profile and whether charity care is available.' It implies the tool is for patient-provided hospital names/CCNs, though it doesn't explicitly mention when not to use it or alternative tools. The siblings are sufficiently distinct in domain, so the guidance is adequate.
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.
No comments yet. Be the first to start the discussion!
