Skip to main content

Status Tracking

The satellite tracks the health and availability of each MCP server instance (per-user) through a 12-state status system. This enables real-time monitoring, automatic recovery, and tool availability filtering on a per-user basis.

Overview

Per-User Instance Status

DeployStack tracks status at the instance level, not the installation level:
  • Status Location: mcpServerInstances table (per user)
  • No Installation Status: Status fields completely removed from mcpServerInstallations table
  • Independent Tracking: Each team member has independent status for each MCP server
  • User-Specific Filtering: Users see only tools from their OWN instances that are online
Example:

Status Tracking Purposes

Status tracking serves three primary purposes:
  1. User Visibility: Users see their OWN instance status in real-time via the frontend
  2. Tool Availability: Tools from user’s unavailable instances are filtered from discovery
  3. Automatic Recovery: System detects and recovers from failures per instance
The status system is managed by UnifiedToolDiscoveryManager and updated through:
  • Instance 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)
  • User configuration completion (awaiting_user_config → provisioning)

Status Values

New Status: awaiting_user_configThis status indicates that an MCP server has required user-level configuration fields (e.g., personal API keys) and the user hasn’t configured them yet. The satellite does NOT spawn processes for instances with this status. Once the user completes their configuration via the dashboard, the status automatically transitions to provisioning and the instance spawns normally.See Instance Lifecycle - Process A for details.

Status Lifecycle

Initial Installation Flow (User Has Complete Config)

Initial Installation Flow (User Missing Required Config)

When an MCP server has required user-level configuration fields and the user hasn’t configured them:
Backend Filtering: The satellite does NOT receive configurations for instances with awaiting_user_config status. Backend filters these instances out in the config endpoint, preventing spawn attempts for incomplete configurations.

Configuration Update Flow

Failure and Recovery Flow

OAuth Failure Flow

Stdio Crash Flow (Permanent Failure)

Status Tracking Implementation

UnifiedToolDiscoveryManager

The status system is implemented in UnifiedToolDiscoveryManager:

Status Callbacks

Discovery managers call status callbacks when discovery succeeds or fails: HTTP/SSE Discovery:
Stdio Discovery:

Tool Filtering by Status

Per-User Instance Filtering

Tool availability is filtered based on the authenticated user’s OWN instance status: Key Principles:
  • Each user sees only tools from their own instances that are online
  • Other team members’ instance status does NOT affect your tool availability
  • If your instance is awaiting_user_config, you see NO tools from that server
  • If your instance is online, you see all tools (even if teammates’ instances are offline)
Example:

Discovery Filtering

When LLMs call discover_mcp_tools, only tools from the user’s available instances are returned:

Execution Blocking

When LLMs attempt to execute tools from the user’s unavailable instances:

Status Transition Triggers

Backend-Triggered (Database Updates)

Source: Backend API routes update mcpServerInstances table (per user)
Status Target: All backend status updates target the mcpServerInstances table. Status fields have been completely removed from mcpServerInstallations. Each user’s instance has independent status tracking.

Satellite-Triggered (Event Emission)

Source: Satellite emits mcp.server.status_changed events to backend (includes user_id field) Event Payload:
The user_id field ensures status updates are applied to the correct user’s instance.

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

Instance Lifecycle

Four lifecycle processes for instance creation, deletion, and team membership changes

Event Emission

Status change event details with user_id field

Recovery System

Automatic recovery logic for failed instances

Tool Discovery

How status affects per-user tool discovery