Secure Clinical LLM Access via MCP

A research-oriented framework for secure access to structured clinical data using open-weight large language models and the Model Context Protocol (MCP).

Overview

Large language models can provide an intuitive interface for exploring complex data, but directly connecting an LLM to a clinical database introduces important challenges around data access, security, reliability, and control.

This project investigates a controlled alternative: exposing structured clinical data to an LLM through a set of narrowly scoped, validated, and auditable tools using the Model Context Protocol (MCP).

Instead of allowing the model to generate and execute arbitrary SQL, the system provides purpose-specific tools for accessing clinical information. This creates an explicit security boundary between the language model and the underlying database.

The project combines:

• Open-weight LLMs

• Model Context Protocol (MCP)

• Structured relational clinical data

• Python-based data transformation pipelines

• Tool-scoped database access

• Input validation and result-size limits

• Audit logging

• Security testing

• LLM-based clinical question answering

All clinical data used in this project is synthetic. No real patient data is stored or processed.

Related MCP server: atlas_mcp

Research Motivation

The project explores the following question:

How can open-weight language models access and analyze structured clinical data while maintaining a controlled and auditable data-access boundary?

This is particularly relevant to clinical research environments where medical professionals may need natural-language access to complex datasets without giving an LLM unrestricted access to the underlying database.

The system therefore focuses on the interface between:

Human
  │
  │ Natural-language question
  ▼
Open-weight LLM
  │
  │ Tool selection
  ▼
MCP Interface
  │
  │ Validated, scoped request
  ▼
Clinical Database
  │
  ▼
Synthetic Clinical Data

System Architecture

                  ┌──────────────────────────┐
                  │       User / Clinician   │
                  └────────────┬─────────────┘
                               │
                       Natural-language
                            question
                               │
                               ▼
                  ┌──────────────────────────┐
                  │    Open-weight LLM       │
                  │      (Ollama)             │
                  └────────────┬─────────────┘
                               │
                         Tool selection
                               │
                               ▼
                  ┌──────────────────────────┐
                  │       MCP Client          │
                  │     Clinical Agent        │
                  └────────────┬─────────────┘
                               │
                         MCP protocol
                               │
                               ▼
                  ┌──────────────────────────┐
                  │       MCP Server          │
                  │                          │
                  │  • Input validation      │
                  │  • Tool scoping          │
                  │  • Result limits         │
                  │  • PII exclusion         │
                  │  • Audit logging          │
                  └────────────┬─────────────┘
                               │
                       Controlled tools
                               │
                               ▼
                  ┌──────────────────────────┐
                  │    Relational Database   │
                  │        SQLite            │
                  └────────────┬─────────────┘
                               │
                               ▼
                  ┌──────────────────────────┐
                  │   Synthetic Clinical     │
                  │        Data              │
                  │        Synthea            │
                  └──────────────────────────┘

Data Pipeline

Clinical data is generated using Synthea, a synthetic patient generator designed to produce realistic but non-identifiable medical records.

The generated heterogeneous CSV files are transformed into a linked relational database:

Synthea
   │
   ├── Patients
   ├── Encounters
   ├── Conditions
   ├── Observations
   └── Medications
          │
          ▼
     Ingestion Pipeline
          │
          ▼
   Relational SQLite DB

The ingestion pipeline is implemented in Python and establishes relationships between patients, encounters, diagnoses, observations, and medications.

Why MCP Instead of Direct SQL?

A central design decision is not to expose a generic SQL execution tool to the language model.

A naive architecture might look like:

LLM → Generate SQL → Execute SQL → Database

This approach gives the model significant control over the database and creates unnecessary security risks.

This project instead uses:

LLM
 │
 ▼
MCP Tool
 │
 ├── Validate parameters
 ├── Restrict operation
 ├── Limit result size
 ├── Exclude identifying fields
 └── Record audit event
 │
 ▼
Database

Each tool has a narrowly defined purpose.

For example:

get_patient_summary()
get_conditions()
get_medications()
get_lab_trends()
get_encounters()

The model can select and parameterize these tools, but it cannot arbitrarily execute SQL.

This creates a tool-level security boundary that is independent of the model's ability to follow system prompts.

Security Model

The project treats the LLM as an untrusted component.

Security controls are therefore implemented outside the model wherever possible.

Implemented controls

• Tool-scoped database access

• Input validation

• Read-only operations

• Result-size limits

• Exclusion of identifying fields

• Audit logging

• Protocol-level testing

• Security test suite

The design goal is:

Do not rely on the LLM to enforce security policies that can be enforced by the application layer.

This is particularly important when language models are connected to sensitive data sources.

MCP Tools

The MCP server currently exposes five controlled tools.

Each tool validates its arguments before accessing the database.

LLM Integration

The project is designed to work with local open-weight language models through Ollama.

