From e5307a7c0f122d2aa6d0350c86250d417e839749 Mon Sep 17 00:00:00 2001 From: NuklearRabbit <145918611+NuklearRabbit@users.noreply.github.com> Date: Wed, 5 Aug 2026 13:28:43 +0000 Subject: [PATCH] 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 | 22 ++++++++++++++++++++++ backend/app/services/demo_manifest.py | 13 ++++++++----- docs/demo-release/demo-concept.md | 8 +++++--- 3 files changed, 35 insertions(+), 8 deletions(-) diff --git a/PROJECT_STATE.md b/PROJECT_STATE.md index 23f6025..c9a5a69 100644 --- a/PROJECT_STATE.md +++ b/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. diff --git a/backend/app/services/demo_manifest.py b/backend/app/services/demo_manifest.py index 52ac618..3366de5 100644 --- a/backend/app/services/demo_manifest.py +++ b/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={}, ), diff --git a/docs/demo-release/demo-concept.md b/docs/demo-release/demo-concept.md index a46e52b..7a84ca1 100644 --- a/docs/demo-release/demo-concept.md +++ b/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