Skip to main content
Glama

Medicare Opps Rate

medicare_opps_rate
Read-onlyIdempotent

What does Medicare pay a HOSPITAL OUTPATIENT department for a procedure, device, or drug code? Returns the status indicator, Ambulatory Payment Classification (APC), relative weight, national payment rate, and beneficiary copayment for a HCPCS/CPT code under the Hospital Outpatient Prospective Payment System (OPPS) — the schedule that applies when the same service is billed by a hospital's outpatient department rather than a physician office (medicare_physician_payment) or a lab (medicare_lab_rate). Answers "what does Medicare pay for CPT 33289 in a hospital outpatient setting", "what is the APC for C2624", "is this device on pass-through status", "what is the OPPS payment rate and copay for this code". Flags device_pass_through and drug_or_biological_pass_through — whether the code is CURRENTLY in a CMS pass-through category (status indicator H or G), meaning it is paid separately, outside the normal APC amount, rather than packaged into the procedure it goes with. A packaged code (status indicator N, among others) still has a valid status_indicator but no apc/payment_rate_usd, because OPPS pays for it only as part of whatever procedure it is billed with — that is a normal result, not a missing one. States the fee-schedule YEAR and QUARTER (Q1=Jan, Q2=Apr, Q3=Jul, Q4=Oct) used on every response. Sourced from CMS, OPPS Addendum B.

Input Schema

NameRequiredDescriptionDefault
codeYesHCPCS or CPT code, e.g. "33289" (CardioMEMS implant procedure) or "C2624" (implantable wireless pulmonary artery pressure sensor).
yearNoCalendar year, e.g. 2026. Omit to use the newest loaded year, which is stated in the response.
quarterNoWhich quarterly release: "Q1".."Q4", or the release month CMS actually uses ("january"/"april"/"july"/"october"). Omit to use the newest loaded quarter for the resolved year.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/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 substantial behavior beyond that — the meaning of pass-through status (H/G paid separately vs packaged), why a packaged code (status N) legitimately returns no apc/payment_rate_usd, and that year/quarter are always disclosed. That is exactly the edge-case context an agent needs to interpret results.

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 paragraph is information-dense, but it is long and somewhat repetitive, restating the tool's scope through several near-duplicate example questions. Each sentence carries meaning, but trimming would tighten it.

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 a read-only lookup with rich annotations and a 100%-covered schema, the description covers everything: return fields, pass-through semantics, the packaged-code non-result, and the year/quarter provenance. Nothing an agent needs to call and interpret 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, but the description adds value by explaining the Q1=Jan..Q4=Oct mapping and the year/quarter resolution default (newest loaded), which goes slightly beyond the schema's own field descriptions.

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 opening sentence states a specific question and resource scope ('what does Medicare pay a HOSPITAL OUTPATIENT department') and enumerates the exact return fields (status indicator, APC, relative weight, payment rate, copay). It explicitly separates itself from the physician-office and lab schedules, so an agent can distinguish it from siblings without opening any schema.

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

Usage Guidelines5/5

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

It names the alternatives (medicare_physician_payment, medicare_lab_rate) and states the condition that selects this tool versus them ('the schedule that applies when the same service is billed by a hospital's outpatient department rather than a physician office'). Concrete example questions cement when to invoke it.

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.