Skip to main content
Glama
vdeeplearning

NIH Research MCP Demo

by vdeeplearning
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

NIH Research MCP Demo

This is a small, synthetic Model Context Protocol (MCP) server for NIH-style clinical research workflows. It exposes reusable biomedical research tools over MCP so an LLM assistant can search publications, inspect cohort metadata, query AAA measurements, compute summary statistics, and retrieve protocol guidance.

All data in this repository is synthetic/mock data. It does not contain PHI.

What MCP is in this project

MCP is the interface layer between an AI assistant and external research capabilities. In this demo, the MCP server wraps a synthetic patient cohort, CT imaging metadata, publications, and protocol documents behind a small set of typed tools.

Instead of every assistant needing custom code to read CSV files, JSON metadata, and markdown protocols, the tools are implemented once in server.py and exposed through MCP.

Claude / MCP Client
        |
        v
NIH Research MCP Server
        |
        v
Synthetic patient cohort, CT metadata, publications, protocols

Related MCP server: Agent Care MCP

Why MCP is useful for NIH-style biomedical research

Biomedical research systems often span cohort tables, imaging metadata, literature collections, SOPs, and analysis utilities. MCP provides a clean abstraction layer over those resources. A research team can expose validated tools and data access patterns once, then allow multiple AI assistants or applications to reuse them consistently.

That makes it easier to:

  • Reuse the same research infrastructure across AI clients.

  • Keep data access logic centralized and auditable.

  • Separate assistant behavior from biomedical data plumbing.

  • Provide domain-specific tools without embedding data handling code into every chat application.

Tool reference

The server exposes five MCP tools. In a real LLM application, the user asks a natural-language question, the MCP client chooses one of these tools, and the server returns structured data for the assistant to summarize.

search_publications(query: str)

Searches data/publications.json, a synthetic collection of NIH-style research publication records.

Arguments:

  • query: Keyword query used to search publication titles and abstracts. Example: "automated AAA detection".

Returns:

  • A list of matching publications.

  • Each result includes title, authors, year, journal, and short_abstract.

Example use:

Find publications about automated AAA detection.

Why it matters:

This simulates an assistant searching a curated biomedical literature index or internal research knowledge base through a reusable MCP tool instead of custom application code.

get_patient_metadata(patient_id: str)

Returns demographics and CT imaging metadata for one synthetic patient/study.

Arguments:

  • patient_id: Synthetic patient identifier. Example: "SYN-017".

Returns:

  • patient_id

  • age

  • sex

  • aaa_diameter_cm

  • aaa_positive

  • scan_date

  • scanner_manufacturer

  • slice_thickness_mm

  • contrast_status

Example use:

Return metadata for patient SYN-017.

Why it matters:

This simulates an assistant retrieving approved study-level metadata from a clinical research cohort or imaging archive. The demo uses synthetic local files, but the same MCP tool shape could sit in front of a secure database or imaging metadata service.

find_aaa_patients(min_diameter_cm: float = 3.0, min_age: int | None = None)

Finds synthetic patients whose abdominal aortic aneurysm diameter meets a threshold, with an optional age filter.

Arguments:

  • min_diameter_cm: Minimum AAA diameter in centimeters. Default is 3.0, the demo threshold for AAA-positive status.

  • min_age: Optional minimum age filter. Use null or omit it when no age filter is needed.

Returns:

  • A list of matching synthetic patients.

  • Each result includes demographics, AAA diameter, AAA-positive status, scan date, scanner manufacturer, slice thickness, and contrast status.

Example use:

Find patients over 65 with AAA diameter greater than 3 cm.

An MCP client might translate that prompt into a structured tool call similar to:

{
  "tool": "find_aaa_patients",
  "arguments": {
    "min_diameter_cm": 3.0,
    "min_age": 66
  }
}

Why it matters:

This simulates cohort discovery: an LLM assistant can ask a controlled backend tool for patients matching research criteria rather than directly reading or reasoning over raw clinical tables.

compute_aaa_statistics()

Computes descriptive statistics for the full synthetic AAA cohort.

Arguments:

  • None.

Returns:

  • cohort_size

  • aaa_positive_patients

  • prevalence

  • mean_aaa_diameter_cm

  • median_aaa_diameter_cm

  • summary_by_sex, including cohort size, AAA-positive count, prevalence, and mean AAA diameter for each sex group.

Example use:

