What can you do with this server?

The CMS Healthcare Data MCP Server enables natural-language Real-World Evidence (RWE) analytics on four CMS public datasets without requiring SQL expertise. Here's what you can do: * Browse available datasets — Use list_datasets to see all four CMS datasets (hcc_risk_adjustment, hospital_readmission, mips_quality_measures, partd_drug_utilization) with metadata including source, update frequency, and key fields. * Inspect dataset schemas — Use get_schema to retrieve full field definitions, types, descriptions, and examples for any dataset before querying. * Query and filter healthcare records — Use get_data to retrieve filtered records using parameters such as ICD-10 codes, NPI, state, hospital CCN, drug name, HCC category, risk score bounds, and more (up to 1,000 rows). * Run pre-approved analytical query templates — Use run_query with one of 12 named, injection-safe templates covering common RWE analyses: * HCC mappings by ICD code/category and risk score distributions * Hospital readmission rates by facility, state, or national benchmark * MIPS performance by provider, quality measure, or specialty * Part D drug cost trends, utilization trends, and top drugs by cost * Discover example queries — Use get_sample_queries to get realistic RWE use-case examples with parameter templates for any dataset. * Monitor cache performance — Use cache_status to view hit/miss ratios, key counts, and memory usage across 24-hour reference and 5-minute transactional caches. Security & Infrastructure: All inputs are validated via Zod schemas and sanitized against SQL injection. No raw SQL is accepted. Optional API key authentication and rate limiting (100 req/min) are supported. Every tool call is written to an NDJSON audit log. The server runs in Demo Mode (embedded sample data, no database needed) or Production Mode (PostgreSQL backend).

How do I use CMS Healthcare Data MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@CMS Healthcare Data MCP Server show me the top 10 Part D drugs by total spending in 2022" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

CMS Healthcare Data MCP Server

by SaeMind

Overview Schema Related Servers Score Discussions

TypeScript

Local

CMS Healthcare Data MCP Server

Production-grade Model Context Protocol (MCP) server exposing four CMS public datasets as callable tools in Claude conversations — enabling natural-language RWE analytics without SQL expertise.

TypeScript MCP SDK Node License: MIT

Overview

Real-world evidence analysts spend a significant portion of project time on data access mechanics: locating CMS datasets, writing parameterized SQL, handling pagination, and normalizing schemas. This server solves that infrastructure problem at the protocol layer.

The server implements the Model Context Protocol specification and runs as a local stdio process that Claude Desktop registers as a tool provider. Once registered, analysts can query HCC risk scores, hospital readmission rates, MIPS quality measures, and Part D drug utilization using plain English — the server handles validation, caching, and safe query execution.

Key capabilities:

Capability	Implementation
Protocol compliance	MCP SDK v1.0.4, `StdioServerTransport`
Datasets exposed	4 CMS public datasets
Tools available	6 callable tools
Query templates	12 pre-approved, injection-safe templates
Caching	TTL-based (NodeCache): 24h reference, 5min transactional
Security	API key auth, rate limiting (100 req/min), Zod validation
Audit logging	NDJSON audit trail to `outputs/audit.log`
Demo mode	Embedded sample data — no database required to run
Test suite	84/84 passing (verified 2026-06-30)

Related MCP server: cpt-analysis-mcp-server

Why MCP for CMS Data?

Traditional CMS data access requires analysts to maintain database credentials, write parameterized SQL, manage connection pools, and handle API pagination. For clinical researchers whose primary skill is domain expertise — not software engineering — this friction reduces productivity and introduces error risk.

MCP solves this by standardizing the interface between language models and external data systems. The server exposes a typed, versioned, audited contract. Claude calls tools; the server handles everything beneath that.

Comparison to alternatives:

Approach	SQL Expertise Required	Audit Trail	Protocol Standard	Claude Native
Direct database query	Yes	No	No	No
REST API wrapper	Partial	Optional	No	No
MCP Server (this project)	No	Yes	Yes (MCP)	Yes
Custom Claude plugin	No	Optional	Proprietary	Partial

