Multi-Database Configuration Support

[noxymon-mekari]

Problem

The current @executeautomation/database-server only supports a single database connection per MCP server instance. Each startup requires explicit CLI flags (--sqlite, --sqlserver, --postgresql, or --mysql) for exactly one database.

This creates significant operational pain in real-world environments:

• Microservice architectures — Companies with multiple services each backed by their own database must spin up N separate MCP server instances just to give an LLM access to all of them. A team with 5 microservices needs 5 running server processes, 5
  MCP client configurations, and 5 sets of connection management overhead.
• Kubernetes / containerized deployments — The CLI-flag-only configuration model doesn't fit well with container orchestration. There's no way to pass a structured config via environment variables or mounted config files, which are the standard
  patterns for injecting configuration into pods. Operators are forced into workaround entrypoint scripts to translate environment variables into CLI flags.
• Mixed database environments — Many organizations use different database engines for different purposes (e.g., PostgreSQL for transactional data, SQLite for local caches, SQL Server for legacy systems). The single-connection model forces users to
  choose which database the LLM can access, or manage multiple disconnected server instances.
• Configuration as code — The CLI-only approach makes it difficult to version-control and review database connection configurations. There's no declarative config file format that can be checked into a repo, reviewed in a PR, or templated with
  Helm/Kustomize.

Proposed Solution

1. Multi-database config file (--config ) — A single JSON configuration file that declares multiple named database connections, loaded and validated at startup. The server initializes all connections in parallel and continues operating even if
   some connections fail (partial failure tolerance).
2. Kubernetes-friendly config ingestion — Support --config '' (auto-detected when the value starts with {) and --config-env <VAR_NAME> (reads config JSON from an environment variable). This covers the two most common patterns for
   injecting config into Kubernetes pods: ConfigMaps/Secrets mounted as env vars, and inline container args.
3. Per-tool database routing — All existing tools (read_query, write_query, create_table, list_tables, describe_table, export_query) gain an optional database parameter to target a specific named connection. A new list_databases tool enumerates all
   configured connections and their types.
4. Full backward compatibility — The existing single-database CLI flags (--sqlite, --postgresql, etc.) continue to work exactly as before. The multi-database mode is purely additive.

Example Configuration

  {
    "databases": [
      {
        "name": "users-db",
        "type": "postgresql",
        "host": "pg-users.internal",
        "port": 5432,
        "database": "users",
        "user": "readonly",
        "password": "***"
      },
      {
        "name": "orders-db",
        "type": "mysql",
        "host": "mysql-orders.internal",
        "database": "orders",
        "user": "readonly",
        "password": "***"
      },
      {
        "name": "local-cache",
        "type": "sqlite",
        "path": "/data/cache.db"
      }
    ]
  }

Why This Is Urgent

Without this, adopting database-server in any non-trivial production environment requires maintaining a fleet of single-purpose MCP server instances — one per database. This multiplies infrastructure cost, configuration complexity, and failure
surface area linearly with the number of databases. For teams evaluating MCP-based tooling for LLM agents, this is a blocker for adoption beyond toy/demo use cases.