Compute AAA prevalence in the synthetic cohort.

Why it matters:

This simulates a reusable analysis function exposed through MCP. Instead of each assistant implementing its own statistics logic, the validated computation lives once in the server.

search_protocols(query: str)

Searches markdown research protocol documents in data/protocols.

Arguments:

  • query: Keyword query used to search protocol text. Example: "DICOM de-identification rules".

Returns:

  • A list of matching protocol documents.

  • Each result includes document and a relevant excerpt.

Example use:

Search the protocols for DICOM de-identification rules.

Why it matters:

This simulates an assistant retrieving controlled research SOPs, measurement rules, or data governance procedures through MCP. In a real NIH-style environment, the protocol files could be replaced by an approved document repository.

Install and run

Use Python 3.10 or newer.

pip install -e .
python server.py

When you run python server.py directly in a terminal, it prints local demo instructions. When an MCP client launches the same file with stdio pipes, it runs as the MCP server.

You can try the data tools from PowerShell without configuring an MCP client:

python server.py "Find patients over 65 with AAA diameter greater than 3 cm."
python server.py "Search the protocols for DICOM de-identification rules."
python server.py "Compute AAA prevalence in the synthetic cohort."
python server.py "Find publications about automated AAA detection."

The local demo prints a concise human-readable summary. Add --json to any demo command to inspect the raw tool output.

The project uses the official Python MCP SDK package, declared in pyproject.toml as mcp. The server follows the common FastMCP pattern:

from mcp.server.fastmcp import FastMCP

Example prompts

  • "Find patients over 65 with AAA diameter greater than 3 cm."

  • "Search the protocols for DICOM de-identification rules."

  • "Compute AAA prevalence in the synthetic cohort."

  • "Find publications about automated AAA detection."

More examples are available in examples/example_queries.md.

Project structure

nih-research-mcp/
  README.md
  pyproject.toml
  server.py
  data/
    patients.csv
    imaging_metadata.json
    publications.json
    protocols/
      aaa_screening.md
      dicom_deidentification.md
  examples/
    example_queries.md

Why this matters

Traditional LLM applications often require custom integration code for every data source or tool. This project demonstrates how biomedical research capabilities can be exposed once through MCP, allowing multiple AI applications to reuse the same tools and data access patterns.

Available Tools

5 tools
compute_aaa_statisticsB

Compute simple descriptive statistics for the synthetic AAA cohort.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

B3.2/5.0
Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It only says 'compute simple descriptive statistics,' implying a read-only operation, but does not mention side effects, data sensitivity, or any constraints. The description is insufficient for full transparency.

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, concise sentence that is front-loaded with the key action and target. Every word earns its place with no superfluous content.

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 lack of parameters and existence of an output schema, the description is somewhat adequate but could be improved by specifying what 'simple descriptive statistics' includes (e.g., mean, median, count). It does not mention the output schema, which the instructions say is not required, but more detail would enhance completeness.

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

Parameters4/5

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

There are no parameters, so the schema coverage is complete. The description does not need to add parameter details, and it correctly implies the tool has no inputs. The baseline of 4 is appropriate here.

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 clearly states it computes descriptive statistics for the synthetic AAA cohort, using a specific verb and resource. However, it lacks specificity about which statistics are included, which slightly reduces clarity.

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 sibling tools. While siblings have different purposes (finding patients, metadata, protocols, publications), explicit usage context is missing.

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

find_aaa_patientsA

Find patients meeting an AAA diameter threshold and optional age filter.

ParametersJSON Schema
NameRequiredDescriptionDefault
min_ageNo
min_diameter_cmNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.5/5.0
Behavior2/5

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

No annotations provided, so description carries full burden. It does not disclose behavior like pagination, sorting, error handling, or performance characteristics. Only states basic query operation.

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?

Single sentence of 12 words, no redundancy. Information is front-loaded and efficient.

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?

Adequate for a simple query tool with output schema handling return values. However, lacks context on use cases, limitations, or data scope. Could mention if it supports large datasets or timeouts.

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

Parameters4/5

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

Schema coverage is 0%, but description adds meaning by explaining 'AAA diameter threshold' for min_diameter_cm and 'optional age filter' for min_age. This compensates for lack of schema descriptions, though could clarify units (cm, years).

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 clearly states verb 'Find', resource 'patients', and specific criteria: AAA diameter threshold and optional age filter. This distinguishes it from sibling tools like compute_aaa_statistics and get_patient_metadata.

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 on when to use this tool versus alternatives. No mention of when-not or prerequisites. The description only tells what it does, not how to choose it over siblings.

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

