Configuration

dbmcp reads its settings from DBMCP_* environment variables, optional env files, and optional YAML config files. The command line only names those files (--config-file, --env-file); there is no per-setting flag. The table below lists every setting; each key links to the page that explains it, with its type and full description. For the file formats, ${} interpolation, and path rules, see Config files.

The config file has a JSON Schema for editor completion and validation. Editors backed by the YAML language server (VS Code's YAML extension, JetBrains IDEs, Neovim, Zed) pick it up from this modeline on the first line of the file:

# yaml-language-server: $schema=https://raw.githubusercontent.com/haymon-ai/dbmcp/master/crates/config/assets/dbmcp.schema.json

The master URL tracks the latest schema; replace master with a release tag such as vX.Y.Z to match an older binary. At startup dbmcp checks the file's keys and sections against the same schema and every value by its setting's type, so every value in the file must be valid even when a DBMCP_* variable overrides it.

All settingsCopy Anchor Link

For where these values come from and which source wins, see Precedence.

Value FormatsCopy Anchor Link

The Type column in the settings tables determines how a value is written:

yes/no/on/off are not booleans and are rejected. A default of — or unset means the setting is absent until you set it.

LoggingCopy Anchor Link

Migrating from CLI flagsCopy Anchor Link

Earlier releases accepted one CLI flag per setting. Those flags are gone: passing one now fails with clap's error: unexpected argument '--db-backend' found (exit code 2). The only flags left are --config-file, --env-file, -h/--help, and -V/--version. --transport and --log-level moved too: use DBMCP_TRANSPORT / transport and DBMCP_LOG_LEVEL / log_level.

Every DBMCP_* environment variable name is unchanged, so each removed flag maps to the variable that already backed it:

Other behaviour changes to check while migrating:

• Booleans are stricter. Boolean env vars used to accept yes/no and on/off in any case. They now accept only true/false, 1/0, t/f, TRUE/FALSE, and True/False; anything else fails startup. A bare boolean flag such as --pii becomes DBMCP_PII_ENABLE=true.
• Empty values mean unset. An empty DBMCP_* value counts as unset and falls through to the next source. In particular, --allowed-origins "" used to disable Origin validation; that is now only possible with allowed_origins: [] under http in the config file.
• Lists keep the comma-separated env format; in the config file, write them as YAML sequences.

Before — settings passed as arguments in .mcp.json:

{
  "mcpServers": {
    "dbmcp": {
      "command": "dbmcp",
      "args": [
        "--db-backend", "postgres",
        "--db-host", "localhost",
        "--db-user", "postgres",
        "--db-name", "myapp",
        "--pii",
        "--log-level", "debug"
      ]
    }
  }
}

After — the same settings as environment variables:

{
  "mcpServers": {
    "dbmcp": {
      "command": "dbmcp",
      "env": {
        "DBMCP_DB_BACKEND": "postgres",
        "DBMCP_DB_HOST": "localhost",
        "DBMCP_DB_USER": "postgres",
        "DBMCP_DB_NAME": "myapp",
        "DBMCP_PII_ENABLE": "true",
        "DBMCP_LOG_LEVEL": "debug"
      }
    }
  }
}

To keep the settings in a file instead, move them into a YAML file and point at it with "args": ["--config-file", "/abs/path/dbmcp.yaml"]; see Config files.