Architecture

┌─────────────────────────────────────────────────────────────────┐
│                        Claude Desktop                           │
│              (MCP client, initiates tool calls)                 │
└─────────────────────────┬───────────────────────────────────────┘
                          │ stdio (MCP protocol)
                          ▼
┌─────────────────────────────────────────────────────────────────┐
│                     server.ts (MCP Server)                      │
│  - StdioServerTransport                                         │
│  - ListToolsRequestSchema handler                               │
│  - CallToolRequestSchema handler                                │
│  - HTTP health endpoint (:3000/health)                          │
└─────────────────────────┬───────────────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────────────┐
│                   tools.ts (Request Pipeline)                   │
│                                                                 │
│  [1] API Key Auth → [2] Rate Limiter → [3] Zod Validation      │
│  [4] Cache Lookup → [5] Data Fetch  → [6] Cache Store          │
│  [7] Audit Write  → [8] JSON Response                          │
└────────────┬──────────────────────┬────────────────────────────┘
             │                      │
             ▼                      ▼
┌────────────────────┐   ┌──────────────────────────────────────┐
│    validators.ts   │   │           datasources.ts             │
│                    │   │                                      │
│  - Zod schemas     │   │  DEMO_MODE=true  → sample data       │
│  - SQL sanitizer   │   │  DEMO_MODE=false → PostgreSQL pool   │
│  - Template        │   │                                      │
│    whitelist       │   │  fetchHccData()                      │
│    (12 templates)  │   │  fetchReadmissionData()              │
│                    │   │  fetchMipsData()                     │
└────────────────────┘   │  fetchPartdData()                    │
                         └──────────────────────────────────────┘
             │
             ▼
┌─────────────────────────────────────────────────────────────────┐
│                         cache.ts                                │
│  NodeCache TTL tiers:                                           │
│  - Reference data (HCC, MIPS): 24h                             │
│  - Transactional (readmission, Part D): 5min                   │
│  - SHA-256 deterministic cache keys                            │
└─────────────────────────────────────────────────────────────────┘

Directory structure:

cms-mcp-server/
├── src/
│   ├── server.ts         # MCP server core, transport, health endpoint
│   ├── tools.ts          # Tool definitions and request handlers
│   ├── datasources.ts    # CMS data connectors (demo + PostgreSQL)
│   ├── validators.ts     # Zod schemas, sanitizer, template whitelist
│   ├── cache.ts          # TTL cache with deterministic key generation
│   ├── config.ts         # Zod-validated environment configuration
│   ├── logger.ts         # Winston app + audit + query loggers
│   └── types.ts          # Shared TypeScript interfaces
├── tests/
│   ├── unit.test.ts      # Validator, cache, injection-safety tests
│   └── integration.test.ts  # Full tool lifecycle in DEMO_MODE
├── schema/
│   ├── cms_data_schema.json  # JSON Schema Draft-07 for all record types
│   └── init.sql              # PostgreSQL schema for production mode
├── docs/
│   └── protocol_spec.md      # Full MCP protocol specification
├── outputs/              # Runtime: audit.log written here
├── .env.example
├── docker-compose.yml
├── Dockerfile
├── jest.config.cjs
├── package.json
└── tsconfig.json

Exposed Datasets

Dataset ID	Source	Update Frequency	Cache TTL	Key Fields
`hcc_risk_adjustment`	CMS-HCC V28 Model	Annual	24h	`icd10Code`, `hccCategory`, `riskScore`, `modelYear`
`hospital_readmission`	HCUP AHRQ	Quarterly	5min	`ccn`, `measureId`, `readmissionRate`, `state`
`mips_quality_measures`	CMS QPP	Annual	24h	`npi`, `measureId`, `performanceScore`, `specialty`
`partd_drug_utilization`	CMS Part D PUF	Annual	24h	`drugName`, `genericName`, `totalCost`, `claimCount`

