Skip to main content
Glama
Cicatriiz

PopHIVE MCP Server

by Cicatriiz
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Remote

PopHIVE MCP Server

Featured on Claude, try it out here: https://claude.ai/directory/ant.dir.gh.cicatriiz.pophive

A Model Context Protocol (MCP) server that provides access to PopHIVE (Population Health Information Visual Explorer) public health data from Yale School of Public Health. This server exposes comprehensive health surveillance data including immunizations, respiratory diseases, and chronic diseases through standardized MCP tools, resources, and prompts.

🎯 Production-Ready: All critical bugs fixed, enhanced error handling, and comprehensive dataset metadata included.

📦 Desktop Extension Ready: Fully compliant with Anthropic's Desktop Extension (DXT) specification for one-click installation in Claude Desktop and other MCP-enabled applications.

What is PopHIVE?

PopHIVE (Population Health Information Visual Explorer) is Yale's comprehensive platform that aggregates near real-time public health data from authoritative sources including CDC surveillance systems, Epic Cosmos EHR networks, and Google Health Trends. It's an invaluable resource for epidemiologists, researchers, and public health professionals.

👉 Explore PopHIVE: https://www.pophive.org/

Related MCP server: WHO MCP Server

Recent Improvements

New Features

Implemented scrapers for three new datasets:
    Hospital Capacity: Fetches state-level hospital utilization data from HealthData.gov.
    Injury & Overdose: Fetches national-level injury and overdose death data from data.cdc.gov.
    Youth Mental Health ED Visits: Fetches national-level data on youth mental health-related emergency department visits from data.cdc.gov.

Performance Improvements

Implemented a parallel, batched initial fetch for the hospital capacity dataset to significantly speed up the first-time data download.
Added incremental update logic to all scrapers to only fetch new data, reducing subsequent load times.

Bug Fixes

Corrected date parsing logic in the analysis tools to robustly handle various date formats across all datasets.
Fixed an issue where the hospital capacity scraper was not fetching all records.

Overview

PopHIVE aggregates near real-time health data from multiple authoritative sources:

  • CDC National Immunization Survey (NIS): Gold-standard vaccination coverage data

  • Epic Cosmos EHR Network: Real-world clinical data from electronic health records

  • CDC Laboratory Surveillance (NREVSS): Respiratory virus test positivity rates

  • CDC Wastewater Surveillance (NWWS): Environmental viral monitoring

  • Google Health Trends: Population behavior and symptom search patterns

Features

🔧 MCP Tools

  • filter_data: Filter datasets by state, date range, demographics, and conditions

  • compare_states: Compare health metrics across multiple states with statistical analysis

  • time_series_analysis: Analyze trends over time with aggregation options

  • get_available_datasets: Comprehensive catalog of all available datasets

  • search_health_data: Search across datasets for specific conditions or keywords

📊 MCP Resources

  • dataset://immunizations_nis: CDC National Immunization Survey data

  • dataset://immunizations_epic: Epic Cosmos immunization data by demographics

  • dataset://respiratory_ed: Emergency department visits for respiratory viruses

  • dataset://respiratory_lab: Laboratory test positivity rates

  • dataset://respiratory_wastewater: Wastewater viral surveillance data

  • dataset://respiratory_trends: Google search trends for respiratory symptoms

  • dataset://chronic_obesity: Obesity prevalence by state and age group

  • dataset://chronic_diabetes: Diabetes prevalence and glycemic control data

  • dataset://hospital_capacity: HHS hospital capacity data

  • dataset://injury_overdose: CDC injury and overdose data

  • dataset://youth_ed_mental_health: CDC youth mental health ED visit data

💡 MCP Prompts

  • immunization_gaps: Analyze vaccination coverage gaps by demographics

  • respiratory_surge_detection: Detect and analyze respiratory disease surges

  • chronic_disease_trends: Analyze chronic disease prevalence trends

  • multi_source_analysis: Comprehensive analysis integrating multiple data sources

