Skip to main content
Glama

Distill

Negotiated prices for one billing code in one area, per canonical payer and plan type

hospital_payers
Read-only

Every payer’s negotiated dollar amounts for the code at the hospitals within the radius, grouped by canonical payer_id (the stable id behind the many ways hospitals write a payer’s name), plan type and methodology (a per diem and a case rate are never pooled): how many hospitals and rates, and nearest-rank statistics. Payers with the most hospitals first. Percentage-only rates are left out (they have no dollar amount; hospital.prices shows them). The payer_ids here are what the payer filter of hospital.prices and hospital.compare takes. 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 every rate in the payer rows returned of normalize × quality × freshness, with the same factors as hospital.prices (normalize: the stored per-rate payer canonicalization confidence, rule 1, model 0.9, fallback 0.6; quality: 1 valid v3.0, 0.85 with conformance errors, 0.7 after header repair; freshness: 1 while last_updated_on is at most 365 days old, then halving every 180 days, times 1 within 14 days of our fetch, then halving every 30 days). 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
latNoLatitude of the point (with lon).
lonNoLongitude of the point (with lat).
zipNoA 5-digit ZIP code (its Census ZCTA point). Give a zip, or lat and lon.
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).
settingNoOptional: inpatient or outpatient (items posted for both always match).
code_typeNoOptional: the code type. Inferred from the code’s shape when omitted.
plan_typeNoOptional: the canonical plan type.
radius_milesNoSearch radius in miles (default 25, at most 100).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior5/5

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

Annotations only cover readOnlyHint and openWorldHint, yet the description discloses far more: cost ($0.02/call), a free-tier cap (3 calls/day, 3 rows max, consumed unless _meta marks skip), a full confidence formula, the data source and legal framing (45 CFR 180 posted standard charges, not a quote), and the sort order. This is exactly the extra context annotations cannot carry.

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 purpose and payer_ids linkage are correctly front-loaded, but the confidence sentence is a single sprawling parenthetical that packs six nested factors and their weights, which is hard to parse. The pricing/free-tier/legal content is useful but the overall length and density exceed what the task needs.

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

Completeness4/5

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

With no output schema, the description steps in and describes the return shape (per-payer rows with hospital and rate counts plus nearest-rank statistics, sorted by hospital count), the free-tier row cap, and the exclusion of percentage-only rates. It covers what an agent needs to call and interpret the tool, though 'nearest-rank statistics' remains loosely specified.

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 description coverage is 100% with enums on setting, code_type, and plan_type, so the schema already documents every parameter. The description adds only light framing (the code is the subject, radius bounds the search, plan_type is a grouping key) and no format or default details beyond the schema. Baseline 3 applies.

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 states a specific verb and resource (negotiated dollar amounts per payer for one billing code within a radius) and names the exact grouping keys: canonical payer_id, plan type, and methodology. It also distinguishes itself from siblings by name, noting that percentage-only rates live in hospital.prices, so an agent can tell the three hospital tools apart without opening a schema.

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

Usage Guidelines4/5

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

It gives clear context for selection: use this for the payer/plan-type breakdown, and it explicitly routes percentage-only rates to hospital.prices. It also explains that the returned payer_ids are the ones the hospital.prices and hospital.compare payer filters accept, which is actionable linkage. It stops short of an explicit 'use this instead of X when Y' exclusion, so it is clear but not fully prescriptive.

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