Data lineage metadata is returned on every response:

{
  "dataLineage": {
    "source": "CMS-HCC V28 Risk Adjustment Model",
    "sourceUrl": "https://www.cms.gov/medicare/payment/medicare-advantage/risk-adjustment",
    "lastUpdated": "2024-01-01T00:00:00Z",
    "lagDays": 365,
    "disclaimer": "CMS data has 3-6 month lag..."
  }
}

Tools Reference

`list_datasets`

Returns the catalog of all available CMS datasets with metadata.

Parameters: None

Returns: Array of dataset descriptors including ID, name, description, source URL, last-updated timestamp, and row count.

`get_schema`

Returns the field schema for a specific dataset.

Parameters:

Parameter	Type	Required	Description
`datasetId`	`string`	Yes	One of the four dataset IDs above

`get_data`

Retrieves filtered records from a dataset.

Parameters:

Parameter	Type	Required	Description
`datasetId`	`string`	Yes	Target dataset
`filters`	`object`	No	Dataset-specific filter fields (see below)
`limit`	`number`	No	Max rows returned (1–1000, default 100)

HCC filters: icd10Code (regex: /^[A-Z][0-9]{2}(\.[0-9A-Z]{1,4})?$/), hccCategory (integer), modelYear (2020–2030), riskScoreMin/Max (0.0–5.0)

Readmission filters: ccn (6-digit), state (2-letter), measureId, readmissionRateMin/Max (0.0–1.0)

MIPS filters: npi (10-digit), specialty (string), measureId, performanceScoreMin/Max (0–100)

Part D filters: drugName (string), genericName (string), year (2015–2030), minTotalCost (number)

`run_query`

Executes a named, pre-approved query template with parameters.

Parameters:

Parameter	Type	Required	Description
`templateId`	`string`	Yes	One of 12 approved templates
`params`	`object`	No	Template-specific parameters

Approved templates:

Template ID	Dataset	Description
`hcc_by_icd_code`	HCC	Retrieve HCC mappings for a specific ICD-10 code
`hcc_by_category`	HCC	All diagnoses in a given HCC category
`hcc_risk_score_distribution`	HCC	Risk score distribution across model years
`readmission_by_hospital`	Readmission	Readmission rates for a specific hospital (CCN)
`readmission_by_state`	Readmission	State-level readmission rate summary
`readmission_national_benchmark`	Readmission	National average by measure
`mips_performance_by_provider`	MIPS	MIPS scores for a specific NPI
`mips_performance_by_measure`	MIPS	Performance distribution for a quality measure
`mips_specialty_summary`	MIPS	Average MIPS score by specialty
`partd_cost_by_drug`	Part D	Cost trends for a specific drug
`partd_utilization_trends`	Part D	Year-over-year claim volume trends
`partd_top_drugs_by_cost`	Part D	Top N drugs by total cost

`cache_status`

Returns current cache statistics.

Returns: Hit rate, miss rate, key count, memory usage, TTL configuration.

`get_sample_queries`

Returns ready-to-use example queries for a dataset.

Parameters:

Parameter	Type	Required
`datasetId`	`string`	Yes

How to Run

Prerequisites

Node.js 20+
npm 10+
(Optional, for production mode) PostgreSQL 16+

Installation

git clone https://github.com/SaeMind/mcp-server-for-cms-healthcare-data-tools.git
cd cms-mcp-server
npm install

Environment configuration

cp .env.example .env

Key variables:

# Set to true to run with embedded sample data (no database required)
DEMO_MODE=true

# Required only when DEMO_MODE=false
DATABASE_URL=postgresql://cms_user:password@localhost:5432/cms_data

# Optional: enable API key authentication
API_KEY=your-key-here

# Optional: override rate limit (default: 100 req/min)
RATE_LIMIT_PER_MINUTE=100

