DB MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DB_URL | Yes | The connection URL for the database (e.g., postgresql+psycopg://user:pass@localhost:5432/dbname). | |
| DB_ENGINE | Yes | The database engine to use (e.g., postgresql, mysql, mariadb, oracle, sqlserver, sqlite, mongodb, redis, elasticsearch). | |
| DB_ALLOW_WRITE | No | Set to 'true' to allow write operations. If not set or set to 'false', the session is read-only. | false |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| db_connectC | Connect a named session. engine is postgresql, mysql, mariadb, sqlite, oracle, sqlserver, mongodb, redis, or elasticsearch. |
| db_disconnectC | Disconnect a database session. |
| db_statusA | List active database sessions and supported engines. |
| db_list_tablesA | List tables in a SQL schema. Oracle schema is the owner. Postgres schema is usually public. |
| db_describe_tableB | Describe columns of a SQL table. |
| db_queryA | Run a read statement. Use :name binds in params_json. Results are capped by limit (max 500). |
| db_executeB | Run a write statement. DROP, TRUNCATE, and ALTER require confirm=true. |
| db_insertC | Insert one row. values_json is a JSON object of column to value. |
| db_updateC | Update rows. where_sql is required, for example id = :id. |
| db_deleteB | Delete rows matching where_sql. confirm=true is required. |
| mongo_list_databasesB | List MongoDB database names. |
| mongo_list_collectionsC | List collections in a MongoDB database. |
| mongo_findD | Find MongoDB documents. |
| mongo_insertC | Insert one MongoDB document. |
| mongo_updateC | Update MongoDB documents. update_json should include operators such as $set. Empty filters are refused. |
| mongo_deleteB | Delete MongoDB documents matching a non-empty filter. confirm=true is required. |
| redis_getC | GET a Redis key. |
| redis_setC | SET a Redis key. |
| redis_deleteC | DEL a Redis key. |
| redis_keysC | List Redis keys matching a pattern, capped at 200. |
| es_searchC | Search an Elasticsearch index. |
| es_index_documentB | Index one Elasticsearch document. Omit doc_id to let Elasticsearch assign one. |
| es_delete_documentA | Delete one Elasticsearch document. confirm=true is required. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 23 tools
Every tool is namespaced by engine (db_, mongo_, redis_, es_) and action, making read, write, and administrative operations easy to separate. Even db_execute vs db_insert/update/delete is clear because execute is for arbitrary SQL statements while the specialized tools target row-level operations.
Tool names follow a mostly consistent <engine>_<operation> pattern, with clear prefixes like db_, mongo_, redis_, and es_. Minor inconsistency exists between verb-only names like db_query, db_execute, and mongo_find versus verb-noun names like db_list_tables and mongo_list_databases.
23 tools is slightly above the typical sweet spot, but the server covers four different database engines, so the breadth is justified. Each tool represents a distinct operation and none feel redundant or purely decorative.
SQL, MongoDB, and Redis have solid CRUD and inspection coverage, and Elasticsearch covers search, indexing, and deletion. Minor gaps exist, such as no ES update/get-by-id, no explicit transaction control, and no SQL database listing, but agents can often work around these with db_execute or search queries.