A
licenseNot graded
qualityB
maintenanceEnables querying Medicare payment amounts for physician services, lab tests, and DMEPOS items, plus daily unit limits and NCCI code-pair billing edits, with vintage- and locality-aware answers.
639 npm
MIT
Medicare Fee Schedule Rates
by com.s2reason
Server Details
Medicare Physician Fee Schedule amounts by code, date and locality, traced to archived CMS files.
If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
A4.5/5.0
Scored across 2 tools
Disambiguation5/5
The two tools have clearly distinct purposes—one retrieves fee amounts for specific lines, the other lists available releases—and each description explicitly directs users to the other for the alternate need.
Naming Consistency5/5
Both names use the `medicare_` prefix and a consistent snake_case verb_noun pattern (`get_...`, `list_...`), making the set predictable.
Tool Count3/5
Two tools is thin for a server named Medicare Fee Schedule Rates, even if scoped to the Physician Fee Schedule; it covers only lookup and release listing, with no discovery or auxiliary operations.
Completeness4/5
The core read-only workflows are covered: retrieving allowed amounts for CPT/HCPCS lines and listing available CMS releases with coverage details. Minor gaps exist around discovering valid localities or code lists, but the primary use cases are supported.
Available Tools
2 toolsmedicare_get_physician_feeMedicare physician fee lookupARead-onlyIdempotentInspect
Use this when you need what Medicare's Physician Fee Schedule allows for a CPT or HCPCS code on a given date of service, for the nation or for one state or locality, in the office or facility setting. It takes up to 25 lines (code, modifier, date of service) and returns one answer per line, in order: CMS's allowed amount (national figure, plus the state range or one locality's figure when a state is given), the CMS release in force on that date, its source files with SHA-256 checksums, and the release catalog URL. It covers dates of service from Jan 1, 2023 through Dec 31, 2026; each date is priced under the quarterly CMS release in force that day, and a date outside that span gets a reason instead of a figure. A code with no national rate on this schedule (bundled, carrier-priced, laboratory, drug, anesthesia, ambulance, supplies, or absent from that release) returns a result_kind and a reason, not an error, and a malformed line returns an error for that line only. Do not use it for hospital outpatient or inpatient facility payments, ambulatory surgery center fees, Medicaid, commercial or workers' compensation rates, CPT code descriptions, or opinions on whether a charge is reasonable. It is read-only; amounts are Medicare-allowed amounts per unit, before sequestration and multiple-procedure reductions.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| lines | Yes | One to 25 service lines to price. The answers come back in this order. | |
| state | No | Optional, applies to every line. Two-letter key or full name of a state, DC, Puerto Rico or the Virgin Islands. Leave it out for the national figure only. Example: NJ. | |
| detail | No | Optional, applies to every line. concise (default) returns the national figure and the state range. detailed lists every locality in the state, with the geographic indexes used, and needs state. | |
| setting | No | Optional, applies to every line. Which setting the headline figure reports: office (non-facility) or facility (hospital). Both settings are always in the figures. Leave it out for the setting CMS shows first. | |
| locality | No | Optional, applies to every line, needs state. CMS locality number inside that state. Leave it out to get the state's range. Example: 01. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| notice | Yes | |
| schema | Yes | |
| results | Yes | |
| coverage | Yes | |
| releases | Yes | |
| ama_notice | Yes | |
| recipe_formula | Yes | |
| release_catalog_url | Yes |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, non-destructive, idempotent, and closed-world. The description adds rich behavioral context: coverage dates from Jan 1, 2023 to Dec 31, 2026, quarterly release pricing, behavior for codes with no national rate (returns result_kind and reason, not error), malformed line handling, and output format details (allowed amount, release, source files with checksums, catalog URL). This far exceeds annotation coverage.
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 description is long and dense, covering many aspects, but every sentence is informative. However, it could be more front-loaded: the key usage condition is first, but the output format and coverage details are packed into long sentences that may be harder to parse. It's appropriately sized given the complexity, but not optimally structured for quick scanning.
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?
Given the tool's complexity (5 parameters, nested lines array, specific output format), the description is highly complete. It explains input structure, output format, date coverage, error handling, and exclusions. The output schema exists, so detailed return values need not be explained, and the description still provides a helpful summary. Nothing critical is missing for correct invocation.
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 description coverage is 100%, so the schema already fully documents every parameter. The description adds meaning beyond the schema by explaining the overall input structure (up to 25 lines of code, modifier, date of service) and output ordering, but does not add syntax or format details not already in the schema. Baseline 3 is appropriate; slight boost because it clarifies the multi-line nature and result per line.
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 (look up) and resource (Medicare Physician Fee Schedule amount) for a CPT/HCPCS code and date, and explicitly contrasts with sibling medicare_list_fee_releases by focusing on pricing rather than listing releases. An agent can distinguish this from the sibling without opening its 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?
Explicitly states when to use it ('when you need what Medicare's Physician Fee Schedule allows...'), provides detailed exclusions (hospital outpatient/inpatient, ASC, Medicaid, commercial, workers' comp, CPT descriptions, reasonableness opinions), and implicitly routes to other tools for those purposes. Clear conditions for use and non-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
medicare_list_fee_releasesMedicare fee schedule release listARead-onlyIdempotentInspect
Use this when you need to know which CMS Medicare Physician Fee Schedule releases the archive holds, with their effective dates, CMS source files, SHA-256 checksums and any gaps in coverage, before or instead of looking up a fee. It takes no input and returns every release, newest first (id, label, effective and end dates, the CMS document that fixed the dates, source files, the hosted data bundle), plus the coverage summary and the release catalog URL. Coverage runs from Jan 1, 2023 through Dec 31, 2026, and the list changes only when a new CMS release is archived. Do not use it to get a fee amount (use medicare_get_physician_fee), or for other Medicare schedules such as hospital outpatient, ambulatory surgery center, laboratory, ambulance or DMEPOS, or for Medicaid or commercial rates. It is read-only.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| schema | Yes | |
| coverage | Yes | |
| releases | Yes | |
| release_catalog_url | Yes |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive, closed-world behavior, so the bar is lower; the description nonetheless adds the coverage window (2023-01-01 to 2026-12-31), the update cadence ('changes only when a new CMS release is archived'), and the novelty of checksums/gaps. It omits pagination/rate-limit behavior, but the cache-like update note is valuable.
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?
Well front-loaded with purpose then scope then exclusions, but somewhat long and dense, packing return fields and the coverage window into single sentences. Every clause earns its place, but it could be tighter.
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 an output schema present, the description needn't enumerate return values, yet it does so anyway; it also covers scope, cadence, and exclusions. Complete enough to invoke correctly, though the return-field recital is partly redundant against the output schema.
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?
Zero parameters, so baseline is 4; the description correctly states 'It takes no input', which is consistent with the empty schema and avoids implying any filtering knobs.
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: listing archived CMS Medicare Physician Fee Schedule releases with their metadata. It explicitly distinguishes from the single sibling, medicare_get_physician_fee, and enumerates what the archive holds.
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?
Explicit when-to-use ('before or instead of looking up a fee') and when-not-to-use, naming the alternative sibling and ruling out other Medicare schedules plus Medicaid/commercial rates. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
- First observed
medicare_get_physician_fee - First observed
medicare_list_fee_releases
Related MCP Connectors
What does Medicare PAY — physician fee schedule, lab rates, and per-day unit
Medicare coverage and fee-schedule amounts for CPT/HCPCS codes against a diagnosis
Medicare rates, hospital quality, and dispute scenarios from six federal public-domain datasets.
CMS Medicare Part D drug spending and prescriber data. 2024 quarterly data.
Related MCP Servers
- AlicenseBqualityCmaintenanceProvides comprehensive access to CMS Medicare data including physician services, prescriber information, hospital quality metrics, drug spending, formulary coverage, and ASP pricing for healthcare analysis and decision-making.18MIT
- AlicenseNot gradedqualityBmaintenanceEnables searching the CMS Open Payments dataset for physician, company, product, and research payments using structured filters, with annual dataset discovery through the official DKAN API.224 npmMIT
- FlicenseNot gradedqualityDmaintenanceSource-provenanced US federal healthcare provider data over MCP. Resolve any NPI or CCN across NPPES, OIG LEIE, SAM.gov, state Medicaid exclusions, CMS PECOS, Care Compare, and Open Payments — every field carries a 14-field provenance contract, and an "excluded or compromised anywhere" check runs on every lookup.-
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.