Installation

Option 1: Desktop Extension (Recommended)

For Claude Desktop users:

  1. Download the .dxt file from the releases page

  2. Double-click the file to open with Claude Desktop

  3. Click "Install" in the installation dialog

  4. Configure any required settings (update frequency, cache size)

  5. The extension will be automatically available in Claude Desktop

For other MCP-enabled applications:

  • Use the same .dxt file with any application supporting Desktop Extensions

  • Follow your application's extension installation process

Option 2: Manual Installation

Prerequisites:

  • Node.js 18+

  • npm or yarn

Setup:

  1. Clone and install dependencies:

git clone <repository-url>
cd pophive-mcp-server
npm install

  1. Configure environment (optional):

# Create .env file for custom configuration
echo "DATA_CACHE_DIR=./data" > .env
echo "UPDATE_FREQUENCY=daily" >> .env

  1. Test the server:

npm test

  1. Start the server:

npm start

Option 3: Build Your Own Extension

Create a Desktop Extension from source:

  1. Install DXT CLI tools:

npm install -g @anthropic-ai/dxt

  1. Clone and prepare:

git clone <repository-url>
cd pophive-mcp-server
npm install

  1. Package as extension:

dxt pack

  1. Install the generated .dxt file in Claude Desktop or other MCP applications

Configuration

Environment Variables

Variable

Default

Description

DATA_CACHE_DIR

./data

Directory for cached data files

UPDATE_FREQUENCY

daily

Data refresh frequency (hourly, daily, weekly)

NODE_ENV

development

Environment mode

MCP Client Configuration

Add to your MCP client configuration (e.g., Claude Desktop):

{
  "mcpServers": {
    "pophive": {
      "command": "node",
      "args": ["server/index.js"],
      "cwd": "/path/to/pophive-mcp-server"
    }
  }
}

Dataset Selection Guide

Choose the right dataset for your analysis:

Dataset

Geographic Level

Best Use Cases

Date Range

Update Frequency

Key Limitations

immunizations_nis

National + State

National vaccination trends, state comparisons

2019-2024

Annual

Survey data, limited demographics

immunizations_epic

National + State

Real-world vaccination patterns, insurance analysis

2020-2024

Monthly

EHR network bias

respiratory_ed

National + State

Emergency department surveillance, outbreak detection

2020-2024

Weekly

Healthcare utilization only

respiratory_lab

National only

Clinical test positivity, laboratory surveillance

2020-2024

Weekly

National aggregates only

respiratory_wastewater

Regional

Environmental surveillance, early warning

2022-2024

Weekly

Limited geographic coverage

respiratory_trends

National + State

Population behavior, symptom searches

2020-2024

Weekly

Behavioral proxy, not clinical

chronic_obesity

National + State

Obesity prevalence, chronic disease tracking

2020-2024

Quarterly

Clinical populations only

chronic_diabetes

National + State

Diabetes management, glycemic control

2020-2024

Quarterly

Clinical populations only

hospital_capacity

State

Hospital utilization, bed capacity, staffing shortages

2020-2024

Daily

COVID-era focus

injury_overdose

National

Drug overdoses, homicides, suicides

2019-2025

Monthly/Quarterly

National aggregates only

youth_ed_mental_health

National

Youth mental health ED visits, demographic trends

2019-2025

Monthly

National aggregates only

Quick Dataset Selection

For national trends: Use immunizations_nis, respiratory_lab, or any dataset with geography="national"

For state comparisons: Use respiratory_ed, chronic_obesity, chronic_diabetes, or immunizations_nis

For real-time surveillance: Use respiratory_ed, respiratory_wastewater, or respiratory_trends

For clinical outcomes: Use immunizations_epic, chronic_obesity, or chronic_diabetes

Usage Examples

Basic Data Filtering

// ✅ WORKING: Filter immunization data for California
{
  "tool": "filter_data",
  "arguments": {
    "dataset": "immunizations_nis",
    "state": "CA"
  }
}

