Skip to main content
Glama
zhusinian

db-mcp

by zhusinian
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

db-mcp

一个轻量级 MCP（Model Context Protocol）数据库服务器。它通过 stdio 与 MCP 客户端通信，支持在运行时动态打开 PostgreSQL、MySQL 和 MongoDB 连接，并执行 SQL 或 MongoDB command。

特性

  • 动态连接：内置 connect 工具，可在会话中按需创建或替换 PostgreSQL / MySQL / MongoDB 连接。

  • 执行 SQL：execute_sql 工具支持位置化参数绑定，避免拼接注入。

  • 执行 MongoDB command：execute_mongodb 接收通用 command 文档或 query Extended JSON 字符串，不限制为固定 CRUD 方法。

  • 事务控制：提供 begin_transaction、commit_transaction、rollback_transaction 三个工具。

  • 关闭连接：close_connection 用于主动释放指定或当前连接。

  • 只读模式：支持 --readOnly / --readonly 启动参数。

  • 自动识别 SQL 类型：读（read）、写（write）、事务（transaction）、未知（unknown）。

  • 只读模式仅放行 read 类型，write、transaction、unknown 全部拒绝；MongoDB aggregate 中包含 $out / $merge 时按写操作处理。

Related MCP server: mcp-db-server

安装

环境要求：Node.js 20+。

npm install
npm run build

运行

默认启动（可写）：

npx db-mcp

只读模式：

npx db-mcp --readOnly

开发模式（tsx 直接执行源码）：

npm run dev -- --readOnly

在 MCP 客户端中配置

在客户端的 MCP 配置中新增一个 server 条目即可。

{
  "mcpServers": {
    "db-mcp": {
      "command": "node",
      "args": ["/absolute/path/to/db-mcp/dist/index.js", "--readOnly"]
    }
  }
}

如果不启用只读模式，去掉 --readOnly 即可。

工具列表

工具

说明

connect

创建或替换一个动态数据库连接

execute_sql

执行 SQL 语句，支持位置化参数

execute_mongodb

执行 MongoDB command 文档或 query Extended JSON 字符串

begin_transaction

开启一个事务

commit_transaction

提交当前事务

rollback_transaction

回滚当前事务

close_connection

关闭指定连接或当前连接

connectionId 参数在所有工具中都是可选的：不传时使用最近一次 connect 创建的连接。

这些工具的 MCP 描述中内置了面向客户端 AI 的使用提示。客户端 AI 会看到各工具的 description 和参数 schema description，用于决定应该生成 SQL、MongoDB command 对象，还是 Extended JSON 查询字符串。

工具详解

connect

创建一个新连接，或在 id 冲突时替换已有连接。id 不传时默认为 default。

PostgreSQL 示例（使用连接字符串）：

{
  "id": "analytics",
  "type": "postgres",
  "connectionString": "postgres://user:password@localhost:5432/app"
}

PostgreSQL 示例（使用离散字段）：

{
  "id": "app_pg",
  "type": "postgres",
  "host": "localhost",
  "port": 5432,
  "database": "app",
  "user": "app",
  "password": "secret",
  "ssl": false
}

MySQL 示例：

{
  "id": "app_mysql",
  "type": "mysql",
  "host": "localhost",
  "port": 3306,
  "database": "app",
  "user": "root",
  "password": "secret"
}

MongoDB 示例（使用连接字符串）：

{
  "id": "app_mongo",
  "type": "mongodb",
  "connectionString": "mongodb://user:password@localhost:27017/app",
  "database": "app"
}

MongoDB 示例（使用离散字段）：

{
  "id": "app_mongo",
  "type": "mongodb",
  "host": "localhost",
  "port": 27017,
  "database": "app",
  "user": "root",
  "password": "secret",
  "ssl": false
}

execute_sql

执行单条 SQL，并支持位置化参数。参数占位符与底层驱动一致：

  • PostgreSQL 使用 $1、$2 …

  • MySQL 使用 ?

