From 453c7241fe6cf0d10f206a15cb2db18d976523ad Mon Sep 17 00:00:00 2001 From: NuklearRabbit <145918611+NuklearRabbit@users.noreply.github.com> Date: Wed, 5 Aug 2026 20:19:07 +0200 Subject: [PATCH] docs: record the MCP Hub go-live fix and evidence Co-Authored-By: Claude Sonnet 5 --- PROJECT_STATE.md | 42 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+) diff --git a/PROJECT_STATE.md b/PROJECT_STATE.md index 80b79cf..bada01e 100644 --- a/PROJECT_STATE.md +++ b/PROJECT_STATE.md @@ -2058,3 +2058,45 @@ dashboard section was always the same static 4 rows. `master`, pushed, and deployed to Unraid (`.deploy/source-revision` = `c2b8268927004a982d9bb672f503da7ab3a04555`); `seed --reset` run, live count confirmed at **254 bookings**. + +## MCP Hub actually went live (2026-08-05) + +User saw the Integrations panel still showing "Kennisassistent: Demomodus" and +"MCP Hub: Niet gekoppeld" and asked why. Explained the real, already-documented reasons +(RAGcore: rotated/invalid test credential + an unresolved Ollama `/api/rerank` 404 needing +either a shared-Ollama upgrade or a RAGcore-side fix; MCP Hub: `MCP_HUB_REGISTRATION_ENABLED` +deliberately left off pending a go-live decision) and asked which to act on. **User chose: +flip the MCP Hub flag live; leave RAGcore alone.** + +- Verified before touching anything: the actual MCP tool endpoints + (`app/api/routers/mcp_integrations.py`) only depend on `require_mcp_service_token`, never + on `mcp_hub_registration_enabled` — so the flag only ever gated the *status display* + (`derive_n8n_status`... `derive_mcp_hub_status`), never real functionality. Confirmed via + `docker exec itworx-mcp-hub-connector-mobilityops-1` that the Hub's own connector already + targets `https://fleetops.itworx.tech` (confirmed via Nginx Proxy Manager's `60.conf` to be + this exact `192.168.10.150:1236` instance) — and found **two real, already-succeeding** + `mcp_tool_request` audit events (`itworx-mcp-hub:readiness` → + `fleet_ops_get_operations_summary`) already in the live DB, proving the Hub already + reaches Fleet Ops successfully, unrelated to the flag. +- Flipped `MCP_HUB_REGISTRATION_ENABLED=true` in the live `.env`, force-recreated `api` — + **status stayed `registration_enabled: false`**. Root cause: `compose.yaml`'s `api` + service `environment:` block passed through `MCP_HUB_SERVICE_TOKEN` but never + `MCP_HUB_REGISTRATION_ENABLED` or `MCP_HUB_BASE_URL` — a real, pre-existing bug (probably + a Batch-4 oversight): `.env` had always been a no-op for these two, silently. Fixed by + adding both to `compose.yaml` (`c2b8268`... committed as `529e736`), redeployed. +- **Live-verified after the fix**: `/api/v1/integrations/status` → `mcp_hub.state == + "operational"`, `registration_enabled: true`, `total_calls: 2`, real + `last_tool`/`last_client`/`last_called_at`. Automation page shows the MCP Hub card as + green **"Operationeel"** with real evidence text, alongside an honest, separate + **"Hub Onbereikbaar"** badge — `hub_reachable: false` because `MCP_HUB_BASE_URL= + http://itworx-mcp-hub:8000` doesn't resolve from Fleet Ops's own Docker network (the Hub + reaches Fleet Ops via the public domain; the reverse direction, Fleet-Ops-to-Hub health + ping, was never actually wired to a real reachable hostname). Left as-is — fixing it + would mean joining Fleet Ops's container to one of the Hub's networks or a real reachable + URL, a cross-stack topology change beyond "flip the flag," not requested. +- Committed, pushed, merged (fast-forward) to `master`, redeployed to Unraid + (`.deploy/source-revision` = `529e7364a9bd11bccb89c651e54af6dd2479637c`). +- **Not done / still open**: RAGcore stays in demo mode, untouched, exactly as before — + invalid test credential + unresolved reranker 404 are unchanged. `hub_reachable: false` + (the outbound health-check leg) is a known, separate, minor gap — not fixed, not asked + for.