Skip to main content
Glama

Medicare Pricing

by io.github.pipeworx-io
OverviewDiscussionsAdmin

Medicare Dmepos Rate

medicare_dmepos_rate
Read-onlyIdempotent

What does Medicare pay for a piece of durable medical equipment, prosthetic, orthotic, or medical supply (DMEPOS)? Returns the fee-schedule amount for a HCPCS Level II code (E/K/L/A-codes — CPAP machines, wheelchairs, ostomy supplies, braces, oxygen equipment...) in a given US state, with SEPARATE rural and non-rural amounts, since Medicare pays DMEPOS by state rather than by the physician-fee-schedule locality. Answers "how much does Medicare pay for a CPAP machine (E0601)", "DMEPOS rate for a wheelchair in Texas", "what is the rural rate for this HCPCS code in Montana". Unlike medicare_physician_payment, this DOES include the HCPCS code description — DMEPOS uses HCPCS Level II, which CMS itself maintains and is not AMA copyright (CPT/HCPCS Level I is). States the fee-schedule YEAR and RELEASE (quarterly-ish: A=January, B=April, C=July, D=October) used on every response, and the modifier resolved (many DMEPOS codes price differently for rental "RR" vs. new purchase "NU" vs. used "UE" — pass one if you know it, otherwise the first modifier on file for the code is used and stated).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeYesHCPCS Level II code, e.g. "E0601" (CPAP device) or "E1390" (oxygen concentrator).
yearNoFee-schedule year, e.g. 2026. Omit to use the newest loaded year, which is stated in the response.
stateNoUS state, DC, or territory (PR/VI) where the equipment is furnished — a 2-letter code ("TX") or full name ("Texas"). DMEPOS is priced by STATE, not by Medicare locality. Omit only for the raw record without a resolved dollar amount.
releaseNoQuarterly release letter within the year: "A" (Jan), "B" (Apr), "C" (Jul), or "D" (Oct). Omit to use the newest loaded release for the resolved year.
modifierNoOptional HCPCS modifier, e.g. "RR" (rental), "NU" (purchase, new), "UE" (purchase, used). Many DMEPOS codes are priced only under one modifier; omit to use whichever is on file (stated in the response).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the bar is lower. The description still adds real behavior: it states the year and quarterly release are disclosed on every response and explains modifier resolution (RR/NU/UE, falling back to the first on file).

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?

The core question is front-loaded and the rest is dense but mostly functional. A few asides, notably the CMS-vs-AMA copyright parenthetical, do not help an agent invoke the tool and cost some tightness.

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?

With no output schema, the description carries the return-value burden and does so: it says what comes back (fee-schedule amount, separate rural and non-rural, stated year/release/modifier). Nothing needed to call it correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description goes modestly beyond by clarifying the modifier fallback ('otherwise the first modifier on file for the code is used and stated') and reinforcing that state drives pricing while year/release default to newest loaded.

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?

States a specific verb+resource ('What does Medicare pay for... DMEPOS') and returns the fee-schedule amount for a HCPCS Level II code. It explicitly distinguishes itself from the sibling medicare_physician_payment and pins down the rural/non-rural, by-state pricing model.

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?

Gives concrete trigger questions ('how much does Medicare pay for a CPAP machine', 'rural rate in Montana') and names medicare_physician_payment as the contrasting tool, plus when to pass a modifier. It stops short of an explicit 'do not use this for X' exclusion, so 4 rather than 5.

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

All Medicare Pricing toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources