Documentation  ·  MariaDB

Connecting to MariaDB

The connection is configuration, not something anyone types into a form. As on Oracle, the Design pages have no connect form: host, port, database, login and the databases to list all come from the environment, and everything except the password is shown in the console so an operator can check what they are pointed at.

docker run -d --name mcpdbwizard-mariadb \
  -p 8080:8080 \
  -v mcpdbwizard-data:/data \
  -e MCPDBWIZARD_DB_HOST=db.example.com \
  -e MCPDBWIZARD_DB_PORT=3306 \
  -e MCPDBWIZARD_DB_NAME=shop \
  -e MCPDBWIZARD_DB_USER=mcp_agent \
  -e DB_PASS_FILE=/run/secrets/db \
  ghcr.io/srmadscience/mcpdbwizard-mariadb:2.0.36

The image already says it is for MariaDB (MCPDBWIZARD_DB_PRODUCT=MARIADB), so a deployment never sets that itself. Each required setting that is missing gets its own warning in docker logs at start-up.

Which databases are listed

The Design pages list the objects in the database named by MCPDBWIZARD_DB_NAME, plus every database matching MCPDBWIZARD_DB_OTHER_USER:

MCPDBWIZARD_DB_OTHER_USER=reporting       ->  the reporting database
MCPDBWIZARD_DB_OTHER_USER='shop%'         ->  shop_archive, shop_eu, ...

The login’s name does not matter here. On MariaDB an object belongs to its database, not to a user, so a login called mcp_agent connecting to shop lists shop’s objects. The system databases (mysql, information_schema, performance_schema, sys) are never listed. The strip along the top of every Design tab says which databases you are getting.

Names are case-sensitive on a Linux server unless it runs with lower_case_table_names=1, so Shop in a setting does not match a database created as shop. Nothing is upper-cased.

The login the agent uses

Every caller shares one login, and that login’s grants are the outer limit of what any generated server can do, whatever the config selects. Give it a login of its own with only what the selected objects need, rather than an administrator:

create user 'mcp_agent'@'%' identified by 'change-me';

-- needed to describe routines: see below
grant show create routine on shop.* to 'mcp_agent'@'%';

-- tables and views the config exposes, with only the operations it exposes
grant select on shop.orders to 'mcp_agent'@'%';
grant select, insert, update on shop.order_lines to 'mcp_agent'@'%';

-- procedures and functions it calls
grant execute on procedure shop.book_order to 'mcp_agent'@'%';
grant execute on function shop.order_total to 'mcp_agent'@'%';

-- a package's members: the grant is on the package BODY
grant execute on package body shop.pricing to 'mcp_agent'@'%';

-- sequences it exposes as nextval tools: NEXTVAL needs both SELECT and INSERT
grant select, insert on shop.order_seq to 'mcp_agent'@'%';

Calling a package member needs EXECUTE on the PACKAGE BODY. A grant on the PACKAGE alone is refused when the member is called (error 1370). Granting select, execute, show create routine on shop.* covers a whole database at once, package bodies included, if that is the scope you intend; a sequence still needs INSERT on top of it.

SHOW CREATE ROUTINE is the grant that is easy to miss (it exists from MariaDB 11.3). MariaDB records a ROW parameter’s fields, a package’s members, whether a function is an aggregate and (on 11.8) a parameter’s default only in the routine’s source, and a login without this grant cannot read the source of a routine it did not create. Without it, a routine with a ROW parameter is left out by name when the server is generated, a package’s members cannot be found, and every other routine is generated with a warning naming the grant.

A MariaDB routine runs with its definer’s rights by default (SQL SECURITY DEFINER). That is how to let the agent change data through a procedure without granting it the tables, and also why EXECUTE on a routine written by an administrator is a broad grant. Read what it does before granting it.

The host part of the login ('mcp_agent'@'%', or the container’s address) must match where the container connects from.

The password is the one secret

Supply it as DB_PASS, or better as DB_PASS_FILE pointing at a Docker or Kubernetes secret, which stays out of docker inspect and can be rotated by replacing the file. Set exactly one: setting both is an error, because two sources for one secret hide which credential is in use. A trailing newline is stripped; a trailing space is not.

A saved config never contains the password. It records a placeholder that is filled from the environment when the server starts.

When it cannot connect

The console becomes a single MariaDB unavailable page naming the reason, what it is pointed at, and whether reloading will help: a missing setting is read once at start-up and needs a restart, while a database that is down is retried on every page load.

Servers that were already running are not affected. Each holds its own connection pool and keeps answering agents.