内置提示会要求客户端 AI：

  • 生成普通 SQL，不生成 MongoDB 语法。

  • 使用 params 绑定参数，不把用户输入拼接进 SQL 字符串。

  • PostgreSQL 使用 $1、$2 等占位符。

  • MySQL 使用 ? 占位符。

  • 只读模式下只生成读查询。

PostgreSQL 示例：

{
  "connectionId": "analytics",
  "sql": "select id, email from users where id = $1",
  "params": [1]
}

MySQL 示例：

{
  "connectionId": "app_mysql",
  "sql": "select id, email from users where id = ?",
  "params": [1]
}

返回结构示例：

{
  "statementType": "read",
  "rows": [{ "id": 1, "email": "a@example.com" }],
  "fields": ["id", "email"],
  "rowCount": 1
}

execute_mongodb

执行 MongoDB 原生命令。command、query、commandJson 三选一：

  • command：直接传 JSON 对象。

  • query：传 Extended JSON 字符串，适合让 AI 直接生成完整 MongoDB command 查询语句。

  • commandJson：query 的兼容别名，适合 $oid、$date 等 BSON 类型。

内置提示会要求客户端 AI：

  • 使用 MongoDB command，不生成 db.users.find(...) 这类 Mongo shell JavaScript。

  • 查询字符串必须是合法 Extended JSON。

  • find 使用 {"find":"users","filter":{},"limit":10} 这类 command。

  • aggregate 使用 {"aggregate":"orders","pipeline":[...],"cursor":{}}，并包含 cursor。

  • _id、日期等 BSON 值使用 $oid、$date 等 Extended JSON。

  • 只读模式下避免写命令，且不要使用包含 $out / $merge 的聚合。

查询示例：

{
  "connectionId": "app_mongo",
  "database": "app",
  "command": {
    "find": "users",
    "filter": { "active": true },
    "limit": 10
  }
}

聚合示例：

{
  "connectionId": "app_mongo",
  "database": "app",
  "command": {
    "aggregate": "orders",
    "pipeline": [
      { "$match": { "status": "paid" } },
      { "$group": { "_id": "$userId", "total": { "$sum": "$amount" } } }
    ],
    "cursor": {}
  }
}

Extended JSON 示例：

{
  "connectionId": "app_mongo",
  "database": "app",
  "query": "{\"find\":\"users\",\"filter\":{\"_id\":{\"$oid\":\"66f000000000000000000001\"}},\"limit\":1}"
}

写入也通过同一个工具传 MongoDB command：

{
  "connectionId": "app_mongo",
  "database": "app",
  "command": {
    "insert": "users",
    "documents": [{ "email": "a@example.com", "active": true }]
  }
}

只读模式下会拒绝明确写操作和未知命令；aggregate 管道包含 $out 或 $merge 时也会被拒绝。

事务控制

begin_transaction、commit_transaction、rollback_transaction 的入参一致，仅支持 PostgreSQL / MySQL 连接：

{ "connectionId": "analytics" }

调用顺序示例：先 begin_transaction，再连续 execute_sql 执行若干写语句，最后根据结果调用 commit_transaction 或 rollback_transaction。

注意：

  • 一个连接同一时间只能存在一个事务，重复开启会报错。

  • 只读模式下，三个事务工具都会被拒绝。

  • 进程退出时会自动关闭所有连接。

close_connection

关闭指定连接；不传 connectionId 时关闭当前默认连接。

{ "connectionId": "analytics" }

SQL 类型识别

服务器会跳过空白、-- 行注释、/* ... */ 块注释以及引号/反引号包裹的字符串，再判断第一个关键字：

  • 读（read）：select、show、describe、desc、explain、values，以及不包含写关键字的 with 查询。

  • 写（write）：insert、update、delete、merge、replace、create、alter、drop、truncate、grant、revoke、call、do、copy、load、set、reset、analyze、vacuum、refresh。

  • 事务（transaction）：begin、start、commit、rollback、savepoint、release。

  • 未知（unknown）：以上均不匹配，例如以 @、变量、方言特有语法开头的语句。

