Skip to main content
Glama

Medicare Coverage

by io.github.pipeworx-io

Medicare Coverage Timeline

medicare_coverage_timeline
Read-onlyIdempotent

Retrieve official CMS version or revision history for a Medicare NCD, NCA, CAL, or LCD. Accepts either identifier CMS publishes for a coverage document: the public one that appears in the policy text and in every citation of it — an NCD section number such as 310.1 or 90.2, an NCA/CAL tracking number such as CAG-00450N, an LCD number such as L34246 — or CMS's internal numeric document id. Public identifiers are resolved to the internal id automatically, and every response reports the resolved internal document_id alongside the public document_display_id and the document title so a caller can confirm the policy matches the one they asked about. LCD revision history requires a caller-supplied CMS license token. Timeline entries describe policy publication and revision history; utilization, payment, and claim-level adjudication come from other tools.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
versionNoOptional LCD version.
document_idYesEither the public identifier (NCD section number like "310.1", NCA/CAL tracking number like "CAG-00450N", LCD number like "L34246") or CMS's internal numeric document id. A leading "NCD "/"NCA "/"CAL "/"LCD " word is accepted and ignored. A digits-only value is read as the internal id: CMS numbers the two identifier spaces independently, so internal id 90 is the policy published as NCD 190.18, while NCD 90.2 is internal id 372.
_licenseTokenNoRequired only for LCD.
document_typeYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
hintNo
foundYes
titleYes
totalNo
reasonNo
sourceYes
returnedNo
timelineNo
candidatesNo
document_idYesCMS internal id the request actually resolved to.
resolved_byNo
document_typeYes
interpretationYes
cms_document_typeNo
document_display_idYesPublic identifier of the resolved document.
requested_document_idYesExactly what the caller passed.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed15 schema fields changed
    • changedInput schema / examples
      Previous value: -[
-  {
-    "document_id": "355",
-    "document_type": "NCD"
-  }
-]New value: +[
+  {
+    "document_id": "310.1",
+    "document_type": "NCD"
+  },
+  {
+    "document_id": "1",
+    "document_type": "NCD"
+  },
+  {
+    "document_id": "CAG-00450N",
+    "document_type": "NCA"
+  },
+  {
+    "document_id": "150",
+    "document_type": "CAL"
+  }
+]
    • addedInput schema / properties / document_id / description
      Added value: +"Either the public identifier (NCD section number like \"310.1\", NCA/CAL tracking number like \"CAG-00450N\", LCD number like \"L34246\") or CMS's internal numeric document id. A leading \"NCD \"/\"NCA \"/\"CAL \"/\"LCD \" word is accepted and ignored. A digits-only value is read as the internal id: CMS numbers the two identifier spaces independently, so internal id 90 is the policy published as NCD 190.18, while NCD 90.2 is internal id 372."
    • addedInput schema / properties / version / description
      Added value: +"Optional LCD version."
    • addedOutput schema / properties / candidates
      Added value: +{
+  "items": {
+    "type": "object"
+  },
+  "type": "array"
+}
    • addedOutput schema / properties / cms_document_type
      Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
    • addedOutput schema / properties / document_display_id
      Added value: +{
+  "description": "Public identifier of the resolved document.",
+  "type": [
+    "string",
+    "null"
+  ]
+}
    • addedOutput schema / properties / document_id
      Added value: +{
+  "description": "CMS internal id the request actually resolved to.",
+  "type": [
+    "string",
+    "null"
+  ]
+}
    • addedOutput schema / properties / document_type
      Added value: +{
+  "type": "string"
+}
    • addedOutput schema / properties / found
      Added value: +{
+  "type": "boolean"
+}
    • addedOutput schema / properties / hint
      Added value: +{
+  "type": "string"
+}
    • addedOutput schema / properties / reason
      Added value: +{
+  "type": "string"
+}
    • addedOutput schema / properties / requested_document_id
      Added value: +{
+  "description": "Exactly what the caller passed.",
+  "type": "string"
+}
    • addedOutput schema / properties / resolved_by
      Added value: +{
+  "type": "string"
+}
    • addedOutput schema / properties / title
      Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
    • changedOutput schema / required
      Previous value: -[
-  "total",
-  "returned",
-  "timeline",
-  "source",
-  "interpretation"
-]New value: +[
+  "found",
+  "document_type",
+  "requested_document_id",
+  "document_id",
+  "document_display_id",
+  "title",
+  "source",
+  "interpretation"
+]
  2. Added

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds valuable behavioral context: public identifiers are automatically resolved to internal IDs, every response reports both IDs plus the title to confirm the correct policy, and LCD history requires a license token. It also clarifies that timeline entries are limited to publication/revision history, setting expectations about scope. This goes well beyond the annotations.

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 description is relatively long but every sentence earns its place. It is front-loaded with the main purpose, then explains identifier types, resolution behavior, license requirements, and scope exclusions. No redundant or fluffy language; it's dense but organized. The only minor deduction is that it could be split into more scannable bullet points, but it's acceptable as prose.

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 (4 params, multiple document types, output schema present), the description is very complete. It covers input format, ID resolution behavior, license prerequisites, output confirmation, and scope boundaries. The statement that 'utilization, payment, and claim-level adjudication come from other tools' provides important context for when a caller should look elsewhere. The output schema handles return-value details, so the description doesn't need to over-explain.

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?

The input schema already provides extensive descriptions for the key parameters, especially document_id, which explains public/internal ID formats and the digits-only ambiguity. The tool description adds some clarification about automatic resolution and response IDs, but this is more output-focused than parameter semantics. With schema coverage at 75%, the description doesn't need to compensate heavily, so a baseline 3 is appropriate.

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 specific verb+resource: 'Retrieve official CMS version or revision history for a Medicare NCD, NCA, CAL, or LCD.' It clearly distinguishes from sibling tools like medicare_ncd_detail or medicare_lcd_search by focusing on version/revision history, not policy details or search. It also explains the output includes both public and internal IDs, further clarifying its unique purpose.

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?

The description explicitly states when NOT to use this tool: 'utilization, payment, and claim-level adjudication come from other tools.' It also provides context for prerequisites, noting 'LCD revision history requires a caller-supplied CMS license token.' While it doesn't name specific alternative tools, the exclusionary guidance is clear and helpful for tool selection.

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

All Medicare Coverage toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.5/5.0
Disambiguation2/5

The server mixes Medicare-specific tools with many unrelated general-purpose tools (e.g., bet_research, polymarket_arbitrage, remember), and there are multiple similar ask_pipeworx variants. This makes it difficult for an agent to distinguish which tool is appropriate for a given task without confusion.

Naming Consistency2/5

Tool names follow no consistent pattern. Some use a medicare_ prefix with underscores, others use generic verbs like forget, recall, or compound names like ask_pipeworx, deep_research. There is no uniform verb_noun or noun_verb structure.

Tool Count2/5

57 tools is excessive for a server ostensibly focused on 'Medicare Coverage'. Many tools (e.g., bet_research, polymarket_edge_tracker, scan_dependency) are unrelated to Medicare and should be in separate servers, inflating the count and diluting focus.

Completeness4/5

The Medicare-specific tools cover a broad range: NCDs, LCDs, NCAs, enrollment, DME, Part D, hospital, outpatient, post-acute, and provider data. Minor gaps include Medicare Advantage (Part C) and Medicare Supplement, but the coverage is largely comprehensive.

Resources