Status Tracking
The satellite tracks the health and availability of each MCP server installation through an 11-state status system. This enables real-time monitoring, automatic recovery, and tool availability filtering.Overview
Status tracking serves three primary purposes:- User Visibility: Users see current server state in real-time via the frontend
- Tool Availability: Tools from unavailable servers are filtered from discovery
- Automatic Recovery: System detects and recovers from failures automatically
UnifiedToolDiscoveryManager and updated through:
- Installation lifecycle events (provisioning → online)
- Health check results (online → offline)
- Tool execution failures (online → offline/error/requires_reauth)
- Configuration changes (online → restarting)
- Recovery detection (offline → connecting → online)
Status Values
| Status | Description | Tools Available? | User Action Required |
|---|---|---|---|
provisioning | Initial state after installation created | No | Wait |
command_received | Satellite received configuration command | No | Wait |
connecting | Connecting to MCP server | No | Wait |
discovering_tools | Running tool discovery | No | Wait |
syncing_tools | Syncing tools to backend | No | Wait |
online | Server healthy and responding | Yes | None |
restarting | Configuration updated, server restarting | No | Wait |
offline | Server unreachable (auto-recovers) | No | Wait or check server |
error | General error state (auto-recovers) | No | Check logs |
requires_reauth | OAuth token expired/revoked | No | Re-authenticate |
permanently_failed | 3+ crashes in 5 minutes (stdio only) | No | Manual restart required |
Status Lifecycle
Initial Installation Flow
Configuration Update Flow
Failure and Recovery Flow
OAuth Failure Flow
Stdio Crash Flow (Permanent Failure)
Status Tracking Implementation
UnifiedToolDiscoveryManager
The status system is implemented inUnifiedToolDiscoveryManager:
Status Callbacks
Discovery managers call status callbacks when discovery succeeds or fails: HTTP/SSE Discovery:Tool Filtering by Status
Discovery Filtering
When LLMs calldiscover_mcp_tools, only tools from available servers are returned:
Execution Blocking
When LLMs attempt to execute tools from unavailable servers:Status Transition Triggers
Backend-Triggered (Database Updates)
Source: Backend API routes| Trigger | New Status | When |
|---|---|---|
| Installation created | provisioning | User installs MCP server |
| Config updated | restarting | User modifies environment vars/args/headers |
| OAuth callback success | connecting | User re-authenticates |
| Health check fails | offline | Server unreachable (3-min interval) |
| Credential validation fails | requires_reauth | OAuth token invalid |
Satellite-Triggered (Event Emission)
Source: Satellite emitsmcp.server.status_changed events to backend
| Trigger | New Status | When |
|---|---|---|
| Configure command received | command_received | Satellite polls backend |
| Server connection starts | connecting | Spawning process or HTTP connect |
| Tool discovery starts | discovering_tools | Calling tools/list |
| Tool discovery succeeds | online | Discovery completed successfully |
| Tool execution fails (3 retries) | offline/error/requires_reauth | Tool call failed after retries |
| Server recovery detected | connecting | Previously offline server responds |
| Stdio crashes 3 times | permanently_failed | 3 crashes within 5 minutes |
Implementation Components
The status tracking system consists of several integrated components:- Database schema for status field
- Backend event handler for status updates
- Satellite status event emission
- Tool availability filtering by status
- Configuration update status transitions
- Tool execution status updates with auto-recovery
Related Documentation
- Event Emission - Status change event details
- Recovery System - Automatic recovery logic
- Tool Discovery - How status affects tool discovery
- Hierarchical Router - Status-based tool filtering

