Mirobody MCP Server

Community

The AI-native health data engine — collect, translate, reason with agents.

★ 1.3k Stars Category · Other Very popular

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.

Reliability

9/20

Security and permissions

11/20

Maintenance

13/20

Documentation

12/20

Setup experience

9/20

Read the FMRS scoring method →

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.

Setup

Clone the repository: git clone --depth 1 https://github.com/thetahealth/mirobody.git && cd mirobody
Fetch large files: git lfs install && git lfs pull (the resolver's LOINC bundle)
Run ./deploy.sh to start Postgres + pgvector, Redis, the server and the worker, then open http://localhost:18060
Sign in as [email protected] with code 111111, or POST /password/register to create your own account
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
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

Fit and risk

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

Troubleshooting

Empty or wrong resolution: run mirobody resolve "<term>"; category terms (e.g. 血脂 lipids) return nothing rather than a wrong code
The same name returns different LOINC codes by unit: pass the value and unit with resolve_reading(name, value, unit)
Deployment fails to start: confirm git lfs pull fetched the LOINC bundle and ./deploy.sh brought up Postgres, Redis, the server and the worker
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
Clone is too large: use --depth 1; drop the flag if you plan to send a pull request
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

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 DesktopFull support

CursorFull support

Related MCP servers

Compare with other MCP servers