M
MCP Directory CURATED DIRECTORY
911 MCP servers indexed
中文
← Back to directory
M

Mirobody MCP Server

Community
The AI-native health data engine — collect, translate, reason with agents.
How to install ↓ Compare GitHub source repository ↗
Category
Other #119 of 230
Stars
★ 1.4k Very popular
Transport
stdio (local process) · SSE · Streamable HTTP
Runtime
Python 3.12+ · Docker
Credentials
Optional API key
License
Apache-2.0
Last commit
54FMRS · D

Mirobody is an Apache-2.0, AI-native health data engine that standardizes lab reports, wearables and genomics into LOINC-coded, UCUM-normalized, FHIR-ready records, and serves its agent tools over MCP to Claude Desktop, Cursor or a custom agent. It suits developers and teams that want to self-host and standardize health data, and is less suited to users wanting a zero-setup hosted product or local GPU inference. Key considerations are the sensitivity of health data, care-circle access gating, the default demo seed data, and that document content is processed by a hosted model provider.

Strongest · Maintenance 13/20 Weakest · Reliability 9/20

Reliability
9/20
Security and permissions
11/20
Maintenance
13/20
Documentation
12/20
Setup experience
9/20
Why each score
Reliability 9/20
The README describes a self-hosted stack started by ./deploy.sh (Postgres + pgvector, Redis, server, worker) that serves every agent tool at /mcp. However this is a static-only review: nothing was executed, and the SERVER MANIFEST is explicitly not cached, so the MCP init handshake, the declared tool list, and whether those tools match real behavior cannot be verified. The claim of 213/213 coverage via mirobody/tests/test_engine_coverage.py is documentation-level assertion only; no CI workflow or committed test artifacts are visible in the supplied evidence to substantiate reproducible key paths or controlled, diagnosable failures. The offline resolver's name-to-code path (with explicit abstention) is described concretely and is the most credible part, but the server-side behavior stays unverified. Per the static calibration cap (no reliability above 12 without verifiable CI + tests), deduct accordingly.
Security and permissions 11/20
Positive signals: Apache-2.0, the API key lives only in .env and config.llm.yaml references the variable name (e.g. OPENROUTER_API_KEY) rather than the secret, no real tokens appear in the install examples, and no signs of malware or covert exfiltration are present. The care-circle model is explicit (care_circle_members.health_access NOT NULL DEFAULT 0, invite alone shares nothing, unauthorized routes answer 403), which is good least-privilege design. Open risks: the agent reads original medical documents and report images and relays content to third-party hosted LLM providers (OpenRouter/DashScope/OpenAI/Anthropic/DeepSeek) — the scope of data sent off-box, redaction, or PHI handling is not disclosed; the agent stage appears to include an eval REPL (langchain-quickjs) with no stated confirmation gate for dangerous operations; and SEED_DEMO_DATA is on by default, which risks mixing synthetic and real data if not disabled. Main risks are visible but permission/confirmation/data-flow disclosure is incomplete; no red line is crossed, so 11.
Maintenance 13/20
The repository shows 1,322 stars, 1 open issue, is not archived, and ships Apache-2.0 plus links to SECURITY.md, CHANGELOG, CONTRIBUTING, and a roadmap; the README states releases land most weeks and the project publishes an arXiv paper, HuggingFace benchmarks, and a separate mirobody-eval repo, which suggests real governance. Static evidence cannot confirm commit recency, issue response latency, or dependency update cadence. Reductions: the arXiv identifier (2604.02834) and the 2026 copyright/release dates are future-dated and therefore impossible to verify, which weakens trust in the stated activity claims. No evidence of abandonment, archived status, or a missing license. Net 13.
Documentation 12/20
Documentation is layered and generally strong: a 60-second uvx smoke test, concrete Python examples (resolve/resolve_reading, including the deliberate abstention and refusal semantics), deployment steps, model/key configuration guidance, MCP enablement location (Settings → MCP, /mcp, gated per user), and many docs.mirobody.ai links. It also honestly discloses that 'offline' means only the resolver and that no inference runs locally. Deductions: the MCP tool parameter list, auth model, rate/cost limits, and troubleshooting procedures are missing from the supplied material (manifest not cached); several external references, the arXiv ID, and the 2026 dates cannot be statically verified; and troubleshooting relies on the external docs site rather than self-contained files. Net 12.
Setup experience 9/20
The README provides a fairly explicit multi-step path: git clone --depth 1, git lfs install && git lfs pull (required for the LOINC bundle, otherwise only a pointer stub — an easy-to-miss failure), then ./deploy.sh bringing Postgres/pgvector, Redis, server, and worker up at localhost:18060, plus demo credentials, a registration curl, and the SEED_DEMO_DATA default. Friction is real: Docker, Git LFS, and a separate .env for the API key (a shell export does not reach containers; a restart is required), and although no local inference runs, a hosted model key is still mandatory for upload and question flows. No concrete Claude Desktop/Cursor configuration snippet is included in the evidence — only links to docs. With no execution evidence, the static cap (no setup above 15 without verifiable CI + tests) pushes this lower; net 9.

Static review · not runListed 2026-09-18

Read the FMRS scoring method →

Fit and risk

What it can accessReads local filesUses the networkConnects to a database

Best for

  • Developers and health-data teams that need to standardize heterogeneous lab reports and wearable data
  • Teams that want a self-hosted, Apache-2.0, FHIR-oriented health-data stack
  • Users plugging health-data tools into MCP clients such as Claude Desktop or Cursor
  • Offline terminology and unit resolution with no network and no key

