Skip to main content
Glama

Distill

One billing code across up to 10 named hospitals, one normalized row each

hospital_compare
Read-only

For each named hospital: whether it posts the code, and over its items for the code (only those without modifiers when it posts any, so a professional -26 or bilateral -50 line does not skew the row) nearest-rank statistics of its gross charges, discounted cash prices and negotiated dollar amounts across payers and plans, the range of negotiated percentages, the de-identified minimum and maximum, and the number of payers. The same filters as hospital.prices. Hospital ids come from hospital.prices (or pass a CMS certification number). Not charged when none of the hospitals is known. Price: $0.02 per call. Free tier: 3 free calls a day per IP, at most 3 rows per answer, taken by an unpaid call unless its _meta["distill/free-tier"] is "skip". Confidence: Mean over the returned rows (each rate; an item with no rate counts once) of normalize × quality × freshness. Normalize: the stored per-rate normalize confidence (payer canonicalization: rule 1, model 0.9, fallback 0.6; rate basis for rates with no dollar amount: rule 1, model 0.9, fallback 0.75; 1 for an item with no rate). Quality of the MRF: 1 valid against the v3.0 schema, 0.85 parsed with conformance errors, 0.7 parsed only after header repair. Freshness: 1 while the MRF’s last_updated_on is at most 365 days old, then halving every 180 days (0.5 with no date), times 1 within 14 days of our fetch, then halving every 30 days. Rows are each hospital’s items for the code as compared. Posted standard charges from hospital machine-readable files (45 CFR 180): posted rates, not a quote; not medical or financial advice. What you pay depends on your plan, your care and the hospital. See /terms.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeYesThe billing code: CPT (5 characters, e.g. 99213), HCPCS Level II (a letter and 4 digits, e.g. J1885) or MS-DRG (3 digits, e.g. 470).
planNoOptional: text the plan name (or payer name) contains as the hospital writes it, case-insensitive, e.g. "PPO" or "Medicare Advantage".
payerNoOptional: a canonical payer_id (e.g. aetna, cigna, unitedhealthcare, anthem, medicare, medicaid). hospital.payers lists the payers with prices for a code.
settingNoOptional: inpatient or outpatient (items posted for both always match).
code_typeNoOptional: the code type. Inferred from the code’s shape when omitted.
hospitalsYesOne to ten hospital ids (e.g. co-060001) or CMS certification numbers, comma-separated.
plan_typeNoOptional: the canonical plan type.
billing_classNoOptional: facility or professional (items posted for both always match).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With readOnlyHint/openWorldHint already covering the safety profile, the description adds substantial behavioral context beyond annotations: $0.02 per-call cost, free-tier terms (3 calls/day/IP, max 3 rows, skip meta flag), a full confidence formula with normalize/quality/freshness weights, and the data provenance/disclaimer. This is far richer than the annotations alone.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The first sentence front-loads the core output, but the body is extremely dense, packing the confidence formula, pricing, free-tier rules, and legal disclaimer into one unbroken block. Much of it earns its place behaviorally, yet the formatting is hard to parse and would benefit from structure.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 8-parameter, output-schema-less tool, the description is comprehensive: it explains the returned rows, the statistics computed, filter inheritance, id sourcing, cost, and confidence interpretation. An agent has everything needed to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents all 8 parameters including enums and patterns, making 3 the baseline. The description adds marginal meaning only, e.g. modifier handling ('only those without modifiers when it posts any') and the hospital.prices filter reuse, but does not extend the individual parameter definitions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb+resource and the exact output: for each named hospital, whether it posts the code plus nearest-rank statistics of gross charges, discounted cash prices, negotiated amounts, the negotiated percentage range, de-identified min/max, and payer count. The scope ('across up to 10 named hospitals, one normalized row each' in the title) clearly distinguishes it from the single-hospital sibling hospital.prices.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It says 'The same filters as hospital.prices' and that hospital ids come from hospital.prices (or a CMS certification number), which gives useful origin guidance. However, it never explicitly states when to choose this multi-hospital comparison over hospital.prices, and the 'Not charged when none of the hospitals is known' clause is a billing note rather than usage routing. Differentiation is implied but not spelled out.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources