UOM Orchestrator: MCP Database Toolbox & Schema Inspection
To ensure accurate database translations, the orchestrator must inspect the schemas of the source and target databases. The UOM Orchestrator achieves this by integrating with the Model Context Protocol (MCP), loading schema inspection tools from running MCP servers dynamically.1. The Role of MCP in Database Schema Inspection
During the initial phase of the translation workflow, theschema_inspection node uses an LLM equipped with database tools. This node executes inspection queries against:
- Microsoft SQL Server (Source): Retrieving table schemas, column types, primary keys, and foreign key relationships.
- Neo4j (Target): Inspecting node labels, relationship types, and properties.
- MongoDB (Target): Examining document structures, collection lists, and validators.
- Generic Database Toolbox: Exposes tools for executing Cypher statements, viewing relational tables, and extracting metadata.
- MongoDB MCP Server: Exposes collection-level management and query execution tools.
2. Dynamic Configuration Synchronization (modify_toolbox_sources)
The Database Toolbox MCP server runs as a separate service (often inside its own Docker container). When the orchestrator context loads, connection strings (like localhost:1333 for SQL Server) are read from environment variables.
2.1 The Localhost Resolution Problem
If the Database Toolbox container attempts to connect tolocalhost:1333, it resolves to itself (the toolbox container), rather than the host machine or Daytona workspace databases, causing immediate connection failures.
2.2 Host Gateway Translation
To prevent this, the custom tool manager (mcp_database.py) uses translate_localhost_to_host_gateway to replace localhost or 127.0.0.1 with the Docker host gateway IP:
- Default Gateway: Resolves to
host.docker.internal(or a customOUTER_HOST_GATEWAY_IPprovided by the Daytona network bridge). - MSSQL Connection Parsing:
extract_mssql_connection_infoparses the connection string using a strict regex pattern to extract connection parameters (host, port, database, user, password) needed to populate the MCP configuration:
2.3 Overwriting settings Files Dynamically
Once translated, the orchestrator writes the data source credentials directly to the Database Toolbox settings file located atconfig/db_toolbox/custom_config.yaml using asynchronous file I/O:
3. Dynamic Tool Binding
The orchestrator connects to MCP servers asynchronously and maps their tools to LangChain-compatible schemas.3.1 Loading Database Toolbox Tools (load_toolbox_tools)
- The loader connects to the server using the
ToolboxClientSSE wrapper: - The loaded tools are cast to LangChain
BaseToolobjects and returned to the schema inspection node.
3.2 Loading MongoDB Tools (load_mongodb_tools)
- To connect to the MongoDB MCP server, the loader instantiates a
MultiServerMCPClientwithtool_name_prefix=True: - Enabling
tool_name_prefix=Trueprefixes MongoDB tools withmongodb_(e.g.mongodb_list_collections), preventing naming collisions with other tools.
4. Exception Safety & Fallback Policies
Connecting to remote MCP servers introduces potential failure points:- The database engine or Database Toolbox container might be temporarily down or starting up.
- Network glitches can trigger connection timeouts.
- Dynamic schema binding can raise
BrokenResourceErrorin AnyIO sessions.
4.1 Exception Group Filtering (except*)
By using Python’s except* block, the orchestrator filters and catches exception groups (such as parallel AnyIO resource crashes) without letting them escape.
4.2 Graceful Failure Degradation
Instead of raising a fatal runtime error:- The tool loaders log a warning with the full stack trace for debugging.
- They yield an empty list (
[]) back to the schema inspection node. - The ReAct agent continues executing without access to schema tools.
- The agent falls back to performing the translation using the user’s raw inputs and its static training data.