补充规则：

  • with 查询中若出现写关键字（insert / update / delete / merge / replace 等），按写处理。

  • select ... for update、select ... for share、select ... into ... 等具有副作用的形态，按写处理。

  • 只读模式下仅放行 read 类型。

MongoDB command 类型识别

execute_mongodb 通过 command 文档的第一个键判断操作类型：

  • 读（read）：例如 find、aggregate、count、distinct、listCollections、listIndexes、dbStats、collStats、serverStatus、ping。

  • 写（write）：例如 insert、update、delete、findAndModify、create、drop、createIndexes、dropIndexes、renameCollection。

  • 未知（unknown）：不在内置列表中的命令。

  • aggregate 管道中包含 $out 或 $merge 时按写操作处理。

  • explain 只有包裹的命令可判定为读操作时才按读处理。

常见问题

  • 启动报错 “No database connection is open”：先调用 connect 成功建立连接再执行 SQL。

  • 执行写语句被拒绝：检查是否在只读模式下；可在 MCP 启动参数中移除 --readOnly。

  • MongoDB 命令被判定为 unknown：只读模式下未知命令会被拒绝；可改用明确的 read command，或在可写模式下执行。

  • 事务相关报错 “No transaction is open”：只有调用过 begin_transaction 后才能 commit / rollback。

  • 关闭进程后连接未释放：通常不需要关心；如果长时间持有连接，建议在每次会话结束前调用 close_connection。

开发

npm run dev      # 监听源码变更并以 tsx 执行
npm run build    # 类型检查并输出 dist
npm start        # 执行 dist/index.js

源码结构：

  • src/index.ts：MCP server 入口、工具注册、只读模式开关。

  • src/db.ts：连接管理、SQL 执行、MongoDB command 执行、事务控制。

  • src/sqlClassifier.ts：SQL 类型识别。

许可

MIT

Available Tools

7 tools
begin_transactionB

Begin a transaction for a connection.

ParametersJSON Schema
NameRequiredDescriptionDefault
connectionIdNoConnection id. Defaults to the latest connection.

TDQS

B3.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description must carry full burden. It does not disclose any behavioral traits like locking, transaction ID generation, or consequences of beginning a new transaction while one is active.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, front-loaded with action, no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one optional parameter and no output schema, the description is minimally adequate but lacks important context about transaction lifecycle (e.g., what happens on success/failure, side effects).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and parameter description is clear ('Defaults to the latest connection'). The tool description adds no additional meaning beyond the schema, meeting the baseline for high coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'begin' and resource 'transaction for a connection', clearly stating the action. It doesn't differentiate from siblings like commit_transaction, but the action is distinct enough.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. While siblings suggest a workflow (begin then commit/rollback), no explicit context is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

close_connectionB

Close one connection, or the latest connection if no id is supplied.

ParametersJSON Schema
NameRequiredDescriptionDefault
connectionIdNoConnection id. Defaults to the latest connection.

TDQS

B3.2/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It only repeats what the schema says about the default behavior, lacking details on side effects such as whether pending transactions are rolled back or resources freed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, front-loaded with key action and distinction, no unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having one simple parameter, the description omits important context about the consequences of closing a connection, such as impact on transactions or ability to reconnect. No output schema is provided, and the description does not compensate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the description reiterates the default behavior already present in the schema. No additional semantic value is added beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Close' and the resource 'connection', and distinguishes between closing a specific connection and the latest one. The sibling tool 'connect' further clarifies the opposite action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives like 'rollback_transaction' or 'connect'. The description only states what it does, not when or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

commit_transactionC

Commit the current transaction for a connection.