// ✅ WORKING: Filter national immunization data
{
  "tool": "filter_data",
  "arguments": {
    "dataset": "immunizations_nis",
    "state": "US"
  }
}

// ❌ AVOID: This will return 0 results
{
  "tool": "filter_data",
  "arguments": {
    "dataset": "respiratory_lab",
    "state": "CA"  // respiratory_lab only has national data
  }
}

State Comparison

// ✅ WORKING: Compare obesity rates across states
{
  "tool": "compare_states",
  "arguments": {
    "dataset": "chronic_obesity",
    "states": ["CA", "TX", "FL", "NY"],
    "metric": "prevalence_rate",
    "time_period": "latest"
  }
}

// ✅ WORKING: Compare vaccination coverage
{
  "tool": "compare_states",
  "arguments": {
    "dataset": "immunizations_nis",
    "states": ["California", "Texas", "New York"],  // Full names work too
    "metric": "coverage_rate"
  }
}

Time Series Analysis

// ✅ WORKING: Analyze national respiratory trends
{
  "tool": "time_series_analysis",
  "arguments": {
    "dataset": "respiratory_ed",
    "metric": "ed_visits_per_100k",
    "geography": "national",  // Use "national" for US-level data
    "aggregation": "weekly"
  }
}

// ✅ WORKING: Analyze state-level trends
{
  "tool": "time_series_analysis",
  "arguments": {
    "dataset": "respiratory_ed",
    "metric": "ed_visits_per_100k",
    "geography": "CA",
    "start_date": "2024-01-01",
    "end_date": "2024-12-01"
  }
}

Search Health Data

// ✅ WORKING: Search with national geography
{
  "tool": "search_health_data",
  "arguments": {
    "query": "RSV",
    "geography": "national"  // Fixed: Use "national" instead of "US"
  }
}

// ✅ WORKING: Search specific datasets
{
  "tool": "search_health_data",
  "arguments": {
    "query": "vaccination coverage",
    "datasets": ["immunizations_nis", "immunizations_epic"]
  }
}

Using Prompts

// ✅ WORKING: Generate immunization gap analysis
{
  "prompt": "immunization_gaps",
  "arguments": {
    "state": "Texas",
    "demographic_focus": "insurance"
  }
}

// ✅ WORKING: Detect respiratory surges
{
  "prompt": "respiratory_surge_detection",
  "arguments": {
    "region": "California",
    "virus_type": "RSV",
    "time_period": "last_4_weeks"
  }
}

Common Issues & Solutions

Issue: "No data found" or 0 results

Cause: Geographic mismatch or dataset limitations

Solutions:

  1. Check dataset capabilities: Use get_available_datasets to see supported geographies

  2. Use correct geography values:

    • For national data: "geography": "national" (not "US")

    • For states: Use state codes ("CA") or full names ("California")

  3. Try alternative datasets: Some datasets only support national-level analysis

// ❌ Problem: Wrong geography for national data
{
  "tool": "search_health_data",
  "arguments": {
    "query": "influenza",
    "geography": "US"  // Should be "national"
  }
}

// ✅ Solution: Use correct geography
{
  "tool": "search_health_data",
  "arguments": {
    "query": "influenza",
    "geography": "national"
  }
}

Issue: Empty results for state-level queries

Cause: Dataset only contains national-level data

Solutions:

  1. Check dataset metadata first using get_available_datasets

  2. Use state-capable datasets: respiratory_ed, chronic_obesity, chronic_diabetes, immunizations_nis

  3. Switch to national analysis for datasets like respiratory_lab

Issue: Metric not found

Cause: Incorrect metric name or dataset mismatch

Solutions:

  1. Use dataset-appropriate metrics:

    • Immunizations: coverage_rate, sample_size

    • Respiratory: ed_visits_per_100k, positivity_rate

    • Chronic: prevalence_rate, patient_count

  2. Check sample data using get_available_datasets with include_sample: true