get_patient_metadataB

Return synthetic demographics and CT metadata for one patient/study.

ParametersJSON Schema
NameRequiredDescriptionDefault
patient_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It discloses that the data is synthetic and that the tool returns metadata for one patient/study, implying a read-only operation. However, it omits details like error handling, authentication needs, or rate limits.

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, efficient sentence that front-loads the purpose without any extraneous content. Every word contributes to the overall understanding.

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 tool's simplicity (one parameter, output schema exists), the description covers the core purpose and basic behavior. However, it lacks usage context, such as when to use this tool versus searching for patients, and does not address potential error cases or expected outcomes.

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?

The schema description coverage is 0%, and the description does not add meaning to the required 'patient_id' parameter beyond the schema's title. It only implies the parameter's role through the phrase 'for one patient/study', but lacks format, constraints, or examples.

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 synthetic demographics and CT metadata for a single patient or study, using the verb 'Return' and specifying the resource and scope. This distinguishes it from sibling tools like find_aaa_patients (which finds patients) and compute_aaa_statistics (which computes statistics).

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, nor are there any prerequisites or exclusions. The description only states what the tool does without contextualizing its usage.

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

search_protocolsB

Search markdown research protocol files and return relevant excerpts.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.2/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 of disclosing behavioral traits. It states the tool searches and returns excerpts, implying a read operation, but fails to mention whether it is read-only, any required permissions, rate limits, or other important behaviors.

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 of 10 words, front-loading the verb and resource. Every word contributes to the purpose, with no redundancy or irrelevant details.

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 tool's simplicity (one parameter, output schema exists), the description is minimally adequate. It explains the core function but omits details like whether results are paginated, how many excerpts are returned, or any filtering capabilities. It covers the basics but leaves gaps.

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?

The input schema has one parameter (query) with 0% description coverage in the schema. The description adds minimal meaning by indicating the query is used to search markdown files, but it does not explain query syntax, supported operators, or how excerpts are matched. The description partially compensates but remains insufficient.

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's purpose: 'Search markdown research protocol files and return relevant excerpts.' It specifies the verb (Search), the resource (markdown research protocol files), and the output (relevant excerpts). This distinctively separates it from sibling tools like compute_aaa_statistics or find_aaa_patients.

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 explicit guidance on when to use this tool versus alternatives. While it implies it's for searching protocol files, it does not state when not to use it or suggest other tools for different contexts. The sibling tools list includes search_publications, but no differentiation is made.

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

search_publicationsC

Search synthetic publications by title and abstract keywords.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.9/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 only states the search criteria (title and abstract keywords) but does not disclose behaviors like result limits, pagination, ordering, or side effects. Minimal beyond basic purpose.

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?

A single sentence that is efficient and to the point. No fluff, but it could be slightly more detailed without losing conciseness.

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 description covers the basic action and search fields. With an output schema existing, the return structure is handled. However, lacking usage guidelines and behavioral traits, it feels minimally adequate.

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 0%, so the description must clarify parameters. It adds that the 'query' parameter searches by title and abstract keywords, which provides some meaning beyond the raw schema. However, no format or operators are specified.

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 clearly states it searches synthetic publications by title and abstract keywords. It distinguishes from sibling tools like search_protocols, though it does not explicitly contrast them. The verb 'search' and resource 'publications' are specific.

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 on when to use this tool vs alternatives like search_protocols. No context about prerequisites, typical use cases, or scenarios where other tools might be preferred.

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

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

TDQS

A3.7/5.0
Disambiguation5/5

Each tool targets a distinct function: statistics computation, patient finding, metadata retrieval, protocol search, and publication search. There is no overlap in purposes.

Naming Consistency5/5

All tools follow a consistent verb_noun snake_case pattern (compute_, find_, get_, search_, search_), making naming predictable and clear.

Tool Count5/5

With 5 tools, the server is well-scoped for a research demo, covering essential tasks without being overwhelming or sparse.

Completeness5/5

The tool set covers core research needs: patient cohort exploration, statistics, metadata, and literature/protocol search. No obvious gaps for the stated demo purpose.

Maintenance

ActivityStale
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

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/vdeeplearning/nih-research-mcp'

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