Skip to content

com.medigami/mcp

com.medigami/mcpmedigami.comstreamable-httpv1.0.0Scanned

Medigami: medical bill error scan, denial decoding, appeal deadlines, hospital price lookup

87 tools: 2 do something that can't be undone, 72 change things and 13 only read.

Tools: 0 delete, 2 irreversible, 72 write, 13 read.
  • Reads private data · 2
  • Reads text others write · 4
  • Can send data out · 0
  • No findings

Tools listed without sign-in. Remote posture

Anlyon alternative

74 of these tools change something. Run those as governed actions.

Declare what an action changes, and Anlyon puts it under a shared limit, binds every approval to the exact request, and grades the outcome. It works on any HTTPS API you can describe as an action.

Anlyon does not run, proxy or govern this MCP server. A tool your own code calls directly is not routed through Anlyon and is not governed by it.

Import an OpenAPI spec →

Tools

Grouped by what each tool does, most consequential first. Open one for its reasons and full description; descriptions are the publisher's own words.

87 tools

Can't be undone 2Claude Code: ask
  • billing_charge_vs_allowed_delta[Taxonomy III.51 — baseline response (public data only)] Delta between billed charge and payer-allowed amount for a claim line.No findings

    Why it is in this group

    • The name "billing_charge_vs_allowed_delta" says "charge": a word that usually means money moves, which cannot be taken back.
    Description, as the server wrote it
    [Taxonomy III.51 — baseline response (public data only)] Delta between billed charge and payer-allowed amount for a claim line. WHEN TO USE: User wants to understand what a service typically costs, compare prices across regions/providers, or gauge whether a billed amount is reasonable. WHEN NOT: For a specific bill they have in hand, scan_bill_for_errors is more actionable. For insurance-path estimates, use deductible_impact_calculator or coinsurance_simulator.
  • payment_plan_optimizer[Taxonomy X.180 — baseline response (public data only)] Optimize a payment plan structure for a patient balance.No findings

    Why it is in this group

    • The name "payment_plan_optimizer" says "payment": a word that usually means money moves, which cannot be taken back.
    Description, as the server wrote it
    [Taxonomy X.180 — baseline response (public data only)] Optimize a payment plan structure for a patient balance. WHEN TO USE: User has a balance and wants to structure a payment plan. Pass balance_usd and months. WHEN NOT: If user may qualify for charity care — run financial_assistance_finder first. EXAMPLES: - 12-month plan for $3K balance: `{"balance_usd":3000,"months":12}`
