@tdd_issue @tdd_issue_10512
Feature: MCPToolAdapter releases RLock during transport calls
  As a developer using MCPToolAdapter concurrently
  I want the adapter to release its RLock before making transport calls
  So that concurrent operations are not blocked by slow transport calls

  # -------------------------------------------------------------------
  # Bug #10512: MCPToolAdapter holds RLock during entire transport call,
  # blocking concurrent operations.
  #
  # The fix releases the lock before the transport.call() and
  # re-acquires it only when shared state must be mutated.
  # -------------------------------------------------------------------

  Scenario: Concurrent invoke calls are not blocked by a slow transport
    Given a connected MCP adapter with a concurrency-tracking transport tool "slow_op" taking 0.05 seconds
    When I invoke "slow_op" concurrently from 3 threads
    Then all 3 concurrent invocations should succeed
    And at least 2 invocations should have been in-flight simultaneously

  Scenario: Concurrent discover_tools calls are not blocked by a slow transport
    Given a connected MCP adapter with a concurrency-tracking discovery transport taking 0.05 seconds
    When I call discover_tools concurrently from 3 threads
    Then all 3 concurrent discoveries should succeed
    And at least 2 discoveries should have been in-flight simultaneously

  Scenario: Lock is not held during invoke transport call
    Given a connected MCP adapter with a lock-checking transport tool "check_lock"
    When I invoke "check_lock" with arguments {}
    Then the invocation should succeed
    And the lock should not have been held during the transport call

  Scenario: Lock is not held during discover_tools transport call
    Given a connected MCP adapter with a lock-checking discovery transport
    When I discover tools from the adapter
    Then the lock should not have been held during the discovery transport call

  Scenario: Invoke still validates under lock before transport call
    Given a connected MCP adapter with a slow transport tool "slow_op" taking 0.1 seconds
    When I invoke "nonexistent_tool" with arguments {}
    Then the invocation should fail
    And the invocation error should mention "not found"

  Scenario: Invoke on disconnected adapter still raises under lock
    Given an MCP adapter with a mock transport
    When I invoke MCP tool "any_tool" while disconnected
    Then the adapter error should mention "not connected"

  Scenario: Discover on disconnected adapter still raises under lock
    Given an MCP adapter with a mock transport
    When I discover tools expecting an error
    Then the adapter error should mention "not connected"