# Optional: override HTTP health port (default: 3000)
PORT=3000

Build and start (demo mode)

npm run build
npm start

The server starts on stdio and exposes a health endpoint at http://localhost:3000/health.

Start without build (development)

npm run dev

Docker (PostgreSQL + server)

mkdir -p outputs
docker-compose up --build

The compose stack starts PostgreSQL 16 on port 5432 and the MCP server. The database schema is initialized from schema/init.sql.

Configure Claude Desktop

Add the following block to ~/.claude/claude_desktop_config.json:

{
  "mcpServers": {
    "cms-healthcare-data": {
      "command": "node",
      "args": ["/absolute/path/to/cms-mcp-server/dist/server.js"],
      "env": {
        "DEMO_MODE": "true"
      }
    }
  }
}

Restart Claude Desktop. The server tools appear under the tool picker in any new conversation.

Example Queries

Once registered, invoke tools directly in Claude:

List available datasets:

Call list_datasets

HCC risk score for E11.9 (Type 2 Diabetes):

Call get_data with datasetId=hcc_risk_adjustment, filters={icd10Code: "E11.9"}

Hospital readmission rate by state:

Call run_query with templateId=readmission_by_state, params={state: "TX"}

MIPS performance for a specific provider:

Call run_query with templateId=mips_performance_by_provider, params={npi: "1234567890"}

Top 10 Part D drugs by total cost:

Call run_query with templateId=partd_top_drugs_by_cost, params={limit: 10}

Drug utilization trend for metformin:

Call run_query with templateId=partd_cost_by_drug, params={drugName: "metformin"}

Safety and Validation

Security is implemented in layers. Each tool call passes through the full pipeline before any data is accessed:

[1] API Key Authentication  →  Constant-time comparison (crypto.timingSafeEqual)
[2] Rate Limiting           →  RateLimiterMemory, 100 req/min per key
[3] Input Validation        →  Zod schemas per dataset; type coercion disabled
[4] String Sanitization     →  Strip SQL metacharacters: ' " ; -- /* */ xp_ EXEC
[5] Template Whitelist      →  run_query only executes from 12 approved templates
[6] Parameterized SQL       →  All PostgreSQL queries use $N positional params
[7] Audit Logging           →  Every call written to outputs/audit.log (NDJSON)

No raw SQL is accepted from callers under any circumstances. The run_query tool maps template IDs to pre-written, parameterized query objects. Parameters are validated and sanitized before substitution. The approved template set is a ReadonlySet<string> — it cannot be extended at runtime.

Audit log entry format (NDJSON):

{
  "timestamp": "2024-06-01T14:23:11.042Z",
  "level": "audit",
  "tool": "run_query",
  "templateId": "readmission_by_state",
  "params": {"state": "TX"},
  "cacheHit": false,
  "rowsReturned": 47,
  "durationMs": 12,
  "apiKeyHash": "sha256:a1b2c3..."
}

Demo Mode vs. Production Mode

DEMO_MODE=true (default): The server returns the embedded sample records in src/datasources.ts — 10 HCC records, 5 readmission records, 4 MIPS records, and 5 Part D records. No database is required. These records are representative of real CMS data formats but are not live CMS data.

DEMO_MODE=false: The server queries a PostgreSQL database initialized from schema/init.sql. The schema is production-ready, but no ETL script is included to load real CMS data. This mode requires a separately populated database.

The Tableau dashboard included in this repository was built from the DEMO_MODE=true sample dataset. It visualizes the server's tool interface and data schema; it does not reflect live CMS population statistics.

Tableau Dashboard

CMS MCP Server — Executive Dashboard

Views included:

HCC risk factor distribution by disease hierarchy group
Hospital readmission rate vs. national benchmark by facility and measure
Part D drug cost per claim by drug class

CSV exports used to build the dashboard are in outputs/ (generated by scripts/export_demo_csv.ts).

