Is your US medical bill fair? Compares charges with Medicare rates and drafts a dispute letter.
Scored across 5 tools
check_price and check_whole_bill both compare charges against Medicare rates and check_price vs search_services both surface Medicare rates, but the descriptions clearly separate single-charge comparison, multi-line bill audit, plain-word code lookup, letter drafting, and hospital ownership lookup. The overlap is manageable because each description states its trigger scenario explicitly.
All five tools follow a clean verb_noun snake_case pattern: check_price, check_whole_bill, draft_bill_letter, look_up_hospital, search_services. No mixing of conventions or vague verbs.
Five tools is well-scoped for a medical bill checking assistant and each tool covers a distinct workflow step (lookup, compare, audit, draft, verify nonprofit status). Nothing feels padded or missing at the structural level.
The surface covers the core lifecycle: find codes, compare one or many charges, understand hospital charity obligations, and produce a dispute/request letter. Minor gaps remain (e.g. no tool to retrieve a full itemized bill or check drug/device pricing), but agents can work around these with the existing tools.
Compare a charge with Medicare's rate for one service. For when someone asks whether a charge is high or what Medicare pays, for example "I was charged $450 for a 99213 office visit in Texas, is that too high?" or "what does Medicare pay for an MRI of the knee?". Takes the billing code if they have it, otherwise the service in plain words as q. Returns Medicare's 2026 rate for the state (or the city's own pricing area when city is given) in medicare_2026, the amount providers typically billed in 2024, and how many times the Medicare rate the charge is. For care in a hospital, hospital_facility_2026 gives Medicare's national rate for the hospital's own facility fee and comparison.compared_with says what the charge was set against. Dental work has no Medicare rate and returns 404 with a pointer to a free dental cost source.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | The service in plain words, used when there is no code, like "knee MRI" or "ER visit". | |
| city | No | City, for states where Medicare pays big cities differently, like Houston, Chicago, Miami or Los Angeles. Other places use the rest-of-state rate. | |
| code | No | Five-character CPT or HCPCS code from the bill, like 99213, 73721 or G0121. | |
| state | No | US state name or two-letter code, like Texas or TX. Med Bill Check is for US bills; a UK place gets a short answer pointing to UK sources. | |
| charged | No | The amount on the bill in US dollars, like 450. | |
| setting | No | Setting: office (clinic, office, imaging center) or facility (hospital or surgery center). Leave out to use the usual setting. | |
| billed_by | No | Whose bill the charge is on when the service was in a hospital: hospital (the hospital's own facility charge) or doctor (the doctor's or physician group's bill). Leave out if not known: the charge is then compared with both together. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds real behavior beyond that: dental work returns 404 with a pointer to a free source, a UK location yields a short UK-pointer answer, and the pre-2026 billed baseline plus ratio semantics are disclosed. Rate limits or latency are not mentioned, keeping it below 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?
The purpose and situational triggers are front-loaded, and the remaining sentences about return fields and the dental 404 are substantive rather than filler. It runs somewhat long with nested parentheticals, but no sentence is clearly expendable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the full burden of explaining returns and it does so concretely: medicare_2026, the 2024 billed baseline, the multiple-of-Medicare ratio, hospital_facility_2026 and comparison.compared_with, plus the dental 404 path. All seven parameters are covered, so an agent has everything needed to call and interpret it.
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 carries per-parameter meaning (baseline 3). The description nonetheless adds useful cross-parameter logic: pass the billing code if available, otherwise the plain-words service in q, and the city-vs-rest-of-state and hospital-vs-doctor fallback behavior. That is a genuine increment over the structured fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Compare a charge with Medicare's rate for one service') and the 'one service' scope implicitly separates it from the sibling check_whole_bill. An agent can identify the tool and its granularity without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear triggering condition ('when someone asks whether a charge is high or what Medicare pays') plus two concrete example questions, which is strong when-to-use guidance. It does not name an alternative such as check_whole_bill or state when not to use it, so it falls short of the explicit alternatives-routing seen in top-scoring definitions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check several lines of an itemized bill at once. For when someone reads out or pastes several lines from an itemized bill, for example "my ER bill has 99284 for $2,500, 85025 twice for $120 and 36415 three times, does anything look off?". Takes the lines as code, optional x and units, then the amount. Returns each line against Medicare's rate, totals, and questions_to_ask: repeated codes, units above Medicare's automated daily limit, the highest visit levels, hospital clinic facility fees and charges far above what providers typically bill. Lines of a hospital bill (any bill with an ER visit on it, or setting=facility) are compared with Medicare's hospital outpatient rate plus the doctor's part; each such line says compared_with.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City, for big cities with their own Medicare rates. | |
| lines | Yes | Up to 15 bill lines separated by commas: code, then x and units if more than one, then the amount. Example: 99284:2500, 85025x2:120, 36415:45. | |
| state | No | US state name or two-letter code. | |
| setting | No | Setting: office or facility. Leave out if not known. | |
| billed_by | No | Whose bill the charge is on when the service was in a hospital: hospital (the hospital's own facility charge) or doctor (the doctor's or physician group's bill). Leave out if not known: the charge is then compared with both together. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover safety (readOnly, idempotent, non-destructive), and the description adds substantial non-schema behavior: what is returned (per-line Medicare comparison, totals, questions_to_ask with the specific categories flagged), and the special handling for hospital/facility lines with the compared_with field. This is meaningful disclosure beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded and every sentence carries information, but the third sentence is a long run-on enumerating questions_to_ask categories, and the second sentence embeds a verbose quoted example. It is dense but slightly sprawling.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must carry the return-value burden, and it does: it names the returned comparison, totals, and questions_to_ask contents. The facility vs. office comparison logic and the compared_with annotation are also explained, leaving nothing an agent needs to call 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?
Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it explains the lines syntax (code, optional x and units, then amount) and how setting/facility lines are treated, including that omitted billed_by compares against both together. That exceeds what the schema alone conveys.
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 (check) and resource (several lines of an itemized bill) with the scope 'at once', which implies batch vs. the sibling check_price. It never names the sibling outright, so differentiation from check_price relies on inference from 'several lines at once'.
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 'For when someone reads out or pastes several lines...' clause plus a concrete example gives a clear usage context. It stops short of explicit exclusions or named alternatives (e.g., 'for a single code use check_price'), so it does not reach the 5 bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Draft a letter to a billing office for the user to send. For requests like "help me dispute this bill", "write a letter asking for an itemized bill", "can I ask for a discount?" or "how do I apply for charity care?". Returns a letter as plain text with [brackets] for anything not given, tips, and the user's No Surprises Act and Good Faith Estimate rights with official CMS links. It never sends anything.
| Name | Required | Description | Default |
|---|---|---|---|
| code | No | Billing code of the charge. With amount, a dispute letter adds Medicare's benchmark (for a hospital charge, the hospital outpatient rate as well as the doctor's part). | |
| date | No | Date of service. | |
| name | No | Patient or account holder name. | |
| type | Yes | Type: itemized (ask for an itemized bill), dispute (ask for a charge to be reviewed), discount (prompt-pay or self-pay discount), or assistance (financial assistance or charity care). | |
| state | No | US state, used for the benchmark in a dispute letter. | |
| amount | No | Amount charged or balance due, in US dollars. | |
| reason | No | A sentence on what the user wants checked, for a dispute letter. | |
| account | No | Account or invoice number on the bill. | |
| insured | No | Set to no if paying without insurance (self-pay), for a discount letter. | |
| service | No | The service in plain words. | |
| setting | No | Setting: office or facility (hospital or surgery center), for the benchmark in a dispute letter. ER visits and hospital clinic visits count as facility anyway. | |
| provider | No | Hospital, clinic or provider name. | |
| billed_by | No | Whose bill the charge is on when the service was in a hospital: hospital (the hospital's own facility charge) or doctor (the doctor's or physician group's bill). Leave out if not known: the charge is then compared with both together. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: it discloses exactly what is returned (plain text with [brackets] for missing values, tips, and No Surprises Act / Good Faith Estimate rights with CMS links) and closes with 'It never sends anything', which is a valuable reinforcement of the read-only contract.
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 key fact — draft a letter, never sent — leads the description, and the second sentence earns its length by covering both trigger examples and return content. It is slightly dense but has no filler sentences.
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 13-parameter generator with no output schema, the description covers the essentials: what it produces, how placeholders are marked, and that it is non-sending. The remaining detail (benchmark computation, enum behaviors) lives in a fully annotated schema, so nothing critical 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 description coverage is 100% across 13 parameters, and the enum values, units, and conditional logic (e.g. code+amount adds the Medicare benchmark, billed_by defaults to comparing both) are all documented in the schema itself. The description maps user phrasings to the four 'type' values but adds nothing beyond what the schema already states, so the baseline of 3 applies.
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 verb and resource ('Draft a letter to a billing office') and grounds it in four concrete user intents ('help me dispute this bill', 'write a letter asking for an itemized bill', etc.). None of the siblings (check_price, check_whole_bill, look_up_hospital, search_services) generate letters, so the boundary is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The quoted request examples make the triggering condition clear — the tool is for users who want to communicate with a billing office rather than look up prices or bills. It stops short of explicitly naming when to prefer a sibling or what to do if the request is purely informational, so it is strong context without formal exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Whether a hospital is nonprofit, for financial assistance. For requests like "is St. Luke's in Boise a nonprofit?" or "does this hospital have to offer charity care?". Returns how Medicare lists the hospital's ownership (nonprofit, government, for-profit), its city and main phone number, and what that means for financial assistance. Nonprofit hospitals must have a financial assistance policy.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City, to pick between hospitals with the same name. | |
| name | Yes | Hospital name as on the bill, like St. Luke's Regional Medical Center. | |
| state | No | US state name or two-letter code. Recommended, since many hospitals share names. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds value beyond that by naming the returned fields (ownership classification per Medicare, city, main phone number) and the downstream implication (nonprofits must have a financial assistance policy).
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 compact sentences: purpose, example queries, and returned content. The opening sentence largely restates the title, which is mild redundancy, but nothing is padded and the useful return-value information comes early.
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 correctly takes on describing the return values (ownership category, city, phone, financial-assistance meaning). This is sufficient for a simple 3-parameter lookup; only edge cases like hospitals not found in Medicare data are unaddressed.
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 name/city/state are already documented, including the disambiguation rationale. The description adds no additional syntax, format, or matching-behavior detail beyond what the schema provides, which is the expected 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?
The description states a specific resource (hospital ownership/nonprofit status) and the domain purpose (financial assistance eligibility), and it is clearly not a price or bill tool. It does not explicitly name a sibling, but the subject matter differentiates it from check_price, check_whole_bill, and search_services well enough.
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?
Concrete example questions ("is St. Luke's in Boise a nonprofit?", "does this hospital have to offer charity care?") make the triggering context clear. There is no explicit when-not guidance or routing to alternatives, but no overlap with siblings is apparent, so the implied usage is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find billing codes and Medicare rates by plain words. For when someone describes a service but has no code, or asks what a code means, for example "what's the code for a colonoscopy?", "how much does Medicare pay for a chest x-ray in Ohio?" or "what is code 99214?". Returns up to eight matching codes with Medicare's typical allowed and billed amounts.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Plain words or a code, like "hernia repair" or 99214. | |
| state | No | US state name or two-letter code. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, open-world, non-destructive behavior, so the safety profile is covered. The description adds real value beyond them: result cardinality ('up to eight matching codes') and return content (Medicare's typical allowed and billed amounts). It omits what happens on no-match, but that is minor.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded core purpose followed by trigger conditions and return summary, with no filler. Three illustrative examples are one more than strictly needed and the phrase 'by plain words' repeats the title, so it is efficient but not maximally tight.
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 adequately characterizes the response (up to eight codes with allowed and billed amounts), and both parameters are covered by the schema plus the state example. Missing only edge-case behavior such as no-match results or any default for state.
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 self-documented; per the rubric the baseline is 3. The Ohio example adds meaning the schema does not: it shows that `state` materially changes the Medicare rate, not just a formatting hint.
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 (find) plus two concrete resources (billing codes, Medicare rates) and the input modality (plain words). It implicitly separates itself from check_price by scoping to the no-code/description case, but it never names a sibling tool, so an agent must infer the boundary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit trigger condition ('when someone describes a service but has no code, or asks what a code means') backed by three concrete user utterances. It stops short of stating when NOT to use it (e.g., when a definitive code is already known), leaving a gap against check_price.
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.
check_price1 field changedInput schema / properties / setting / descriptionPrevious value: -"office (clinic, office, imaging center) or facility (hospital or surgery center). Leave out to use the usual setting."New value: +"Setting: office (clinic, office, imaging center) or facility (hospital or surgery center). Leave out to use the usual setting."check_whole_bill1 field changedInput schema / properties / setting / descriptionPrevious value: -"office or facility. Leave out if not known."New value: +"Setting: office or facility. Leave out if not known."draft_bill_letter3 fields changedInput schema / properties / insured / descriptionPrevious value: -"no if paying without insurance (self-pay), for a discount letter."New value: +"Set to no if paying without insurance (self-pay), for a discount letter."Input schema / properties / setting / descriptionPrevious value: -"office or facility (hospital or surgery center), for the benchmark in a dispute letter. ER visits and hospital clinic visits count as facility anyway."New value: +"Setting: office or facility (hospital or surgery center), for the benchmark in a dispute letter. ER visits and hospital clinic visits count as facility anyway."Input schema / properties / type / descriptionPrevious value: -"itemized (ask for an itemized bill), dispute (ask for a charge to be reviewed), discount (prompt-pay or self-pay discount), or assistance (financial assistance or charity care)."New value: +"Type: itemized (ask for an itemized bill), dispute (ask for a charge to be reviewed), discount (prompt-pay or self-pay discount), or assistance (financial assistance or charity care)."check_pricecheck_whole_billdraft_bill_letterlook_up_hospitalsearch_servicesMedigami: medical bill error scan, denial decoding, appeal deadlines, hospital price lookup
Search US hospital prices, compare costs, and find insurance-negotiated rates.
Medigami patient tools: rates, markups, denial codes, deadlines, overturn rates, procedure codes
Audit junk fees, project annual costs and draft dispute letters. Free.
Add one secure layer between your agents and this server.
