MoleCare MCP Server
Model Context Protocol (MCP) server that gives Claude and other MCP clients access to:
- Dermatology knowledge — ABCDE education, SNOMED CT / ICD-10 helpers, risk-factor prompts
- Optional MoleCare API tools — moles, trends, analysis (your backend + API key)
- Optional MLOps / ops tools — shipped as a separate binary,
molecare-ops-mcp (mock-first)
Not a medical device. Outputs are educational and operational aids only. Do not use for diagnosis or treatment decisions.
Product site: molecare.co.uk · App: iOS · Android
One command, no API key, no database. Real output from the published package.
Why this exists
MoleCare helps people track moles over time and prepare for clinician visits. This MCP server lets developers and operators:
- Query educational skin-health knowledge from Claude Desktop / Cursor
- Prototype assistant flows against a MoleCare-compatible API
- Explore MLOps tooling with safe mock data when no credentials are set
Quick start
No credentials, no database, no cloud account. Add this to your MCP client config
and restart it:
{
"mcpServers": {
"molecare": {
"command": "npx",
"args": ["-y", "molecare-mcp"]
}
}
}
For Claude Desktop on macOS that file is
~/Library/Application Support/Claude/claude_desktop_config.json.
The dermatology knowledge tools work immediately — they read from a knowledge base
bundled in the package. Everything that talks to a backend returns clearly-labelled
mock data until you configure it, so you can explore the whole tool surface before
deciding whether you want any of it.
To try it without a client at all:
It starts and waits on stdio. No output means it is working.
Connecting a real backend
Only needed if you are running a MoleCare-compatible API:
{
"mcpServers": {
"molecare": {
"command": "npx",
"args": ["-y", "molecare-mcp"],
"env": {
"MOLECARE_API_URL": "http://localhost:8080/api",
"MOLECARE_API_KEY": "your-local-api-key"
}
}
}
}
Use localhost (or your own deployment). Do not paste production keys into config
files that sync to cloud drives.
Environment variables
Every setting is optional. The public server falls back to mock product data
without API credentials, and its knowledge tools continue to work offline. For
the operations server, use NODE_ENV=development (the .env.example default)
to keep integrations in mock mode.
Shared by both binaries
| Variable | Purpose | Example |
|---|
MOLECARE_API_URL | MoleCare-compatible HTTP API | http://localhost:8080/api |
MOLECARE_API_KEY | API bearer/key; required with a real MoleCare API | local-dev-key |
LOG_LEVEL | Logging verbosity: debug, info, warn, or error | info |
MCP_HEALTH_PORT | Preferred port for the optional HTTP /health endpoint | 3000 |
PORT | Fallback health port, useful for container platforms | 3000 |
PRIVACY_GATE_URL | Optional local sidecar that checks tool results before egress | http://localhost:8231 |
PRIVACY_GATE_TIMEOUT_MS | Privacy-gate request timeout in milliseconds | 4000 |
Public server (molecare-mcp)
The public server has no additional settings. Its dermatology knowledge works
without configuration; the shared MoleCare API variables enable its optional
mole and profile tools.
Operations server (molecare-ops-mcp)
The operations binary also accepts the shared settings above. These additional
variables only configure its infrastructure, monitoring, and CI/CD tools:
| Variable | Purpose | Example |
|---|
NODE_ENV | development forces mock mode; use production only with configured services | development |
MLFLOW_TRACKING_URI | MLflow tracking server | http://localhost:5000 |
MLFLOW_API_KEY | Optional MLflow API key | — |
ML_SERVING_URL | Model-serving health endpoint | http://localhost:5000/health |
FEAST_SERVER_URL | Feast feature server | http://localhost:6566 |
FEAST_PROJECT | Feast project name | molecare |
WEB_APP_URL | MoleCare web application | http://localhost:3000 |
MOBILE_API_URL | MoleCare mobile API | http://localhost:8080/api |
ADMIN_API_URL | MoleCare admin API | http://localhost:8080 |
BACKEND_URL | Backend health endpoint | http://localhost:8080 |
METRICS_API_URL | Application metrics API; leaving it empty keeps app monitoring mocked | — |
GITHUB_OWNER | Repository owner used by CI/CD tools | MoleCare |
GITHUB_REPO | Repository name used by CI/CD tools | MoleCare-ML |
GITHUB_TOKEN | GitHub token used by CI/CD tools | — |
AWS_REGION | AWS region used by EC2 and CloudWatch tools | us-east-1 |
AWS_PROFILE | Named AWS credential profile | — |
AWS_ACCESS_KEY_ID | AWS SDK credential-chain access key; prefer a role or profile | — |
EC2_INSTANCE_IDS | Comma-separated EC2 instance IDs | — |
DB_HOST | PostgreSQL host used by database health checks | localhost |
DB_PORT | PostgreSQL port | 5432 |
DB_NAME | PostgreSQL database name | molecare |
REDIS_HOST | Redis host and port | localhost:6379 |
ES_HOST | Elasticsearch host and port | localhost:9200 |
See .env.example for the copyable source-of-truth list.
Dermatology knowledge — no setup required
These are the reason most people install this. They answer from a bundled knowledge
base and need no API, no key, and no network.
| Tool | Description |
|---|
search_medical_info | Search the dermatology knowledge base |
lookup_medical_concept | Look up a SNOMED CT concept |
search_medical_concepts | Search conditions by name or description |
map_snomed_to_icd10 | Map a SNOMED CT code to ICD-10 |
classify_lesion_features | ABCDE-style feature descriptors for a lesion |
assess_risk_from_factors | Named educational risk factors (no score) |
get_condition_risk_factors | Known risk factors for a condition |
get_condition_progression | Typical progression stages for a condition |
get_malignant_conditions | Malignant skin conditions with codes |
Resources: molecare://knowledge/* — ABCDE criteria, Fitzpatrick skin types,
prevention, when to see a dermatologist. molecare://ontology/* — SNOMED CT and
ICD-10 reference lists, the full snomed-icd10-map mapping table, and risk
factors, all with provenance metadata.
Educational prompts
The server also exposes three reusable MCP prompts: walk_through_abcde,
prepare_dermatology_appointment, and explain_snomed_code. They help a client
organize observations or explain terminology without diagnosing a condition,
assigning urgency, or producing a risk score. Every rendered prompt includes
the non-diagnostic educational disclaimer; the terminology prompt requires a
SNOMED CT code argument.
What the terminology actually covers
| Bundled |
|---|
| SNOMED CT concepts | 7 — melanoma, melanoma in situ, BCC, SCC, actinic keratosis, dysplastic naevus, melanocytic naevus |
| WHO ICD-10 categories | 25 — malignant, in situ, benign, precancerous, inflammatory and pigmentation, across Chapters II and XII |
| SNOMED → ICD-10 mappings | 9 rows covering all 7 concepts — some concepts have more than one plausible target |
Every SNOMED concept the server advertises resolves through
lookup_medical_concept and maps through map_snomed_to_icd10. Ask for a code
outside the subset and the response carries a coverage block listing what is
bundled, rather than an empty result. Browse the whole table with the
molecare://ontology/snomed-icd10-map resource.
ICD-10 coverage is deliberately broader than SNOMED coverage. Expanding the
bundled SNOMED concept set is on hold pending a redistribution question with
SNOMED International: free use in a member country is not the same as free
redistribution via npm to non-member territories
(#49). WHO licenses ICD-10
more permissively at this level, so that side can grow in the meantime.
Terminology provenance
Bundled SNOMED CT / ICD-10 helpers are an educational subset, not a licensed
terminology distribution. Named sources live in
src/resources/terminology-provenance.ts
and are returned on map_snomed_to_icd10 and the ontology resources:
| System | What this package reflects |
|---|
| SNOMED CT | International Edition concept IDs / FSNs checked against the SNOMED International browser (last checked 2026-09-03). Plain-English search aliases are written for this package and are not SNOMED descriptions |
| ICD-10 | WHO ICD-10 category-level codes (e.g. C43, D22), with four-character subcategories only where the category alone would mislead (L57.0, D18.0). Not ICD-10-CM — codes such as C4A are deliberately absent |
| SNOMED → ICD-10 | Approximate category-level mappings — not certified one-to-one map rows. Each row carries a rationale |
The dataset itself lives in
src/resources/terminology-data.ts and is
the single source for both the src/api/ontology-client.ts mock paths and the
ontology resources. Educational prose without clinical codes lives in
src/resources/medical-kb.ts.
MoleCare product data — needs an API
Returns labelled mock data until MOLECARE_API_URL is set.
| Tool | Description |
|---|
get_user_moles | List moles for a user id |
get_mole_analysis | Analysis payload for a mole |
get_mole_changes | Change history for a mole |
get_user_risk_factors | A user's risk profile |
compare_moles | Compare two moles |
Operations and MLOps tooling (39 tools — separate molecare-ops-mcp binary)
These exist because MoleCare operates this stack from an assistant. They are of
little use outside that context, and all of them return mock data unless the
matching backend is configured.
They are not part of the molecare-mcp tool list. Loading 39 infrastructure
tools that nobody outside MoleCare can use made it measurably harder for a model
to pick the right dermatology tool, so they live in their own server:
{
"mcpServers": {
"molecare-ops": {
"command": "npx",
"args": ["-y", "-p", "molecare-mcp", "molecare-ops-mcp"]
}
}
}
| Area | Tools |
|---|
| Health | get_system_health, check_server_health, get_service_health, clear_cache |
| MLflow | get_mlflow_experiments, get_mlflow_runs, get_registered_models, get_model_version, compare_model_runs, get_training_runs |
| Feature store | get_feature_views, get_feature_view_details, get_feature_freshness, get_online_features, get_feature_store_stats |
| CI/CD | get_pipeline_runs, get_pipeline_summary, get_deployments, get_deployment_status, get_releases |
| AWS | get_ec2_instances, get_ec2_instance, get_ec2_health, get_ec2_metrics |
| Apps | get_app_status, get_web_app_status, get_mobile_api_status, get_all_apps_status, get_app_metrics, get_app_errors, get_app_versions, get_app_store_status |
| Database | get_database_status, get_database_metrics, get_slow_queries, get_table_stats, get_backup_history, get_connection_pools |
| Kubernetes | get_kubernetes_status |
The AWS tools need @aws-sdk/client-ec2 and @aws-sdk/client-cloudwatch, which are
optional peer dependencies — they are not installed by default, because they add
33 MB that nobody wanting the dermatology tools should have to download. Install them
yourself if you want live AWS data:
npm i @aws-sdk/client-ec2 @aws-sdk/client-cloudwatch
Architecture
Claude / Cursor / MCP client
│ stdio (JSON-RPC)
▼
molecare-mcp molecare-ops-mcp
├─ medical KB (local) ├─ MLflow / Feast clients
├─ MoleCare API client ├─ AWS / CI / K8s clients
└─ ontology client └─ database / app clients
│ (14 tools) │ (39 tools, internal)
│ │
└───────────┬───────────────────┘
└─ optional HTTP GET /health (Docker / ECS)
Docker
docker build -t molecare-mcp .
docker run --rm -p 3000:3000 molecare-mcp
curl http://localhost:3000/health
Security
- Never commit
.env files or API keys — see SECURITY.md to report a vulnerability
- Prefer mock mode for demos and screenshots
- Tools that accept
userId can return PHI only if you point them at a real backend with real auth — treat that as production
- Rate-limit and auth belong on your API, not only on the MCP process
Medical disclaimer
MoleCare MCP provides educational information and developer tooling. It does not diagnose melanoma or any disease. Always consult a qualified clinician for medical concerns.
Development
git clone https://github.com/MoleCare/molecare-mcp.git
cd molecare-mcp
npm install
npm run build
npm run dev
npm run inspect
Contributions are welcome. Read CONTRIBUTING.md first — it covers the mock-first rule,
the clinical-safety boundary for anything touching medical content, and how to pick up a good first issue.
Please keep secrets out of examples and prefer localhost defaults.
Environment variables: .env.example is the authoritative list. CI compares
it with the variables reachable from both server entrypoints and checks the
public/operations grouping above.
Contributors
Thank you to everyone who has helped molecare-mcp.
The list is filled by Contributors from
GitHub commits, bots omitted — never hand-maintained, because a stale list is
worse than none. Contributor graph ·
good first issue
License
Apache-2.0 © MoleCare LTD