Testing

# Full test suite
npm test

# Unit tests only (validators, cache, injection safety)
npm run test:unit

# Integration tests only (full tool lifecycle in DEMO_MODE)
npm run test:integration

# Type checking without emit
npm run typecheck

Unit test coverage:

Area	Tests
`validateDatasetId`	Valid IDs, invalid strings, non-string inputs
`assertApprovedTemplate`	All 12 valid templates, rejection of arbitrary strings
HCC parameter validation	ICD-10 regex, risk score bounds, limit bounds, model year range
Readmission validation	CCN format, rate bounds, SQL injection in free-text fields
MIPS validation	NPI regex, score bounds
Part D validation	Year range, cost floor
Cache	Key determinism (parameter order independence), store/retrieve, TTL expiry, flush, stats
SQL injection adversarial suite	6 injection patterns across all string filter fields

Integration test coverage:

Scenario	Assertion
`list_datasets` returns 4 entries	Dataset IDs match expected set
`get_schema` returns field metadata	Schema fields present per dataset
`get_data` HCC with ICD filter	Result rows match filter
`get_data` readmission with state filter	State field matches filter value
Cache hit on duplicate request	Second identical call returns `cacheHit: true`
Error response shape	No stack traces; `error` field present
`run_query` template routing	All 12 templates resolve without error
`get_sample_queries`	Returns non-empty array per dataset

Technologies Used

Technology	Version	Role
TypeScript	5.3	Language (strict mode)
`@modelcontextprotocol/sdk`	1.0.4	MCP server and transport
`zod`	3.22	Runtime schema validation
`node-cache`	5.1	TTL-based in-process caching
`rate-limiter-flexible`	5.0	In-memory rate limiting
`pg`	8.11	PostgreSQL client (production mode)
`winston`	3.11	Structured logging and audit trail
`dotenv`	16.4	Environment configuration
Jest + ts-jest	29.7	Unit and integration testing
Docker + PostgreSQL 16	—	Optional production backend

Data Sources

Dataset	Source	URL
CMS-HCC V28 Risk Adjustment	CMS Medicare Advantage	https://www.cms.gov/medicare/payment/medicare-advantage/risk-adjustment
Hospital Readmission Rates	HCUP AHRQ	https://hcupnet.ahrq.gov/
MIPS Quality Measures	CMS QPP	https://qpp.cms.gov/mips/quality-measures
Part D Drug Utilization	CMS Part D PUF	https://data.cms.gov/provider-summary-by-type-of-service/medicare-part-d-prescribers

All datasets are CMS public data. No PHI is accessed or stored. All outputs are aggregate or de-identified per CMS data use agreements.

Extending the Server

To add a new dataset:

Add the dataset ID to the DatasetId union type in src/types.ts
Define the filter interface and Zod schema in src/validators.ts
Add a fetch function in src/datasources.ts
Add the tool handler branch in src/tools.ts
Add the dataset entry to DATASET_CATALOG
Add corresponding unit and integration tests
Update schema/cms_data_schema.json with the new record type

This server implements the same pattern used by enterprise RWE platforms (Flatiron, IQVIA, Komodo Health) to expose claims data through typed interfaces — but applies it at the protocol layer rather than the application layer, enabling LLM-native access without a purpose-built frontend.

Relevant literature:

Bodenreider O. (2004). The Unified Medical Language System (UMLS): integrating biomedical terminology. Nucleic Acids Research, 32(Database issue), D267–D270.
Forrest CB, et al. (2014). PCORnet: a national patient-centered clinical research network. Journal of the American Medical Informatics Association, 21(4), 574–577.
Mandl KD, et al. (2020). The SMART/HL7 FHIR-based ecosystem. Journal of the American Medical Informatics Association, 23(3), 447–452.

License

MIT — see LICENSE.

Built as part of a Clinical Data Science portfolio targeting RWE Analyst roles in healthcare analytics. Author: Andrew Lee | GitHub | LinkedIn | ORCID