Changes things 72Claude Code: ask
  • appeal_argument_generator[Taxonomy VII.120 — baseline response (public data only)] Generate component arguments for an appeal letter: medical-necessity, contract, policy.No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    [Taxonomy VII.120 — baseline response (public data only)] Generate component arguments for an appeal letter: medical-necessity, contract, policy. WHEN TO USE: User has a denied claim and wants to appeal, or is preparing arguments / evidence / escalation steps for one. WHEN NOT: For explaining what a denial code means without drafting an appeal, use denial_code_explainer first. For finding a negotiation path on a non-denied bill, use negotiate_bill_script. EXAMPLES: - Argument blocks for CO-50 with UHC: `{"denial_code":"CO-50","insurer":"UnitedHealthcare"}`
  • appeal_escalation_path_finder[Taxonomy VII.129 — baseline response (public data only)] Find the correct escalation path for a denied claim (internal appeal → external review → DOI).No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    [Taxonomy VII.129 — baseline response (public data only)] Find the correct escalation path for a denied claim (internal appeal → external review → DOI). WHEN TO USE: User needs to know the deadlines and agencies for each step of appealing a denial. Pass state (e.g. 'CA') and insurer for state-specific and insurer-specific values. WHEN NOT: Without state/insurer — still works but returns generic federal defaults. Follow up with state for best answer. EXAMPLES: - CA / UnitedHealthcare escalation path: `{"state":"CA","insurer":"UnitedHealthcare"}`
  • appeal_success_predictor[Taxonomy E.25 — delegates to estimate_appeal_success] Given a denial, predict the probability of a successful appeal.No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    [Taxonomy E.25 — delegates to estimate_appeal_success] Given a denial, predict the probability of a successful appeal. Returns probability with 95% CI, sample size, and recommended appeal-strategy tags. WHEN TO USE: User or caller wants a probabilistic estimate (denial likelihood, appeal success, payment delay, etc.) to decide whether to pursue a path. WHEN NOT: For hard facts (dollar amounts, code definitions, deadlines). Predictions carry confidence bands; call out the uncertainty when you relay the number.
  • batch_scan_billsScan multiple medical bills in one call.No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    Scan multiple medical bills in one call. Returns per-bill anomaly lists + total recovery estimate across the batch. Input is a list of {bill_text, provider?, insurer?} items (max 10 per call). Much faster than serial scan_bill_for_errors when handling a bulk upload. WHEN TO USE: User has multiple bills or EOBs to review at once (e.g. a family's bills from one visit, or a year of statements). WHEN NOT: For a single bill (use scan_bill_for_errors).
  • bill_shock_predictor[Taxonomy X.179 — baseline response (public data only)] Predict risk that a planned service will trigger an unexpected large bill.No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    [Taxonomy X.179 — baseline response (public data only)] Predict risk that a planned service will trigger an unexpected large bill. WHEN TO USE: User planning a service and wants to know if it will trigger an unexpected-large-bill situation. Pass expected_charge_usd and optionally cpt_code to get Medicare-ratio context. WHEN NOT: For a bill already received — scan_bill_for_errors first. EXAMPLES: - Check shock risk on $5,000 office visit: `{"expected_charge_usd":5000,"cpt_code":"99213"}`
  • bundling_violation_detector[Taxonomy C.16 — delegates to scan_bill_for_errors] Detect CPT unbundling (billing components of a procedure separately to inflate the claim).No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    [Taxonomy C.16 — delegates to scan_bill_for_errors] Detect CPT unbundling (billing components of a procedure separately to inflate the claim). Uses the CMS NCCI edits plus payer-specific bundling rules. WHEN TO USE: Caller is building or validating a claim payload before submission — format, structure, completeness, alignment. WHEN NOT: For an already-submitted and denied claim, use generate_appeal_letter. For market pricing context, use benchmark_payer_rate.
  • cash_price_estimator[Taxonomy III.39 — baseline response (public data only)] Estimate a fair cash price for a service in a given region (no-insurance path).No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    [Taxonomy III.39 — baseline response (public data only)] Estimate a fair cash price for a service in a given region (no-insurance path). WHEN TO USE: Uninsured/self-pay user wants a fair-market cash price for a service. Returns Medicare national as a floor + commercial-multiple band. WHEN NOT: For insurance-covered scenarios (deductible_impact_calculator + coinsurance_simulator). EXAMPLES: - Cash price for office visit: `{"cpt_code":"99213","zip3":"902"}`
  • cash_vs_insurance_optimizer[Taxonomy H.41 — baseline response (public data only)] For a given service + patient plan, determine whether cash-pay + charity-care beats insurance billing.No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    [Taxonomy H.41 — baseline response (public data only)] For a given service + patient plan, determine whether cash-pay + charity-care beats insurance billing. WHEN TO USE: User is planning for a medical expense, comparing plan options, looking for financial assistance, or trying to structure a payment plan. WHEN NOT: For billing-error analysis (scan_bill_for_errors) or appeal drafting (generate_appeal_letter).
  • claim_consistency_checker[Taxonomy C.14 — delegates to scan_bill_for_errors] Detect internal contradictions in a claim: time mismatches, mutually exclusive codes, missing required fields, patient-gender/pr…No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    [Taxonomy C.14 — delegates to scan_bill_for_errors] Detect internal contradictions in a claim: time mismatches, mutually exclusive codes, missing required fields, patient-gender/procedure mismatches. WHEN TO USE: Caller is building or validating a claim payload before submission — format, structure, completeness, alignment. WHEN NOT: For an already-submitted and denied claim, use generate_appeal_letter. For market pricing context, use benchmark_payer_rate.
  • claim_duplicate_line_detector[Taxonomy IV.75 — baseline response (public data only)] Detect duplicated service lines within a single claim.No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    [Taxonomy IV.75 — baseline response (public data only)] Detect duplicated service lines within a single claim. WHEN TO USE: Caller is building or validating a claim payload before submission — format, structure, completeness, alignment. WHEN NOT: For an already-submitted and denied claim, use generate_appeal_letter. For market pricing context, use benchmark_payer_rate.
  • claim_rebuttal_generator[Taxonomy VII.128 — baseline response (public data only)] Generate a rebuttal to a payer's denial rationale point-by-point.No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    [Taxonomy VII.128 — baseline response (public data only)] Generate a rebuttal to a payer's denial rationale point-by-point. WHEN TO USE: User has a denied claim and wants to appeal, or is preparing arguments / evidence / escalation steps for one. WHEN NOT: For explaining what a denial code means without drafting an appeal, use denial_code_explainer first. For finding a negotiation path on a non-denied bill, use negotiate_bill_script.
  • claim_reconsideration_builder[Taxonomy VII.132 — baseline response (public data only)] Build a claim reconsideration request (lighter-weight than a formal appeal).No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    [Taxonomy VII.132 — baseline response (public data only)] Build a claim reconsideration request (lighter-weight than a formal appeal). WHEN TO USE: User has a denied claim and wants to appeal, or is preparing arguments / evidence / escalation steps for one. WHEN NOT: For explaining what a denial code means without drafting an appeal, use denial_code_explainer first. For finding a negotiation path on a non-denied bill, use negotiate_bill_script.
  • code_bundle_validator[Taxonomy II.25 — baseline response (public data only)] Check a set of CPT codes against NCCI bundling rules (distinct from modifier-based unbundling).No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    [Taxonomy II.25 — baseline response (public data only)] Check a set of CPT codes against NCCI bundling rules (distinct from modifier-based unbundling). WHEN TO USE: User asks about medical codes: what a CPT/ICD/HCPCS code means, whether a code combination is valid, or how to map between them. WHEN NOT: For full bill scans (use scan_bill_for_errors). For appealing a coding-related denial (use generate_appeal_letter).
  • code_conflict_detector[Taxonomy A.5 — delegates to scan_bill_for_errors] Detect CPT unbundling, mutually exclusive code pairs, and NCCI edit violations in a set of codes.No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    [Taxonomy A.5 — delegates to scan_bill_for_errors] Detect CPT unbundling, mutually exclusive code pairs, and NCCI edit violations in a set of codes. Implemented by the bill scanner's anomaly engine. WHEN TO USE: User asks about medical codes: what a CPT/ICD/HCPCS code means, whether a code combination is valid, or how to map between them. WHEN NOT: For full bill scans (use scan_bill_for_errors). For appealing a coding-related denial (use generate_appeal_letter).
  • coinsurance_simulator[Taxonomy III.49 — baseline response (public data only)] Simulate member coinsurance exposure across plan-design variants.No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    [Taxonomy III.49 — baseline response (public data only)] Simulate member coinsurance exposure across plan-design variants. WHEN TO USE: User wants to model their coinsurance share of a post-deductible charge. Pass charge_usd and optionally coinsurance_rate. WHEN NOT: For flat-copay services (copay_model). EXAMPLES: - Simulate 20% coinsurance on $1K: `{"charge_usd":1000,"coinsurance_rate":0.2}`
  • copay_model[Taxonomy III.50 — baseline response (public data only)] Model member copay for a service by plan-design class.No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    [Taxonomy III.50 — baseline response (public data only)] Model member copay for a service by plan-design class. WHEN TO USE: User wants the typical copay for a service type (primary / specialist / er). Uses KFF EHBS 2024 averages. WHEN NOT: For patient-specific plan details — copay varies by plan design. EXAMPLES: - Typical specialist copay: `{"service_type":"specialist"}`
  • cpt_to_icd_mapper[Taxonomy II.21 — baseline response (public data only)] For a given CPT, surface the ICD-10 codes typically paired with it for medical-necessity support.No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    [Taxonomy II.21 — baseline response (public data only)] For a given CPT, surface the ICD-10 codes typically paired with it for medical-necessity support. WHEN TO USE: User has a CPT code and wants to know what ICD-10 diagnoses commonly pair with it for medical-necessity support. WHEN NOT: For specific payer policy lookups (code_validation). EXAMPLES: - Common ICDs for 99213: `{"cpt_code":"99213"}`
  • decode_denialDecode a CARC (Claim Adjustment Reason Code) denial code into plain English.No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    Decode a CARC (Claim Adjustment Reason Code) denial code into plain English. Returns meaning, category, whether it's typically reversible on appeal, and appeal guidance. Source: public X12 External Code List + CMS/ERISA public rules. Free, no auth. WHEN TO USE: Reference lookups: individual code details, verifying a provider registry entry, checking a prior Medigami response's signature, or tracking an outcome. WHEN NOT: For composite workflows use the higher-level tool that calls these internally.
  • deductible_impact_calculator[Taxonomy III.48 — baseline response (public data only)] Estimate how a planned service will draw against the member's deductible.No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    [Taxonomy III.48 — baseline response (public data only)] Estimate how a planned service will draw against the member's deductible. WHEN TO USE: User wants to know how a specific charge affects their deductible (how much draws down, remaining after, post-deductible exposure). WHEN NOT: For total annual out-of-pocket across a year (healthcare_budget_forecaster). EXAMPLES: - Compute deductible drawdown for $4K charge: `{"charge_usd":4000,"deductible_remaining_usd":1735}`
  • denial_code_explainer[Taxonomy VII.131 — baseline response (public data only)] Explain a CARC/RARC denial code in plain language with common causes.No findings

    Why it is in this group

    • The input takes a statement or command to run (input.code), which can change anything it can reach.
    Description, as the server wrote it
    [Taxonomy VII.131 — baseline response (public data only)] Explain a CARC/RARC denial code in plain language with common causes. WHEN TO USE: User asks 'what does CO-16 mean' or similar — any CARC/RARC code. Returns full X12 table entry when available with meaning, category, typical root cause, primary remediation, and reversibility flag. WHEN NOT: For drafting an appeal (generate_appeal_letter). For the full escalation path (appeal_escalation_path_finder). EXAMPLES: - Explain CARC CO-16: `{"code":"CO-16"}` - Explain CARC CO-50 (medical necessity): `{"code":"CO-50"}`
  • denial_reason_classifier[Taxonomy VI.106 — baseline response (public data only)] Classify a denial letter or remittance advice into normalized denial-reason categories.No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    [Taxonomy VI.106 — baseline response (public data only)] Classify a denial letter or remittance advice into normalized denial-reason categories. WHEN TO USE: User or caller wants a probabilistic estimate (denial likelihood, appeal success, payment delay, etc.) to decide whether to pursue a path. WHEN NOT: For hard facts (dollar amounts, code definitions, deadlines). Predictions carry confidence bands; call out the uncertainty when you relay the number.
  • denial_response_builder[Taxonomy VII.121 — baseline response (public data only)] Build a denial-response package tailored to the denial reason code.No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    [Taxonomy VII.121 — baseline response (public data only)] Build a denial-response package tailored to the denial reason code. WHEN TO USE: User has a denied claim and wants to appeal, or is preparing arguments / evidence / escalation steps for one. WHEN NOT: For explaining what a denial code means without drafting an appeal, use denial_code_explainer first. For finding a negotiation path on a non-denied bill, use negotiate_bill_script. EXAMPLES: - Build response package for CO-197: `{"denial_reason":"CO-197","insurer":"Aetna","cpt_code":"45378","amount":1850}`
  • dispute_case_builder[Taxonomy VII.123 — baseline response (public data only)] Assemble a complete dispute case file including claim, denial, evidence, and timeline.No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    [Taxonomy VII.123 — baseline response (public data only)] Assemble a complete dispute case file including claim, denial, evidence, and timeline. WHEN TO USE: User has a denied claim and wants to appeal, or is preparing arguments / evidence / escalation steps for one. WHEN NOT: For explaining what a denial code means without drafting an appeal, use denial_code_explainer first. For finding a negotiation path on a non-denied bill, use negotiate_bill_script.
  • estimate_appeal_successProbability an appeal will be approved, derived from outcome-labeled data weighted by label provenance (IRO determinations, EOB reversals, physician confirmations).No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    Probability an appeal will be approved, derived from outcome-labeled data weighted by label provenance (IRO determinations, EOB reversals, physician confirmations). Returns probability + 95% CI + sample_size + expected_days_to_resolution + tracking_id. Report the actual outcome later via POST /api/outcomes/record with the same tracking_id to improve future estimates. WHEN TO USE: User or caller wants probability-of-reversal before spending time on an appeal. Returns probability + confidence interval. WHEN NOT: For picking among multiple appeal strategies (appeal_strategy_success_model). As a stand-alone — usually chain into generate_appeal_letter. EXAMPLES: - Gauge CO-50 appeal odds on Aetna: `{"insurer":"Aetna","denial_reason":"CO-50","cpt_code":"72148","state":"TX","amount":1200}`
  • evidence_pack_generator[Taxonomy VII.124 — baseline response (public data only)] Generate an evidence package supporting a claim or appeal (references, studies, policies).No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    [Taxonomy VII.124 — baseline response (public data only)] Generate an evidence package supporting a claim or appeal (references, studies, policies). WHEN TO USE: User has a denied claim and wants to appeal, or is preparing arguments / evidence / escalation steps for one. WHEN NOT: For explaining what a denial code means without drafting an appeal, use denial_code_explainer first. For finding a negotiation path on a non-denied bill, use negotiate_bill_script.
  • fair_price_estimator[Taxonomy B.8 — delegates to benchmark_payer_rate] Fair-market price distribution for a service: DP-noised percentiles (p10, p25, p50, p75, p90) for the given CPT in a ZIP3 region.No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    [Taxonomy B.8 — delegates to benchmark_payer_rate] Fair-market price distribution for a service: DP-noised percentiles (p10, p25, p50, p75, p90) for the given CPT in a ZIP3 region. WHEN TO USE: User wants to understand what a service typically costs, compare prices across regions/providers, or gauge whether a billed amount is reasonable. WHEN NOT: For a specific bill they have in hand, scan_bill_for_errors is more actionable. For insurance-path estimates, use deductible_impact_calculator or coinsurance_simulator.
  • financial_assistance_finder[Taxonomy X.181 — baseline response (public data only)] Find applicable financial-assistance programs (hospital charity, 340B, state, pharma).No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    [Taxonomy X.181 — baseline response (public data only)] Find applicable financial-assistance programs (hospital charity, 340B, state, pharma). WHEN TO USE: User needs help paying a medical bill. Pass household_income_usd and family_size for FPL-based eligibility flags across 6 programs (501(r) charity, Medicaid, PE, manufacturer PAPs, 340B, state pools). WHEN NOT: For insured users with low exposure (use coinsurance_simulator or deductible_impact_calculator). EXAMPLES: - Find assistance for family of 3 at $45K income: `{"household_income_usd":45000,"family_size":3}`
  • financial_exposure_model[Taxonomy X.176 — delegates to financial_risk_exposure_model] Model a member's financial exposure.No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    [Taxonomy X.176 — delegates to financial_risk_exposure_model] Model a member's financial exposure. Alias of financial_risk_exposure_model. WHEN TO USE: User is planning for a medical expense, comparing plan options, looking for financial assistance, or trying to structure a payment plan. WHEN NOT: For billing-error analysis (scan_bill_for_errors) or appeal drafting (generate_appeal_letter).
  • financial_risk_exposure_model[Taxonomy H.42 — baseline response (public data only)] Quantify a patient's financial exposure to medical-debt risk given current plan, health status, and historical claim volatili…No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    [Taxonomy H.42 — baseline response (public data only)] Quantify a patient's financial exposure to medical-debt risk given current plan, health status, and historical claim volatility. WHEN TO USE: User is planning for a medical expense, comparing plan options, looking for financial assistance, or trying to structure a payment plan. WHEN NOT: For billing-error analysis (scan_bill_for_errors) or appeal drafting (generate_appeal_letter).
  • format_citationFormat an LLM-citable reference to a previously-attested Medigami MCP response.No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    Format an LLM-citable reference to a previously-attested Medigami MCP response. Input: either the full signed envelope that an earlier attested tool returned, OR just a tracking_id. Returns a short citation string, a public verification URL a third party can open to inspect and cryptographically verify the payload, and a long-form attribution block. Use this after any substantive Medigami tool call (scan, estimate, resolve, benchmark) so the user has a verifiable reference to the specific answer and its expiration date. WHEN TO USE: After a substantive tool call, generate a citable string + short URL the LLM can paste into its user-facing response for later verification. WHEN NOT: For non-substantive lookups where citation is unnecessary. EXAMPLES: - Generate a citable URL from a tracking_id: `{"tracking_id":"evt_abc123"}`
  • format_medigami_citationDEPRECATED ALIAS of format_citation — kept for backward compatibility with v0.1.7 clients.No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    DEPRECATED ALIAS of format_citation — kept for backward compatibility with v0.1.7 clients. New code should call format_citation directly. WHEN TO USE: Reference lookups: individual code details, verifying a provider registry entry, checking a prior Medigami response's signature, or tracking an outcome. WHEN NOT: For composite workflows use the higher-level tool that calls these internally.
  • generate_appeal_letterGenerate a legally-grounded insurance appeal letter for a denied claim.No findings

    Why it is in this group

    • The name "generate_appeal_letter" says "generate": a word for a change.
    Description, as the server wrote it
    Generate a legally-grounded insurance appeal letter for a denied claim. Returns the letter as a template with [PATIENT NAME] and [PROVIDER NAME] placeholders (structured-only PHI posture). Includes legal citations, recommended attachments, and appeal-deadline calendar. WHEN TO USE: User has a specific claim denied and wants a drafted appeal letter. Requires insurer, denial_reason (CARC code), cpt_code, diagnosis (ICD-10), and dollar amount. Returns an attested letter with reversal rate, insurer-specific tips, recommended attachments. WHEN NOT: If the user only wants to understand a denial code, use denial_code_explainer first. If they haven't received a formal denial yet, don't draft — clarify status first. For non-CARC disputes (e.g. billing errors pre-adjudication), use scan_bill_for_errors. EXAMPLES: - Draft CO-16 appeal to UHC for office visit: `{"insurer":"UnitedHealthcare","d...
  • generate_appeal_letter_v2[Taxonomy F.28 — delegates to generate_appeal_letter] [Taxonomy alias] Generate a state-specific insurance appeal letter with UPL-safe disclaimers for 19 US states.No findings

    Why it is in this group

    • The name "generate_appeal_letter_v2" says "generate": a word for a change.
    Description, as the server wrote it
    [Taxonomy F.28 — delegates to generate_appeal_letter] [Taxonomy alias] Generate a state-specific insurance appeal letter with UPL-safe disclaimers for 19 US states. Same impl as generate_appeal_letter. WHEN TO USE: User has a denied claim and wants to appeal, or is preparing arguments / evidence / escalation steps for one. WHEN NOT: For explaining what a denial code means without drafting an appeal, use denial_code_explainer first. For finding a negotiation path on a non-denied bill, use negotiate_bill_script.
  • healthcare_budget_forecaster[Taxonomy X.183 — baseline response (public data only)] Forecast a household's annual healthcare spend based on plan + utilization.No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    [Taxonomy X.183 — baseline response (public data only)] Forecast a household's annual healthcare spend based on plan + utilization. WHEN TO USE: User planning annual healthcare spend, comparing plans, or estimating worst-case exposure. WHEN NOT: For a specific procedure cost (benchmark_payer_rate). EXAMPLES: - Forecast annual spend range: `{}`
  • icd_to_cpt_mapper[Taxonomy II.22 — baseline response (public data only)] For a given ICD-10, surface the CPT codes typically billed for that diagnosis.No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    [Taxonomy II.22 — baseline response (public data only)] For a given ICD-10, surface the CPT codes typically billed for that diagnosis. WHEN TO USE: User has an ICD-10 diagnosis and wants to know what CPTs are commonly billed for it. WHEN NOT: For planning specific services (use benchmark_payer_rate once the CPT is chosen). EXAMPLES: - Common CPTs for essential hypertension: `{"icd10_code":"I10"}`
  • inflation_adjusted_price_model[Taxonomy III.46 — baseline response (public data only)] Inflation-adjusted price comparison across years for a CPT.No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    [Taxonomy III.46 — baseline response (public data only)] Inflation-adjusted price comparison across years for a CPT. WHEN TO USE: User has a historical dollar amount and wants it adjusted for medical-care inflation to a given year. WHEN NOT: For current market prices (benchmark_payer_rate). EXAMPLES: - Adjust $1K 3yr forward at medical CPI: `{"base_amount_usd":1000,"years":3}`
  • insurance_plan_optimizer[Taxonomy H.39 — baseline response (public data only)] Given a patient's historical claim patterns, rank available insurance plans by expected annual cost.No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    [Taxonomy H.39 — baseline response (public data only)] Given a patient's historical claim patterns, rank available insurance plans by expected annual cost. WHEN TO USE: User is planning for a medical expense, comparing plan options, looking for financial assistance, or trying to structure a payment plan. WHEN NOT: For billing-error analysis (scan_bill_for_errors) or appeal drafting (generate_appeal_letter).
  • insurance_response_interpreter[Taxonomy F.31 — baseline response (public data only)] Parse an insurer's response letter or EOB into structured fields: denial reason codes, appeal rights, deadlines, next-step re…No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    [Taxonomy F.31 — baseline response (public data only)] Parse an insurer's response letter or EOB into structured fields: denial reason codes, appeal rights, deadlines, next-step recommendations. WHEN TO USE: User has a denied claim and wants to appeal, or is preparing arguments / evidence / escalation steps for one. WHEN NOT: For explaining what a denial code means without drafting an appeal, use denial_code_explainer first. For finding a negotiation path on a non-denied bill, use negotiate_bill_script.
  • insurance_value_optimizer[Taxonomy X.185 — baseline response (public data only)] Recommend insurance-plan selections to maximize value given projected utilization.No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    [Taxonomy X.185 — baseline response (public data only)] Recommend insurance-plan selections to maximize value given projected utilization. WHEN TO USE: User is planning for a medical expense, comparing plan options, looking for financial assistance, or trying to structure a payment plan. WHEN NOT: For billing-error analysis (scan_bill_for_errors) or appeal drafting (generate_appeal_letter).
  • market_price_distribution_model[Taxonomy III.55 — baseline response (public data only)] Full DP-noised market price distribution for a CPT+region pair.No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    [Taxonomy III.55 — baseline response (public data only)] Full DP-noised market price distribution for a CPT+region pair. WHEN TO USE: User wants to understand what a service typically costs, compare prices across regions/providers, or gauge whether a billed amount is reasonable. WHEN NOT: For a specific bill they have in hand, scan_bill_for_errors is more actionable. For insurance-path estimates, use deductible_impact_calculator or coinsurance_simulator.
  • maximize_recoveryGiven a prior scan_id, returns a prioritized action list: anomalies ranked by (expected overcharge x recovery probability), with the next steps to pursue each.No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    Given a prior scan_id, returns a prioritized action list: anomalies ranked by (expected overcharge x recovery probability), with the next steps to pursue each. Use after scan_bill_for_errors. WHEN TO USE: User has already run scan_bill_for_errors and wants the anomalies ranked by expected dollar recovery. WHEN NOT: As a first call — always scan first.
  • medical_spending_analyzer[Taxonomy X.184 — baseline response (public data only)] Analyze a patient's medical spending over a period and surface optimization opportunities.No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    [Taxonomy X.184 — baseline response (public data only)] Analyze a patient's medical spending over a period and surface optimization opportunities. WHEN TO USE: User is planning for a medical expense, comparing plan options, looking for financial assistance, or trying to structure a payment plan. WHEN NOT: For billing-error analysis (scan_bill_for_errors) or appeal drafting (generate_appeal_letter).
  • medigami_deadlineFederal appeal-deadline window (ERISA §503 internal-appeal / ACA §2719 external-review / NSA IDR) for a plan type.No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    • The server marks it read-only (readOnlyHint: true), but an annotation never lowers a class.
    Description, as the server wrote it
    Federal appeal-deadline window (ERISA §503 internal-appeal / ACA §2719 external-review / NSA IDR) for a plan type. Public regulator data, k-anonymity floored, not legal advice. WHEN TO USE: Reference lookups: individual code details, verifying a provider registry entry, checking a prior Medigami response's signature, or tracking an outcome. WHEN NOT: For composite workflows use the higher-level tool that calls these internally.

    Annotations the server declares

    • title: Appeal deadline
    • readOnlyHint: true
    • destructiveHint: false
    • idempotentHint: true
    • openWorldHint: false
  • medigami_oddsHistorical external-review overturn rate published by the state regulator for the insurer you name, in a regulated venue (CA/NY/MD/NJ/MI/OH/NC).No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    • The server marks it read-only (readOnlyHint: true), but an annotation never lowers a class.
    Description, as the server wrote it
    Historical external-review overturn rate published by the state regulator for the insurer you name, in a regulated venue (CA/NY/MD/NJ/MI/OH/NC). Returns one insurer's own rate — not a comparison or ranking against other insurers. Public regulator data, k-anonymity floored, not legal advice. WHEN TO USE: Reference lookups: individual code details, verifying a provider registry entry, checking a prior Medigami response's signature, or tracking an outcome. WHEN NOT: For composite workflows use the higher-level tool that calls these internally.

    Annotations the server declares

    • title: Denial overturn odds
    • readOnlyHint: true
    • destructiveHint: false
    • idempotentHint: true
    • openWorldHint: false
  • medigami_rateA hospital's own MRF-published negotiated rate for a CPT code (no billed-amount comparison — use medigami_roast for that).No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    • The server marks it read-only (readOnlyHint: true), but an annotation never lowers a class.
    Description, as the server wrote it
    A hospital's own MRF-published negotiated rate for a CPT code (no billed-amount comparison — use medigami_roast for that). Public regulator data, k-anonymity floored, not legal advice. WHEN TO USE: Reference lookups: individual code details, verifying a provider registry entry, checking a prior Medigami response's signature, or tracking an outcome. WHEN NOT: For composite workflows use the higher-level tool that calls these internally.

    Annotations the server declares

    • title: Negotiated rate
    • readOnlyHint: true
    • destructiveHint: false
    • idempotentHint: true
    • openWorldHint: false
  • negotiate_bill_scriptGenerate a phone script the user can read when negotiating a medical bill directly with the provider.No findings

    Why it is in this group

    • The description's first verb is "generate": a word for a change.
    Description, as the server wrote it
    Generate a phone script the user can read when negotiating a medical bill directly with the provider. Combines DP-noised commercial rate benchmarks + the caller's household income + federal charity-care rules (IRS §501(r)) into three negotiation angles: financial assistance, self-pay discount, and itemized-bill coding review. Returns the script + reference-only benchmark range (for the user's own research, not an insurance-consulting recommendation) + charity-care tier. Output is educational only; the user negotiates on their own behalf. Some states (notably NY, FL, CA) regulate public-adjuster activity — the attached disclaimer references this. WHEN TO USE: User wants talking points and a target settlement range to negotiate a medical bill with the provider. Best for self-pay and out-of-network balances. WHEN NOT: For a bill that was denied (generate_appeal_letter — the payer, not ...
  • negotiation_strategy_generator[Taxonomy F.30 — baseline response (public data only)] Given a bill + patient situation, generate a ranked negotiation strategy: hardship appeal, charity-care application, itemizat…No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    [Taxonomy F.30 — baseline response (public data only)] Given a bill + patient situation, generate a ranked negotiation strategy: hardship appeal, charity-care application, itemization request, phone scripts. WHEN TO USE: User has a denied claim and wants to appeal, or is preparing arguments / evidence / escalation steps for one. WHEN NOT: For explaining what a denial code means without drafting an appeal, use denial_code_explainer first. For finding a negotiation path on a non-denied bill, use negotiate_bill_script.
  • out_of_pocket_optimizer[Taxonomy X.174 — baseline response (public data only)] Optimize out-of-pocket spend across a sequence of planned services.No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    [Taxonomy X.174 — baseline response (public data only)] Optimize out-of-pocket spend across a sequence of planned services. WHEN TO USE: User is planning for a medical expense, comparing plan options, looking for financial assistance, or trying to structure a payment plan. WHEN NOT: For billing-error analysis (scan_bill_for_errors) or appeal drafting (generate_appeal_letter).
  • overpriced_service_detector[Taxonomy III.53 — baseline response (public data only)] Flag services billed materially above market percentile thresholds.No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    [Taxonomy III.53 — baseline response (public data only)] Flag services billed materially above market percentile thresholds. WHEN TO USE: User wants to understand what a service typically costs, compare prices across regions/providers, or gauge whether a billed amount is reasonable. WHEN NOT: For a specific bill they have in hand, scan_bill_for_errors is more actionable. For insurance-path estimates, use deductible_impact_calculator or coinsurance_simulator.
  • patient_cost_explainer[Taxonomy X.182 — baseline response (public data only)] Explain why a specific charge appears on a bill in plain language.No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    [Taxonomy X.182 — baseline response (public data only)] Explain why a specific charge appears on a bill in plain language. WHEN TO USE: User is planning for a medical expense, comparing plan options, looking for financial assistance, or trying to structure a payment plan. WHEN NOT: For billing-error analysis (scan_bill_for_errors) or appeal drafting (generate_appeal_letter).
  • patient_cost_forecaster[Taxonomy H.38 — baseline response (public data only)] Given a patient's plan + predicted care needs, forecast annual out-of-pocket spend across expected claims.No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    [Taxonomy H.38 — baseline response (public data only)] Given a patient's plan + predicted care needs, forecast annual out-of-pocket spend across expected claims. WHEN TO USE: User is planning for a medical expense, comparing plan options, looking for financial assistance, or trying to structure a payment plan. WHEN NOT: For billing-error analysis (scan_bill_for_errors) or appeal drafting (generate_appeal_letter).
  • patient_financial_risk_score[Taxonomy X.186 — baseline response (public data only)] Score a patient's financial risk exposure from planned or ongoing care.No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    [Taxonomy X.186 — baseline response (public data only)] Score a patient's financial risk exposure from planned or ongoing care. WHEN TO USE: User is planning for a medical expense, comparing plan options, looking for financial assistance, or trying to structure a payment plan. WHEN NOT: For billing-error analysis (scan_bill_for_errors) or appeal drafting (generate_appeal_letter).
  • payer_specific_appeal_templates[Taxonomy VII.130 — baseline response (public data only)] Return payer-specific appeal templates known to perform well.No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    [Taxonomy VII.130 — baseline response (public data only)] Return payer-specific appeal templates known to perform well. WHEN TO USE: User has a denied claim and wants to appeal, or is preparing arguments / evidence / escalation steps for one. WHEN NOT: For explaining what a denial code means without drafting an appeal, use denial_code_explainer first. For finding a negotiation path on a non-denied bill, use negotiate_bill_script.
  • price_anomaly_detector[Taxonomy III.52 — baseline response (public data only)] Detect service-line prices statistically anomalous versus market.No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    [Taxonomy III.52 — baseline response (public data only)] Detect service-line prices statistically anomalous versus market. WHEN TO USE: User wants to understand what a service typically costs, compare prices across regions/providers, or gauge whether a billed amount is reasonable. WHEN NOT: For a specific bill they have in hand, scan_bill_for_errors is more actionable. For insurance-path estimates, use deductible_impact_calculator or coinsurance_simulator.
  • price_outlier_detector[Taxonomy III.56 — baseline response (public data only)] Detect claim-line outliers relative to a learned market distribution.No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    [Taxonomy III.56 — baseline response (public data only)] Detect claim-line outliers relative to a learned market distribution. WHEN TO USE: User wants to understand what a service typically costs, compare prices across regions/providers, or gauge whether a billed amount is reasonable. WHEN NOT: For a specific bill they have in hand, scan_bill_for_errors is more actionable. For insurance-path estimates, use deductible_impact_calculator or coinsurance_simulator.
  • price_recommendation_engine[Taxonomy III.58 — baseline response (public data only)] Recommend a reasonable price to propose to a provider for a service (self-pay or negotiation).No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    [Taxonomy III.58 — baseline response (public data only)] Recommend a reasonable price to propose to a provider for a service (self-pay or negotiation). WHEN TO USE: User wants to understand what a service typically costs, compare prices across regions/providers, or gauge whether a billed amount is reasonable. WHEN NOT: For a specific bill they have in hand, scan_bill_for_errors is more actionable. For insurance-path estimates, use deductible_impact_calculator or coinsurance_simulator.
  • price_variance_analyzer[Taxonomy B.9 — baseline response (public data only)] Given a target price and a CPT+region, return how many standard deviations above/below the market the target sits, plus confid…No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    [Taxonomy B.9 — baseline response (public data only)] Given a target price and a CPT+region, return how many standard deviations above/below the market the target sits, plus confidence. WHEN TO USE: User wants to understand what a service typically costs, compare prices across regions/providers, or gauge whether a billed amount is reasonable. WHEN NOT: For a specific bill they have in hand, scan_bill_for_errors is more actionable. For insurance-path estimates, use deductible_impact_calculator or coinsurance_simulator.
  • procedure_affordability_ranker[Taxonomy X.177 — baseline response (public data only)] Rank a set of procedures by affordability for a given member.No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    [Taxonomy X.177 — baseline response (public data only)] Rank a set of procedures by affordability for a given member. WHEN TO USE: User is planning for a medical expense, comparing plan options, looking for financial assistance, or trying to structure a payment plan. WHEN NOT: For billing-error analysis (scan_bill_for_errors) or appeal drafting (generate_appeal_letter).
  • procedure_cost_decomposition[Taxonomy III.57 — baseline response (public data only)] Decompose the cost of a procedure into component services + facility + professional fees.No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    [Taxonomy III.57 — baseline response (public data only)] Decompose the cost of a procedure into component services + facility + professional fees. WHEN TO USE: User wants to understand what a service typically costs, compare prices across regions/providers, or gauge whether a billed amount is reasonable. WHEN NOT: For a specific bill they have in hand, scan_bill_for_errors is more actionable. For insurance-path estimates, use deductible_impact_calculator or coinsurance_simulator.
  • regional_price_benchmark[Taxonomy III.43 — baseline response (public data only)] Regional price benchmark for a CPT at state/metro/ZIP3 granularity.No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    [Taxonomy III.43 — baseline response (public data only)] Regional price benchmark for a CPT at state/metro/ZIP3 granularity. WHEN TO USE: User wants to understand what a service typically costs, compare prices across regions/providers, or gauge whether a billed amount is reasonable. WHEN NOT: For a specific bill they have in hand, scan_bill_for_errors is more actionable. For insurance-path estimates, use deductible_impact_calculator or coinsurance_simulator.
  • scan_bill_for_errorsScan a medical bill or EOB text for errors: duplicate charges, CPT unbundling, upcoding, facility-fee overcharges.No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    Scan a medical bill or EOB text for errors: duplicate charges, CPT unbundling, upcoding, facility-fee overcharges. Returns flagged anomalies with estimated dollar impact and a total recovery estimate. PHI WARNING: bill text typically contains PHI (patient name, DOB, MRN, insurer ID). Medigami runs a server-side PHI redactor before any downstream LLM call when scan_bill is invoked from the public SKU, but best practice is to redact client-side before passing the bill through an LLM tool call. For your own bill only — this tool is not for reviewing someone else's claims. WHEN TO USE: User pastes or uploads a medical bill, EOB, itemized statement, hospital charge summary, or similar. The bill text can be raw (OCR output fine) — the scanner parses it. Prefer this over manual line-by-line analysis for any bill above ~$100. WHEN NOT: For a denial appeal (generate_appeal_letter). For pre-...
  • settlement_optimizer[Taxonomy F.32 — baseline response (public data only)] For a disputed bill, compute the optimal settlement target price balancing probability of acceptance against amount saved.No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    [Taxonomy F.32 — baseline response (public data only)] For a disputed bill, compute the optimal settlement target price balancing probability of acceptance against amount saved. WHEN TO USE: User has a denied claim and wants to appeal, or is preparing arguments / evidence / escalation steps for one. WHEN NOT: For explaining what a denial code means without drafting an appeal, use denial_code_explainer first. For finding a negotiation path on a non-denied bill, use negotiate_bill_script.
  • specialty_price_benchmark[Taxonomy III.44 — baseline response (public data only)] Price benchmark for a CPT within a specific provider specialty.No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    [Taxonomy III.44 — baseline response (public data only)] Price benchmark for a CPT within a specific provider specialty. WHEN TO USE: User wants to understand what a service typically costs, compare prices across regions/providers, or gauge whether a billed amount is reasonable. WHEN NOT: For a specific bill they have in hand, scan_bill_for_errors is more actionable. For insurance-path estimates, use deductible_impact_calculator or coinsurance_simulator.
  • submit_denial_letterSubmit a medical-claim denial letter to the Medigami Denial Common Crawl (public aggregate dataset).Reads text others writeNo findings

    Why it is in this group

    • The name "submit_denial_letter" says "submit": a word for a change.

    What it can reach

    • untrusted-inputThe description's first sentence says "crawl": it reads web pages, which anyone can write.
    Description, as the server wrote it
    Submit a medical-claim denial letter to the Medigami Denial Common Crawl (public aggregate dataset). Consent-gated — caller must pass consent=true to attest the submission is voluntary. Server-side PHI scrubber runs before any storage; the public aggregate contains only coded fields (insurer_canonical, denial_reason_code, state, cpt_category, dollars_bin, days_to_resolution_bin). Raw text is never republished. Optional tracking_id closes the outcome loop to a prior Medigami scan / resolve call. WHEN TO USE: User wants to contribute a denial letter to the public Denial Common Crawl (consent-gated). PHI is scrubbed before aggregation. WHEN NOT: Just to explain a denial (denial_code_explainer). To draft a response (generate_appeal_letter).
  • supporting_document_selector[Taxonomy VII.135 — baseline response (public data only)] Select optimal supporting documents for an appeal from an available document pool.No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    [Taxonomy VII.135 — baseline response (public data only)] Select optimal supporting documents for an appeal from an available document pool. WHEN TO USE: User is preparing an appeal and needs a ranked list of supporting documents for the denial category. Pass denial_code. WHEN NOT: Without denial_code — still returns generic docs but category-specific ranking is the high-value output. EXAMPLES: - Docs for a CO-50 medical-necessity denial: `{"denial_code":"CO-50"}`
  • treatment_cost_comparator[Taxonomy X.178 — baseline response (public data only)] Compare expected costs across treatment alternatives for a condition.No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    [Taxonomy X.178 — baseline response (public data only)] Compare expected costs across treatment alternatives for a condition. WHEN TO USE: User is planning for a medical expense, comparing plan options, looking for financial assistance, or trying to structure a payment plan. WHEN NOT: For billing-error analysis (scan_bill_for_errors) or appeal drafting (generate_appeal_letter).
  • unbundling_detector[Taxonomy II.26 — delegates to scan_bill_for_errors] Detect CPT unbundling patterns in a claim.No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    [Taxonomy II.26 — delegates to scan_bill_for_errors] Detect CPT unbundling patterns in a claim. Alias of scan_bill_for_errors. WHEN TO USE: User asks about medical codes: what a CPT/ICD/HCPCS code means, whether a code combination is valid, or how to map between them. WHEN NOT: For full bill scans (use scan_bill_for_errors). For appealing a coding-related denial (use generate_appeal_letter).
  • verify_attestationVerify an Ed25519-signed Medigami MCP response envelope — confirm a medical-bill / appeal / denial / rate answer came from Medigami and hasn't been tampered with.No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    Verify an Ed25519-signed Medigami MCP response envelope — confirm a medical-bill / appeal / denial / rate answer came from Medigami and hasn't been tampered with. Input: the signed envelope + a public key (PEM) or expected-fingerprint you pinned out-of-band. Returns {valid, reason, tracking_id, timestamp, exp, public_key_fingerprint} so callers can cite the result as FRE 902(14) self-authenticating evidence. Usage: (a) Preferred: supply public_key_pem pinned out-of-band. (b) Otherwise: supply expected_fingerprint (SHA-256 of the pinned key); the envelope's embedded fingerprint is compared against it AND the key is fetched over HTTPS from the envelope's public_key_url (or Medigami's well-known URL) for signature verification. Freshness (exp) and fingerprint equality are both checked. Non-repudiation note: this tool deliberately does NOT silently fall back to the local server's ke...
  • verify_mcp_responseDEPRECATED ALIAS of verify_attestation — kept for backward compatibility with v0.1.7 clients.No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    DEPRECATED ALIAS of verify_attestation — kept for backward compatibility with v0.1.7 clients. New code should call verify_attestation directly. WHEN TO USE: Reference lookups: individual code details, verifying a provider registry entry, checking a prior Medigami response's signature, or tracking an outcome. WHEN NOT: For composite workflows use the higher-level tool that calls these internally.
  • watch_appeal_outcomeSubscribe to an appeal outcome by tracking_id.No findings

    Why it is in this group

    • The description's first verb is "subscribe": a word for a change.
    Description, as the server wrote it
    Subscribe to an appeal outcome by tracking_id. Blocks up to `timeout_seconds` (default 300). Returns the outcome payload as soon as it's recorded, or {status: 'timeout'} if nothing resolved within the window — caller re-invokes to keep watching. Tracking ids are returned by estimate_appeal_success and other Tier 3 moat tools. WHEN TO USE: Caller wants to subscribe to the outcome of an in-flight appeal by tracking_id. WHEN NOT: One-shot queries — prefer the callbacks via /api/outcomes/record.
  • watch_claim_denialSubscribe to a claim denial event for a given scan_id.No findings

    Why it is in this group

    • The description's first verb is "subscribe": a word for a change.
    Description, as the server wrote it
    Subscribe to a claim denial event for a given scan_id. Blocks up to `timeout_seconds`. Returns {status: 'denied', ...} as soon as the payer marks the claim denied in claim_status_history, or {status: 'timeout'} if no denial observed within the window. WHEN TO USE: Caller wants to stream denial events for a set of claims. WHEN NOT: One-shot queries.
  • zip_based_price_variance[Taxonomy III.41 — baseline response (public data only)] Report price variance for a CPT across ZIP3 regions with DP noise.No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    [Taxonomy III.41 — baseline response (public data only)] Report price variance for a CPT across ZIP3 regions with DP noise. WHEN TO USE: User wants to understand what a service typically costs, compare prices across regions/providers, or gauge whether a billed amount is reasonable. WHEN NOT: For a specific bill they have in hand, scan_bill_for_errors is more actionable. For insurance-path estimates, use deductible_impact_calculator or coinsurance_simulator.
Only reads 13Show 13 read-only tools
  • analyze_glp1_pathwaysFind all access pathways for a GLP-1 drug (Ozempic, Wegovy, Mounjaro, Zepbound) given patient eligibility factors.No findings

    Why it is in this group

    • The name "analyze_glp1_pathways" says "analyze": a word for reading.
    Description, as the server wrote it
    Find all access pathways for a GLP-1 drug (Ozempic, Wegovy, Mounjaro, Zepbound) given patient eligibility factors. Ranks pathways by monthly cost, flags prior-authorization rules and step-therapy, and returns the recommended appeal strategy if denial is likely. WHEN TO USE: User specifically asks about GLP-1 drugs (Ozempic, Wegovy, Mounjaro, Zepbound) — coverage, prior-auth strategy, step-therapy alternatives. WHEN NOT: For non-GLP-1 prescriptions (use optimize_prescription).
  • explain_appeal_successHuman-readable rationale for an appeal probability.No findings

    Why it is in this group

    • The name "explain_appeal_success" says "explain": a word for reading.
    Description, as the server wrote it
    Human-readable rationale for an appeal probability. Returns {probability, tier, recommended_posture, rationale, expected_days_to_resolution, tracking_id} grounded in aggregate outcome rates — not model feature weights. Use this when the caller wants 'why' in plain English alongside the number. WHEN TO USE: Reference lookups: individual code details, verifying a provider registry entry, checking a prior Medigami response's signature, or tracking an outcome. WHEN NOT: For composite workflows use the higher-level tool that calls these internally.
  • get_appeal_deadlineExternal-review filing deadline for a state + the date of the FINAL adverse determination.Reads text others writeNo findings

    Why it is in this group

    • The name "get_appeal_deadline" says "get": a word for reading.

    What it can reach

    • untrusted-inputThe description's first sentence says "review": it reads comments, which other people can write.
    Description, as the server wrote it
    External-review filing deadline for a state + the date of the FINAL adverse determination. Returns the deadline date, the statutory window label + citation, and whether the exact state-specific window still needs verification (most states carry a conservative NAIC-model 4-month floor unless statute-confirmed, e.g. CA/NY). Free, no auth. WHEN TO USE: Reference lookups: individual code details, verifying a provider registry entry, checking a prior Medigami response's signature, or tracking an outcome. WHEN NOT: For composite workflows use the higher-level tool that calls these internally.
  • get_venueWhere and how to file an external review for a given state — the venue name, filing channel (portal/mail/fax), portal URL, and whether expedited review is available.Reads private dataReads text others writeNo findings

    Why it is in this group

    • The name "get_venue" says "get": a word for reading.

    What it can reach

    • private-dataThe description's first sentence says "file": it reads files.
    • untrusted-inputThe description's first sentence says "review": it reads comments, which other people can write.
    Description, as the server wrote it
    Where and how to file an external review for a given state — the venue name, filing channel (portal/mail/fax), portal URL, and whether expedited review is available. Free, no auth. WHEN TO USE: Reference lookups: individual code details, verifying a provider registry entry, checking a prior Medigami response's signature, or tracking an outcome. WHEN NOT: For composite workflows use the higher-level tool that calls these internally.
  • lookup_cptLook up a CPT or HCPCS-J code or search by keyword.No findings

    Why it is in this group

    • The name "lookup_cpt" says "lookup": a word for reading.
    Description, as the server wrote it
    Look up a CPT or HCPCS-J code or search by keyword. Covers the most common outpatient billing codes (E/M, preventive, lab, imaging, procedure, cardiology, therapy, behavioral, vaccine, injectable drugs). Note: CPT is a registered trademark of the American Medical Association; full-dataset commercial use requires an AMA license. This tool provides short descriptors for identification in billing-review workflows. WHEN TO USE: User asks about a specific CPT/HCPCS procedure code or wants to search for codes by procedure description. WHEN NOT: For the expected ICD pairings (icd_to_cpt_mapper or cpt_to_icd_mapper). EXAMPLES: - Find CPT for routine office visit: `{"query":"office visit established patient"}`
  • lookup_icd10Look up an ICD-10-CM diagnosis code or search by keyword.No findings

    Why it is in this group

    • The name "lookup_icd10" says "lookup": a word for reading.
    Description, as the server wrote it
    Look up an ICD-10-CM diagnosis code or search by keyword. Input is either an exact code (e.g. 'E11.21') or a free-text description phrase ('type 2 diabetes with nephropathy'). Returns either the matching code + description or up to 20 candidate matches. Use when a clinical note uses non-standard phrasing and the correct code is needed for billing. WHEN TO USE: User asks about a specific ICD-10 diagnosis code or wants RAG-search over ICD-10 for a condition name. WHEN NOT: For the matching CPT codes (cpt_to_icd_mapper). For code validation against a payer (code_validation). EXAMPLES: - Find ICD-10 for hypertension: `{"query":"essential hypertension"}`
  • lookup_npiLook up a provider in the CMS NPPES National Provider Identifier registry.No findings

    Why it is in this group

    • The name "lookup_npi" says "lookup": a word for reading.
    Description, as the server wrote it
    Look up a provider in the CMS NPPES National Provider Identifier registry. Accepts a 10-digit NPI number OR a provider name (optionally narrowed by 2-char state). Returns up to 20 matches with entity type, specialty, taxonomy code, address, and status. Source: CMS NPPES public API (free, no key required). WHEN TO USE: User wants to verify a specific provider by NPI number, or find a provider by name + state. WHEN NOT: For provider performance analytics (provider_efficiency_score). EXAMPLES: - Look up a provider by NPI number: `{"npi_number":"1234567893"}`
  • lookup_provider_taxonomyLook up a NUCC provider taxonomy code (the specialty codes used on HIPAA transactions + NPI registrations) or search by keyword.No findings

    Why it is in this group

    • The name "lookup_provider_taxonomy" says "lookup": a word for reading.
    Description, as the server wrote it
    Look up a NUCC provider taxonomy code (the specialty codes used on HIPAA transactions + NPI registrations) or search by keyword. Returns classification + type + optional specialization. Source: NUCC Health Care Provider Taxonomy Code Set (public; CMS-accepted). WHEN TO USE: Resolving a NUCC provider taxonomy code to its specialty description. WHEN NOT: For finding a provider by specialty in a region (not yet implemented).
  • medigami_roastCompare a billed charge against a hospital's own MRF-published negotiated rate for a CPT code; returns the markup multiple.No findings

    Why it is in this group

    • The description's first verb is "compare": a word for reading.
    Description, as the server wrote it
    Compare a billed charge against a hospital's own MRF-published negotiated rate for a CPT code; returns the markup multiple. Public regulator data, k-anonymity floored, not legal advice. WHEN TO USE: Reference lookups: individual code details, verifying a provider registry entry, checking a prior Medigami response's signature, or tracking an outcome. WHEN NOT: For composite workflows use the higher-level tool that calls these internally.

    Annotations the server declares

    • title: Bill roast
    • readOnlyHint: true
    • destructiveHint: false
    • idempotentHint: true
    • openWorldHint: false
  • optimize_prescriptionFind the lowest-cost path for a prescription: generics, biosimilars, GoodRx coupons, manufacturer assistance, 90-day fills, and mail-order vs retail comparison.Reads private dataReads text others writeNo findings

    Why it is in this group

    • The description's first verb is "find": a word for reading.

    What it can reach

    • private-dataThe description's first sentence says "find" and "mail": it reads mail.
    • untrusted-inputThe description's first sentence says "find" and "mail": it reads inbound email, which other people can write.
    Description, as the server wrote it
    Find the lowest-cost path for a prescription: generics, biosimilars, GoodRx coupons, manufacturer assistance, 90-day fills, and mail-order vs retail comparison. Returns ranked options with annual savings vs current copay. WHEN TO USE: User asks about prescription cost — lowest-price generic, biosimilar, GoodRx coupon, mail-order, manufacturer assistance, or 90-day fill options. WHEN NOT: For insurance-covered Rx copay questions (use copay_model). For medical necessity appeals of formulary denials (use generate_appeal_letter). EXAMPLES: - Find cheapest path for atorvastatin 20mg: `{"drug_name":"atorvastatin 20mg","current_insurance_cost_30day":45,"is_maintenance_med":true}`
  • resolve_codes[Taxonomy A.1 — baseline response (public data only)] Unified code resolver — free-form query or clinical description → ranked ICD-10-CM, CPT, and HCPCS codes with confidence score…No findings

    Why it is in this group

    • The name "resolve_codes" says "resolve": a word for reading.
    Description, as the server wrote it
    [Taxonomy A.1 — baseline response (public data only)] Unified code resolver — free-form query or clinical description → ranked ICD-10-CM, CPT, and HCPCS codes with confidence scores. Use when you need to translate symptoms, procedures, or diagnoses into billable codes without running three separate lookups. WHEN TO USE: User asks about medical codes: what a CPT/ICD/HCPCS code means, whether a code combination is valid, or how to map between them. WHEN NOT: For full bill scans (use scan_bill_for_errors). For appealing a coding-related denial (use generate_appeal_letter).
  • resolve_denialEnd-to-end denial resolution: returns appeal probability + confidence interval + a drafted letter template grounded in aggregate outcome data + plan-context flags (ERISA, restricti…No findings

    Why it is in this group

    • The name "resolve_denial" says "resolve": a word for reading.
    Description, as the server wrote it
    End-to-end denial resolution: returns appeal probability + confidence interval + a drafted letter template grounded in aggregate outcome data + plan-context flags (ERISA, restrictive-adjuster state). One call, one tracking_id. No recovery-financing product is offered by this tool. WHEN TO USE: Single-shot composite: user has a specific denial and wants scan + estimate + appeal + citation in one call. WHEN NOT: For nuanced step-by-step workflows, call the individual tools in order. EXAMPLES: - End-to-end CO-197 denial resolution: `{"insurer":"Aetna","denial_reason":"CO-197","cpt_code":"45378","state":"TX","amount":1850}`
  • verify_dea_authorizationValidate the format + checksum of a DEA registration number (format: [A-Z][A-Z9][0-9]{7}; public checksum algorithm).No findings

    Why it is in this group

    • The description's first verb is "validate": a word for reading.
    Description, as the server wrote it
    Validate the format + checksum of a DEA registration number (format: [A-Z][A-Z9][0-9]{7}; public checksum algorithm). Useful as a sanity check on a DEA number you were given (e.g. on a prescription label or a provider's letterhead). Scope note: this tool confirms the number is well-formed — it does NOT verify current registration status or the specific controlled-substance schedule the holder is authorized to prescribe. Authority verification requires a licensed DEA data broker (DEA ARCOS, RxMix). WHEN TO USE: Checking if a provider's DEA registration covers a specific controlled-substance CPT. WHEN NOT: For non-controlled-substance claims.

This is not a safety rating, and no finding is not a safety guarantee. The groups and findings come from fixed checks of the tool definitions the server returned on the date shown, not from its code or what it does when called. How the checks work.

Exfil surface

Which tools read private data, which read text someone else can write, and which can send data out. One of each is a path a prompt injection can use.

No private-data, untrusted-input, outbound path in this server alone: no tool is tagged outbound.

Reads private data2
Reads files, mail, messages, databases, secrets, calendars or repositories.
Reads text others write4
Brings in text someone else can write: web pages, inbound email, messages, issues and comments.
Can send data out0
Can carry data to people or systems: it sends, posts or publishes, or takes a recipient, channel or URL.

Other servers in the same agent add their own tools to these paths. Audit your whole setup to see them together.

Remote posture

What anyone on the internet sees at the remote endpoint: an anonymous initialize and tools/list, and the public OAuth metadata.

Tools listed without sign-in

Looked at Oct 22, 2026, 14:36 UTC, unchanged since Oct 22, 2026. No credentials were sent and no tool was called. What is looked at.

Reachable
yes
HTTP status of an anonymous initialize
200
tools/list served without credentials
yes
Tools that change things, listed without credentials
74
Protocol version
2025-06-18
WWW-Authenticate on 401
not observed
resource_metadata in WWW-Authenticate
not observed
RFC 9728 protected resource metadata
not observed
Authorization servers
not observed
Legacy HTTP+SSE transport
no
Dynamic client registration
not observed
Client ID metadata documents
not observed
  • HighThe whole server

    The endpoint served tools/list without credentials, and the list has 74 tools that change things (2 irreversible, 72 write). Whether a call also works without credentials was not tested: tools are never called.

    Matched text

    https://mcp.medigami.com/public/mcp: tools/list returned 87 tools to an anonymous client, including billing_charge_vs_allowed_delta (irreversible), payment_plan_optimizer (irreversible), scan_bill_for_errors (write), generate_appeal_letter (write), verify_attestation (write) and 69 more

    What this check looks for

Findings

Matches of fixed checks, with the text they matched.

No check matched anything in these tool definitions. That is not a safety guarantee.

History

Changes to its tool definitions and to its remote endpoint, newest first.

No change seen yet. Its tools are rescanned every day, and a remote endpoint is looked at once a week.

Install

Pinned to version 1.0.0. Values in angle brackets are yours to fill in.

claude mcp add --transport http medigami https://mcp.medigami.com/public/mcp
claude mcp add --transport http medigami https://mcp.medigami.com/public/mcp

Run in a terminal.

Claude Code permissions

Allow the reads, ask before a change or a way out, deny the deletes. Paste into .claude/settings.json.

.claude/settings.json
{
  "permissions": {
    "allow": [
      "mcp__medigami__optimize_prescription",
      "mcp__medigami__analyze_glp1_pathways",
      "mcp__medigami__resolve_denial",
      "mcp__medigami__explain_appeal_success",
      "mcp__medigami__lookup_icd10",
      "mcp__medigami__lookup_cpt",
      "mcp__medigami__lookup_npi",
      "mcp__medigami__verify_dea_authorization",
      "mcp__medigami__lookup_provider_taxonomy",
      "mcp__medigami__resolve_codes",
      "mcp__medigami__get_appeal_deadline",
      "mcp__medigami__get_venue",
      "mcp__medigami__medigami_roast"
    ],
    "ask": [
      "mcp__medigami__scan_bill_for_errors",
      "mcp__medigami__generate_appeal_letter",
      "mcp__medigami__verify_attestation",
      "mcp__medigami__watch_appeal_outcome",
      "mcp__medigami__watch_claim_denial",
      "mcp__medigami__format_citation",
      "mcp__medigami__submit_denial_letter",
      "mcp__medigami__verify_mcp_response",
      "mcp__medigami__format_medigami_citation",
      "mcp__medigami__estimate_appeal_success",
      "mcp__medigami__maximize_recovery",
      "mcp__medigami__negotiate_bill_script",
      "mcp__medigami__batch_scan_bills",
      "mcp__medigami__code_conflict_detector",
      "mcp__medigami__fair_price_estimator",
      "mcp__medigami__price_variance_analyzer",
      "mcp__medigami__claim_consistency_checker",
      "mcp__medigami__bundling_violation_detector",
      "mcp__medigami__appeal_success_predictor",
      "mcp__medigami__generate_appeal_letter_v2",
      "mcp__medigami__negotiation_strategy_generator",
      "mcp__medigami__insurance_response_interpreter",
      "mcp__medigami__settlement_optimizer",
      "mcp__medigami__patient_cost_forecaster",
      "mcp__medigami__insurance_plan_optimizer",
      "mcp__medigami__cash_vs_insurance_optimizer",
      "mcp__medigami__financial_risk_exposure_model",
      "mcp__medigami__cpt_to_icd_mapper",
      "mcp__medigami__icd_to_cpt_mapper",
      "mcp__medigami__code_bundle_validator",
      "mcp__medigami__unbundling_detector",
      "mcp__medigami__cash_price_estimator",
      "mcp__medigami__zip_based_price_variance",
      "mcp__medigami__regional_price_benchmark",
      "mcp__medigami__specialty_price_benchmark",
      "mcp__medigami__inflation_adjusted_price_model",
      "mcp__medigami__deductible_impact_calculator",
      "mcp__medigami__coinsurance_simulator",
      "mcp__medigami__copay_model",
      "mcp__medigami__billing_charge_vs_allowed_delta",
      "mcp__medigami__price_anomaly_detector",
      "mcp__medigami__overpriced_service_detector",
      "mcp__medigami__market_price_distribution_model",
      "mcp__medigami__price_outlier_detector",
      "mcp__medigami__procedure_cost_decomposition",
      "mcp__medigami__price_recommendation_engine",
      "mcp__medigami__claim_duplicate_line_detector",
      "mcp__medigami__denial_reason_classifier",
      "mcp__medigami__appeal_argument_generator",
      "mcp__medigami__denial_response_builder",
      "mcp__medigami__dispute_case_builder",
      "mcp__medigami__evidence_pack_generator",
      "mcp__medigami__claim_rebuttal_generator",
      "mcp__medigami__appeal_escalation_path_finder",
      "mcp__medigami__payer_specific_appeal_templates",
      "mcp__medigami__denial_code_explainer",
      "mcp__medigami__claim_reconsideration_builder",
      "mcp__medigami__supporting_document_selector",
      "mcp__medigami__out_of_pocket_optimizer",
      "mcp__medigami__financial_exposure_model",
      "mcp__medigami__procedure_affordability_ranker",
      "mcp__medigami__treatment_cost_comparator",
      "mcp__medigami__bill_shock_predictor",
      "mcp__medigami__payment_plan_optimizer",
      "mcp__medigami__financial_assistance_finder",
      "mcp__medigami__patient_cost_explainer",
      "mcp__medigami__healthcare_budget_forecaster",
      "mcp__medigami__medical_spending_analyzer",
      "mcp__medigami__insurance_value_optimizer",
      "mcp__medigami__patient_financial_risk_score",
      "mcp__medigami__decode_denial",
      "mcp__medigami__medigami_odds",
      "mcp__medigami__medigami_deadline",
      "mcp__medigami__medigami_rate"
    ],
    "deny": []
  }
}

Tools that only read are allowed, tools that change things ask first, tools that delete or cancel are denied. A read that can send data out (it takes a URL, say) asks first too. It assumes the server is installed as medigami. Review it before you use it.

Capability tags behind 4 rules
  • mcp__medigami__optimize_prescription private-data, untrusted-input
  • mcp__medigami__submit_denial_letter untrusted-input
  • mcp__medigami__get_appeal_deadline untrusted-input
  • mcp__medigami__get_venue private-data, untrusted-input

Pin

Keep the decision: fail CI when the tools change, follow every change, or show a badge.

Pin in CI

Fail a build when the tools you reviewed are not the tools the server serves today.

curl -s "https://anlyon.dev/api/v1/servers/com.medigami/mcp/verify?hash=36c199950660f21c2ad6ec0cda4f1f2b0ef8b5217db3300d4085cc7adb5d2c0d" | jq -e '.changed == false'

Pinned hash 36c199950660, from Oct 21, 2026, 18:52 UTC.

Watch

Get told when its tools change: a new tool, a new description, a new class.

https://anlyon.dev/servers/com.medigami/mcp/changes.xml

An Atom feed. Works in any feed reader or Slack's RSS app.

Badge

anlyon.dev badge for com.medigami/mcp
[![anlyon.dev](https://anlyon.dev/badge/com.medigami/mcp.svg)](https://anlyon.dev/servers/com.medigami/mcp)

Source: MCP Registry. Synced Oct 21, 2026, 17:59 UTC.