langchain-mcp-tools 0.1.1__tar.gz → 0.1.2__tar.gz

{langchain_mcp_tools-0.1.1/src/langchain_mcp_tools.egg-info → langchain_mcp_tools-0.1.2}/PKG-INFO

@@ -1,9 +1,10 @@
 Metadata-Version: 2.2
 Name: langchain-mcp-tools
-Version: 0.1.1
+Version: 0.1.2
 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
+Keywords: modelcontextprotocol,mcp,mcp-client,langchain,langchain-python,tool-call,tool-calling,python
 Requires-Python: >=3.11
 Description-Content-Type: text/markdown
 License-File: LICENSE
@@ -102,80 +103,3 @@ A more realistic usage example can be found
 ## Limitations
 
 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, including successful final resource cleanup...
-
-I'm new to Python, so it is very possible that my ignorance is playing
-a big role here...  
-I'll summarize the difficulties I faced below.
-The source code is available
-[here](https://github.com/hideya/langchain-mcp-tools-py/blob/main/src/langchain_mcp_tools/langchain_mcp_tools.py).  
-Any comments pointing out something I am missing would be greatly appreciated!
-[(comment here)](https://github.com/hideya/langchain-mcp-tools-ts/issues)
-
-1. Challenge:
-
-   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
-   - Server cleanup can be initiated later by a task other than the one
-     that initialized the resources, whereas `AsyncExitStack.aclose()` must be
-     called from the same task that created the context
-
-2. Solution:
-
-   The key insight is to keep the initialization tasks alive throughout the
-   session lifetime, rather than letting them complete after initialization.
-
-   By using `asyncio.Event`s for coordination, we can:
-   - Allow parallel initialization while maintaining proper context management
-   - Keep each initialization task running until explicit cleanup is requested
-   - Ensure cleanup occurs in the same task that created the resources
-   - Provide a clean interface for the caller to manage the lifecycle
-
-   Alternative Considered:
-   A generator/coroutine approach using `finally` block for cleanup was
-   considered but rejected because:
-   - It turned out that the `finally` block in a generator/coroutine can be
-     executed by a different task than the one that ran the main body of
-     the code
-   - This breaks the requirement that `AsyncExitStack.aclose()` must be
-     called from the same task that created the context
-
-3. Task Lifecycle:
-
-   The following task lifecyle diagram illustrates how the above strategy
-   was impelemented:
-   ```
-   [Task starts]
-     ↓
-   Initialize server & convert tools
-     ↓
-   Set ready_event (signals tools are ready)
-     ↓
-   await cleanup_event.wait() (keeps task alive)
-     ↓
-   When cleanup_event is set:
-   exit_stack.aclose() (cleanup in original task)
-   ```
-This approach indeed enables parallel initialization while maintaining proper
-async resource lifecycle management through context managers.
-However, I'm afraid I'm twisting things around too much.
-It usually means I'm doing something very worng...
-
-I think it is a natural assumption that MCP SDK is designed with consideration
-for parallel server initialization.
-I'm not sure what I'm missing...
-(FYI, with the TypeScript MCP SDK, parallel initialization was
-[pretty straightforward](https://github.com/hideya/langchain-mcp-tools-ts/blob/main/src/langchain-mcp-tools.ts))

langchain_mcp_tools-0.1.2/README.md

@@ -0,0 +1,81 @@
+# MCP To LangChain Tools Conversion Utility [![License: MIT](https://img.shields.io/badge/License-MIT-blue.svg)](https://github.com/hideya/langchain-mcp-tools-py/blob/main/LICENSE) [![pypi version](https://img.shields.io/pypi/v/langchain-mcp-tools.svg)](https://pypi.org/project/langchain-mcp-tools/)
+
+This package is intended to simplify the use of
+[Model Context Protocol (MCP)](https://modelcontextprotocol.io/)
+server tools with LangChain / Python.
+
+It contains a utility function `convert_mcp_to_langchain_tools()`.  
+This async function handles parallel initialization of specified multiple MCP servers
+and converts their available tools into a list of LangChain-compatible tools.
+
+A typescript equivalent of this utility library is available
+[here](https://www.npmjs.com/package/@h1deya/langchain-mcp-tools)
+
+## Requirements
+
+- Python 3.11+
+
+## Installation
+
+```bash
+pip install langchain-mcp-tools
+```
+
+## Quick Start
+
+`convert_mcp_to_langchain_tools()` utility function accepts MCP server configurations
+that follow the same structure as
+[Claude for Desktop](https://modelcontextprotocol.io/quickstart/user),
+but only the contents of the `mcpServers` property,
+and is expressed as a `dict`, e.g.:
+
+```python
+mcp_configs = {
+    'filesystem': {
+        'command': 'npx',
+        'args': ['-y', '@modelcontextprotocol/server-filesystem', '.']
+    },
+    'fetch': {
+        'command': 'uvx',
+        'args': ['mcp-server-fetch']
+    }
+}
+
+tools, cleanup = await convert_mcp_to_langchain_tools(
+    mcp_configs
+)
+```
+
+This utility function initializes all specified MCP servers in parallel,
+and returns LangChain Tools
+([`tools: List[BaseTool]`](https://python.langchain.com/api_reference/core/tools/langchain_core.tools.base.BaseTool.html#langchain_core.tools.base.BaseTool))
+by gathering available MCP tools from the servers,
+and by wrapping them into LangChain tools.
+It also returns an async callback function (`cleanup: McpServerCleanupFn`)
+to be invoked to close all MCP server sessions when finished.
+
+The returned tools can be used with LangChain, e.g.:
+
+```python
+# from langchain.chat_models import init_chat_model
+llm = init_chat_model(
+    model='claude-3-5-haiku-latest',
+    model_provider='anthropic'
+)
+
+# from langgraph.prebuilt import create_react_agent
+agent = create_react_agent(
+    llm,
+    tools
+)
+```
+A simple and experimentable usage example can be found
+[here](https://github.com/hideya/langchain-mcp-tools-py-usage/blob/main/src/example.py)
+
+A more realistic usage example can be found
+[here](https://github.com/hideya/mcp-client-langchain-py)
+
+
+## Limitations
+
+Currently, only text results of tool calls are supported.

{langchain_mcp_tools-0.1.1 → langchain_mcp_tools-0.1.2}/pyproject.toml

@@ -1,7 +1,17 @@
 [project]
 name = "langchain-mcp-tools"
-version = "0.1.1"
+version = "0.1.2"
 description = "Model Context Protocol (MCP) To LangChain Tools Conversion Utility"
+keywords = [
+    "modelcontextprotocol",
+    "mcp",
+    "mcp-client",
+    "langchain",
+    "langchain-python",
+    "tool-call",
+    "tool-calling",
+    "python",
+]
 readme = "README.md"
 requires-python = ">=3.11"
 dependencies = [

{langchain_mcp_tools-0.1.1 → langchain_mcp_tools-0.1.2}/src/langchain_mcp_tools/langchain_mcp_tools.py

@@ -1,5 +1,8 @@
 # Standard library imports
-import asyncio
+from anyio.streams.memory import (
+    MemoryObjectReceiveStream,
+    MemoryObjectSendStream,
+)
 import logging
 import os
 import sys
@@ -13,6 +16,7 @@ from typing import (
     NoReturn,
     Tuple,
     Type,
+    TypeAlias,
 )
 
 # Third-party imports
@@ -21,6 +25,7 @@ try:
     from langchain_core.tools import BaseTool, ToolException
     from mcp import ClientSession, StdioServerParameters
     from mcp.client.stdio import stdio_client
+    import mcp.types as mcp_types
     from pydantic import BaseModel
     from pympler import asizeof
 except ImportError as e:
@@ -29,111 +34,34 @@ except ImportError as e:
     sys.exit(1)
 
 
-"""
-Resource Management Pattern for Parallel Server Initialization
---------------------------------------------------------------
-This code implements a specific pattern for managing async resources that
-require context managers while enabling parallel initialization.
-The key aspects are:
-
-1. Challenge:
-
-   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)
-   - Initializing multiple MCP servers in parallel requires a dedicated
-     `asyncio.Task` per server
-   - Server cleanup can be initiated later by a task other than the one that
-     initialized the resources, whereas `AsyncExitStack.aclose()` must be
-     called from the same task that created the context
-
-2. Solution:
-
-   The key insight is to keep the initialization tasks alive throughout the
-   session lifetime, rather than letting them complete after initialization.
-
-   By using `asyncio.Event`s for coordination, we can:
-   - Allow parallel initialization while maintaining proper context management
-   - Keep each initialization task running until explicit cleanup is requested
-   - Ensure cleanup occurs in the same task that created the resources
-   - Provide a clean interface for the caller to manage the lifecycle
-
-   Alternative Considered:
-   A generator/coroutine approach using `finally` block for cleanup was
-   considered but rejected because:
-   - It turned out that the `finally` block in a generator/coroutine can be
-     executed by a different task than the one that ran the main body of
-     the code
-   - This breaks the requirement that `AsyncExitStack.aclose()` must be
-     called from the same task that created the context
-
-3. Task Lifecycle:
-
-   The following task lifecyle diagram illustrates how the above strategy
-   was impelemented:
-   ```
-   [Task starts]
-     ↓
-   Initialize server & convert tools
-     ↓
-   Set ready_event (signals tools are ready)
-     ↓
-   await cleanup_event.wait() (keeps task alive)
-     ↓
-   When cleanup_event is set:
-   exit_stack.aclose() (cleanup in original task)
-   ```
-This approach indeed enables parallel initialization while maintaining proper
-async resource lifecycle management through context managers.
-However, I'm afraid I'm twisting things around too much.
-It usually means I'm doing something very worng...
-
-I think it is a natural assumption that MCP SDK is designed with consideration
-for parallel server initialization.
-I'm not sure what I'm missing...
-(FYI, with the TypeScript MCP SDK, parallel initialization was
-pretty straightforward.
-"""
-
-
-async def spawn_mcp_server_tools_task(
+# Type alias for the bidirectional communication channels with the MCP server
+# FIXME: not defined in mcp.types, really?
+StdioTransport: TypeAlias = tuple[
+    MemoryObjectReceiveStream[mcp_types.JSONRPCMessage | Exception],
+    MemoryObjectSendStream[mcp_types.JSONRPCMessage]
+]
+
+
+async def spawn_mcp_server_and_get_transport(
     server_name: str,
     server_config: Dict[str, Any],
-    langchain_tools: List[BaseTool],
-    ready_event: asyncio.Event,
-    cleanup_event: asyncio.Event,
+    exit_stack: AsyncExitStack,
     logger: logging.Logger = logging.getLogger(__name__)
-) -> None:
-    """Convert MCP server tools to LangChain compatible tools
-    and manage lifecycle.
-
-    This task initializes an MCP server connection, converts its tools
-    to LangChain format, and manages the connection lifecycle.
-    It adds the tools to the provided langchain_tools list and uses events
-    for synchronization.
+) -> StdioTransport:
+    """
+    Spawns an MCP server process and establishes communication channels.
 
     Args:
-        server_name: Name of the MCP server
-        server_config: Server configuration dictionary containing command,
-            args, and env
-        langchain_tools: List to which the converted LangChain tools will
-            be appended
-        ready_event: Event to signal when tools are ready for use
-        cleanup_event: Event to trigger cleanup and connection closure
-        logger: Logger instance to use for logging events and errors.
-               Defaults to module logger.
+        server_name: Server instance name to use for better logging
+        server_config: Configuration dictionary for server setup
+        exit_stack: Context manager for cleanup handling
+        logger: Logger instance for debugging and monitoring
 
     Returns:
-        None
+        A tuple of receive and send streams for server communication
 
     Raises:
-        Exception: If there's an error in server connection or tool conversion
+        Exception: If server spawning fails
     """
     try:
         logger.info(f'MCP server "{server_name}": initializing with:',
@@ -146,29 +74,59 @@ async def spawn_mcp_server_tools_task(
         if 'PATH' not in env:
             env['PATH'] = os.environ.get('PATH', '')
 
+        # Create server parameters with command, arguments and environment
         server_params = StdioServerParameters(
             command=server_config['command'],
             args=server_config.get('args', []),
             env=env
         )
 
+        # Initialize stdio client and register it with exit stack for cleanup
+        stdio_transport = await exit_stack.enter_async_context(
+            stdio_client(server_params)
+        )
+    except Exception as e:
+        logger.error(f'Error spawning MCP server: {str(e)}')
+        raise
+
+    return stdio_transport
+
+
+async def get_mcp_server_tools(
+    server_name: str,
+    stdio_transport: StdioTransport,
+    exit_stack: AsyncExitStack,
+    logger: logging.Logger = logging.getLogger(__name__)
+) -> List[BaseTool]:
+    """
+    Retrieves and converts MCP server tools to LangChain format.
+
+    Args:
+        server_name: Server instance name to use for better logging
+        stdio_transport: Communication channels tuple
+        exit_stack: Context manager for cleanup handling
+        logger: Logger instance for debugging and monitoring
+
+    Returns:
+        List of LangChain tools converted from MCP tools
+
+    Raises:
+        Exception: If tool conversion fails
+    """
+    try:
+        read, write = stdio_transport
+
         # Use an intermediate `asynccontextmanager` to log the cleanup message
         @asynccontextmanager
         async def log_before_aexit(context_manager, message):
+            """Helper context manager that logs before cleanup"""
             yield await context_manager.__aenter__()
             try:
                 logger.info(message)
             finally:
                 await context_manager.__aexit__(None, None, None)
 
-        # Initialize the MCP server
-        exit_stack = AsyncExitStack()
-
-        stdio_transport = await exit_stack.enter_async_context(
-            stdio_client(server_params)
-        )
-        read, write = stdio_transport
-
+        # Initialize client session with cleanup logging
         session = await exit_stack.enter_async_context(
             log_before_aexit(
                 ClientSession(read, write),
@@ -182,11 +140,14 @@ async def spawn_mcp_server_tools_task(
         # Get MCP tools
         tools_response = await session.list_tools()
 
-        # Wrap MCP tools to into LangChain tools
+        # Wrap MCP tools into LangChain tools
+        langchain_tools: List[BaseTool] = []
         for tool in tools_response.tools:
+            # Define adapter class to convert MCP tool to LangChain format
             class McpToLangChainAdapter(BaseTool):
                 name: str = tool.name or 'NO NAME'
                 description: str = tool.description or ''
+                # Convert JSON schema to Pydantic model for argument validation
                 args_schema: Type[BaseModel] = jsonschema_to_pydantic(
                     tool.inputSchema
                 )
@@ -197,12 +158,17 @@ async def spawn_mcp_server_tools_task(
                     )
 
                 async def _arun(self, **kwargs: Any) -> Any:
+                    """
+                    Asynchronously executes the tool with given arguments.
+                    Logs input/output and handles errors.
+                    """
                     logger.info(f'MCP tool "{server_name}"/"{tool.name}"'
                                 f' received input:', kwargs)
                     result = await session.call_tool(self.name, kwargs)
                     if result.isError:
                         raise ToolException(result.content)
 
+                    # Log result size for monitoring
                     size = asizeof.asizeof(result.content)
                     logger.info(f'MCP tool "{server_name}"/"{tool.name}" '
                                 f'received result (size: {size})')
@@ -210,24 +176,19 @@ async def spawn_mcp_server_tools_task(
 
             langchain_tools.append(McpToLangChainAdapter())
 
+        # Log available tools for debugging
         logger.info(f'MCP server "{server_name}": {len(langchain_tools)} '
                     f'tool(s) available:')
         for tool in langchain_tools:
             logger.info(f'- {tool.name}')
     except Exception as e:
-        logger.error(f'Error getting response: {str(e)}')
+        logger.error(f'Error getting MCP tools: {str(e)}')
         raise
 
-    # Set ready_event; signals tools are ready
-    ready_event.set()
-
-    # Keep this task alive until cleanup is requested
-    await cleanup_event.wait()
-
-    # Cleanup the resources
-    await exit_stack.aclose()
+    return langchain_tools
 
 
+# Type hint for cleanup function
 McpServerCleanupFn = Callable[[], Awaitable[None]]
 
 
@@ -264,43 +225,46 @@ async def convert_mcp_to_langchain_tools(
         # Use tools...
         await cleanup()
     """
-    per_server_tools = []
-    ready_event_list = []
-    cleanup_event_list = []
 
-    # Concurrently initialize all the MCP servers
-    tasks = []
+    # Initialize AsyncExitStack for managing multiple server lifecycles
+    stdio_transports: List[StdioTransport] = []
+    async_exit_stack = AsyncExitStack()
+
+    # Spawn all MCP servers concurrently
     for server_name, server_config in server_configs.items():
-        server_tools_accumulator: List[BaseTool] = []
-        per_server_tools.append(server_tools_accumulator)
-        ready_event = asyncio.Event()
-        ready_event_list.append(ready_event)
-        cleanup_event = asyncio.Event()
-        cleanup_event_list.append(cleanup_event)
-        task = asyncio.create_task(spawn_mcp_server_tools_task(
+        # NOTE: the following `await` only blocks until the server subprocess
+        # is spawned, i.e. after returning from the `await`, the spawned
+        # subprocess starts its initialization independently of (so in
+        # parallel with) the Python execution of the following lines.
+        stdio_transport = await spawn_mcp_server_and_get_transport(
             server_name,
             server_config,
-            server_tools_accumulator,
-            ready_event,
-            cleanup_event,
+            async_exit_stack,
             logger
-        ))
-        tasks.append(task)
-
-    # Wait for all tasks to finish filling in the `server_tools_accumulator`
-    await asyncio.gather(*(event.wait() for event in ready_event_list))
-
-    # Flatten the tools list
-    langchain_tools = [
-        item for sublist in per_server_tools for item in sublist
-    ]
+        )
+        stdio_transports.append(stdio_transport)
+
+    # Convert tools from each server to LangChain format
+    langchain_tools: List[BaseTool] = []
+    for (server_name, server_config), stdio_transport in zip(
+        server_configs.items(),
+        stdio_transports,
+        strict=True
+    ):
+        tools = await get_mcp_server_tools(
+            server_name,
+            stdio_transport,
+            async_exit_stack,
+            logger
+        )
+        langchain_tools.extend(tools)
 
-    # Define a cleanup callback to set cleanup_event and signal that
-    # it is time to clean up the resources
+    # Define a cleanup function to properly shut down all servers
     async def mcp_cleanup() -> None:
-        for event in cleanup_event_list:
-            event.set()
+        """Closes all server connections and cleans up resources"""
+        await async_exit_stack.aclose()
 
+    # Log summary of initialized tools
     logger.info(f'MCP servers initialized: {len(langchain_tools)} tool(s) '
                 f'available in total')
     for tool in langchain_tools:

{langchain_mcp_tools-0.1.1 → langchain_mcp_tools-0.1.2/src/langchain_mcp_tools.egg-info}/PKG-INFO

@@ -1,9 +1,10 @@
 Metadata-Version: 2.2
 Name: langchain-mcp-tools
-Version: 0.1.1
+Version: 0.1.2
 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
+Keywords: modelcontextprotocol,mcp,mcp-client,langchain,langchain-python,tool-call,tool-calling,python
 Requires-Python: >=3.11
 Description-Content-Type: text/markdown
 License-File: LICENSE
@@ -102,80 +103,3 @@ A more realistic usage example can be found
 ## Limitations
 
 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, including successful final resource cleanup...
-
-I'm new to Python, so it is very possible that my ignorance is playing
-a big role here...  
-I'll summarize the difficulties I faced below.
-The source code is available
-[here](https://github.com/hideya/langchain-mcp-tools-py/blob/main/src/langchain_mcp_tools/langchain_mcp_tools.py).  
-Any comments pointing out something I am missing would be greatly appreciated!
-[(comment here)](https://github.com/hideya/langchain-mcp-tools-ts/issues)
-
-1. Challenge:
-
-   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
-   - Server cleanup can be initiated later by a task other than the one
-     that initialized the resources, whereas `AsyncExitStack.aclose()` must be
-     called from the same task that created the context
-
-2. Solution:
-
-   The key insight is to keep the initialization tasks alive throughout the
-   session lifetime, rather than letting them complete after initialization.
-
-   By using `asyncio.Event`s for coordination, we can:
-   - Allow parallel initialization while maintaining proper context management
-   - Keep each initialization task running until explicit cleanup is requested
-   - Ensure cleanup occurs in the same task that created the resources
-   - Provide a clean interface for the caller to manage the lifecycle
-
-   Alternative Considered:
-   A generator/coroutine approach using `finally` block for cleanup was
-   considered but rejected because:
-   - It turned out that the `finally` block in a generator/coroutine can be
-     executed by a different task than the one that ran the main body of
-     the code
-   - This breaks the requirement that `AsyncExitStack.aclose()` must be
-     called from the same task that created the context
-
-3. Task Lifecycle:
-
-   The following task lifecyle diagram illustrates how the above strategy
-   was impelemented:
-   ```
-   [Task starts]
-     ↓
-   Initialize server & convert tools
-     ↓
-   Set ready_event (signals tools are ready)
-     ↓
-   await cleanup_event.wait() (keeps task alive)
-     ↓
-   When cleanup_event is set:
-   exit_stack.aclose() (cleanup in original task)
-   ```
-This approach indeed enables parallel initialization while maintaining proper
-async resource lifecycle management through context managers.
-However, I'm afraid I'm twisting things around too much.
-It usually means I'm doing something very worng...
-
-I think it is a natural assumption that MCP SDK is designed with consideration
-for parallel server initialization.
-I'm not sure what I'm missing...
-(FYI, with the TypeScript MCP SDK, parallel initialization was
-[pretty straightforward](https://github.com/hideya/langchain-mcp-tools-ts/blob/main/src/langchain-mcp-tools.ts))

langchain_mcp_tools-0.1.1/README.md

@@ -1,158 +0,0 @@
-# MCP To LangChain Tools Conversion Utility [![License: MIT](https://img.shields.io/badge/License-MIT-blue.svg)](https://github.com/hideya/langchain-mcp-tools-py/blob/main/LICENSE) [![pypi version](https://img.shields.io/pypi/v/langchain-mcp-tools.svg)](https://pypi.org/project/langchain-mcp-tools/)
-
-This package is intended to simplify the use of
-[Model Context Protocol (MCP)](https://modelcontextprotocol.io/)
-server tools with LangChain / Python.
-
-It contains a utility function `convert_mcp_to_langchain_tools()`.  
-This async function handles parallel initialization of specified multiple MCP servers
-and converts their available tools into a list of LangChain-compatible tools.
-
-A typescript equivalent of this utility library is available
-[here](https://www.npmjs.com/package/@h1deya/langchain-mcp-tools)
-
-## Requirements
-
-- Python 3.11+
-
-## Installation
-
-```bash
-pip install langchain-mcp-tools
-```
-
-## Quick Start
-
-`convert_mcp_to_langchain_tools()` utility function accepts MCP server configurations
-that follow the same structure as
-[Claude for Desktop](https://modelcontextprotocol.io/quickstart/user),
-but only the contents of the `mcpServers` property,
-and is expressed as a `dict`, e.g.:
-
-```python
-mcp_configs = {
-    'filesystem': {
-        'command': 'npx',
-        'args': ['-y', '@modelcontextprotocol/server-filesystem', '.']
-    },
-    'fetch': {
-        'command': 'uvx',
-        'args': ['mcp-server-fetch']
-    }
-}
-
-tools, cleanup = await convert_mcp_to_langchain_tools(
-    mcp_configs
-)
-```
-
-This utility function initializes all specified MCP servers in parallel,
-and returns LangChain Tools
-([`tools: List[BaseTool]`](https://python.langchain.com/api_reference/core/tools/langchain_core.tools.base.BaseTool.html#langchain_core.tools.base.BaseTool))
-by gathering available MCP tools from the servers,
-and by wrapping them into LangChain tools.
-It also returns an async callback function (`cleanup: McpServerCleanupFn`)
-to be invoked to close all MCP server sessions when finished.
-
-The returned tools can be used with LangChain, e.g.:
-
-```python
-# from langchain.chat_models import init_chat_model
-llm = init_chat_model(
-    model='claude-3-5-haiku-latest',
-    model_provider='anthropic'
-)
-
-# from langgraph.prebuilt import create_react_agent
-agent = create_react_agent(
-    llm,
-    tools
-)
-```
-A simple and experimentable usage example can be found
-[here](https://github.com/hideya/langchain-mcp-tools-py-usage/blob/main/src/example.py)
-
-A more realistic usage example can be found
-[here](https://github.com/hideya/mcp-client-langchain-py)
-
-
-## Limitations
-
-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, including successful final resource cleanup...
-
-I'm new to Python, so it is very possible that my ignorance is playing
-a big role here...  
-I'll summarize the difficulties I faced below.
-The source code is available
-[here](https://github.com/hideya/langchain-mcp-tools-py/blob/main/src/langchain_mcp_tools/langchain_mcp_tools.py).  
-Any comments pointing out something I am missing would be greatly appreciated!
-[(comment here)](https://github.com/hideya/langchain-mcp-tools-ts/issues)
-
-1. Challenge:
-
-   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
-   - Server cleanup can be initiated later by a task other than the one
-     that initialized the resources, whereas `AsyncExitStack.aclose()` must be
-     called from the same task that created the context
-
-2. Solution:
-
-   The key insight is to keep the initialization tasks alive throughout the
-   session lifetime, rather than letting them complete after initialization.
-
-   By using `asyncio.Event`s for coordination, we can:
-   - Allow parallel initialization while maintaining proper context management
-   - Keep each initialization task running until explicit cleanup is requested
-   - Ensure cleanup occurs in the same task that created the resources
-   - Provide a clean interface for the caller to manage the lifecycle
-
-   Alternative Considered:
-   A generator/coroutine approach using `finally` block for cleanup was
-   considered but rejected because:
-   - It turned out that the `finally` block in a generator/coroutine can be
-     executed by a different task than the one that ran the main body of
-     the code
-   - This breaks the requirement that `AsyncExitStack.aclose()` must be
-     called from the same task that created the context
-
-3. Task Lifecycle:
-
-   The following task lifecyle diagram illustrates how the above strategy
-   was impelemented:
-   ```
-   [Task starts]
-     ↓
-   Initialize server & convert tools
-     ↓
-   Set ready_event (signals tools are ready)
-     ↓
-   await cleanup_event.wait() (keeps task alive)
-     ↓
-   When cleanup_event is set:
-   exit_stack.aclose() (cleanup in original task)
-   ```
-This approach indeed enables parallel initialization while maintaining proper
-async resource lifecycle management through context managers.
-However, I'm afraid I'm twisting things around too much.
-It usually means I'm doing something very worng...
-
-I think it is a natural assumption that MCP SDK is designed with consideration
-for parallel server initialization.
-I'm not sure what I'm missing...
-(FYI, with the TypeScript MCP SDK, parallel initialization was
-[pretty straightforward](https://github.com/hideya/langchain-mcp-tools-ts/blob/main/src/langchain-mcp-tools.ts))