Medigami patient tools: rates, markups, denial codes, deadlines, overturn rates, procedure codes
Each tool addresses a distinct information need—bill markup, denial code explanation, appeal deadline, hospital negotiated rate, insurer overturn rate, and procedure code lookup—with no overlapping responsibilities.
All six tool names follow a verb_noun snake_case pattern (check, explain, get, get, get, lookup). The slight variation between 'get' and 'lookup' does not break the overall consistent convention.
Six tools is well-scoped for a healthcare billing and insurance transparency assistant, providing enough utility without unnecessary clutter or an overwhelming number of options.
The tool set covers the main patient-facing billing and insurance workflows: price transparency, code explanations, denial reasons, appeal timing, and insurer appeal statistics, with no obvious core gaps.
Compares one billed line to the hospital's own published negotiated rate for that code and returns the multiple. You type the code and amount; no bill upload. Educational, not billing advice.
| Name | Required | Description | Default |
|---|---|---|---|
| cpt | Yes | CPT/HCPCS procedure code. | |
| hospital | Yes | Hospital / facility name. | |
| billed_amount | Yes | Amount billed, USD. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful context beyond the annotations by stating the output is a 'multiple' and warning that it is educational rather than professional billing advice. This complements the readOnlyHint and destructiveHint annotations without contradicting them.
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 extremely concise—three short sentences that convey purpose, user input requirements, and a caveat. There is no redundancy or unnecessary detail.
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 adequately covers the tool's core purpose, input requirements, and a limiting caveat. It omits specific output formatting or error scenarios, but for a simple comparative tool, the information is sufficient for an agent to 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 schema descriptions already cover all three parameters (CPT code, hospital name, billed amount) with clear meanings and constraints. The description simply reiterates that the user provides code and amount, adding no new formatting or usage details 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 the tool's function: it compares a billed line to the hospital's published negotiated rate and returns the multiple. This distinct focus on comparing and outputting a multiple differentiates it from siblings like get_hospital_rate or lookup_procedure_code.
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 explicit instructions on what to input ('You type the code and amount') and a clear caveat ('Educational, not billing advice'). However, it does not contrast with sibling tools such as get_hospital_rate, leaving the agent to infer when this tool is preferable to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explains a CARC claim-adjustment reason code from the public X12 code list: what it means, whether it is typically appealable, and the general appeal path. Not legal advice.
| Name | Required | Description | Default |
|---|---|---|---|
| carc_code | Yes | CARC/RARC code, e.g. 'CO-16', '16', 'CO-50'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only, non-destructive profile. The description adds meaningful behavioral calibration beyond that: outputs are described as typical and general ('typically appealable', 'general appeal path'), and the 'Not legal advice' caveat signals heuristic, non-authoritative results. This is useful context an agent needs before relying on the answer.
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 with zero filler: the substantive explanation is front-loaded and the legal disclaimer is cleanly separated. Every clause earns its place, and the sentence-splitting improves scannability.
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 informational tool with a fully documented schema, the description conveys the output shape (meaning, appealability, appeal path) even without an output schema. Minor gaps remain: no statement about invalid/unknown code handling, and the description says CARC while the schema also accepts RARC codes, a slight narrowing.
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% and the schema already documents the parameter well, including format examples ('CO-16', '16', 'CO-50') and the note that RARC codes are accepted. The description only reinforces the CARC/X12 framing and adds no format or syntax detail beyond the schema. Baseline 3 applies because the schema carries the semantic weight.
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 ('Explains') and a precise resource ('CARC claim-adjustment reason code from the public X12 code list'), and enumerates the three output aspects: meaning, typical appealability, and general appeal path. This scoping differentiates it from siblings like lookup_procedure_code (procedure codes) and get_appeal_deadline (deadlines, not the appeal path).
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 scope implies the trigger condition: an agent holding a CARC code who needs its meaning or appealability would select this tool. However, the description gives no explicit when-to-use or when-not-to-use guidance and does not name alternatives, despite some overlap in territory with get_appeal_deadline and lookup_procedure_code.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the appeal window that applies to a plan type (employer ERISA plan, marketplace/individual, Medicare Advantage, Medicaid) with the federal citation and how the clock is counted. Cites the rule; does not tell you whether to file.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | 2-letter US state (echoed on the row; the window itself is federal). | |
| plan_type | Yes | e.g. 'self_funded', 'aca_marketplace', 'medicare', 'medicaid'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context: the tool cites the rule but stops short of advising on whether to file, and clarifies the state parameter is echoed because the window itself is federal. This goes beyond the annotations without contradiction.
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 with no filler. The core return value is stated first, then scope, then an explicit limitation. Every clause 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?
For a two-parameter, read-only tool with a well-described schema and annotations, the description fully covers what is returned (window, citation, clock counting) and what it does not do. Nothing needed for an agent to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are already well-documented, giving a baseline of 3. The description adds meaningful semantic context: state is echoed on the row and does not affect the federal window, while plan_type examples map directly to the parameter's documented examples. This pushes it above baseline.
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 ('Returns') and a precise resource ('the appeal window') with enumerated plan types. Distinguishes itself from siblings by topic (appeal deadlines vs. markup, denial codes, rates, procedure codes) and clarifies what it is not ('does not tell you whether to file').
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 context for when to use the tool: to obtain a plan type's appeal window, federal citation, and clock-counting method. Includes an explicit limitation ('does not tell you whether to file'), but does not name alternative sibling tools or specify when not to use it in favor of another tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the negotiated rate a named hospital publishes in its federally required machine-readable file for a CPT/HCPCS code, with the file's as-of date. Public hospital-transparency data; educational, not billing advice.
| Name | Required | Description | Default |
|---|---|---|---|
| cpt | Yes | CPT/HCPCS procedure code. | |
| hospital | Yes | Hospital / facility name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, establishing a safe read operation. The description adds useful behavioral context beyond that: it returns the as-of date of the source file, identifies the source as federally required machine-readable data, and explicitly frames the output as educational rather than billing advice.
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 tightly written sentences with no filler. The main function is front-loaded, the return value is stated, and the caveat is placed at the end without distracting from the primary purpose. Every sentence 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?
For a two-parameter read-only lookup with no output schema, this description is sufficient. It states what is returned (negotiated rate plus as-of date), clarifies the data source (federally required machine-readable file), and adds a user-facing limitation (educational, not billing advice). No critical information is missing 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 100%, so the schema already documents both parameters. The description adds minimal extra meaning beyond what the schema provides, only restating that the tool looks up a named hospital and a CPT/HCPCS code. Baseline 3 is appropriate because the schema carries the parameter documentation burden.
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 ('Returns'), names the resource ('negotiated rate a named hospital publishes'), and specifies the key inputs (hospital, CPT/HCPCS code). It also clearly distinguishes this tool from siblings like explain_denial_code or get_insurer_overturn_rate by focusing on hospital-published transparent pricing.
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: use this tool to retrieve a hospital's published negotiated rate for a CPT/HCPCS code. It does not explicitly name alternative tools or state when not to use it, but the hospital-transparency framing and the 'educational, not billing advice' caveat make the intended use obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns, for one insurer in one state, the share of external-review appeals the state regulator reports as overturned, with the sample size, the regulator's report as the source, and the as-of date. Available for CA, NY, MD, NJ, MI, OH, NC. This is one insurer's own historical rate — not a ranking or comparison against other insurers, and not a prediction for your case.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | Venue state: CA, NY, MD, NJ, MI, OH, or NC. | |
| insurer | Yes | Insurer / payer name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful behavioral context: the data comes from the regulator's report, includes sample size and as-of date, and is historical rather than predictive. This clarifies the nature and limitations of the returned value.
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 with no filler: the first states the result and its components, the second scopes availability, and the third prevents misuse. The most important information 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?
With no output schema, the description still explains the key return components—share, sample size, source, and as-of date—and the supported state set. For a two-parameter read-only lookup, this is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description reinforces that the insurer parameter refers to one specific insurer and that the state must be one of the listed venues, but it adds no format or value details 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 names a specific operation—returning the overturned-share for one insurer in one state—and lists the output elements including sample size, source, and as-of date. It also disambiguates from sibling tools by clarifying this is not a ranking, comparison, or prediction.
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 gives clear usage context by listing supported states and specifying that this is one insurer's own historical rate, not a comparison or prediction. It does not explicitly name sibling alternatives such as 'use get_hospital_rate for comparisons,' so routing guidance could be stronger.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Plain-English description of a CPT/HCPCS procedure code and its category, from public code references.
| Name | Required | Description | Default |
|---|---|---|---|
| cpt_code | Yes | CPT / HCPCS-J code ('99213', 'J1885') or keyword ('knee MRI', 'colonoscopy'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and non-destructive behavior. The description adds useful context ('from public code references') but does not disclose other behavioral traits such as handling of invalid codes, multiple keyword matches, or output format variations. This is adequate but minimal.
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 concise sentence that is front-loaded with the main purpose and includes useful qualifiers like 'plain-English' and 'from public code references.' Every word earns its place, and nothing is redundant.
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-only lookup with one fully documented parameter, the description is mostly complete. It states what the tool does and what it returns (description and category). It does not mention potential multiple matches for keywords, but this is a minor gap given the simple scope and annotation coverage.
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 fully documents the cpt_code parameter with examples, allowed formats, and max length. The description adds no additional parameter-level meaning, so with 100% schema coverage a baseline 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 clearly states a specific action: providing a plain-English description and category for a CPT/HCPCS procedure code. It also names the resource type and differentiates from sibling tools like explain_denial_code by specifying procedure codes.
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?
No explicit guidance is given about when to use this tool versus alternatives. The description implies a use case but does not mention exclusions, prerequisites, or sibling tool comparisons, leaving routing decisions to inference.
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. Dates show when Glama detected each change.
check_bill_markupexplain_denial_codeget_appeal_deadlineget_hospital_rateget_insurer_overturn_ratelookup_procedure_codeClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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!
Medigami: medical bill error scan, denial decoding, appeal deadlines, hospital price lookup
Search US hospital prices, compare costs, and find insurance-negotiated rates.
Medicare rates, hospital quality, and dispute scenarios from six federal public-domain datasets.
Insurer denial rates, appeal outcomes by treatment and condition, and appeal rights lookups.