Available Tools

6 tools

cache_statusB

Return current cache statistics: key count, hit/miss ratio, memory usage. Useful for understanding whether responses are served from cache vs live data.

ParametersJSON Schema

Name	Required	Description	Default
`api_key`	No

TDQS

B3/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It mentions the return metrics but does not specify if the tool is read-only, side effects, or authentication needs.

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 concise with two sentences, front-loading the purpose. No redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no parameter description, the description is incomplete. It lists statistics but lacks details on output format or parameter usage.

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

Parameters1/5

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

The description does not explain the purpose of the only parameter (api_key). With 0% schema coverage, the description fails to add any meaning beyond the schema.

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 clearly states the tool returns cache statistics (key count, hit/miss ratio, memory usage) and distinguishes itself from sibling tools that deal with data queries or schemas.

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

Usage Guidelines3/5

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

The description provides a use case ('useful for understanding whether responses are served from cache vs live data') but does not explicitly mention when to use this tool over siblings or when not to use it.

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

get_dataA

Retrieve filtered records from a CMS dataset. Supports filtering by date range, geography, diagnosis codes, provider identifiers, and more. Results are cached (24h for reference data, 5min for transactional). Returns JSON with data lineage metadata.

ParametersJSON Schema

Name	Required	Description
`dataset_id`	Yes	Target dataset
`filters`	No	Dataset-specific filter parameters. Use get_schema to see available filters for each dataset.
`api_key`	No

TDQS

A3.9/5.0

Behavior4/5

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

With no annotations, the description provides useful behavioral details: caching durations (24h reference, 5min transactional) and JSON return format with data lineage metadata. However, it lacks disclosure on authentication requirements or potential side effects, though 'get_data' implies read-only.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences effectively cover purpose, filters, and caching/return format. No redundant text, front-loaded with core function.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (many parameters, nested object, no output schema) and lack of annotations, the description misses details on constructing the filters object and the required api_key parameter. Caching info is helpful, but pagination and auth are left unclear.

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 67%, and the schema already documents many parameters well. The description adds a general statement about supported filters but no specific parameter meaning beyond what the schema provides. Baseline score of 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 clearly states the tool retrieves filtered records from a CMS dataset, with specific verb and resource. It distinguishes from siblings like 'run_query' by emphasizing filtering capabilities and listing filter types.

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

Usage Guidelines3/5

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

The description implies usage for filtered data retrieval but does not explicitly state when to use this tool versus alternatives like 'run_query' or 'get_schema'. No 'when not to use' or sibling differentiation.

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

get_sample_queriesA

Return example queries and query templates for a given dataset. Includes realistic RWE use cases with parameter examples.

ParametersJSON Schema

Name	Required	Description	Default
`dataset_id`	Yes	Dataset to get sample queries for
`api_key`	No

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description alone must disclose behavioral traits. It only states the function returns examples, with no mention of authentication, rate limits, side effects, or whether it is read-only.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, front-loading the core purpose in the first sentence and adding useful details in the second, with no unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no output schema, so the description should clarify the return format. It does not specify what the output looks like (e.g., array of strings, objects with fields). Given the simple parameter set, this is a notable gap.

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 50%; the dataset_id parameter has an enum and description, but api_key has no description. The description adds context about including 'realistic RWE use cases with parameter examples', which provides extra meaning, but does not document the api_key parameter.

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 clearly states the tool returns example queries and query templates for a given dataset, with a specific verb 'Return' and resource 'sample queries'. It distinguishes from siblings like get_schema, get_data, and run_query by focusing on query examples.

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

Usage Guidelines3/5

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

The description implies use when seeking example queries for a dataset but does not explicitly state when to use it versus alternatives, nor does it mention any conditions or prerequisites.

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

get_schemaA

Return the full field schema (names, types, descriptions, examples) for a specific CMS dataset. Use this before get_data to understand available fields and filter parameters.