ParametersJSON Schema
NameRequiredDescriptionDefault
connectionIdNoConnection id. Defaults to the latest connection.

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description must disclose behavioral traits. It only states 'commit' without explaining side effects (e.g., transaction finalization, connection state changes) or error scenarios (e.g., no active transaction). This is insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no wasted words. While very brief, it is not overly verbose. However, it could be slightly expanded for clarity without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description should explain return values or confirmation. It does not. Also lacks context about error handling and preconditions. Given the simplicity of the tool, more detail is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage for the single parameter, providing its meaning and default behavior. The tool description adds no additional value beyond the schema, so baseline score applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'commit' and the resource 'current transaction'. It is specific enough to understand the tool's function. However, it does not explicitly differentiate from siblings like rollback_transaction, but the sibling names make the distinction clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives (e.g., rollback_transaction) nor prerequisites (e.g., must have an active transaction). This leaves the agent without context for decision-making.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

connectB

Open or replace a dynamic PostgreSQL/MySQL/MongoDB connection.

ParametersJSON Schema
NameRequiredDescriptionDefault
idNoOptional connection id. Defaults to 'default'.
sslNo
hostNo
portNo
typeYes
userNo
databaseNo
passwordNo
connectionStringNo

TDQS

B3.4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description only conveys the basic action and database types, lacking details on side effects like connection replacement behavior, authentication needs, or error scenarios.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single efficient sentence, but it could be slightly expanded to include more parameter guidance without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 9 parameters and no output schema or annotations, the description omits critical details on parameter interactions, connection lifecycle, and how this tool integrates with siblings like execute_sql.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is low (11%), yet the description only adds meaning for the 'type' parameter by listing the three database types, failing to explain other crucial parameters like connectionString, host, or ssl.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'open or replace' and the resource 'dynamic PostgreSQL/MySQL/MongoDB connection', distinguishing it from sibling tools like close_connection or execute_sql.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for establishing or replacing connections but does not explicitly mention when not to use it or provide alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

execute_mongodbA

Execute a MongoDB command query. Use MongoDB command syntax, not Mongo shell JavaScript. Do not generate db.collection.find(...) or db.users.aggregate(...). Instead generate command JSON such as {"find":"users","filter":{"active":true},"limit":10}. For aggregate, include "cursor": {}, for example {"aggregate":"orders","pipeline":[{"$match":{"status":"paid"}}],"cursor":{}}. Use query when providing a string; it must be valid Extended JSON. Use $oid/$date Extended JSON for BSON values. In --readOnly mode, write/unknown commands are rejected, and aggregate with $out/$merge is treated as write.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryNoMongoDB command as an Extended JSON string. Prefer this when the AI is asked to provide a query string. Do not use Mongo shell JavaScript. Example: {"find":"users","filter":{"_id":{"$oid":"66f000000000000000000001"}},"limit":1}.
commandNoMongoDB command document object. Example find: { find: 'users', filter: { active: true }, limit: 10 }. Example aggregate: { aggregate: 'orders', pipeline: [{ $match: { status: 'paid' } }], cursor: {} }.
databaseNoDatabase name. Defaults to the database from connect, or MongoDB driver's default.
commandJsonNoAlias of query for Extended JSON command strings. Prefer query for new calls.
connectionIdNoConnection id. Defaults to the latest connection.

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description covers behavioral traits: readOnly mode rejects writes, aggregate with $out/$merge treated as write, and requires Extended JSON. Missing details about return value or errors but sufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise, front-loaded with purpose, every sentence adds value, examples are clear, no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given complexity and no output schema, description covers usage well. Could add output format or error behavior, but overall complete enough for agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% so baseline 3, but description adds meaning: explains difference between query and commandJson, gives examples for command object, and notes defaults for database and connectionId.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it executes a MongoDB command query, distinguishes from sibling tools like execute_sql by specifying MongoDB syntax, and contrasts with transaction tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit guidelines: use MongoDB command syntax not Mongo shell JS, gives examples, warns about readOnly mode restrictions, and implies when to use this vs other tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

execute_sqlA

Execute one PostgreSQL or MySQL SQL statement with optional positional parameters. Generate normal SQL, not MongoDB syntax. Use params instead of interpolating values into sql. For PostgreSQL placeholders use $1, $2, ...; for MySQL placeholders use ?. In --readOnly mode, write/transaction/unknown SQL is rejected.