Working Parameter Combinations

Immunization Analysis

// National vaccination trends
{
  "tool": "time_series_analysis",
  "arguments": {
    "dataset": "immunizations_nis",
    "metric": "coverage_rate",
    "geography": "national"
  }
}

// State vaccination comparison
{
  "tool": "compare_states",
  "arguments": {
    "dataset": "immunizations_nis",
    "states": ["CA", "TX", "NY", "FL"],
    "metric": "coverage_rate"
  }
}

Respiratory Surveillance

// Emergency department trends
{
  "tool": "filter_data",
  "arguments": {
    "dataset": "respiratory_ed",
    "state": "CA",
    "condition": "RSV"
  }
}

// National lab surveillance
{
  "tool": "time_series_analysis",
  "arguments": {
    "dataset": "respiratory_lab",
    "metric": "positivity_rate",
    "geography": "national"
  }
}

Chronic Disease Analysis

// Obesity prevalence by state
{
  "tool": "filter_data",
  "arguments": {
    "dataset": "chronic_obesity",
    "state": "TX",
    "age_group": "18-64"
  }
}

// Diabetes trends
{
  "tool": "time_series_analysis",
  "arguments": {
    "dataset": "chronic_diabetes",
    "metric": "prevalence_rate",
    "geography": "CA"
  }
}

Data Sources & Quality

Immunization Data

  • NIS Data: Household survey, gold standard for coverage rates

  • Epic Cosmos: EHR data with demographic breakdowns

  • Update Frequency: Annual (NIS), Monthly (Epic)

  • Geographic Level: State

  • Quality: High confidence, large sample sizes

Respiratory Disease Surveillance

  • ED Visits: Near real-time healthcare utilization

  • Lab Data: Clinical test positivity rates

  • Wastewater: Environmental viral monitoring (early indicator)

  • Search Trends: Population behavior signals

  • Update Frequency: Weekly

  • Quality: High for clinical data, moderate for environmental/behavioral

Chronic Disease Data

  • Source: Epic Cosmos EHR network

  • Metrics: Clinical measurements (BMI, HbA1c)

  • Update Frequency: Quarterly

  • Geographic Level: State with age stratification

  • Quality: High - real-world clinical data

API Reference

Tools

filter_data

Filter datasets by various criteria.

Parameters:

  • dataset (required): Dataset identifier

  • state (optional): State code or name

  • start_date (optional): Start date (YYYY-MM-DD)

  • end_date (optional): End date (YYYY-MM-DD)

  • age_group (optional): Age group filter

  • condition (optional): Condition/metric filter

compare_states

Compare health metrics across multiple states.

Parameters:

  • dataset (required): Dataset identifier

  • states (required): Array of state codes/names

  • metric (required): Metric to compare

  • time_period (optional): Time period for comparison

time_series_analysis

Analyze trends over time.

Parameters:

  • dataset (required): Dataset identifier

  • metric (required): Metric to analyze

  • geography (optional): Geographic focus

  • start_date (optional): Analysis start date

  • end_date (optional): Analysis end date

  • aggregation (optional): Time aggregation (weekly, monthly, quarterly, yearly)

Resources

All resources return JSON data with standardized schemas:

// Example immunization record
{
  "geography": "CA",
  "year": 2024,
  "vaccine": "MMR",
  "age_group": "19-35 months",
  "coverage_rate": 96.1,
  "sample_size": 1876,
  "source": "CDC NIS"
}

// Example respiratory surveillance record
{
  "geography": "US",
  "date": "2024-12-01",
  "week": "2024-48",
  "virus": "RSV",
  "ed_visits_per_100k": 3.8,
  "percent_change": 15.2,
  "source": "Epic Cosmos"
}

Development

Project Structure

