We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/debugmcpdev/mcp-debugger'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
SSE_TO_STDIO_BRIDGE_SUMMARY.md•3.71 kB
# SSE-to-STDIO Bridge Implementation Summary
## Task 2 Completion Status
### ✅ Completed Components
1. **StdioSubprocessManager Class**
- Spawns and manages STDIO subprocess
- Handles restart logic with exponential backoff
- Message buffering (100 message queue)
- Health tracking and metrics
- Graceful shutdown
2. **Message Routing Architecture**
- SSE → STDIO: HTTP POST bodies forwarded to subprocess stdin
- STDIO → SSE: Subprocess stdout parsed and routed to SSE connections
- Request/response correlation using message IDs
- Session-based notification routing
3. **Session Management**
- SSE session IDs generated on connection
- Debug session observer pattern for notifications
- Sessions persist across SSE reconnections (in STDIO subprocess)
- Multi-client support for same debug session
4. **Error Handling**
- 503 Service Unavailable when STDIO subprocess down
- Request timeout after 30 seconds
- Automatic reconnection and message buffering
- Graceful degradation
### ❌ Current Issue: SSE Protocol Initialization
The tests are timing out because the SSE client can't complete the MCP protocol handshake.
**Problem Analysis:**
1. SSE client connects to `/sse` endpoint
2. We send session ID: `data: ${sseSessionId}\n\n`
3. Client sends MCP initialize request to `/sse?sessionId=xxx`
4. Request is forwarded to STDIO subprocess
5. **TIMEOUT** - No valid response received
**Root Cause:**
The STDIO subprocess expects certain initialization that we're not providing correctly. The SSE transport protocol has specific requirements that differ from pure STDIO.
### Debugging Approach
To diagnose the issue:
1. Check if STDIO subprocess is actually starting
2. Verify messages are being sent to STDIO
3. Check if responses are coming back from STDIO
4. Verify the SSE protocol format is correct
### Next Steps
1. Add more detailed logging to track message flow
2. Verify STDIO subprocess health during tests
3. Check if MCP protocol initialization is correct
4. Consider if we need to handle special SSE transport requirements
## Architecture Overview
```
┌─────────────┐ HTTP POST ┌─────────────┐ stdin ┌──────────────┐
│ SSE Client │ ──────────────────> │ SSE Server │ ───────────────> │ STDIO Process│
│ │ │ (Express) │ │ (MCP Server) │
│ │ <────────────────── │ │ <────────────── │ │
└─────────────┘ SSE Events └─────────────┘ stdout └──────────────┘
│
├── Request Correlation Map
├── Session Observer Map
└── Message Queue (100)
```
## Implementation Files
- `/src/cli/sse-command.ts` - Main implementation
- `StdioSubprocessManager` - Subprocess lifecycle management
- `createSSEApp` - Express app with SSE/STDIO bridge
- `handleSSECommand` - Entry point
## Test Results
Both JavaScript SSE tests are timing out after 60 seconds:
- `should successfully debug JavaScript via SSE transport`
- `should provide stack trace without overriding launch args`
This indicates the fundamental SSE ↔ STDIO bridge is not working correctly yet.