# mom-mcp-lite

A runtime-only variant of [mom-mcp](../mom-mcp): the same MCP server + REST
API for datasets, connections, flows, pipelines, and cron — **without**
server-side AI/LLM execution and **without** a full entity-authoring admin
UI. It's meant to be a deployment *target*, not a design environment.

## What's different from full mom-mcp

- **No server-side LLM execution.** `Settings.server_llm_enabled` defaults
  to `False` — `ServerContext.llm_default()` raises `LLMNotConfigured`
  immediately and deliberately, rather than incidentally because no API key
  is set. Every existing caller that already handles `LLMNotConfigured`
  gracefully (MCP `invoke_skill`'s sampling fallback, dashboard
  `ai_insight`/`ai_actions`, `jit_sequencer`'s AI-recommend, `/query`,
  `text2sql`, `kb_lookup`) degrades cleanly with zero code changes.
- **No bundled chat.** `POST /studio/chat` (the in-process SSE chat
  orchestrator) returns `501` — it always needs a server-side LLM by
  construction (multi-turn planning), so there's no clean way to keep it
  working under `server_llm_enabled=False`. The `/studio/chat/sessions*`
  history-CRUD routes stay enabled: a paired client with its own chat
  implementation (mom-portal's `bff/chat.py`, its own LLM key) reads/writes
  that same history store remotely and never calls the bundled orchestrator
  at all.
- **Tenant configuration is deployed via package import, not authored
  here.** Datasets, skills, dashboards, flows, pipelines, glossary, REST
  actions, etc. are meant to arrive as a signed `.mcp-pkg.zip` exported from
  a full mom-mcp instance (`packaging/bundle.py`, already ships every entity
  kind including `flows`). This variant ships with **no example
  `tenants/`** and **no `skills_repository/`** — both are populated by
  import, not by shipping example content.
- **No bundled Apriso version templates.** `templates/` starts empty
  (`PrimaryDataStore.from_templates_root` handles a missing/empty root
  gracefully) — the multi-GB Apriso 2023/2025 template bundles aren't
  copied.
- **New: `POST /tenants/{tenant_id}/cron/{job_id}/run-now`** — full mom-mcp
  has no way to fire a cron job outside its schedule; a lite deployment's
  operator UI needs one (e.g. run a job immediately right after
  importing/editing it). Reuses `SchedulerRunner._run_job` verbatim (same
  locking/status/audit trail a real scheduled firing gets), off-loaded via
  `asyncio.to_thread` since that method may itself call `asyncio.run()`
  internally for a `run_flow` action.
- **No admin frontend build.** `web/admin` isn't copied/built into this
  tree yet — `/admin` serves a placeholder page
  (`admin/ui.py`'s existing graceful fallback). The operator-facing slice
  (Users, Roles, Server settings, Cron, Pipelines, Connections) is a
  follow-up, not part of this pass.

## What's identical to full mom-mcp

Everything else — `ServerContext`, `TenantResolver`, `ConfigStore`,
`ConnectionManager`, `DatasetEngine`, `SkillRunner`, `FlowEngine`,
`PipelineExecutor`, `SchedulerRunner`, the full `admin_router`/`studio_router`
REST surface, and every MCP tool — is an unmodified copy. A client (e.g.
mom-portal with `MOM_PORTAL_LLM_MODE=portal`) needs **zero code changes** to
point at this server instead of a full one: it never touches the
entity-authoring REST routes at all (see `mom-portal`'s `bff/proxy.py`
allowlist), and the dashboard/chat-tool prepare→own-LLM→finalize split it
already uses doesn't need this server to have any LLM configured.

## Running it

```powershell
cd mom-mcp-lite
python -m venv .venv
.venv\Scripts\pip install -e ".[dev]"
.venv\Scripts\python -m mom_mcp init --username admin
.venv\Scripts\python -m mom_mcp serve --host 127.0.0.1 --port 8787
```

Then point a client (mom-portal, or any MCP client) at
`http://127.0.0.1:8787`.

## Known gaps / not yet done

- No trimmed admin frontend (Users/Roles/Server/Cron/Pipelines/Connections)
  — `/admin` is a placeholder until `web/admin` is built and copied in,
  restricted to those routes.
- No route-level trimming of `admin_router` — every full-mom-mcp REST route
  is still mounted (harmless with no frontend exposing them, but not yet a
  hardened "operator can only touch these six things" boundary).
- Fire-and-forget AI triggers (cron `invoke_skill`/`run_flow`, MQTT rule
  `invoke_skill`, MQTT-arrival pipeline `invoke_skill`/`run_flow`, a skill's
  own `post_action: run_flow` chain) have no live caller to relay a portal
  completion through — they simply won't work with `server_llm_enabled`
  off, by design, not by a bug. Flip the setting to `True` for a "lite+"
  deployment that still wants server-side AI for those specific triggers.