ParametersJSON Schema

Name	Required	Description	Default
`dataset_id`	Yes	Dataset identifier
`api_key`	No

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden. It implies a read-only operation by stating it returns schema data, but does not explicitly mention safety or side effects. The name itself suggests read-only, but the description could be more explicit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with two sentences. The first sentence clearly states the purpose, and the second provides usage guidance, making it efficient and well-structured.

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?

Given the tool's simplicity (two parameters, no output schema), the description is fairly complete. It explains what is returned ('names, types, descriptions, examples') and when to use it. However, it lacks details about the api_key parameter and output format specifics.

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

Parameters1/5

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

The schema has 50% coverage (dataset_id has description, api_key does not). The description does not add any parameter semantics beyond the schema. It mentions 'specific CMS dataset' but does not clarify the api_key parameter or its purpose.

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 clearly states the verb 'Return', the resource 'full field schema', and the target 'specific CMS dataset'. It also distinguishes from sibling tools by recommending use before 'get_data'.

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 says 'Use this before get_data to understand available fields and filter parameters', providing clear context for when to use the tool. However, it does not mention when not to use it or alternatives beyond 'get_data'.

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

list_datasetsA

List all available CMS healthcare datasets with metadata including source, update frequency, row count, key fields, and available filters. Always call this first to understand what data is available.

ParametersJSON Schema

Name	Required	Description	Default
`api_key`	No	API key (if server auth is enabled)

TDQS

A4/5.0

Behavior3/5

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

The description discloses the metadata fields returned (source, update frequency, row count, key fields, available filters), which is good. However, without annotations, it does not mention rate limits, authentication behavior (beyond the optional api_key), or any pagination/limitations. It's honest but incomplete.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences: first lists the action and metadata, second provides usage guidance. No wasted words; all information is relevant and front-loaded.

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?

For a simple listing tool with one optional parameter and no output schema, the description provides adequate context by listing the metadata fields and recommending it as a first step. It could mention if there is a maximum number of datasets returned, but it's fairly complete.

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 baseline is 3. The description adds no additional meaning beyond the schema's parameter description for api_key. It does not explain when or how to use the api_key parameter.

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 clearly states the tool 'list all available CMS healthcare datasets with metadata', using a specific verb and resource. It distinguishes from siblings like get_data, get_schema, and run_query which focus on data retrieval or schema, not listing.

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?

It explicitly instructs 'Always call this first to understand what data is available', providing a clear usage context. However, it does not explicitly exclude alternatives or mention specific scenarios where this tool would be inappropriate.

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

run_queryA

Execute a pre-approved named query template with parameters. Templates cover common RWE analyses: HCC grouping, readmission benchmarks, MIPS performance summaries, drug cost trends. Use get_sample_queries to see available templates.

ParametersJSON Schema

Name	Required	Description
`template_id`	Yes	Approved query template identifier
`parameters`	No	Template-specific parameter values
`api_key`	No

TDQS

A3.6/5.0

Behavior2/5

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

No annotations provided, so description bears full burden. It only says 'Execute' with no disclosure of side effects, authentication requirements, rate limits, or whether it is read-only. The api_key parameter implies auth needs but is not mentioned in the description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: first sentence states core purpose, second provides context and sibling reference. No redundant or filler content. Front-loaded with action verb 'Execute'.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, no annotations, and 3 parameters (one nested). Description fails to explain return format, error behavior, pagination details, or authentication needs. Essential context for a query execution tool is missing.

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 covers 67% of parameters with descriptions. The tool description adds no extra meaning to parameters beyond listing template categories. The api_key parameter lacks schema description, and the tool description does not address it. Baseline score of 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?

Description explicitly states 'Execute a pre-approved named query template with parameters' and lists example template categories (HCC grouping, readmission benchmarks, etc.). It distinguishes from siblings like get_data (raw data) and get_sample_queries (listing templates).

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?

