langchain-mcp-tools 0.0.13__tar.gz → 0.0.15__tar.gz

{langchain_mcp_tools-0.0.13 → langchain_mcp_tools-0.0.15}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.2
 Name: langchain-mcp-tools
-Version: 0.0.13
+Version: 0.0.15
 Summary: Model Context Protocol (MCP) To LangChain Tools Conversion Utility
 Project-URL: Bug Tracker, https://github.com/hideya/langchain-mcp-tools-py/issues
 Project-URL: Source Code, https://github.com/hideya/langchain-mcp-tools-py
@@ -108,7 +108,7 @@ Currently, only text results of tool calls are supported.
 ## Technical Details
 
 It was very tricky (for me) to get the parallel MCP server initialization
-to work successfully...
+to work, including successful final resource cleanup...
 
 I'm new to Python, so it is very possible that my ignorance is playing
 a big role here...  
@@ -119,23 +119,24 @@ Any comments pointing out something I am missing would be greatly appreciated!
 [(comment here)](https://github.com/hideya/langchain-mcp-tools-ts/issues)
 
 1. Core Challenge:
-   - Async resources management for `stdio_client` and `ClientSession` seems
+
+   A key requirement for parallel initialization is that each server must be
+   initialized in its own dedicated task - there's no way around this as far as
+   I know. However, this poses a challenge when combined with
+   `asynccontextmanager`.
+
+   - Resources management for `stdio_client` and `ClientSession` seems
      to require relying exclusively on `asynccontextmanager` for cleanup,
      with no manual cleanup options
      (based on [the mcp python-sdk impl as of Jan 14, 2025](https://github.com/modelcontextprotocol/python-sdk/tree/99727a9/src/mcp/client))
    - Initializing multiple MCP servers in parallel requires a dedicated
      `asyncio.Task` per server
-   - Necessity of keeping sessions alive for later use by different tasks
+   - Need to keep sessions alive for later use by different tasks
      after initialization
-   - Ensuring proper cleanup later in the same task that created them
+   - Need to ensure proper cleanup later in the same task that created them
 
 2. Solution Strategy:
 
-   A key requirement for parallel initialization is that each server must be
-   initialized in its own dedicated task - there's no way around this as far
-   as I understand. However, this creates a challenge since we also need to
-   maintain long-lived sessions and handle cleanup properly.
-
    The key insight is to keep the initialization tasks alive throughout the
    session lifetime, rather than letting them complete after initialization.
 
@@ -156,7 +157,7 @@ Any comments pointing out something I am missing would be greatly appreciated!
 
 3. Task Lifecycle:
 
-   To allow the initialization task to stay alive waiting for cleanup:
+   The following illustrates how to implement the above-mentioned strategy:
    ```
    [Task starts]
      ↓

{langchain_mcp_tools-0.0.13 → langchain_mcp_tools-0.0.15}/README.md

@@ -83,7 +83,7 @@ Currently, only text results of tool calls are supported.
 ## Technical Details
 
 It was very tricky (for me) to get the parallel MCP server initialization
-to work successfully...
+to work, including successful final resource cleanup...
 
 I'm new to Python, so it is very possible that my ignorance is playing
 a big role here...  
@@ -94,23 +94,24 @@ Any comments pointing out something I am missing would be greatly appreciated!
 [(comment here)](https://github.com/hideya/langchain-mcp-tools-ts/issues)
 
 1. Core Challenge:
-   - Async resources management for `stdio_client` and `ClientSession` seems
+
+   A key requirement for parallel initialization is that each server must be
+   initialized in its own dedicated task - there's no way around this as far as
+   I know. However, this poses a challenge when combined with
+   `asynccontextmanager`.
+
+   - Resources management for `stdio_client` and `ClientSession` seems
      to require relying exclusively on `asynccontextmanager` for cleanup,
      with no manual cleanup options
      (based on [the mcp python-sdk impl as of Jan 14, 2025](https://github.com/modelcontextprotocol/python-sdk/tree/99727a9/src/mcp/client))
    - Initializing multiple MCP servers in parallel requires a dedicated
      `asyncio.Task` per server
-   - Necessity of keeping sessions alive for later use by different tasks
+   - Need to keep sessions alive for later use by different tasks
      after initialization
-   - Ensuring proper cleanup later in the same task that created them
+   - Need to ensure proper cleanup later in the same task that created them
 
 2. Solution Strategy:
 
-   A key requirement for parallel initialization is that each server must be
-   initialized in its own dedicated task - there's no way around this as far
-   as I understand. However, this creates a challenge since we also need to
-   maintain long-lived sessions and handle cleanup properly.
-
    The key insight is to keep the initialization tasks alive throughout the
    session lifetime, rather than letting them complete after initialization.
 
@@ -131,7 +132,7 @@ Any comments pointing out something I am missing would be greatly appreciated!
 
 3. Task Lifecycle:
 
-   To allow the initialization task to stay alive waiting for cleanup:
+   The following illustrates how to implement the above-mentioned strategy:
    ```
    [Task starts]
      ↓

{langchain_mcp_tools-0.0.13 → langchain_mcp_tools-0.0.15}/langchain_mcp_tools.egg-info/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.2
 Name: langchain-mcp-tools
-Version: 0.0.13
+Version: 0.0.15
 Summary: Model Context Protocol (MCP) To LangChain Tools Conversion Utility
 Project-URL: Bug Tracker, https://github.com/hideya/langchain-mcp-tools-py/issues
 Project-URL: Source Code, https://github.com/hideya/langchain-mcp-tools-py
@@ -108,7 +108,7 @@ Currently, only text results of tool calls are supported.
 ## Technical Details
 
 It was very tricky (for me) to get the parallel MCP server initialization
-to work successfully...
+to work, including successful final resource cleanup...
 
 I'm new to Python, so it is very possible that my ignorance is playing
 a big role here...  
@@ -119,23 +119,24 @@ Any comments pointing out something I am missing would be greatly appreciated!
 [(comment here)](https://github.com/hideya/langchain-mcp-tools-ts/issues)
 
 1. Core Challenge:
-   - Async resources management for `stdio_client` and `ClientSession` seems
+
+   A key requirement for parallel initialization is that each server must be
+   initialized in its own dedicated task - there's no way around this as far as
+   I know. However, this poses a challenge when combined with
+   `asynccontextmanager`.
+
+   - Resources management for `stdio_client` and `ClientSession` seems
      to require relying exclusively on `asynccontextmanager` for cleanup,
      with no manual cleanup options
      (based on [the mcp python-sdk impl as of Jan 14, 2025](https://github.com/modelcontextprotocol/python-sdk/tree/99727a9/src/mcp/client))
    - Initializing multiple MCP servers in parallel requires a dedicated
      `asyncio.Task` per server
-   - Necessity of keeping sessions alive for later use by different tasks
+   - Need to keep sessions alive for later use by different tasks
      after initialization
-   - Ensuring proper cleanup later in the same task that created them
+   - Need to ensure proper cleanup later in the same task that created them
 
 2. Solution Strategy:
 
-   A key requirement for parallel initialization is that each server must be
-   initialized in its own dedicated task - there's no way around this as far
-   as I understand. However, this creates a challenge since we also need to
-   maintain long-lived sessions and handle cleanup properly.
-
    The key insight is to keep the initialization tasks alive throughout the
    session lifetime, rather than letting them complete after initialization.
 
@@ -156,7 +157,7 @@ Any comments pointing out something I am missing would be greatly appreciated!
 
 3. Task Lifecycle:
 
-   To allow the initialization task to stay alive waiting for cleanup:
+   The following illustrates how to implement the above-mentioned strategy:
    ```
    [Task starts]
      ↓

{langchain_mcp_tools-0.0.13 → langchain_mcp_tools-0.0.15}/langchain_mcp_tools.egg-info/SOURCES.txt

@@ -1,12 +1,13 @@
 LICENSE
 README.md
 pyproject.toml
-langchain_mcp_tools/__init__.py
-langchain_mcp_tools/langchain_mcp_tools.py
-langchain_mcp_tools/py.typed
 langchain_mcp_tools.egg-info/PKG-INFO
 langchain_mcp_tools.egg-info/SOURCES.txt
 langchain_mcp_tools.egg-info/dependency_links.txt
 langchain_mcp_tools.egg-info/requires.txt
 langchain_mcp_tools.egg-info/top_level.txt
-tests/test_langchain_mcp_tools.py
+src/langchain_mcp_tools/__init__.py
+src/langchain_mcp_tools/langchain_mcp_tools.py
+src/langchain_mcp_tools/py.typed
+src/tests/__init__.py
+src/tests/test_langchain_mcp_tools.py

langchain_mcp_tools-0.0.15/langchain_mcp_tools.egg-info/top_level.txt

@@ -0,0 +1,3 @@
+build
+dist
+src

{langchain_mcp_tools-0.0.13 → langchain_mcp_tools-0.0.15}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "langchain-mcp-tools"
-version = "0.0.13"
+version = "0.0.15"
 description = "Model Context Protocol (MCP) To LangChain Tools Conversion Utility"
 readme = "README.md"
 requires-python = ">=3.11"

{langchain_mcp_tools-0.0.13 → langchain_mcp_tools-0.0.15/src}/langchain_mcp_tools/langchain_mcp_tools.py

@@ -37,21 +37,23 @@ require context managers while enabling parallel initialization.
 The key aspects are:
 
 1. Core Challenge:
-   - Async resources management for `stdio_client` and `ClientSession` seems
+
+   A key requirement for parallel initialization is that each server must be
+   initialized in its own dedicated task - there's no way around this as far as
+   I know. However, this poses a challenge when combined with
+   `asynccontextmanager`.
+
+   - Resources management for `stdio_client` and `ClientSession` seems
      to require relying exclusively on `asynccontextmanager` for cleanup,
      with no manual cleanup options
      (based on [the mcp python-sdk impl as of Jan 14, 2025](https://github.com/modelcontextprotocol/python-sdk/tree/99727a9/src/mcp/client))
    - Initializing multiple MCP servers in parallel requires a dedicated
      `asyncio.Task` per server
-   - Necessity of keeping sessions alive for later use by different tasks
+   - Need to keep sessions alive for later use by different tasks
      after initialization
-   - Ensuring proper cleanup later in the same task that created them
+   - Need to ensure proper cleanup later in the same task that created them
 
 2. Solution Strategy:
-   A key requirement for parallel initialization is that each server must be
-   initialized in its own dedicated task - there's no way around this as far
-   as I understand. However, this creates a challenge since we also need to
-   maintain long-lived sessions and handle cleanup properly.
 
    The key insight is to keep the initialization tasks alive throughout the
    session lifetime, rather than letting them complete after initialization.
@@ -73,7 +75,7 @@ The key aspects are:
 
 3. Task Lifecycle:
 
-   To allow the initialization task to stay alive waiting for cleanup:
+   The following illustrates how to implement the above-mentioned strategy:
    ```
    [Task starts]
      ↓

langchain_mcp_tools-0.0.15/src/tests/__init__.py

@@ -0,0 +1,2 @@
+
+# Test package initialization

langchain_mcp_tools-0.0.13/langchain_mcp_tools.egg-info/top_level.txt

@@ -1,3 +0,0 @@
-build
-dist
-langchain_mcp_tools