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.
20 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
- Uptime
- 100.0% over 21 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
A4.7/5.0
Scored across 2 tools
Disambiguation5/5
The two tools serve clearly distinct purposes: one retrieves fee amounts, the other lists available CMS releases. The descriptions explicitly cross-reference each other and warn against misuse, leaving no ambiguity about which tool to select.
Naming Consistency5/5
Both names follow a consistent `medicare_<verb>_<noun>` pattern in snake_case: `medicare_get_physician_fee` and `medicare_list_fee_releases`. The verbs (`get`, `list`) are standard and predictable for read-only operations.
Tool Count4/5
Two tools is slightly under the typical 3–15 range, but the server's scope is narrow and read-only (fee lookup plus release metadata). Each tool is substantial and earns its place, though a third tool for code coverage or validation could be envisioned.
Completeness5/5
For the stated domain—Medicare Physician Fee Schedule rates—the surface covers the core operations: querying fees for specific codes/dates and discovering available releases. No critical gaps exist within the defined read-only scope; exclusions (e.g., CPT descriptions) are deliberate.
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.
| 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
| 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.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive), and the description adds substantial behavioral context beyond them: the Jan 1 2023–Dec 31 2026 coverage window, quarterly-release pricing per date, out-of-span dates returning a reason rather than a figure, unpriced code categories returning result_kind/reason instead of an error, per-line malformed errors, and that amounts precede sequestration/multiple-procedure reductions.
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 dense block is front-loaded with the use case and each sentence conveys distinct, non-redundant information (coverage dates, per-line error behavior, exclusions). It is long, but nearly every clause earns its place; only marginal tightening would help.
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 a 5-parameter tool with nested line objects, rich annotations, and an output schema, the description supplies everything an agent needs: coverage span, degradation behavior, exclusions, and the meaning of the returned figures. No material gap remains for correct invocation.
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%, so the schema already fully documents code, modifier, date, state, detail, setting, and locality (including the 'needs state' dependencies). The description restates the line count and national/state/locality scope, adding only mild reinforcing context rather than new semantics, so the 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 opens with a precise verb+resource+scope: it returns what Medicare's Physician Fee Schedule allows for a CPT/HCPCS code on a given date, nationally or by state/locality, in office or facility setting. This is specific enough that an agent can distinguish it from medicare_list_fee_releases (which lists releases) without opening the 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 explicitly states when to use it and then enumerates a comprehensive when-NOT list: hospital outpatient/inpatient payments, ASC fees, Medicaid, commercial/workers' comp rates, CPT descriptions, and reasonableness opinions. The exclusions are strong enough to route the agent correctly even though the sibling is not named by name.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| schema | Yes | |
| coverage | Yes | |
| releases | Yes | |
| release_catalog_url | Yes |
TDQS
A4.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the closing "It is read-only" is redundant. What the description adds beyond structured data is genuinely useful: the coverage window (Jan 1 2023 – Dec 31 2026) and the staleness rule ("the list changes only when a new CMS release is archived"), which tells the agent cacheability. It stops short of describing pagination or response size.
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?
Front-loaded trigger and scope, then return shape, then coverage window, then exclusions — a logical order. It is on the long side and restates read-only (already in annotations) and enumerates return fields (already in the output schema), so a couple of clauses do not fully earn their place.
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 no-parameter listing tool, the agent knows when to call it, what it will receive (newest-first releases plus coverage summary and catalog URL), the date bounds, and every neighboring tool it should not use. Output schema exists, so the return-field recap is bonus rather than necessary. Nothing material 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?
Zero parameters, so the baseline is 4. The description explicitly confirms "It takes no input", which aligns with additionalProperties:false and the empty schema, leaving no ambiguity about invocation.
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 (list CMS Medicare Physician Fee Schedule releases the archive holds) and explicitly names the sibling it is not (medicare_get_physician_fee). An agent can distinguish this catalog-listing tool from the fee-lookup tool without opening either 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?
Gives an explicit when-to-use trigger ("before or instead of looking up a fee"), a named alternative for the fee case, and a when-not-to-use clause listing other schedules (hospital outpatient, ASC, lab, ambulance, DMEPOS) plus Medicaid and 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 limits.
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.
What US health plans pay for care: negotiated rates by plan, provider and billing code, near a ZIP.
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 gradedqualityCmaintenanceProvides Florida Medicaid reimbursement rate data from AHCA cost reimbursement schedules — FQHC and rural health clinic per-visit encounter rates, nursing home, skilled nursing unit, swing bed, hospice, and state mental health hospital per diem rates — queryable by provider and rate semester with statewide min/median/max and effective dates.526 npmMIT
- 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.15 npmMIT
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.