Description instructs 'Use get_sample_queries to see available templates,' providing a clear sibling reference. However, it does not explicitly state when to avoid this tool (e.g., for ad-hoc queries) or mention alternative tools.

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. Dates show when Glama detected each change.

6 tool updatesv1.0.0Jun 24, 2026
- First observedcache_status
- First observedget_data
- First observedget_sample_queries
- First observedget_schema
- First observedlist_datasets
- First observedrun_query

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: cache status, data retrieval, sample queries, schema, listing datasets, and executing named queries. No overlap or ambiguity.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern in snake_case (e.g., cache_status, get_data, list_datasets). No mixing of conventions.

Tool Count5/5

6 tools is well-scoped for a healthcare data server, covering discovery, schema, data retrieval, queries, and cache monitoring. Neither too few nor too many.

Completeness4/5

Covers key operations: listing datasets, getting schema, retrieving data, executing pre-built queries, and cache info. Missing clear cache or dataset-level metadata beyond list, but sufficient for its read-only purpose.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

healthcare-data A
com.dataplex-consulting
US healthcare data for AI agents: CMS, FDA adverse events, CDC, NPPES NPI. Keyless, real samples.
Biology & Medicine Government Data Open Data
81
Contextflo
com.contextflo
Query your warehouse or a CSV with Claude/ChatGPT over MCP, governed by table-level ACL + audit.
Databases Security
1
convalytics A
io.github.Dan-Cleary
Read-only analytics for Convex apps, queryable via MCP from Claude, Cursor, and other clients.
Developer Tools Monitoring Databases
1526
AgentSEO B
dev.agentseo.www
Live SEO workflow tools for Claude Code, Codex, and AI agents.
Marketing Browser Automation
454

Related MCP Servers

agentops-mcp
Monitoring Developer Tools
Ludoonus
A
license
A
quality
C
maintenance
Exposes analytics from Claude Code transcripts as MCP tools, enabling cost, audit, safety, and efficiency queries through natural language.
Updated 3 months ago (2026-06-12 10:18 UTC)
4
MIT
cpt-analysis-mcp-server
Biology & Medicine Databases
Ishaan24687
F
license
Not graded
quality
D
maintenance
Connects Claude Desktop to a healthcare claims database for natural-language analysis of CPT codes, reimbursement rates, payer performance, and denial patterns.
Updated 5 months ago (2026-04-10 19:19 UTC)
-
cms-datagov-mcp-server
Government Data Open Data Research & Data
clarifyhealth
A
license
Not graded
quality
D
maintenance
Enables AI assistants to search, query, and analyze CMS healthcare datasets from data.cms.gov, supporting features like dataset discovery, filtering, and CSV download for large-scale analysis.
Updated 9 months ago (2025-12-02 17:50 UTC)
2
MIT
HEOR MCP Server
Biology & Medicine Research & Data
lin-penglin
A
license
Not graded
quality
C
maintenance
Lets Claude run validated, auditable HEOR analyses (cohort construction, outcome computation, overlap-weighted comparison) as deterministic tools on synthetic healthcare data.
Updated 2 months ago (2026-07-05 20:13 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/SaeMind/mcp-server-for-cms-healthcare-data-tools'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

CMS Healthcare Data MCP Server

Overview

Why MCP for CMS Data?

Architecture

Exposed Datasets

Tools Reference

list_datasets

get_schema

get_data

run_query

cache_status

get_sample_queries

How to Run

Prerequisites

Installation

Environment configuration

Build and start (demo mode)

Start without build (development)

Docker (PostgreSQL + server)

Configure Claude Desktop

Example Queries

Safety and Validation

Demo Mode vs. Production Mode

Tableau Dashboard

Testing

Technologies Used

Data Sources

Extending the Server

Related Work

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

`list_datasets`

`get_schema`

`get_data`

`run_query`

`cache_status`

`get_sample_queries`