Example:

User:
Find a female patient and summarize her conditions.

        ↓

Open-weight LLM

        ↓

MCP tool selection

        ↓

get_patient_summary(...)

        ↓

Validated database query

        ↓

Structured result

        ↓

LLM-generated response

The architecture keeps the clinical database local rather than requiring patient data to be sent to an external LLM API.

Evaluation

The project includes an evaluation framework covering both security and usability.

Security evaluation

The security test suite checks whether the MCP layer correctly prevents unauthorized or unsafe operations.

Examples include:

• Invalid tool parameters

• Excessive result requests

• Unauthorized field access

• Unsafe database operations

• Tool-boundary violations

• Audit logging behavior

Current security test status:

7 / 7 security tests passing

Usability evaluation

The evaluation framework is designed to measure:

• Question-answer accuracy

• Tool-selection accuracy

• Response latency

• Successful completion of clinical queries

• Failure cases

The goal is to evaluate not only whether the system works, but how reliably an LLM can interact with structured clinical data through constrained tools.

Project Structure

secure-clinical-llm-mcp/
│
├── agent/
│   ├── __init__.py
│   └── clinical_agent.py
│
├── eval/
│   ├── security_tests.py
│   ├── usability_benchmark.py
│   └── EVALUATION_REPORT.md
│
├── mcp_server/
│   └── server.py
│
├── pipeline/
│   └── ingest.py
│
├── synthea/
│   └── synthea.properties
│
├── requirements.txt
├── README.md
└── .gitignore

Installation

1. Clone the repository

git clone https://github.com/eyasu11321238a/secure-clinical-llm-mcp.git
cd secure-clinical-llm-mcp

2. Install Python dependencies

pip install -r requirements.txt

3. Download Synthea

Synthea is not included in the repository.

Download the latest release:

cd synthea

curl -L -o synthea-with-dependencies.jar \
  https://github.com/synthetichealth/synthea/releases/download/master-branch-latest/synthea-with-dependencies.jar

Java 17 or newer is required.

4. Generate synthetic clinical data

java -jar synthea-with-dependencies.jar \
  -p 25 \
  -c synthea.properties \
  Massachusetts

5. Build the relational database

cd ../pipeline

python ingest.py \
  --csv-dir ../synthea/output/csv \
  --db ../data/clinical.db

6. Start the MCP server

cd ../mcp_server

python server.py

7. Run the security tests

cd ../eval

python security_tests.py

Local LLM

The agent can be connected to an open-weight model running locally through Ollama.

For example:

ollama pull llama3.2:3b

Then run:

python agent/clinical_agent.py \
  "Find a female patient and summarize her conditions"

The agent communicates with the MCP server rather than accessing the database directly.

Current Status

Completed

• Synthetic clinical data generation with Synthea

• Heterogeneous clinical-data ingestion pipeline

• Relational SQLite clinical database

• MCP server

• Five scoped clinical-data tools

• Input validation

• Result-size restrictions

• Identifying-field exclusion

• Audit logging

• MCP protocol-level testing

• Local Ollama agent integration

• Security test suite

• 7/7 security tests passing

In Progress

• Schema-aware clinical query layer

• Expanded clinical question benchmark

• Tool-selection accuracy evaluation

• Latency evaluation

• Prompt-injection evaluation

• Expanded security analysis

• Research evaluation report

Future Work

Several extensions are planned to move the prototype toward a more comprehensive research framework.

1. Schema-aware reasoning

Provide the LLM with structured descriptions of the relational schema and investigate how effectively it can select appropriate tools and parameters.

2. Expanded clinical benchmark

Develop a benchmark containing clinical questions ranging from simple lookups to multi-table analytical queries.

3. Security evaluation

Evaluate robustness against:

• Prompt injection

• Malicious clinical text

• Unauthorized data requests

• Tool manipulation

• Excessive data retrieval

• Attempts to bypass access controls

4. Heterogeneous medical data

Extend the pipeline to support additional healthcare data representations, including FHIR resources.

5. Model comparison

Compare multiple open-weight LLMs with respect to:

• Tool-selection accuracy

• Clinical query accuracy

• Latency

• Failure rate

• Security robustness

Limitations

This project is a research prototype and not a clinical decision-support system.

The data is entirely synthetic and therefore does not represent the full complexity, noise, missingness, or distribution of real-world hospital data.

The system should not be used for medical diagnosis, treatment decisions, or real patient care.

Further validation would be required before applying the approach to real clinical environments.

Research Relevance

This project sits at the intersection of:

Large Language Models
        +
Structured Data
        +
Medical Informatics
        +
MCP / Tool Calling
        +
Data Engineering
        +
AI Security
        +
Evaluation

The central objective is to investigate how language models can provide a natural-language interface to structured clinical data without giving the model unrestricted access to the underlying data source.