MCP Gateway Compliance Review - 2026-03-31

Summary

Found 1 compliance issue during daily review of commit 3b4c53f (fix: lower repo-assist min-integrity to unapproved).

Note: Previously tracked issue spec-version-constant (MCPGatewaySpecVersion was 1.8.0) has been resolved — the constant now correctly reports 1.9.0.

Recent Changes Reviewed

• Commit 3b4c53f: fix: lower repo-assist min-integrity to unapproved — workflow configuration change only, no impact on gateway core compliance.
• All other specification sections remain compliant (see Compliance Status table below).

Important Issues (Persistent SHOULD Violation)

1. GetServerStatus() Always Reports "running" with Zero Uptime

Specification Section: Section 8 — Health Monitoring
Deep Link: https://github.com/github/gh-aw/blob/main/docs/src/content/docs/reference/mcp-gateway.md#8-health-monitoring

Requirement:

Health check includes server uptime and status
Periodic health checks (every 30 seconds recommended)
Automatic restart of failed stdio servers

Current State:

internal/server/unified.go lines 584–604 — GetServerStatus() hardcodes every configured server as "running" and always returns Uptime: 0, regardless of actual connection state:

status[serverID] = ServerStatus{
    Status: "running",
    Uptime: 0, // Will be properly tracked when servers are actually launched
}

The TODO comment ("Will be properly tracked when servers are actually launched") confirms this is a known stub.

Gap:

1. Inaccurate status: The /health endpoint always reports all servers as "running", even if they have crashed, never been contacted, or encountered errors. The BuildHealthResponse() logic only transitions to "unhealthy" when status.Status == "error", which can never happen with the current stub.
2. Zero uptime: Uptime is always 0 — server start times are never tracked.
3. No periodic health checks: There is no background goroutine performing periodic health checks (only a connection pool cleanup ticker exists in internal/launcher/connection_pool.go:101).
4. No automatic restart: Failed stdio servers are not automatically restarted.

Severity: Important (SHOULD violation — spec recommends proactive health tracking and restarts)

File References:

• internal/server/unified.go:584–604 — GetServerStatus() stub
• internal/server/health.go:30–36 — Health logic that relies on accurate status
• internal/launcher/launcher.go:206–252 — Server launch logic with no state tracking

Suggested Fix:

1. Track server connection state in the launcher — Record whether each server has been successfully launched, its start time, and whether its connection has errored:

   type ServerState struct {
       Status    string    // "running" | "stopped" | "error"
       StartedAt time.Time
   }

2. Return actual status — In GetServerStatus(), query the launcher for real connection state instead of hardcoding "running".

3. Track uptime — Store the time.Now() when a server is successfully launched; return int(time.Since(startedAt).Seconds()) for uptime.

4. Optional (SHOULD): Add a background health-check goroutine that pings each backend every 30 seconds and updates server state accordingly.

Compliance Status

Resolved Since Last Review

• ✅ spec-version-constant: MCPGatewaySpecVersion updated from 1.8.0 → 1.9.0

References

• MCP Gateway Specification
• Commits reviewed: 3b4c53f
• Previous review: 2026-03-30

tools:
  github:
    min-integrity: approved  # merged | approved | unapproved | none

Generated by Daily Compliance Checker · ◷