MediBill Saver — medical bill audit tools
Server Details
Medicare rates, hospital quality, and dispute scenarios from six federal public-domain datasets.
- 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.
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.
Tool Definition Quality
Average 4.4/5 across 5 of 5 tools scored.
Each tool serves a distinct function: full audit, scenario detail, scenario listing, rate lookup, and hospital lookup. No overlap in purpose.
All tools use a consistent verb_noun pattern in snake_case (e.g., audit_medical_bill, lookup_cpt_rate), making them predictable and easy to differentiate.
Five tools is well-scoped for a focused medical bill audit domain, covering key operations without unnecessary clutter.
Covers core workflows (audit, dispute info, rate/hospital lookup). Minor gap: no tool for payment or retrieving full audit results after payment, but the preview suffices for initial interaction.
Available Tools
5 toolsaudit_medical_billAudit a medical bill against six federal data sourcesAInspect
Runs 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. |
Tool Definition Quality
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 the audit process, the output types (free preview vs. paid full report), and the payment requirement. It does not mention rate limits or authentication, but the audit is read-only and the description covers key behavioral aspects.
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 primary purpose and provides necessary details in a logical order. It is slightly lengthy but every sentence adds value, making it efficient for an agent to understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple data sources, two-tier output, payment model), the description covers the essential information. It explains the free preview and paid report contents, though it does not list the specific federal data sources. No output schema is provided, but the description compensates.
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 has full schema coverage. The description adds valuable semantics: it advises including line items, charges, dates, and hospital name, and clarifies that photos/PDFs are not supported via MCP, directing users to an alternate upload URL.
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 audits a medical bill against six federal data sources to identify billing errors and provides a free preview. It distinguishes itself from sibling tools (get_dispute_scenario, lookup_cpt_rate, etc.) which serve different purposes.
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 clear context on when to use the tool (for a full audit) and includes practical guidance such as the need for plain text input and a redirect to the website for image/PDF support. It does not explicitly state when not to use it, but the function is self-explanatory.
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 scenarioAInspect
Returns 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the operation is read-only, returns specific data, and is free with no authentication. Lacks mention of potential rate limits or pagination, but as a simple single-parameter tool, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each carrying important information: what the tool returns and when to use it. No fluff.
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 read tool with one parameter and no output schema, the description provides all necessary context: what it returns, use cases, authentication requirements, and reference to the listing 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 coverage is 100% with a clear description of the slug parameter including examples. The tool description adds context on usage but does not significantly extend parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a summary of a dispute scenario with specific fields (title, category, federal statute, link) and includes example use cases. It also differentiates from sibling tools by referencing list_dispute_scenarios.
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: when a patient asks 'how do I dispute X' or 'what is HIPAA §164.524'. Also notes it's free and requires no authentication, providing clear usage context.
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 scenariosAInspect
Returns 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 | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully describes the tool's behavior: it returns a full index with specific fields, is free, and requires no authentication. Some minor details like response format or caching are omitted, but the simplicity of the tool mitigates this.
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 consists of two concise sentences that front-load the core functionality and add a usage tip. Every word earns its place with no 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?
Given the tool has no parameters and no output schema, the description covers the key aspects: purpose, included fields, and relationship to siblings. It could elaborate on the response structure (e.g., JSON array) but is sufficient for a simple listing 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?
There are zero parameters, so the description does not need to explain them. The baseline for 0 parameters is 4, and the description adds value by describing the output, which aids parameter understanding indirectly.
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 returns the full index of dispute scenarios, specifying the fields (slug, title, category, federal statute). It also distinguishes itself from the sibling tool get_dispute_scenario by recommending its use before that call.
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 advises using this tool 'before calling get_dispute_scenario', providing a clear usage context. It also notes it is free and requires no authentication, implying no restrictions.
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 codeAInspect
Returns 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'). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses 'Free, no authentication required' and hints at response including pageUrl. Could be more explicit about full response structure, but sufficient for simple lookup.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each adding value: purpose, use case, and guidance. No unnecessary words. Front-loaded with core functionality.
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 one parameter, no output schema, and no annotations, description covers purpose, use case, auth-free nature, and suggests how to use returned pageUrl. Missing explicit error handling or response format, but adequate for simple 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 coverage is 100% with parameter description. Description adds context (national-average, non-facility) but does not add new constraints beyond schema. 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?
Description clearly states 'Returns the Medicare national-average non-facility allowed amount for a CPT or HCPCS procedure code', using a specific verb and resource. It distinguishes from sibling tools like audit_medical_bill and get_dispute_scenario by focusing on rate lookup.
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 clear use case: 'benchmarking what a hospital or clinic billed against what Medicare reimburses'. Mentions when to redirect to pageUrl for disputes info, implying alternative use of sibling tools. Lacks explicit exclusions.
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 nameAInspect
Returns 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the tool returns metadata, lists fields, and notes it is free and requires no authentication. It does not contradict any annotations (none provided). It could clarify that name search may return multiple results, but overall it adequately discloses the tool's read-only, non-destructive behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first summarizes output and source, the second gives use case and practical info. No unnecessary words, clearly front-loaded with key 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?
Given no output schema, the description lists returned fields and source. It covers use case, auth requirements, and basic behavior. It does not mention pagination or multiple result handling, but for a simple lookup this is adequate. A minor gap: it does not state that at least one param (CCN or name) should be provided.
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 each parameter described, so the baseline is 3. The description does not add new parameter information beyond what the schema provides, but it reinforces that CCN or name can be used for lookup. It does not compensate for missing schema details because none are missing.
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 returns hospital metadata from CMS data, listing specific fields (name, location, ownership type, rating, charity-care eligibility). It explicitly ties the purpose to a use case (patient mentioning a hospital), and the tool name and title reinforce this. It distinguishes from sibling tools (billing, disputes, CPT rates) by focusing on hospital lookup.
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 specifies when to use: '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 also notes it is free and requires no authentication. However, it does not explicitly state when not to use or mention alternatives, though siblings are unrelated.
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!