The Engine as a Library

The chat server is built on top of the engine. The engine itself — ① Collect and ② Standardize — is an ordinary Python package: no framework, no database, and no network calls. pip install mirobody is enough to use it.

The reason for that split: standardizing health data normally requires sending it to an external service, whereas here the vocabulary ships with the wheel and the process needs no network access.

The public API

mirobody/engine.py is the whole public surface of the engine layer: two functions and two result types.

from mirobody.engine import resolve, parse_file

r = resolve("血红蛋白")
r.loinc        # '718-7'
r.canonical    # 'Hemoglobin [Mass/volume] in Blood'
r.resolved     # True
r.candidates   # 72 — how many aliases pointed at this name

readings = await parse_file("physical-2026.pdf")   # needs one model key

resolve() is offline and deterministic. parse_file() is the one call that reads a document: it needs a model key for the extraction half only, and the standardization that follows runs offline, which is why the function still does something useful without one.

Note

The first resolve() call pays a few seconds to load the shipped bundles (a 921k-entry alias index). Reuse the resolver (get_resolver() returns it) rather than calling the module-level convenience in a loop.

The CLI

Installed as a console script, so a plain pip install mirobody gets a runnable command. Deployments use python -m mirobody.

Command	What it does	Needs
mirobody resolve <terms…>	Indicator names → standard codes	nothing: no key, no config, no network
mirobody parse <file>	Lab report in, standardized LOINC table out	one LLM key
mirobody serve	The HTTP server (chat, MCP, API)	the [agents] extra + Postgres/Redis
mirobody worker	The background task worker (indicator sync, profile refresh)	same as serve

serve and worker check for the agent layer up front and print what to install, instead of dying several modules deep with ModuleNotFoundError: langchain.

mirobody resolve "LDL cholesterol" "血红蛋白" "ヘモグロビン" "血圧"

  LDL cholesterol  LOINC 13457-7     Cholesterol in LDL [Mass/volume] in Serum or Plasma by calculation   [63 candidates]
  血红蛋白             LOINC 718-7       Hemoglobin [Mass/volume] in Blood   [72 candidates]
  ヘモグロビン           LOINC 718-7       Hemoglobin [Mass/volume] in Blood   [72 candidates]
  血圧               unresolved — not in the lexical index (the full semantic pipeline may still resolve it)

Three languages, two of them landing on the same code. The fourth line matters: 血圧 names a panel, not an observation, and the lexical index reports an honest miss rather than selecting one of its two components.

Install extras and capabilities

Install	What works	Footprint
the wheel + numpy only	from mirobody.engine import resolve: the offline resolver	77 MB, 2 packages
pip install mirobody	+ mirobody parse (one LLM key) · file parsing (PDF/Excel/audio) · FHIR output	233 MB, 90 packages
pip install 'mirobody[server]'	+ the HTTP API and the MCP endpoint	needs Postgres + Redis
pip install 'mirobody[agents]'	+ DeepAgent / BaseAgent and mirobody serve (includes [server])	+ the LangChain stack
pip install 'mirobody[indicator-build]'	rebuilding the terminology bundles themselves	needs LOINC / UMLS sources

Of the 77 MB floor, 51 MB is the shipped LOINC/SNOMED data — the resolver itself, and the reason standardization works without network access. Two more extras exist: [cn] (Aliyun OSS + Volcengine Ark) and [test] (pytest + import-linter).

The database driver, HTTP server, S3 and email clients live in [server], which [agents] pulls in, so a library user does not pay for a Postgres driver.

Caution

The bundles are Git LFS objects. Working from a clone, run git lfs install and git lfs pull before anything else, or resolve() raises with a message telling you exactly that.

The engine / agent dependency boundary

The engine must import with no agent framework installed. langchain*, deepagents and langgraph are allowed only under agent/ and server/, the same layering langchain itself uses for langchain-core. Two import-linter contracts in pyproject.toml fail the build on violation, function-local imports included:

pip install -e '.[test]' && lint-imports

agent/ · server/ ③ Answers: the only place LangChain may appear

agent/deep_agent.pyagent/base_agent.pyserver/routers/

the engine ① Collect + ② Standardize: framework-free, numpy-only floor

engine.pypulse/indicator/res/

shared infrastructure not a fourth stage, used BY the three

mcp/task/user/utils/

Import direction only ever points down. `utils/` is deliberately a leaf.

That contract is why mirobody.engine can resolve an indicator with numpy as the only third-party package present.

Runnable examples

Five scripts in examples/, in order of how much they need, and each one can be run directly.

	Example	Needs	Shows
01	01_resolve_offline.py	pip install mirobody	② name → LOINC, any language, fully offline
02	02_standardize_a_reading.py	pip install mirobody	① unit conversion + the indicator catalogue
03	03_parse_a_lab_report.py	+ one model key	a document → standardized readings in one call
04	04_mcp_tool_surface.py	pip install mirobody	③ exactly what an external MCP client receives
05	05_agent_server_preflight.py	pip install 'mirobody[agents]'	whether this machine can run the full server, and what is missing

Examples 01, 02 and 04 require only the package. Example 05 reports every prerequisite of the full server in a single run, which is the quickest way to find out what a machine is still missing.

Next steps

Run the whole thing

Docker Compose, a demo login, and the two keys you need.

→

How ② Standardize works

The concept graph, the alias index, and how correctness is scored.

→

Architecture

Where each stage lives, and what the shared infrastructure is.

→

Local development

Editable install and the test suite.

→