pophive-mcp-server/
├── server/
│   ├── index.js                 # Main MCP server
│   ├── utils/
│   │   └── data-loader.js       # Data loading and caching
│   ├── tools/
│   │   └── analysis-tools.js    # MCP tool implementations
│   ├── prompts/
│   │   └── prompt-templates.js  # MCP prompt templates
│   └── scrapers/
│       ├── immunizations.js     # Immunization data scraper
│       ├── respiratory.js       # Respiratory data scraper
│       └── chronic-diseases.js  # Chronic disease data scraper
├── data/                        # Cached data files
├── package.json
├── manifest.json               # MCP server manifest
└── README.md

Adding New Data Sources

  1. Create a scraper in server/scrapers/

  2. Update data loader to include new datasets

  3. Add resource mappings in the main server

  4. Update tool logic to handle new data types

  5. Create prompts for new analysis types

Testing

# Run all tests
npm test

# Test specific components
npm run test:tools
npm run test:scrapers
npm run test:integration

Data Refresh

The server automatically refreshes data based on the UPDATE_FREQUENCY setting. Manual refresh:

npm run refresh-data

Troubleshooting

Common Issues

Server won't start:

  • Check Node.js version (18+ required)

  • Verify all dependencies installed: npm install

  • Check for port conflicts

No data returned:

  • Data may be initializing on first run

  • Check data directory permissions

  • Verify network connectivity for scraping

MCP client connection issues:

  • Verify server path in client configuration

  • Check server logs for errors

  • Ensure MCP client supports stdio transport

Logging

Server logs are written to stderr and include:

  • Data scraping activities

  • Tool execution results

  • Error messages and stack traces

Enable verbose logging:

DEBUG=pophive:* npm start

Contributing

  1. Fork the repository

  2. Create a feature branch

  3. Make changes with tests

  4. Submit a pull request

Code Style

  • Use ESLint configuration

  • Follow existing patterns

  • Add JSDoc comments for public APIs

  • Include error handling

License

MIT License - see LICENSE file for details.

Support

  • Issues: GitHub Issues

  • Documentation: This README and inline code comments

  • Data Questions: Refer to original PopHIVE sources

Acknowledgments

  • Yale School of Public Health for PopHIVE initiative

  • CDC for surveillance data systems

  • Epic Systems for Cosmos EHR network data

  • Model Context Protocol community for standards

Available Tools

5 tools
compare_statesC

Compare health metrics across multiple states

ParametersJSON Schema
NameRequiredDescriptionDefault
metricYesSpecific metric to compare (e.g., "vaccination_rate", "ed_visits", "positivity_rate")
statesYesArray of state codes or names to compare
datasetYesDataset to analyze
time_periodNoTime period for comparison (e.g., "latest", "2024", "last_6_months")

TDQS

C2.9/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 carry the full burden. It only states that it compares metrics, implying a read operation, but does not disclose what the output looks like, any limitations, or side effects. For a tool with required parameters and no output schema, this is insufficient.

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 a single concise sentence with no unnecessary words. It effectively communicates the core purpose without redundancy. It could be slightly expanded to include usage guidance without losing conciseness, but given its current length, it earns its place.

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 the tool has 4 parameters (3 required), no output schema, and no annotations, the 6-word description is too minimal. It does not explain what the comparison output is, any constraints beyond schema, or how results are structured. The description leaves significant gaps for an agent trying to invoke the tool correctly.

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 has 100% description coverage for its 4 parameters. The description adds no additional meaning beyond the schema; it simply echoes the tool's purpose. According to the rubric, with coverage >80%, baseline is 3, and the description does not improve it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Compare health metrics across multiple states' clearly states the verb (compare) and resource (health metrics across states). While it distinguishes from siblings like filter_data and time_series_analysis, it does not explicitly differentiate from search_health_data which could also compare across states. Still, the purpose is well communicated.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus siblings like filter_data, get_available_datasets, search_health_data, or time_series_analysis. There is no mention of prerequisites or context that would help an agent choose this tool over others.

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

filter_dataB

Filter PopHIVE datasets by various criteria (state, date range, demographics)