Not for

  • Users who want a purely hosted, zero-deployment product
  • Users expecting local GPU inference — reasoning relies on a hosted model provider
  • Use as an official diagnostic or licensed clinical decision-making system
  • Document extraction and agent Q&A without configuring any model API key

Required permissions

  • Read health documents and device data the user uploads or imports (labs, wearables, genomics)
  • Access user health records, including records shared in a care circle (gated by the per-row health_access field)
  • Call the configured hosted model provider's API (key kept in .env, e.g. OPENROUTER_API_KEY)
  • Serve agent tools to MCP clients, gated per user

Risks and side effects

  • Health data is highly sensitive personal information; an exposed self-hosted deployment leaks medical records
  • Care-circle sharing: an invited member still decides via health_access on their own row, and any route that forgets the check must answer 403 instead of handing over a record
  • SEED_DEMO_DATA is on by default and should be set to false before a deployment holds real data
  • Documents and photos are sent to the configured hosted model provider, and scanned pages reach a vision model — assess data residency and compliance
  • The project is not a local LLM; assuming full offline operation can fail without network access
  • Model provider API keys written into .env must be protected from commits or leaks

Setup

Before you start

Runtime：Python 3.12+ · Docker

OPENROUTER_API_KEY optionalsecret Recommended hosted-model key placed in the .env next to compose.yaml; get one at openrouter.ai/keys. Needed only for agent/LLM features, not offline resolution.
OPENAI_API_KEY optionalsecret Alternative model key from platform.openai.com/api-keys, set in .env.
ANTHROPIC_API_KEY optionalsecret Alternative model key from platform.claude.com/settings/keys, set in .env.
Other optional settings (2)
SEED_DEMO_DATA optional On by default to populate the demo care circle; set to false for a deployment holding real data.
AGENT_DIRS optional Point at your own agent directory to replace the shipped agent.
  1. Clone the repository: git clone --depth 1 https://github.com/thetahealth/mirobody.git && cd mirobody
  2. Fetch large files: git lfs install && git lfs pull (the resolver's LOINC bundle)
  3. Run ./deploy.sh to start Postgres + pgvector, Redis, the server and the worker, then open http://localhost:18060
  4. Sign in as [email protected] with code 111111, or POST /password/register to create your own account
  5. Put one hosted-model API key in the .env next to compose.yaml (OPENROUTER_API_KEY recommended; OpenAI, Anthropic, Google and DashScope also work) and run docker compose restart; browsing the seeded record needs no key
  6. In your MCP client (e.g. Claude Desktop or Cursor), configure the MCP endpoint: every agent tool is also served at /mcp, gated per user

Check that it works

Run ./deploy.sh and open http://localhost:18060; in Claude Desktop or Cursor, Settings → MCP should list the agent tools served at /mcp. Offline, run uvx mirobody resolve "LDL cholesterol" and confirm it returns a LOINC code with no key or network.

Troubleshooting

  1. Empty or wrong resolution: run mirobody resolve "<term>"; category terms (e.g. 血脂 lipids) return nothing rather than a wrong code
  2. The same name returns different LOINC codes by unit: pass the value and unit with resolve_reading(name, value, unit)
  3. Deployment fails to start: confirm git lfs pull fetched the LOINC bundle and ./deploy.sh brought up Postgres, Redis, the server and the worker
  4. Model calls fail: check the key variable in .env matches the api_key named in config.llm.yaml and run docker compose restart; a shell export does not reach the containers
  5. Clone is too large: use --depth 1; drop the flag if you plan to send a pull request
  6. No tools appear in the MCP client: confirm the deployment is reachable and /mcp is gated per user; see examples/07_claude_agent_sdk.py

Things to try

Once connected, you can ask your AI assistant things like:

  • Resolve the analytes in this lab report PDF to LOINC codes with values and units
  • Chart two years of HbA1c for the shared Demo record and summarize the trend
  • What LOINC code does 'total cholesterol 5.0 mmol/L' resolve to, and why does the unit matter?

Use cases

Turn a lab-report PDF, image, Excel, Word, PowerPoint or text file into readings with values and units
Resolve multilingual test names to LOINC codes and normalize units to UCUM
Import an Apple Health export into one standard health-record format
Let an agent reason over original documents and sensor-derived series with charts and citations
Expose health-data tools over MCP to Claude Desktop, Cursor or your own agent on a self-hosted deployment

Supported clients

Claude Desktop
Cursor

Listed from the project's documentation, not tested by this site.

Overview

Mirobody is an AI-native health data engine that turns lab reports, wearables and genomics into one language AI can read: LOINC-coded, UCUM-normalized, FHIR-ready. It works in three stages: Collect (3 device providers, 7 file formats, Apple Health import), Translate (resolve any reading to canonical LOINC · SNOMED CT · RxNorm codes and normalize units to UCUM), and Agent (an agent reads the original documents through a virtual filesystem and answers with charts and citations). The repository ships a concept graph of 440,961 nodes and 22,044,110 cross-vocabulary edges, 49,253 multilingual aliases (Chinese 22,578 · Japanese 16,809, plus German, Spanish, French, Korean, Russian) and a Traditional Chinese fold table. The resolver runs offline with no key and no network; the whole stack is self-hostable via ./deploy.sh and serves every agent tool over MCP at /mcp to Claude Desktop, Cursor or your own agent, gated per user. Licensed Apache-2.0 and powers the live consumer product Theta Wellness.

Similar servers

BioMCP 75 · B

One binary. One grammar. Evidence from the biomedical sources you already trust.

★ 670 · Tools 11 Compare with this →
Compare with other MCP servers

Source revision e7caaafd9aba Data synced 2026-11-02 Read the FMRS scoring method