Database MCP

Problem

Database tooling often treats “connected” as success, but real work usually starts from unclear schema, unknown column types, and write statements without a safe preview. database-mcp addresses this by exposing a bounded set of MCP tools: connection testing, table listing, schema inspection, read-only queries, and controlled writes, aimed at engineers who need to inspect and maintain data from an MCP client.

How It Works

It provides five tools: connect_db, list_tables, describe_table, query, and execute. A practical workflow is connect → explore → query → confirm write. First, use connect_db to validate host, port, credentials, and database name. Then use list_tables and describe_table to learn table names, fields, types, and constraints. Use query to preview effects before calling execute for writes.
Risk-based execution is the key control. Low-risk statements such as SELECT, SHOW, and DESCRIBE can run directly. Medium-risk statements such as INSERT, UPDATE, DELETE, and RENAME require explicit confirm: true. High-risk statements such as DROP, TRUNCATE, and ALTER should be treated as destructive. Configuration is driven by environment variables such as DB_TYPE, DB_HOST, DB_PORT, DB_USER, DB_PASSWORD, and DB_NAME, with support for MySQL, MariaDB, TiDB, PostgreSQL, SQLite, Oracle, and SQL Server. Queries should be parameterized and select only needed columns.

Boundaries

This skill is useful for local debugging, database inspection, small maintenance tasks, and MCP client integration. In production, prefer backup first, preview impact, and execute only after review. Deletions should include explicit WHERE conditions. If connection fails, check network, port, authentication, and database name. If a table is missing, verify it with list_tables. If parameterization fails, check parameter types against column types. Blocked writes are usually a safety mechanism, not a bug.