ParametersJSON Schema
NameRequiredDescriptionDefault
stateNoState code (e.g., CA, TX, NY) or state name
datasetYesDataset to filter
end_dateNoEnd date for filtering (YYYY-MM-DD)
age_groupNoAge group to filter by (e.g., "0-2 years", "18-64", "65+")
conditionNoHealth condition or metric to filter by
start_dateNoStart date for filtering (YYYY-MM-DD)

TDQS

B3.4/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 cover behavioral traits. It states the tool filters data, but does not mention whether it is read-only, pagination, limits, or side effects. For a filter tool, read-only nature should be 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 a single sentence, front-loaded with the main action, and contains no unnecessary words. It is concise and to the point.

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 the tool has 6 parameters (1 required) and no output schema or annotations, the description is minimal. It lacks details on return format, empty results, sorting, or limits. For a filter tool with many optional filters, more context would improve completeness.

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 all parameters are documented there. The description adds a summary of criteria categories but no additional meaning beyond the schema. 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 clearly states the action ('filter'), the resource ('PopHIVE datasets'), and examples of criteria ('state, date range, demographics'). It distinguishes from sibling tools like 'compare_states' or 'time_series_analysis' which have different purposes.

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 when to use this tool (for filtering datasets), but does not explicitly compare to siblings like 'search_health_data' or 'get_available_datasets'. No when-not-to-use or alternative guidance is provided.

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

get_available_datasetsB

Get comprehensive information about all available PopHIVE datasets

ParametersJSON Schema
NameRequiredDescriptionDefault
include_sampleNoInclude sample data for each dataset

TDQS

B3/5.0
Behavior2/5

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

With no annotations, the description carries full burden. It mentions 'comprehensive information' but does not specify what that includes (e.g., dataset names, descriptions, metadata). The include_sample parameter hints at sample data but behavior is not fully disclosed (e.g., data volume, pagination, response format).

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 a single short sentence, which is functional but could be more informative. It is not excessively verbose but lacks some useful context. It is adequately concise but not exemplary.

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 the simplicity (1 optional param, no output schema), the description is minimal. It does not explain what datasets are, what information is returned, or how it fits with sibling tools. More context about data discovery workflow would improve completeness.

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 coverage is 100% with the boolean parameter already well-described. The description does not add significant extra meaning beyond the schema's 'Include sample data for each dataset'. The baseline is 3, and no additional value is provided.

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 'Get comprehensive information about all available PopHIVE datasets', specifying the verb (Get), resource (available datasets), and scope (all). It distinguishes well from sibling tools like compare_states and filter_data, which are more specific operations.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. It does not mention that this tool should be used first to discover available datasets before applying filters or analyses. The description lacks any usage context or exclusion conditions.

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

search_health_dataB

Search across all datasets for specific health conditions, metrics, or keywords

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesSearch query (health condition, metric name, or keyword)
datasetsNoSpecific datasets to search (if empty, searches all)
geographyNoGeographic filter for search results

TDQS

B3.1/5.0
Behavior2/5

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

Without annotations, the description should disclose behavioral traits like output format, pagination, or data sources. It only says 'search' and does not explain what the result looks like or any constraints, leaving the agent blind to key behaviors.

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 a single concise sentence that front-loads the main purpose. It could be slightly expanded without losing conciseness, but it is efficient and to the point.

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 the tool has no output schema and no annotations, the description is too minimal. It does not explain return format, result structure, or how to further refine searches, leaving significant gaps for a search tool.

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 coverage is 100%, so the description does not need to add meaning for parameters. The description does not provide additional semantics beyond what is already in the schema's property 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 description clearly states the action ('Search across all datasets') and the target ('health conditions, metrics, or keywords'). It differentiates from siblings like 'compare_states' or 'time_series_analysis' by focusing on generic search across all datasets.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. Sibling tools are listed but there is no explicit differentiation or recommendation on which to choose for specific tasks.

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

