Healthcare MCP Server

A custom MCP (Model Context Protocol) server that lets an AI agent (Claude Desktop, or any MCP client) query a small patient-records SQLite database.

Project structure

healthcare-mcp-server/
├── server.py           # MCP server - registers all tools, runs Streamable HTTP on port 8000
├── db.py                # SQLite connection + CREATE TABLE statements
├── seed_data.py          # Populates patients.db with sample data
├── requirements.txt
├── tools/
│   ├── schema.py         # get_schema tool
│   ├── query.py           # query_database tool (SELECT-only, guarded)
│   ├── risk.py             # get_patient_risk_summary tool
│   └── readmission.py       # get_readmission_risk_summary tool
└── patients.db            # created after running db.py + seed_data.py

Related MCP server: MCP SQLite Server (Read-Only)

Tools exposed

Setup

cd healthcare-mcp-server
pip install -r requirements.txt

# 1. Create the tables
python db.py

# 2. Populate sample data (safe to re-run)
python seed_data.py

# 3. Start the MCP server (Streamable HTTP on port 8000)
python server.py

The server will be reachable at http://localhost:8000/mcp.

Connecting it to Claude Desktop

1. Open Claude Desktop → Settings → Developer → Edit Config.

2. Add an entry under mcpServers pointing at your running server:

{
  "mcpServers": {
    "my-healthcare-server": {
      "url": "http://localhost:8000/mcp"
    }
  }
}

3. Save, fully quit and reopen Claude Desktop.

4. Click the + icon → your server should now be listed under connectors. Enable it, and Claude will be able to call the four tools above.

Example prompts to try

• "Can you get me any 5 patient details?"

• "What is the risk profile of the patient James Walker?"

• "How many times has James Walker visited the hospital, and which doctors has he consulted?"

The last question needs a JOIN across visits and can't be answered without the agent first calling get_schema to understand the table structure - that's the point of exposing schema as its own tool.

Safety note

query_database only allows SELECT statements and blocks a short list of destructive keywords (insert, update, delete, drop, alter, attach). This is a minimal example guardrail, not a production-grade solution - a real deployment would need parameterized queries, per-table allow-lists, row limits, timeouts, and audit logging on top of this.