ParametersJSON Schema
NameRequiredDescriptionDefault
sqlYesSingle SQL statement for PostgreSQL or MySQL. PostgreSQL uses $1, $2 placeholders; MySQL uses ? placeholders.
paramsNoValues for positional placeholders. Use this instead of string-concatenating user values into SQL.
connectionIdNoConnection id. Defaults to the latest connection.

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It discloses readOnly mode restriction and database support, but does not describe return format (e.g., result set or affected rows) or error behavior. This gap lowers transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, each with distinct information: statement execution, SQL dialect, param usage, and readOnly behavior. No redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description covers execution behavior, database support, param guidance, and readOnly mode. Missing return value specification, but overall adequate for a SQL tool with moderate complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, baseline 3. The description adds value by detailing placeholder syntax for PostgreSQL and MySQL and emphasizing use of params over interpolation, which aids correct parameter usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it executes one SQL statement for PostgreSQL or MySQL, and explicitly contrasts with MongoDB syntax. The verb 'execute' and resource 'SQL' are specific, and it distinguishes from sibling execute_mongodb.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides guidance on using params instead of interpolation, explains placeholder syntax per database, and notes that write/transaction SQL is rejected in --readOnly mode. Doesn't explicitly compare to transaction or connection tools but gives sufficient context for correct usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

rollback_transactionB

Rollback the current transaction for a connection.

ParametersJSON Schema
NameRequiredDescriptionDefault
connectionIdNoConnection id. Defaults to the latest connection.

TDQS

B3.2/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description should carry full behavioral disclosure. It only states the action, omitting side effects, error handling, or post-rollback state of the connection.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence with no wasted words. However, it could be slightly expanded without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is adequate for a simple tool with one optional parameter and no output schema, but it lacks context about the transaction lifecycle and what happens upon rollback.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so parameters are documented. The description does not add any extra meaning beyond the schema's parameter description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the action (rollback) and resource (current transaction for a connection). It distinguishes from sibling tools like commit_transaction and begin_transaction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use rollback vs alternatives such as commit_transaction. Does not specify prerequisites like needing an active transaction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 7 tool updatesv0.1.0
    • First observedbegin_transaction
    • First observedclose_connection
    • First observedcommit_transaction
    • First observedconnect
    • First observedexecute_mongodb
    • First observedexecute_sql
    • First observedrollback_transaction
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0
Disambiguation5/5

Each tool targets a distinct operation: connection management, SQL execution, MongoDB execution, and transaction control. No overlapping functionality.

Naming Consistency5/5

All tool names use snake_case with a consistent verb_noun pattern (e.g., begin_transaction, execute_sql). No mixing of conventions.

Tool Count5/5

Seven tools is well-scoped for a database server covering connections, transactions, and query execution for two database types. No extraneous tools.

Completeness4/5

Covers connection lifecycle, transaction lifecycle, and query execution for both SQL and MongoDB. Minor gaps like listing connections or switching databases, but core workflows are complete.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • mcp-db-server

    Souhar-dya
    F
    license
    Not graded
    quality
    B
    maintenance
    An MCP server that exposes relational databases (PostgreSQL/MySQL) to AI agents with natural language to SQL query support.
    19
    -

  • mcp-database

    justpoypoy
    A
    license
    Not graded
    quality
    D
    maintenance
    MCP server for connecting to databases (PostgreSQL, MySQL, SQL Server, Redis) enabling SQL queries, table exploration, and Redis key-value operations.
    1
    MIT

  • Universal Database MCP Server

    xiaoshi7915
    F
    license
    Not graded
    quality
    D
    maintenance
    A versatile MCP server that connects to multiple relational databases (MySQL, PostgreSQL, Oracle, SQL Server, SQLite) and enables secure read-only SQL query execution and metadata access.
    4
    -

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/zhusinian/db-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server