time_series_analysisC

Analyze trends over time for specific health metrics

ParametersJSON Schema
NameRequiredDescriptionDefault
metricYesMetric to analyze over time
datasetYes
end_dateNo
geographyNoGeographic focus (state, region, or "national")
start_dateNo
aggregationNomonthly

TDQS

C2.7/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden. It does not disclose whether the tool is read-only, what data freshness assumptions exist, or if side effects occur. The output format is not mentioned, leaving the agent uncertain about what to expect.

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 a single sentence, which is efficient and front-loaded with the core purpose. However, it is too concise at the expense of necessary detail, bordering on under-specification.

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 6 parameters, the description fails to explain return values, default behaviors (e.g., start_date not required), or what happens if dates are omitted. The tool lacks sufficient context for an agent to invoke it correctly without additional knowledge.

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

Parameters2/5

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

Schema description coverage is only 33%, and the description adds no additional meaning beyond the schema's parameter names. For example, 'metric' and 'geography' lack elaboration, and the description does not clarify valid metric values or date range implications.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'Analyze trends over time for specific health metrics,' which clearly indicates the tool's purpose of time series analysis on health metrics. However, it lacks specificity about the type of analysis (e.g., modeling, forecasting) and does not differentiate from sibling tools like compare_states or filter_data.

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

Usage Guidelines2/5

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

No usage guidelines are provided. The description does not specify when to use this tool versus alternatives like compare_states or search_health_data. There is no guidance on prerequisites, data context, or limitations.

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.

  1. 5 tool updates
    • Addedcompare_states
    • Addedfilter_data
    • Addedget_available_datasets
    • Addedsearch_health_data
    • Addedtime_series_analysis
  2. 5 tool updatesv1.1.0
    • Removedcompare_states
    • Removedfilter_data
    • Removedget_available_datasets
    • Removedsearch_health_data
    • Removedtime_series_analysis
  3. 5 tool updatesv1.0.0
    • First observedcompare_states
    • First observedfilter_data
    • First observedget_available_datasets
    • First observedsearch_health_data
    • First observedtime_series_analysis
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0
Disambiguation5/5

Each tool serves a clearly distinct purpose: comparing states, filtering datasets, listing datasets, searching, and time series analysis. No two tools have overlapping functionality.

Naming Consistency4/5

Most tools follow a verb_noun pattern (compare_states, filter_data, get_available_datasets, search_health_data). time_series_analysis is slightly less imperative but still descriptive and consistent in style.

Tool Count5/5

With 5 tools, the server is well-scoped for a health data exploration API. Each tool addresses a key operation without redundancy or bloat.

Completeness4/5

The tool set covers core data exploration needs: discovery, search, filtering, comparison, and trend analysis. Minor missing features like data export exist but are optional for a query-focused server.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • Epic Healthcare MCP Server

    ammar-rcyber
    -
    license
    Not graded
    quality
    Not graded
    maintenance
    Enables AI assistants to securely access Epic Healthcare Systems patient data through FHIR R4 API integration. Provides tools for searching patients, retrieving clinical summaries, vital signs, medications, and generating healthcare reports with HIPAA-compliant OAuth 2.0 authentication.
    -

  • WHO MCP Server

    openpharma-org
    A
    license
    B
    quality
    D
    maintenance
    Provides access to the World Health Organization's Global Health Observatory data, enabling AI assistants to search, retrieve, and analyze comprehensive health indicators, country statistics, disease burden data, and regional health trends through WHO's OData API.
    1
    MIT

  • CDC MCP Server

    openpharma-org
    A
    license
    Not graded
    quality
    D
    maintenance
    Provides access to 73 CDC public health datasets covering disease surveillance, vaccination tracking, behavioral risk factors, environmental health, and outbreak detection across 18 surveillance systems through the Socrata Open Data API.
    2
    MIT

Latest Blog Posts

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/Cicatriiz/pophive-mcp-server'

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