mom-mcp-lite

A runtime-only variant of 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.

Related MCP server: Local AI MCP

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

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.