fix: derive demo-manifest MCP Hub status from real tool-call evidence

The demo manifest still reported the MCP Hub integration as operational purely
because MCP_HUB_REGISTRATION_ENABLED was set, while the integration status page
had already moved to evidence-based status in Batch 4. Registration is
catalog-driven on the Hub's side, so the flag alone proves nothing; reuse
derive_mcp_hub_status() so "operational" requires real recorded mcp_tool_request
calls.

No change to the MCP integration contract: the four read-only routes, service
token and client id handling, inbound X-Correlation-Id preservation, the locale
field on search-knowledge and the provider/correlation_id response fields were
verified as already correct at deployed revision 727c19a and left untouched.

PROJECT_STATE.md

@@ -1840,3 +1840,25 @@ deployed line — `master` is stale, 19 commits behind). Full audit at
   separate go-live choice), not gaps hidden from this summary. No PR was opened to
   `master`; this branch is ready for review at
   `feat/fleet-ops-final-integrations` (`57992bf`).
+
+## MCP Hub status honesty fix (2026-08-05)
+
+Narrow follow-up to Batch 4, made while the Hub-side connector completion (locale,
+correlation propagation, real upstream readiness) was implemented in the sibling
+`ITWorx_MCP_Hub` repository.
+
+- `demo_manifest.py`'s `mcp_hub` integration summary still derived "operational" purely
+  from `MCP_HUB_REGISTRATION_ENABLED`, while `/api/v1/integrations/status` had already
+  moved to evidence-based status in Batch 4. The demo manifest now reuses
+  `derive_mcp_hub_status()`, so "operational" requires real recorded `mcp_tool_request`
+  calls — the flag on its own never proves a registration. `docs/demo-release/
+  demo-concept.md` updated to match.
+- **No change to the MCP contract itself.** The four MCP routes, `X-Service-Token`,
+  `X-Client-Id`, inbound `X-Correlation-Id` preservation, the `locale` field on
+  `search-knowledge`, and `provider`/`correlation_id` in the response were all verified
+  as already correct at the deployed revision `727c19a` and deliberately left untouched.
+- **Not deployed.** This is a UI/status-honesty fix only; no API compatibility change was
+  needed, so no Fleet Ops redeploy was performed or is required for the Hub-side work.
+- Local gates were **not** re-run this session: the environment this ran in has no
+  network and no Docker, so `docker compose build api` + `pytest`/`ruff`/`mypy` could not
+  be executed. Run them before deploying.

backend/app/services/demo_manifest.py

@@ -11,7 +11,7 @@ from app.models.booking import Booking
 from app.models.data_quality import DataQualityIssue
 from app.models.outbox import OutboxEvent
 from app.schemas import DemoIntegrationSummaryOut, DemoManifestOut, DemoScenarioOut
-from app.services.integration_status import derive_n8n_status
+from app.services.integration_status import derive_mcp_hub_status, derive_n8n_status
 from app.services.knowledge import get_knowledge_provider
 
 settings = get_settings()
@@ -124,6 +124,7 @@ def _scenarios(db: Session) -> list[DemoScenarioOut]:
 def _integrations(db: Session) -> list[DemoIntegrationSummaryOut]:
     n8n = derive_n8n_status(db)
     knowledge_health = get_knowledge_provider().health()
+    mcp_hub = derive_mcp_hub_status(db)
 
     return [
         DemoIntegrationSummaryOut(
@@ -147,11 +148,13 @@ def _integrations(db: Session) -> list[DemoIntegrationSummaryOut]:
         ),
         DemoIntegrationSummaryOut(
             key="mcp_hub",
-            status_code="operational" if settings.mcp_hub_registration_enabled else "notConnected",
+            # `MCP_HUB_REGISTRATION_ENABLED` on its own proves nothing: registration is
+            # catalog-driven on the Hub's side, so the flag only says Fleet Ops expects
+            # to be called. Only real recorded `mcp_tool_request` calls make this
+            # "operational" -- same evidence rule the integration status page uses.
+            status_code="operational" if mcp_hub.state == "operational" else "notConnected",
             detail_code=(
-                "mcpDetailEnabled"
-                if settings.mcp_hub_registration_enabled
-                else "mcpDetailNotConnected"
+                "mcpDetailEnabled" if mcp_hub.state == "operational" else "mcpDetailNotConnected"
             ),
             detail_params={},
         ),

docs/demo-release/demo-concept.md

@@ -65,9 +65,11 @@ generated and kept fresh across resets.
   `RAGcoreKnowledgeProvider` HTTP adapter exists and is unit-tested, ready to take over
   the same interface once a real RAGcore backend is available — swapping providers is a
   configuration change (`KNOWLEDGE_PROVIDER`), not a UI change.
-- **ITWorx MCP Hub**: not connected. Registration is disabled by default
-  (`MCP_HUB_REGISTRATION_ENABLED=false`) and the UI always shows "Not connected" —
-  never a fabricated successful registration.
+- **ITWorx MCP Hub**: the UI reports "Operational" only when Fleet Ops has really
+  recorded `mcp_tool_request` calls in its own audit log. `MCP_HUB_REGISTRATION_ENABLED`
+  on its own never makes it operational — registration is catalog-driven on the Hub's
+  side, so the flag alone is not evidence of anything, and a successful registration is
+  never fabricated.
 
 ## Where to go next