Feature: MCP Server Lifecycle Management
  As an actor runtime
  I want MCP servers to start lazily and stop when idle
  So that resources are used efficiently and server management is automatic

  # -------------------------------------------------------------------
  # Lazy Start
  # -------------------------------------------------------------------

  Scenario: MCP server starts on first tool call (lazy start)
    Given an MCP client config for "github" with lazy start enabled
    And a mock MCP transport with tool "list_repos"
    When I create an MCP client
    Then the MCP client state should be "idle"
    And the MCP client should not be connected
    When I call MCP tool "list_repos" with arguments {}
    Then the MCP client should be connected
    And the MCP client state should be "running"

  Scenario: MCP server does not start without tool call when lazy start enabled
    Given an MCP client config for "github" with lazy start enabled
    And a mock MCP transport with tool "list_repos"
    When I create an MCP client
    Then the MCP client should not be connected

  Scenario: Explicit start works with lazy start enabled
    Given an MCP client config for "github" with lazy start enabled
    And a mock MCP transport with tool "list_repos"
    When I create an MCP client
    And I explicitly start the MCP client
    Then the MCP client should be connected
    And the MCP client state should be "running"

  Scenario: Tool call fails when lazy start disabled and not started
    Given an MCP client config for "github" with lazy start disabled
    And a mock MCP transport with tool "list_repos"
    When I create an MCP client
    And I call MCP tool "list_repos" expecting a runtime error
    Then the MCP client error should mention "not started"

  Scenario: Explicit start is idempotent
    Given an MCP client config for "github" with lazy start enabled
    And a mock MCP transport with tool "list_repos"
    When I create an MCP client
    And I explicitly start the MCP client
    And I explicitly start the MCP client
    Then the MCP client should be connected

  # -------------------------------------------------------------------
  # Auto-Stop
  # -------------------------------------------------------------------

  Scenario: MCP server auto-stops after idle timeout
    Given an MCP client config for "github" with idle timeout 0.15 seconds
    And a mock MCP transport with tool "list_repos"
    When I create an MCP client
    And I call MCP tool "list_repos" with arguments {}
    And I wait 0.5 seconds
    Then the MCP client state should be "stopped"
    And the MCP client should not be connected

  Scenario: Activity resets idle timer
    Given an MCP client config for "github" with idle timeout 0.5 seconds
    And a mock MCP transport with tool "list_repos"
    When I create an MCP client
    And I call MCP tool "list_repos" with arguments {}
    And I wait 0.25 seconds
    And I call MCP tool "list_repos" with arguments {}
    And I wait 0.25 seconds
    Then the MCP client should be connected

  Scenario: Auto-stop disabled when timeout is zero
    Given an MCP client config for "github" with idle timeout 0.0 seconds
    And a mock MCP transport with tool "list_repos"
    When I create an MCP client
    And I call MCP tool "list_repos" with arguments {}
    And I wait 0.15 seconds
    Then the MCP client should be connected

  # -------------------------------------------------------------------
  # Shutdown
  # -------------------------------------------------------------------

  Scenario: Explicit shutdown stops the server
    Given an MCP client config for "github" with lazy start enabled
    And a mock MCP transport with tool "list_repos"
    When I create an MCP client
    And I call MCP tool "list_repos" with arguments {}
    And I shutdown the MCP client
    Then the MCP client state should be "stopped"
    And the MCP client should not be connected

  Scenario: Double shutdown is safe
    Given an MCP client config for "github" with lazy start enabled
    And a mock MCP transport with tool "list_repos"
    When I create an MCP client
    And I call MCP tool "list_repos" with arguments {}
    And I shutdown the MCP client
    And I shutdown the MCP client
    Then the MCP client state should be "stopped"

  # -------------------------------------------------------------------
  # Health Monitoring
  # -------------------------------------------------------------------

  Scenario: Health check detects crash and auto-restarts
    Given an MCP client config for "github" with health check interval 0.15 seconds
    And a mock MCP transport with tool "list_repos" that crashes after 1 call
    When I create an MCP client
    And I call MCP tool "list_repos" with arguments {}
    And I wait 1.0 seconds
    Then the MCP client restart count should be greater than 0

  Scenario: Health check disabled when interval is zero
    Given an MCP client config for "github" with health check interval 0.0 seconds
    And a mock MCP transport with tool "list_repos"
    When I create an MCP client
    And I call MCP tool "list_repos" with arguments {}
    Then the MCP client health check failures should be 0

  # -------------------------------------------------------------------
  # Registry (Multiple Servers)
  # -------------------------------------------------------------------

  Scenario: Multiple MCP servers with independent lifecycles
    Given an MCP registry
    And an MCP client config for "github" with lazy start enabled
    And a mock MCP transport with tool "list_repos"
    When I register the MCP client in namespace "gh"
    And I register another MCP client config for "jira" in namespace "jira"
    Then the MCP registry should have 2 namespaces
    And MCP namespace "gh" should not be connected
    And MCP namespace "jira" should not be connected

  Scenario: Registry call_tool starts specific server lazily
    Given an MCP registry
    And an MCP client config for "github" with lazy start enabled
    And a mock MCP transport with tool "list_repos"
    When I register the MCP client in namespace "gh"
    And I call tool "list_repos" on MCP namespace "gh" with arguments {}
    Then MCP namespace "gh" should be connected

  Scenario: Registry shutdown_all stops all servers
    Given an MCP registry with 2 running servers
    When I shutdown all MCP servers
    Then the MCP registry should have 2 namespaces
    And all MCP servers should be stopped

  # -------------------------------------------------------------------
  # Capability Metadata
  # -------------------------------------------------------------------

  Scenario: Full capability metadata exposed after connect
    Given an MCP client config for "github" with lazy start enabled
    And a mock MCP transport with full capabilities
    When I create an MCP client
    And I explicitly start the MCP client
    Then the MCP adapter capability metadata should have tools true
    And the MCP adapter capability metadata should have resources true
    And the MCP adapter capability metadata should have prompts true