Skip to main content
Glama

Condition Hospital Costs

condition_hospital_costs
Read-onlyIdempotent

National U.S. inpatient hospital discharges and aggregate costs by principal diagnosis (CCSR category) and year, from AHRQ HCUP's published "Most Expensive Conditions by Payer" Statistical Brief series — e.g. heart failure, septicemia/sepsis, acute myocardial infarction, COVID-19, stroke (cerebral infarction). Returns the top-20 most expensive conditions nationally (or filtered to one condition) with discharge counts, aggregate cost, and mean cost per stay. Years available: 2022, 2017 (AHRQ has not published a 2021 edition of this cross-condition table as of 2026-10-21). Optionally filter by expected payer (Medicare, Medicaid, private insurance, self-pay) for 2022.

Example tool call

This call uses example arguments supplied in the tool’s input schema.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "year": 2022,
      "condition": "heart failure"
    },
    "name": "condition_hospital_costs"
  }
}

Input Schema

NameRequiredDescriptionDefault
yearNoStatistical Brief edition year. One of: 2022, 2017. Defaults to 2022 (the most recent AHRQ has published).
payerNoExpected payer to filter by. Only 2022 has per-payer tables; other years return the all-payer table regardless of this argument.
conditionNoCondition name (e.g. "heart failure", "sepsis", "stroke") or CCSR code (e.g. "CIR019") to filter to. Omit to get the full top-20 table for that year/payer.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely useful non-obvious context: the upstream source (AHRQ HCUP Statistical Brief series), that 2021 was never published so only 2022 and 2017 exist, and that per-payer tables exist solely for 2022. It does not discuss rate limits, caching, or result-size behavior, keeping it short of a 5.

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

Conciseness4/5

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

One front-loaded paragraph leading with what the tool returns, then supporting detail on conditions, output fields, years, and payer. Every element is relevant, though the parenthetical publication-date stamp and the long list of example conditions are slightly heavier than needed.

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?

There is no output schema, and the description compensates by naming the returned fields and the top-20 cardinality, plus the year/payer coverage limits an agent needs before calling. The remaining gap is disambiguation from sepsis_hospital_outcomes, which matters because sepsis is listed as one of this tool's own example conditions.

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% and both enums are self-documenting, so the schema carries the parameter burden. The description reinforces the year set and the payer restriction ('only 2022 has per-payer tables') and gives condition-name examples like heart failure and stroke, but adds no format or matching semantics (e.g. whether 'sepsis' substring-matches 'septicemia/sepsis') beyond the schema.

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

Purpose4/5

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

Names a specific resource and scope: national U.S. inpatient discharges and aggregate costs by principal diagnosis (CCSR) and year, sourced from AHRQ HCUP. It also enumerates example conditions and states the return shape (top-20 most expensive conditions with discharges, aggregate cost, mean cost). It does not contrast itself with the sibling sepsis_hospital_outcomes, so an agent must infer the boundary between the two.

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?

Usage is implied rather than stated: 'Omit to get the full top-20 table' and the year/payer availability notes tell an agent how the tool behaves, but there is no explicit when-to-use, when-not-to-use, or named alternative. The closest sibling, sepsis_hospital_outcomes, is never mentioned, leaving the agent to guess which one covers sepsis costs.

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.