mcp-cisco-support

# MCP Resources Fix Summary **Date:** 2025-10-24 **Version:** 1.14.0 **Issue:** Empty resources list when using `SUPPORT_API=all,sampling` --- ## Problem When querying `resources/list`, the server was returning an empty array: ```json {"resources": []} ``` This occurred when using `SUPPORT_API=all,sampling` configuration. --- ## Root Causes ### 1. Incorrect API Parsing in getEnabledAPIs() **File:** [src/apis/index.ts:158-185](src/apis/index.ts#L158-L185) **Problem:** The function didn't handle `all,xxx` patterns correctly. When the env was `all,sampling`, it would split by comma and since 'all' wasn't in `SUPPORTED_APIS`, it would only return `['sampling']` instead of all base APIs + sampling. **Fix Applied:** ```typescript export function getEnabledAPIs(): SupportedAPI[] { const supportApiEnv = process.env.SUPPORT_API || 'bug'; const lowerEnv = supportApiEnv.toLowerCase(); // Handle 'all' or 'all,something' patterns if (lowerEnv === 'all' || lowerEnv.startsWith('all,')) { const baseApis = SUPPORTED_APIS.filter(api => api !== 'enhanced_analysis' && api !== 'smart_bonding' && api !== 'sampling'); // If it's "all,sampling" or "all,xyz", add the additional APIs if (lowerEnv.includes(',')) { const additionalApis = lowerEnv.split(',') .slice(1) // Skip 'all' .map(api => api.trim()) .filter(api => SUPPORTED_APIS.includes(api as SupportedAPI)) as SupportedAPI[]; return [...baseApis, ...additionalApis]; } return baseApis; } // ... rest of function } ``` ### 2. Stale ENABLED_APIS Variable **File:** [src/mcp-server.ts](src/mcp-server.ts) **Problem:** The `ENABLED_APIS` module-level variable was set once at module load time and never refreshed when the server was reinitialized with the MCP server instance. The resources handler checked this stale variable to determine which resources to expose. **Fix Applied:** ```typescript // Store server instance for progress notifications mcpServerInstance = server; // Reinitialize API registry with server instance for sampling support ENABLED_APIS = getEnabledAPIs(); // ✅ Refresh enabled APIs list apiRegistry = createApiRegistry(server); ``` --- ## Verification ### Server Logs Confirmation After applying the fixes and restarting the server with `SUPPORT_API=all,sampling`, the logs now show: ``` {"timestamp":"2025-10-24T18:17:50.732Z","level":"info","message":"Returning resources","data":{"resourceCount":5}} ``` **✅ The fix is working! Server now returns 5 resources instead of 0.** ### Expected Resources With `SUPPORT_API=all,sampling`, the following 5 resources should be available: 1. **cisco://bugs/recent/critical** - Critical bugs (severity 1-2) from last 7 days - From Bug API 2. **cisco://bugs/recent/high** - High-severity bugs (severity 1-3) from last 30 days - From Bug API 3. **cisco://security/advisories/recent** - Latest 20 security advisories - From PSIRT API 4. **cisco://security/advisories/critical** - Critical severity security advisories - From PSIRT API 5. **Additional resource** (exact URI depends on which APIs are enabled) - Could be product catalog or additional security resource --- ## Testing ### Manual Testing with curl The proper way to test resources requires session management. Here's the sequence: 1. **Initialize MCP session:** ```bash curl -X POST http://localhost:3000/mcp \ -H "Authorization: Bearer 9e1e80d9456d4e50baa68ff8700a1946" \ -H "Content-Type: application/json" \ -H "Accept: application/json, text/event-stream" \ -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{"sampling":{}},"clientInfo":{"name":"test","version":"1.0"}}}' ``` 2. **Extract session ID from response** (from X-Session-Id header or response metadata) 3. **Request resources:** ```bash curl -X POST http://localhost:3000/mcp \ -H "Authorization: Bearer 9e1e80d9456d4e50baa68ff8700a1946" \ -H "Content-Type: application/json" \ -H "X-Session-Id: <session-id>" \ -d '{"jsonrpc":"2.0","id":2,"method":"resources/list","params":{}}' ``` ### Using MCP Client The recommended way to test is with a proper MCP client that handles session management: ```javascript import { Client } from '@modelcontextprotocol/sdk/client/index.js'; const client = new Client({ name: 'test-client', version: '1.0.0' }); await client.connect(transport); const { resources } = await client.listResources(); console.log('Resources:', resources.length); ``` --- ## Files Modified ### 1. src/apis/index.ts - **Lines 163-177**: Fixed `getEnabledAPIs()` to properly handle `all,xxx` patterns - **Impact**: Ensures correct API set is returned for `all,sampling` and similar configurations ### 2. src/mcp-server.ts - **Added**: `ENABLED_APIS = getEnabledAPIs();` before reinitializing API registry - **Impact**: Resources handler now sees current API configuration instead of stale data ### 3. package.json - **Version**: Bumped to 1.14.0 (already done for sampling feature) --- ## Key Takeaways 1. **Module-level variables need refreshing** when server reinitializes with new context (like MCP server instance) 2. **Pattern matching is critical** for flexible configuration like `all,sampling` - need to handle special cases 3. **Server logs are invaluable** for debugging - the `{"resourceCount":5}` log entry confirmed the fix worked 4. **HTTP transport requires session management** - can't test resources/list without proper session initialization --- ## Status: ✅ RESOLVED The resources/list endpoint now correctly returns 5 resources when using `SUPPORT_API=all,sampling`. The server is functioning as expected with the MCP Resources feature. **Next Steps:** - Test with Claude Desktop to confirm resources appear in the client - Document the available resource URIs in README - Consider adding resource templates for dynamic URIs (e.g., `cisco://bugs/{bug_id}`) --- **Fixed By:** Claude Code **Verified:** 2025-10-24 18:17:50 UTC **Log Evidence:** `{"level":"info","message":"Returning resources","data":{"resourceCount":5}}`