docs/architecture/WIDGET_MCP_ADOPTION.md

WidgetTDC Widget MCP Adoption Analysis

Date: 2025-11-17 Status: Priority 1 Complete - MCP Adoption Assessment Coverage: All 24 Widget Files Analyzed Key Finding: Only ~4% active MCP adoption, 83% alternative data sources

---

Executive Summary

Metric	Value	Status
Total Widgets	24	✅ All analyzed
Using MCP	1	🔴 4% adoption
Mock Data	6	⚠️ 25% incomplete
Direct Gemini APIs	5	❌ Security risk
Non-MCP HTTP APIs	4	🟡 Pre-MCP pattern
UI/Configuration Only	4	✅ Expected
MCP as "Foundation"	❌ NOT REALIZED	🚨 Critical gap

---

Detailed Categorization

✅ Category 1: ACTIVELY USING MCP (1 Widget)

McpRouterWidget.tsx

• Purpose: MCP message router and tool inspector
• Implementation: Direct HTTP calls to /api/mcp/* endpoints
• Evidence:
  • Line 41: fetch('http://localhost:3001/api/mcp/tools')
  • Line 67: fetch('http://localhost:3001/api/mcp/route', { method: 'POST' })
• Features: Tool discovery, message routing, payload inspection
• Status: ✅ PRODUCTION-READY MCP INTEGRATION
• Note: This widget demonstrates the ONLY proper MCP pattern in use

---

🔌 Category 2: WEBSOCKET / MCP-ADJACENT (1 Widget)

PerformanceMonitorWidget.tsx

• Purpose: Real-time performance metrics monitoring
• Implementation: WebSocket connection to metrics stream
• Evidence:
  • Line 13: new WebSocket('ws://localhost:8000/metrics/stream')
• Status: ✅ Uses WebSocket pattern (MCP infrastructure supports this)
• Note: Could easily be converted to MCP WebSocket routing

---

🔴 Category 3: MOCK DATA ONLY - No Real Backend (6 Widgets)

These widgets contain hardcoded sample data and are NOT connected to any backend.

3.1 IntelligentNotesWidget.tsx

• Mock Data: SAMPLE_NOTES constant (lines 31-97)
• Data Structure: 5 mock note objects with sample content from DG CONNECT workshops
• Comment (Line ~1-2): "I en rigtig app ville dette være et API-kald via MCP"
• Translation: "In a real app this would be an API call via MCP"
• Status: ❌ AWAITING MCP INTEGRATION
• Estimated Effort: 2-3 days (create /api/mcp/notes/query endpoint)

3.2 MCPEmailRAGWidget.tsx

• Mock Data: MOCK_EMAILS + MOCK_SUGGESTIONS (lines 6-22)
• Simulation: Artificial 750ms delay with setTimeout() to mimic API response
• Comment (Line 32): "I en rigtig app ville dette være et API-kald via MCP"
• Expected Integration: /api/mcp/email/inbox + /api/mcp/email/suggestions
• Status: ❌ EXPLICITLY AWAITING MCP INTEGRATION
• Estimated Effort: 3-4 days (real RAG engine needed)

3.3 CybersecurityOverwatchWidget.tsx

• Mock Data:
  • THREAT_ALERTS constant (5 threat objects)
  • NETWORK_METRICS constant
  • COMPLIANCE_CONTROLS constant
• Current Logic: Client-side filtering and display
• Status: ❌ NEEDS MCP BACKEND
• Estimated Effort: 4-5 days (security threat API integration)

3.4 AgentBuilderWidget.tsx

• Mock Data: ALL_TOOLS constant with hardcoded tool definitions
• Simulation: Mock setTimeout() suggestion generation (line 33)
• Status: ❌ AWAITING REAL AGENT REGISTRY VIA MCP
• Expected Integration: /api/mcp/agents/tools, /api/mcp/agents/registry
• Estimated Effort: 2-3 days

3.5 PromptLibraryWidget.tsx

• Mock Data: MOCK_PROMPTS constant
• Status: ❌ AWAITING MCP BACKEND
• Expected Integration: /api/mcp/prompts/library, /api/mcp/prompts/search
• Estimated Effort: 1-2 days

3.6 ProcurementIntelligenceWidget.tsx

• Mock Data: OPPORTUNITIES constant (4 mock procurement opportunities)
• Status: ❌ AWAITING MCP BACKEND
• Expected Integration: /api/mcp/procurement/opportunities, /api/mcp/procurement/analysis
• Estimated Effort: 3-4 days

Summary for Category 3:

• Total Mock Widgets: 6 (25% of total)
• Combined Effort: 15-21 days
• Blocking Issue: These widgets demonstrate MCP INTENT but are NOT connected

---

🔐 Category 4: DIRECT EXTERNAL APIS - SECURITY RISK (5 Widgets)

These widgets BYPASS MCP entirely and call external Google Gemini APIs directly from the client. This is a critical security issue - API keys are exposed to client-side code.

4.1 AgentChatWidget.tsx

• External API: Google Gemini API (direct)
• Implementation:
  • Import (line 2): import { GoogleGenAI } from "@google/genai"
  • API Key (line 54): process.env.API_KEY directly in browser
  • Call (line 69): ai.models.generateContent()
• Features: Uses Gemini-native tools (Google Search, Google Maps)
• Security Risk: ⛔ API key exposed to client browser
• Status: ❌ BYPASSING MCP - Should route through /api/mcp/gemini/chat

4.2 AudioTranscriberWidget.tsx

• External API: Google Gemini API (audio model)
• Implementation:
  • Import (line 2): GoogleGenAI
  • Call (line 65): ai.models.generateContent({ model: 'gemini-2.5-flash' })
  • Uses: Audio transcription model
• Security Risk: ⛔ API key in browser
• Status: ❌ SHOULD USE /api/mcp/gemini/audio

4.3 ImageAnalyzerWidget.tsx

• External API: Google Gemini API (vision)
• Implementation: Direct Gemini image analysis call
• Security Risk: ⛔ API key in browser
• Status: ❌ SHOULD USE /api/mcp/gemini/vision

4.4 LiveConversationWidget.tsx - 🔴 HIGHEST RISK

• External API: Google Gemini Live API (WebSocket)
• Implementation:
  • Import (line 2): import { GoogleGenAI, LiveServerMessage, Modality } from "@google/genai"
  • Connection (line 111): ai.live.connect() (WebSocket)
  • Model (line ~X): 'gemini-2.5-flash-native-audio-preview-09-2025' with audio streaming
  • API Key (line 109): process.env.API_KEY
• Security Risk: ⛔⛔ WebSocket connection with API key, real-time audio streaming
• Status: ❌ CRITICAL - SHOULD USE WebSocket MCP route /api/mcp/gemini/live

4.5 VideoAnalyzerWidget.tsx

• External API: Google Gemini API (video model)
• Implementation:
  • Call (line 58): ai.models.generateContent({ model: 'gemini-2.5-pro' })
  • Uses: Video analysis model
• Security Risk: ⛔ API key in browser
• Status: ❌ SHOULD USE /api/mcp/gemini/video

Summary for Category 4:

• Total Widgets: 5 (21% of total)
• Security Risk Level: 🔴 CRITICAL
• API Keys Exposed: Yes, to client-side code
• Recommended Action: Create MCP proxy routes immediately
  • /api/mcp/gemini/chat - Chat completions
  • /api/mcp/gemini/audio - Audio transcription
  • /api/mcp/gemini/vision - Image analysis
  • /api/mcp/gemini/video - Video analysis
  • /api/mcp/gemini/live - WebSocket live streaming
• Estimated Effort: 5-7 days (including secure API key management)

---

🟡 Category 5: NON-MCP HTTP APIS - Pre-MCP Pattern (4 Widgets)

These widgets DO use HTTP APIs, but they bypass MCP routing and call local backend services directly.

5.1 AiPalWidget.tsx

• Service: PAL (Personal AI Logic)
• Direct Calls:
  • fetch('http://localhost:3001/api/pal/recommendations?userId=user-1&orgId=org-1')
  • fetch('http://localhost:3001/api/pal/event', { method: 'POST' })
• Status: ⚠️ Should be routed through /api/mcp/pal/recommendations and /api/mcp/pal/event
• Effort to convert: 1 day

5.2 CmaDecisionWidget.tsx

• Service: CMA Memory contextual prompt
• Direct Call: fetch('http://localhost:3001/api/memory/contextual-prompt', { method: 'POST' })
• Status: ⚠️ Should be routed through /api/mcp/memory/contextual-prompt
• Effort to convert: 1 day

5.3 EvolutionAgentWidget.tsx

• Service: Evolution Agent prompts and runs
• Direct Calls:
  • fetch('http://localhost:3001/api/evolution/prompt/{agentId}')
  • fetch('http://localhost:3001/api/evolution/runs/{agentId}?limit=5')
• Status: ⚠️ Should be routed through /api/mcp/evolution/*
• Effort to convert: 1 day

5.4 SragGovernanceWidget.tsx

• Service: SRAG (Strategic Reasoning/Analysis Grid)
• Direct Call: fetch('http://localhost:3001/api/srag/query', { method: 'POST' })
• Status: ⚠️ Should be routed through /api/mcp/srag/query
• Effort to convert: 1 day

Summary for Category 5:

• Total Widgets: 4 (17% of total)
• API Pattern: Already established (good)
• Issue: Not routed through MCP consolidation layer
• Combined Effort: 4 days (simple MCP wrapper around existing endpoints)
• Benefit: Unified routing, easier monitoring, single point of auth

---

✅ Category 6: UI-ONLY / CONFIGURATION (4 Widgets)

These widgets don't require backend integration - they're UI layers for configuration or pure presentation.

6.1 StatusWidget.tsx

• Purpose: System status display
• Data Source: useWidgetRegistry() and useGlobalState() context hooks
• Status: ✅ CORRECTLY IMPLEMENTED - No backend needed
• Action: None

6.2 SystemSettingsWidget.tsx

• Purpose: Theme and accessibility settings
• Data Source: useGlobalState() context
• Status: ✅ CORRECTLY IMPLEMENTED - Local state management only
• Action: None

6.3 MCPConnectorWidget.tsx

• Purpose: Configure database/API connections
• Implementation: Mock connection testing with setTimeout()
• Status: ⚠️ UI with mock backend testing
• Action: Replace mock testing with real connection validation (1 day)

6.4 WidgetImporterWidget.tsx

• Purpose: Import and register Microsoft Widgets
• Implementation: Local transformation logic using adapters and detectors
• Status: ✅ CORRECTLY IMPLEMENTED - Pure configuration UI
• Action: None, but verify MCP integration for widget registration

Summary for Category 6:

• Total Widgets: 4 (17% of total)
• Action Required: Minimal (mostly verification)
• Total Effort: 0-1 days

---

Integration Roadmap: Phase Implementation

🔴 PHASE 1: IMMEDIATE SECURITY FIX (1-2 days) - CRITICAL

Problem: 5 widgets expose API keys to client-side code

Widgets Affected:

1. AgentChatWidget
2. AudioTranscriberWidget
3. ImageAnalyzerWidget
4. LiveConversationWidget
5. VideoAnalyzerWidget

Solution: Create MCP proxy routes for Gemini APIs

Implementation:

New routes in backend:
POST /api/mcp/gemini/chat          - Chat completions
POST /api/mcp/gemini/audio         - Audio transcription
POST /api/mcp/gemini/vision        - Image analysis
POST /api/mcp/gemini/video         - Video analysis
WebSocket /api/mcp/gemini/live     - Live multimodal streaming

Changes to widgets:
- Move GoogleGenAI initialization to backend
- Replace direct fetch with `/api/mcp/gemini/*` calls
- Remove client-side API key exposure
- Use secure JWT/session-based authentication

Timeline: 1-2 days Blocking: Prevents moving widgets to production

---

🟡 PHASE 2: CONSOLIDATE NON-MCP APIs (3-5 days) - HIGH PRIORITY

Problem: 4 widgets use direct HTTP to backend services, bypassing MCP

Widgets Affected:

1. AiPalWidget
2. CmaDecisionWidget
3. EvolutionAgentWidget
4. SragGovernanceWidget

Solution: Route through MCP consolidation layer

Implementation:

Changes to backend:
- Add MCP routes that wrap existing `/api/{service}/*` endpoints
- Implement request/response standardization
- Add logging and monitoring at MCP layer

Changes to widgets:
- Replace direct localhost calls with `/api/mcp/{service}/*`
- Update error handling for standardized MCP response format

Timeline: 3-5 days Dependencies: Requires Phase 1 patterns to be established

---

🟡 PHASE 3: REPLACE MOCK DATA WITH MCP (5-7 days) - MEDIUM PRIORITY

Problem: 6 widgets use hardcoded mock data instead of real backends

Widgets Affected:

1. IntelligentNotesWidget → /api/mcp/notes/query
2. MCPEmailRAGWidget → /api/mcp/email/{inbox,suggestions}
3. CybersecurityOverwatchWidget → /api/mcp/security/threats
4. AgentBuilderWidget → /api/mcp/agents/{tools,registry}
5. PromptLibraryWidget → /api/mcp/prompts/{library,search}
6. ProcurementIntelligenceWidget → /api/mcp/procurement/opportunities

Solution: Implement real backends and wire through MCP

Implementation:

For each mock widget:
1. Design MCP endpoint contract (request/response schema)
2. Implement backend endpoint
3. Update widget to call MCP endpoint
4. Remove mock data constants
5. Test end-to-end

Effort Breakdown:

• IntelligentNotesWidget: 2-3 days
• MCPEmailRAGWidget: 3-4 days (needs real RAG)
• CybersecurityOverwatchWidget: 4-5 days (threat integration)
• AgentBuilderWidget: 2-3 days
• PromptLibraryWidget: 1-2 days
• ProcurementIntelligenceWidget: 3-4 days

Timeline: 5-7 days Dependencies: Can run in parallel with Phase 2

---

🟢 PHASE 4: POLISH CONFIGURATION UIs (3-4 days) - LOW PRIORITY

Widgets:

1. MCPConnectorWidget - Replace mock testing with real connection validation
2. Verify WidgetImporterWidget MCP integration pattern
3. Audit StatusWidget and SystemSettingsWidget

Timeline: 3-4 days Dependencies: Can run after other phases complete

---

Overall Integration Timeline

Phase	Focus	Days	Widgets	Risk	Critical Path
1	Security (Gemini APIs)	1-2	5	🔴 HIGH	🚨 BLOCKING
2	API Consolidation	3-5	4	🟡 MEDIUM	After Phase 1
3	Mock → Real Data	5-7	6	🟡 MEDIUM	Parallel with Phase 2
4	Polish/Finalize	3-4	4	🟢 LOW	After 1-3
TOTAL	100% MCP	12-18	24	Mixed	2-3 weeks

---

Critical Success Factors

Must-Have (Phase 1)

• ✅ API keys secured behind MCP proxy
• ✅ No client-side exposure of credentials
• ✅ WebSocket MCP route for LiveConversationWidget

Should-Have (Phases 2-3)

• ✅ All widgets routed through MCP layer
• ✅ Unified error handling and logging
• ✅ Real data replaces all mock data

Nice-to-Have (Phase 4)

• ✅ Performance monitoring at MCP layer
• ✅ Standardized request/response formats
• ✅ API versioning strategy

---

Risk Assessment

🔴 CRITICAL RISKS

1. API Key Exposure (Phase 1)

• Impact: Security vulnerability, data exposure
• Likelihood: Already present
• Mitigation: Implement MCP proxy immediately
• Timeline: 1-2 days

2. Breaking Changes (Phases 2-3)

• Impact: Widgets stop working during transition
• Likelihood: Medium (if not careful with rollout)
• Mitigation: Blue-green deployment, feature flags per widget
• Timeline: Include in each phase

🟡 HIGH RISKS

3. RAG Integration Complexity (Phase 3)

• Impact: MCPEmailRAGWidget needs sophisticated backend
• Likelihood: High (RAG is complex)
• Mitigation: Start with simple retrieval, enhance iteratively
• Timeline: 4-5 days for MVP

4. WebSocket Handling (Phase 1)

• Impact: LiveConversationWidget uses real-time audio
• Likelihood: Medium (WebSocket debugging)
• Mitigation: Test thoroughly, monitor latency
• Timeline: Include in Phase 1

---

Success Metrics

After all phases complete, measure:

Metric	Current	Target
Widgets using MCP	1 (4%)	24 (100%)
Mock data widgets	6 (25%)	0 (0%)
API keys in browser	5 expose	0 expose
Non-MCP HTTP calls	4 bypass	0 bypass
Direct external APIs	5 services	0 services
MCP Adoption	4%	100%

---

Recommendations

Immediate (This Week)

1. ✅ Complete Phase 1 security fix (secure Gemini API keys)
2. ✅ Create MCP proxy routes for all external APIs
3. ✅ Test LiveConversationWidget WebSocket reliability

Short-term (Next Week)

4. ⏳ Phase 2: Consolidate non-MCP HTTP calls through MCP layer
5. ⏳ Phase 3: Begin real data backend implementation
6. ⏳ Start with highest-value widgets (MCPEmailRAGWidget, CybersecurityOverwatchWidget)

Medium-term (Dec 1-15)

7. ⏳ Complete Phase 3: All mock data replaced
8. ⏳ Phase 4: Polish configuration UIs
9. ⏳ End-to-end testing with real data

Quality Gates

• ✅ All widgets must pass security audit (no API keys in browser)
• ✅ All widgets must route through MCP for data access
• ✅ 95%+ test coverage for MCP integration points
• ✅ Performance: <100ms latency added by MCP layer

---

MCP as "Foundation" - Reality Check

Current State

• ✅ MCP infrastructure exists (backend, routing, tools registered)
• ✅ 1 widget demonstrates proper MCP usage (McpRouterWidget)
• ❌ MCP "foundation" is infrastructure-only, not integrated into widgets

The Gap

• Claim: "MCP is the foundation for our solution"
• Reality: Only ~4% of widgets actually use it
• Root Cause: Widgets built before or without MCP wiring complete

Path Forward

Completing this 3-phase roadmap (12-18 days) will transform MCP from "infrastructure only" to "actual foundation":

• ✅ 100% of widgets routed through MCP
• ✅ Centralized security (API key management)
• ✅ Unified service layer (all backends via MCP)
• ✅ European sovereignty (MCP routes can enforce EU-only data processing)

---

Next Steps

Immediate Action Required:

1. Review this analysis with hanspedder2 (architecture lead)
2. Prioritize Phase 1 security fix
3. Allocate developer resources
4. Create security audit checklist for API key exposure

Approval Required:

• Confirm Phase 1 (security) start date
• Confirm resource allocation
• Approve MCP proxy route architecture
• Confirm Phase 2-4 sequencing

---

Analysis Prepared By: Claude Code Priority 1 Task Status: Ready for Architecture Review Next Review: After hanspedder2 feedback on implementation approach