How do I use PostgreSQL MCP Server (Read-Write)?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@PostgreSQL MCP Server (Read-Write) list all tables in the database" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

PostgreSQL MCP Server (Read-Write)

by yanxxcloud

Overview Schema Related Servers Score Discussions

JavaScript

Remote

PostgreSQL MCP Server (Read-Write)

这是一个支持 PostgreSQL 数据库增删改查和 DDL 操作的 Model Context Protocol (MCP) 服务器。

npm version npm downloads

📦 npm 包: https://www.npmjs.com/package/mcp-server-postgresql-rw
🐙 GitHub: https://github.com/yanxxcloud/mcp-server-postgresql-rw

功能特性

✅ 查询（SELECT）: 执行 SELECT 查询语句，返回查询结果
✅ 插入（INSERT）: 向表中插入新数据
✅ 更新（UPDATE）: 更新表中的数据
✅ 删除（DELETE）: 从表中删除数据
✅ DDL 操作: 执行数据定义语言操作（CREATE、ALTER、DROP 等）
✅ 通用执行: 执行任意 SQL 语句

Related MCP server: pgEdge Postgres MCP Server

快速开始

方式 1: 通过 npm 安装（⭐ 推荐）

最简单的方式，直接从 npm 安装：

npm install -g mcp-server-postgresql-rw

然后在 mcp.json 中配置：

{
  "mcpServers": {
    "postgresql-rw": {
      "command": "mcp-server-postgresql-rw",
      "env": {
        "POSTGRES_CONNECTION_STRING": "postgresql://user:password@localhost:5432/database"
      }
    }
  }
}

或者使用 npx（无需全局安装，推荐）：

{
  "mcpServers": {
    "postgresql-rw": {
      "command": "npx",
      "args": ["-y", "mcp-server-postgresql-rw"],
      "env": {
        "POSTGRES_CONNECTION_STRING": "postgresql://user:password@localhost:5432/database"
      }
    }
  }
}

方式 2: 从源码安装

如果你想从源码安装或进行开发：

# 克隆项目
git clone https://github.com/yanxxcloud/mcp-server-postgresql-rw.git
cd mcp-server-postgresql-rw

# 安装依赖
npm install

# 构建项目（可选，如果使用 npx tsx 方式则不需要）
npm run build

然后在 mcp.json 中配置（推荐使用 npx tsx 方式，无需构建）：

{
  "mcpServers": {
    "postgresql-rw": {
      "command": "npx",
      "args": [
        "-y",
        "tsx",
        "/path/to/mcp-server-postgresql-rw/src/index.ts"
      ],
      "env": {
        "POSTGRES_CONNECTION_STRING": "postgresql://user:password@localhost:5432/database"
      }
    }
  }
}

3. 重启 Cursor

配置完成后，重启 Cursor 即可使用！

💡 提示:
⭐ 推荐使用 npm 安装：最简单快捷，包已构建好，开箱即用
使用 npx 方式无需全局安装，每次自动下载最新版本
从源码安装适合需要修改代码或参与开发的场景

安装

方式 1: 通过 npm 安装（⭐ 推荐）

最简单的方式，直接从 npm 安装：

npm install -g mcp-server-postgresql-rw

或使用 npx（无需全局安装）：

npx -y mcp-server-postgresql-rw

方式 2: 从源码安装

如果你想从源码安装或进行开发：

# 克隆项目
git clone https://github.com/yanxxcloud/mcp-server-postgresql-rw.git
cd mcp-server-postgresql-rw

# 安装依赖
npm install

# 构建项目（如果使用编译后的文件）
npm run build

配置

通过环境变量配置数据库连接：

方式 1: 使用连接字符串

export POSTGRES_CONNECTION_STRING="postgresql://user:password@localhost:5432/database"

方式 2: 使用单独的参数

export POSTGRES_HOST="localhost"
export POSTGRES_PORT="5432"
export POSTGRES_DATABASE="postgres"
export POSTGRES_USER="postgres"
export POSTGRES_PASSWORD="password"
export POSTGRES_SSL="false"

使用方法

作为 MCP 服务器运行

npm start

开发模式

npm run dev

可用工具

1. query

执行 SELECT 查询语句，返回查询结果。

参数:

sql (string, 必需): SELECT SQL 查询语句

示例:

{
  "sql": "SELECT * FROM users WHERE age > 18"
}

2. insert

执行 INSERT 语句，向表中插入新数据。

参数:

sql (string, 必需): INSERT SQL 语句

示例:

{
  "sql": "INSERT INTO users (name, email) VALUES ('John', 'john@example.com')"
}

3. update

执行 UPDATE 语句，更新表中的数据。

参数:

sql (string, 必需): UPDATE SQL 语句

示例:

{
  "sql": "UPDATE users SET email = 'newemail@example.com' WHERE id = 1"
}

4. delete

执行 DELETE 语句，从表中删除数据。

参数:

sql (string, 必需): DELETE SQL 语句

示例:

{
  "sql": "DELETE FROM users WHERE id = 1"
}

5. execute_ddl

执行 DDL（数据定义语言）语句，包括 CREATE、ALTER、DROP 等操作。

参数:

sql (string, 必需): DDL SQL 语句

示例:

{
  "sql": "CREATE TABLE products (id SERIAL PRIMARY KEY, name VARCHAR(100), price DECIMAL(10,2))"
}

6. execute

执行任意 SQL 语句（查询、DML 或 DDL）。这是一个通用工具。

参数:

sql (string, 必需): SQL 语句

示例:

{
  "sql": "SELECT COUNT(*) FROM users"
}

在 Cursor 中配置 MCP

步骤 1: 找到 mcp.json 配置文件

mcp.json 文件通常位于以下位置：

macOS/Linux: ~/.config/cursor/mcp.json 或 ~/Library/Application Support/Cursor/User/globalStorage/mcp.json
Windows: %APPDATA%\Cursor\User\globalStorage\mcp.json

如果文件不存在，请创建它。

步骤 2: 配置 mcp.json

打开或创建 mcp.json 文件，添加以下配置。有三种运行方式：

方式 A: 使用 npm 安装（⭐ 最简单，推荐）

直接从 npm 安装，无需构建，开箱即用。

配置方式 A1: 全局安装后使用

npm install -g mcp-server-postgresql-rw

{
  "mcpServers": {
    "postgresql-rw": {
      "command": "mcp-server-postgresql-rw",
      "env": {
        "POSTGRES_CONNECTION_STRING": "postgresql://用户名:密码@主机:端口/数据库名"
      }
    }
  }
}

配置方式 A2: 使用 npx（无需全局安装，推荐）

无需全局安装，每次自动使用最新版本：

{
  "mcpServers": {
    "postgresql-rw": {
      "command": "npx",
      "args": ["-y", "mcp-server-postgresql-rw"],
      "env": {
        "POSTGRES_CONNECTION_STRING": "postgresql://用户名:密码@主机:端口/数据库名"
      }
    }
  }
}

实际示例：

{
  "mcpServers": {
    "postgresql-rw": {
      "command": "npx",
      "args": ["-y", "mcp-server-postgresql-rw"],
      "env": {
        "POSTGRES_CONNECTION_STRING": "postgresql://postgres:mypassword@localhost:5432/mydb"
      }
    }
  }
}

方式 B: 使用 npx tsx 直接运行（从源码，无需构建）

这种方式可以直接运行 TypeScript 源文件，无需先执行 npm run build。适合从源码安装的场景。

配置方式 B1: 使用连接字符串

{
  "mcpServers": {
    "postgresql-rw": {
      "command": "npx",
      "args": [
        "-y",
        "tsx",
        "/Users/yanxx/tools/mcp/postgresql-server-rw/src/index.ts"
      ],
      "env": {
        "POSTGRES_CONNECTION_STRING": "postgresql://用户名:密码@主机:端口/数据库名"
      }
    }
  }
}

实际示例：

{
  "mcpServers": {
    "postgresql-rw": {
      "command": "npx",
      "args": [
        "-y",
        "tsx",
        "/Users/yanxx/tools/mcp/postgresql-server-rw/src/index.ts"
      ],
      "env": {
        "POSTGRES_CONNECTION_STRING": "postgresql://postgres:mypassword@localhost:5432/mydb"
      }
    }
  }
}

配置方式 B2: 使用单独参数

{
  "mcpServers": {
    "postgresql-rw": {
      "command": "npx",
      "args": [
        "-y",
        "tsx",
        "/Users/yanxx/tools/mcp/postgresql-server-rw/src/index.ts"
      ],
      "env": {
        "POSTGRES_HOST": "localhost",
        "POSTGRES_PORT": "5432",
        "POSTGRES_DATABASE": "postgres",
        "POSTGRES_USER": "postgres",
        "POSTGRES_PASSWORD": "your_password",
        "POSTGRES_SSL": "false"
      }
    }
  }
}

方式 C: 使用编译后的文件（从源码，需要先构建）

如果你从源码安装并想使用编译后的 JavaScript 文件，需要先构建：

cd /path/to/mcp-server-postgresql-rw
npm install
npm run build

配置方式 C1: 使用连接字符串

{
  "mcpServers": {
    "postgresql-rw": {
      "command": "node",
      "args": ["/path/to/mcp-server-postgresql-rw/dist/index.js"],
      "env": {
        "POSTGRES_CONNECTION_STRING": "postgresql://用户名:密码@主机:端口/数据库名"
      }
    }
  }
}

实际示例：

{
  "mcpServers": {
    "postgresql-rw": {
      "command": "node",
      "args": ["/path/to/mcp-server-postgresql-rw/dist/index.js"],
      "env": {
        "POSTGRES_CONNECTION_STRING": "postgresql://postgres:mypassword@localhost:5432/mydb"
      }
    }
  }
}

配置方式 C2: 使用单独参数

{
  "mcpServers": {
    "postgresql-rw": {
      "command": "node",
      "args": ["/path/to/mcp-server-postgresql-rw/dist/index.js"],
      "env": {
        "POSTGRES_HOST": "localhost",
        "POSTGRES_PORT": "5432",
        "POSTGRES_DATABASE": "postgres",
        "POSTGRES_USER": "postgres",
        "POSTGRES_PASSWORD": "your_password",
        "POSTGRES_SSL": "false"
      }
    }
  }
}

三种方式对比

特性	方式 A (npm/npx)	方式 B (npx tsx)	方式 C (编译后)
安装方式	`npm install -g` 或 `npx`	从源码安装	从源码安装
需要构建	❌ 不需要	❌ 不需要	✅ 需要 `npm run build`
启动速度	⚡ 最快	稍慢（首次需要下载 tsx）	快
更新方式	`npm update -g` 或自动	需要 git pull	需要 git pull + build
推荐场景	⭐ 生产环境、日常使用	开发环境、频繁修改	生产环境、稳定版本

步骤 4: 使用 SSL 连接（可选）

如果数据库需要 SSL 连接，使用 npx tsx 方式：

{
  "mcpServers": {
    "postgresql-rw": {
      "command": "npx",
      "args": [
        "-y",
        "tsx",
        "/Users/yanxx/tools/mcp/postgresql-server-rw/src/index.ts"
      ],
      "env": {
        "POSTGRES_CONNECTION_STRING": "postgresql://user:password@host:5432/db?sslmode=require"
      }
    }
  }
}

或使用单独参数：

{
  "mcpServers": {
    "postgresql-rw": {
      "command": "npx",
      "args": [
        "-y",
        "tsx",
        "/Users/yanxx/tools/mcp/postgresql-server-rw/src/index.ts"
      ],
      "env": {
        "POSTGRES_HOST": "your-host.com",
        "POSTGRES_PORT": "5432",
        "POSTGRES_DATABASE": "mydb",
        "POSTGRES_USER": "myuser",
        "POSTGRES_PASSWORD": "mypassword",
        "POSTGRES_SSL": "true"
      }
    }
  }
}

步骤 5: 如果已有其他 MCP 服务器配置

如果你的 mcp.json 中已经有其他服务器配置，只需在 mcpServers 对象中添加新的配置：

{
  "mcpServers": {
    "existing-server": {
      "command": "node",
      "args": ["/path/to/existing/server.js"]
    },
    "postgresql-rw": {
      "command": "node",
      "args": ["/Users/yanxx/tools/mcp/postgresql-server-rw/dist/index.js"],
      "env": {
        "POSTGRES_CONNECTION_STRING": "postgresql://user:password@localhost:5432/database"
      }
    }
  }
}

步骤 6: 重启 Cursor

配置完成后，重启 Cursor 以使配置生效。

步骤 7: 验证配置

重启后，在 Cursor 中：

打开命令面板（Cmd+Shift+P 或 Ctrl+Shift+P）
输入 "MCP" 查看可用的 MCP 相关命令
尝试使用 AI 助手，询问它是否可以访问 PostgreSQL 工具

你也可以直接询问 AI：

"列出可用的 PostgreSQL 工具"
"查询数据库中的表"
"执行一个简单的 SELECT 查询"

故障排除

问题 1: 找不到 node 命令

如果系统找不到 node 命令，可以使用完整路径：

{
  "mcpServers": {
    "postgresql-rw": {
      "command": "/usr/local/bin/node",
      "args": ["/Users/yanxx/tools/mcp/postgresql-server-rw/dist/index.js"],
      "env": {
        "POSTGRES_CONNECTION_STRING": "postgresql://user:password@localhost:5432/database"
      }
    }
  }
}

查找 node 路径：

which node

问题 2: 连接失败

检查：

数据库服务是否运行
连接字符串或参数是否正确
防火墙是否允许连接
数据库用户是否有足够权限

问题 3: 权限错误

如果使用编译后的文件，确保 dist/index.js 文件有执行权限：

chmod +x /path/to/mcp-server-postgresql-rw/dist/index.js

如果使用 npm 安装，通常不会有权限问题。

问题 4: 查看日志

如果遇到问题，可以查看 Cursor 的日志文件来诊断问题。

发布到 npm

✅ 已发布: 此包已发布到 npm，可以直接使用 npm install -g mcp-server-postgresql-rw 安装。

📦 npm 包地址: https://www.npmjs.com/package/mcp-server-postgresql-rw

如果你想更新版本或重新发布，请按照以下步骤操作：

1. 准备发布

1.1 更新 package.json

确保 package.json 中的信息正确：

name: 包名（必须是唯一的，检查 npm 上是否已存在）
version: 版本号
author: 作者信息
repository: Git 仓库地址（如果有）
description: 包描述

1.2 创建 npm 账号

如果还没有 npm 账号，请访问 npmjs.com 注册。

1.3 登录 npm

npm login

输入你的用户名、密码和邮箱。

2. 检查包名是否可用

npm search mcp-server-postgresql-rw

如果包名已被占用，需要在 package.json 中修改 name 字段。

3. 构建项目

npm run build

4. 测试本地安装

在发布前，可以先测试本地安装：

npm pack

这会生成一个 .tgz 文件，你可以本地安装测试：

npm install -g ./mcp-server-postgresql-rw-1.0.0.tgz

5. 发布到 npm

5.1 发布公开包（推荐）

npm publish --access public

5.2 发布私有包（需要付费账号）

npm publish

6. 验证发布

发布成功后，可以在 npm 上搜索你的包：

npm search mcp-server-postgresql-rw

或者访问：https://www.npmjs.com/package/mcp-server-postgresql-rw

7. 更新版本

发布新版本时：

# 更新版本号（会自动更新 package.json）
npm version patch  # 1.0.0 -> 1.0.1 (补丁版本)
npm version minor  # 1.0.0 -> 1.1.0 (小版本)
npm version major  # 1.0.0 -> 2.0.0 (大版本)

# 然后发布
npm publish --access public

8. 撤销发布（如果需要）

如果发布有误，可以在 72 小时内撤销：

npm unpublish mcp-server-postgresql-rw@1.0.0

⚠️ 注意: 撤销后 24 小时内不能发布相同版本。

发布检查清单

更新 package.json 中的版本号
更新 README.md 中的使用说明
确保代码已构建（npm run build）
测试本地安装（npm pack 和 npm install -g）
确保 .npmignore 配置正确
登录 npm (npm login)
检查包名是否可用
发布 (npm publish --access public)

发布后的使用方式

发布后，其他人可以通过以下方式使用：

全局安装

npm install -g mcp-server-postgresql-rw

然后在 mcp.json 中配置：

{
  "mcpServers": {
    "postgresql-rw": {
      "command": "mcp-server-postgresql-rw",
      "env": {
        "POSTGRES_CONNECTION_STRING": "postgresql://user:password@localhost:5432/database"
      }
    }
  }
}

使用 npx（无需全局安装）

{
  "mcpServers": {
    "postgresql-rw": {
      "command": "npx",
      "args": ["-y", "mcp-server-postgresql-rw"],
      "env": {
        "POSTGRES_CONNECTION_STRING": "postgresql://user:password@localhost:5432/database"
      }
    }
  }
}

安全注意事项

⚠️ 警告: 此服务器允许执行任意 SQL 语句，包括 DDL 和 DML 操作。请确保：

只连接到受信任的数据库
使用具有适当权限的数据库用户
在生产环境中谨慎使用
考虑添加 SQL 注入防护机制

许可证

MIT

Available Tools

6 tools

deleteB

执行 DELETE 语句，从表中删除数据。

ParametersJSON Schema

Name	Required	Description	Default
`sql`	Yes	要执行的 DELETE SQL 语句

TDQS

B3.2/5.0

Behavior2/5

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

The description states 'delete data from table' which implies destructive behavior, but offers no additional context about irreversibility, cascading effects, transaction handling, or permissions required. Without annotations, this is a significant gap for a mutation tool.

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?

The description is a single, concise sentence that clearly communicates the core action without any wasted words or redundant information.

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?

For a destructive operation with no annotations or output schema, the description is too sparse. It omits important context such as cautionary notes, exclusion from safe usage, and what the result of the operation might be. The simplicity of parameters does not compensate for the lack of behavioral context.

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 schema covers 100% of the single parameter with a description of 'DELETE SQL statement to execute.' The tool description adds no further meaning or context beyond the schema, so the baseline of 3 applies.

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 tool executes DELETE statements to remove data from tables, which is a specific verb+resource pairing. It distinguishes itself from sibling tools like query, insert, and update by explicitly naming the DELETE operation.

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 is provided on when to use this tool versus alternatives such as update or execute. There are no prerequisites, caveats, or exclusions mentioned.

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

executeB

执行任意 SQL 语句（查询、DML 或 DDL）。这是一个通用工具，可以执行任何 SQL 操作。

ParametersJSON Schema

Name	Required	Description	Default
`sql`	Yes	要执行的 SQL 语句

TDQS

B3.3/5.0

Behavior3/5

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

The description discloses that the tool can perform DML and DDL, which implies potential data modifications and schema changes. Since no annotations are provided, this is useful context, but it does not elaborate on side effects, permissions, or error behavior.

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 short and front-loaded, but slightly redundant ('any SQL statement' and 'any SQL operation' repeat the same idea). It is still efficient and easy to scan.

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 that this is a generic executor with no output schema and no annotations, the description should clarify expected return values, potential dangers (e.g., destructive DDL), and when it should be preferred over specific sibling tools. It does none of these, leaving significant gaps for safe and correct use.

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% for the single 'sql' parameter, so the schema already documents it fully. The description adds no additional parameter-level meaning beyond restating that it executes SQL, keeping the score at the baseline.

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 tool executes any SQL statement (query, DML, DDL), identifying the verb (execute) and resource (SQL). It distinguishes from siblings by being the generic catch-all, though it does not explicitly name alternatives.

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 as a universal fallback for any SQL operation, but it does not explicitly state when to use this tool over the more specific siblings like query, insert, update, or delete. It lacks clear when/when-not guidance.

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

execute_ddlA

执行 DDL（数据定义语言）语句，包括 CREATE、ALTER、DROP 等操作。用于创建、修改或删除数据库对象（表、索引、视图等）。

ParametersJSON Schema

Name	Required	Description	Default
`sql`	Yes	要执行的 DDL SQL 语句（CREATE、ALTER、DROP 等）

TDQS

A4/5.0

Behavior3/5

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

With no annotations provided, the description must carry the full burden of behavioral disclosure. It explicitly mentions DROP and 'delete database objects', which signals destructive potential. However, it does not warn about irreversibility, locking, or permissions, leaving some behavioral gaps. The explicit mention of DROP earns a middle score.

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?

The description is two concise sentences, front-loaded with the core action and examples, and contains zero wasted words. It efficiently conveys purpose and scope, making it easy to parse quickly.

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?

For a simple tool with one parameter and full schema coverage, the description provides sufficient context: what it does, when to use it, and what operations are possible. It lacks details about return values or side effects like transaction behavior, but these are less critical for DDL execution. The description is functionally complete for agent comprehension.

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 for the single 'sql' parameter is 100%, so the schema fully documents the parameter's meaning. The description repeats that the parameter is a DDL SQL statement without adding extra formatting, syntax, or constraints. This matches the baseline of 3, as the description adds no meaningful value beyond the schema.

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 uses a specific verb ('execute') with a clear resource ('DDL statements'), lists concrete examples (CREATE, ALTER, DROP), and states the overall purpose (create, modify, delete database objects). This strongly distinguishes it from sibling tools like query, insert, update, and delete, which handle DML.

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?

The description clearly establishes when this tool should be used: for DDL statements that manage database objects. It doesn't explicitly name alternatives, but the context is unambiguous—users should choose this for schema operations, and other tools for data manipulation. No exclusions are needed given the semantic clarity.

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

insertB

执行 INSERT 语句，向表中插入新数据。

ParametersJSON Schema

Name	Required	Description	Default
`sql`	Yes	要执行的 INSERT SQL 语句

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral traits, but it only restates the tool's core function. It does not mention whether the operation is safe/unsafe, whether it returns results, errors, or side effects, or any permission requirements. This is a minimal restatement rather than meaningful behavioral disclosure.

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 that front-loads the main action and purpose. While it is very short, it contains no wasted words, though it could benefit from additional context as noted in other dimensions.

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?

For a 1-parameter tool with good schema coverage, the description is functional but incomplete. It fails to clarify how this tool differs from the sibling 'execute' tool, nor does it describe return behavior or side effects, creating ambiguity that could lead to incorrect tool selection.

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 schema already includes a full description for the only parameter (sql), achieving 100% schema description coverage. The tool description adds no additional parameter semantics beyond what the schema provides, so the baseline score of 3 applies.

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 tool as executing INSERT statements to add new data to tables, using a specific verb ('执行'/'execute') and resource ('INSERT 语句'/'INSERT statement'). This distinguishes it from sibling tools like query, update, and delete, which handle other types of SQL operations.

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 is provided on when to use this tool versus the generic 'execute' tool or 'execute_ddl'. The description does not mention exclusions, prerequisites, or alternative tools, leaving the agent to infer the appropriate context from the name alone.

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

queryA

执行 SELECT 查询语句，返回查询结果。用于读取数据。

ParametersJSON Schema

Name	Required	Description	Default
`sql`	Yes	要执行的 SELECT SQL 查询语句

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations, the description carries the burden of disclosing behavior. It does state the tool only accepts SELECT statements and returns query results, which implies a read-only nature. However, it does not mention potential side effects, error handling, or result formatting, leaving some ambiguity.

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?

The description is extremely concise, consisting of two short sentences that each convey useful information: the action (execute SELECT) and the purpose (read data). It is front-loaded and has 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?

The description is sufficient for a simple tool, but it does not clarify how 'query' differs from the sibling 'execute' tool, which could cause confusion. It also does not describe the return format or any limitations. Given the minimal schema and no output schema, more contextual detail would be helpful.

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 the parameter 'sql' is described as the SELECT query to execute. The tool description adds little beyond repeating 'SELECT', which is already in the schema. Thus, it meets the baseline but does not go beyond.

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 tool executes SELECT queries and is used for reading data. This specific verb+resource combination (execute SELECT, read) distinguishes it from write-oriented siblings like insert, update, and delete.

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?

The description implies this tool should be used for read operations ('用于读取数据'), which is clear context. However, it does not explicitly exclude other usages or mention alternatives such as the generic 'execute' tool, so it falls short of full guidance.

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

updateC

执行 UPDATE 语句，更新表中的数据。

ParametersJSON Schema

Name	Required	Description	Default
`sql`	Yes	要执行的 UPDATE SQL 语句

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description must carry the burden of disclosing behavioral traits. It only says 'update data', which is obvious, but does not mention side effects, transactionality, required permissions, or any risks. The mutation implication is present but no additional context is given.

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?

The description is a single concise sentence that directly states the tool's function. There is no unnecessary verbiage, and the information is front-loaded and easy to parse.

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?

The tool is a mutation operation with no annotations, no output schema, and a very minimal description. It lacks usage guidance and behavioral transparency, and the presence of sibling tools like 'execute' and 'execute_ddl' creates ambiguity that is not addressed. The simple parameter schema is well-covered, but overall the description is incomplete for safe and correct invocation.

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 schema has 100% coverage for the single parameter, and its description ('the UPDATE SQL statement to execute') accurately describes it. The tool description adds no further semantic value beyond what the schema already provides, so the baseline 3 is appropriate.

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 states a specific verb ('execute UPDATE') and resource ('data in the table'), clearly distinguishing it from siblings like query, insert, and delete. It is clear and unambiguous, though it could be slightly more explicit about what 'update' entails.

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 is provided on when to use this tool versus alternatives such as the generic 'execute' or 'execute_ddl'. The description does not mention prerequisites, typical use cases, or exclusions, leaving the agent to infer the intended scope.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0

Disambiguation3/5

The specialized tools (query, insert, update, delete, execute_ddl) each map to distinct SQL operations, but the generic execute tool can perform any of these operations, creating overlap and making tool selection less clear.

Naming Consistency4/5

Most tools use a simple verb form (query, insert, update, delete, execute), while execute_ddl uses a verb_noun pattern. This is a minor inconsistency but the naming is still predictable.

Tool Count5/5

Six tools is an appropriate scope for a PostgreSQL read-write server, providing dedicated operations without bloat.

Completeness5/5

The surface covers all core SQL operations (SELECT, INSERT, UPDATE, DELETE, DDL) plus a generic escape hatch for arbitrary SQL, so there are no obvious gaps.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

nlqdb — analytical memory for AI agents AOAuth
com.nlqdb
Analytical memory for AI agents: a real Postgres queried in plain English over MCP. One command.
Databases Knowledge & Memory Search
631
PlainQuery | MCP DB Agent
io.github.Jarvis-27
Query PostgreSQL databases in plain English — LLM-generated, safety-validated SQL.
Databases Search
2
mcpOAuth
com.gibsonai
GibsonAI MCP server: manage your databases with natural language
Databases Search
233
Contextflo
com.contextflo
Query your warehouse or a CSV with Claude/ChatGPT over MCP, governed by table-level ACL + audit.
Databases Security
1

Related MCP Servers

Postgres MCP Server
Databases Developer Tools
wesleyyeung
F
license
Not graded
quality
C
maintenance
Enables querying and modifying PostgreSQL databases through MCP tools with read/write operations, schema inspection, and write-safety constraints that limit modifications to the mcp schema.
Updated 9 months ago (2025-11-26 00:14 UTC)
1
pgEdge Postgres MCP Serverofficial
Databases RAG Systems
pgEdge
A
license
Not graded
quality
A
maintenance
Enables SQL queries against PostgreSQL databases through MCP-compatible clients and includes a natural language agent for forming SQL queries from natural language.
Updated 9 days ago (2026-08-26 09:14 UTC)
219
PostgreSQL
pgsql-mcp-server
Databases Developer Tools
twn39
A
license
Not graded
quality
F
maintenance
Enables interaction with PostgreSQL databases through MCP, supporting queries, DDL, DML, and schema inspection.
Updated 4 months ago (2026-04-21 22:19 UTC)
6
MIT
postgres-mcp-server
Databases Developer Tools
abdulsammad-lgtm
A
license
Not graded
quality
C
maintenance
Enables AI assistants to securely interact with PostgreSQL databases through a standardized MCP interface, supporting SQL queries, schema inspection, and database management.
Updated a month ago (2026-07-31 20:42 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/yanxxcloud/mcp-server-postgresql-rw'

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

PostgreSQL MCP Server (Read-Write)

功能特性

快速开始

方式 1: 通过 npm 安装（⭐ 推荐）

方式 2: 从源码安装

3. 重启 Cursor

安装

方式 1: 通过 npm 安装（⭐ 推荐）

方式 2: 从源码安装

配置

方式 1: 使用连接字符串

方式 2: 使用单独的参数

使用方法

作为 MCP 服务器运行

开发模式

可用工具

1. query

2. insert

3. update

4. delete

5. execute_ddl

6. execute

在 Cursor 中配置 MCP

步骤 1: 找到 mcp.json 配置文件

步骤 2: 配置 mcp.json

方式 A: 使用 npm 安装（⭐ 最简单，推荐）

配置方式 A1: 全局安装后使用

配置方式 A2: 使用 npx（无需全局安装，推荐）

方式 B: 使用 npx tsx 直接运行（从源码，无需构建）

配置方式 B1: 使用连接字符串

配置方式 B2: 使用单独参数

方式 C: 使用编译后的文件（从源码，需要先构建）

配置方式 C1: 使用连接字符串

配置方式 C2: 使用单独参数

三种方式对比

步骤 4: 使用 SSL 连接（可选）

步骤 5: 如果已有其他 MCP 服务器配置

步骤 6: 重启 Cursor

步骤 7: 验证配置

故障排除

问题 1: 找不到 node 命令

问题 2: 连接失败

问题 3: 权限错误

问题 4: 查看日志

发布到 npm

1. 准备发布

1.1 更新 package.json

1.2 创建 npm 账号

1.3 登录 npm

2. 检查包名是否可用

3. 构建项目

4. 测试本地安装

5. 发布到 npm

5.1 发布公开包（推荐）

5.2 发布私有包（需要付费账号）

6. 验证发布

7. 更新版本

8. 撤销发布（如果需要）

发布检查清单

发布后的使用方式

全局安装

使用 npx（无需全局安装）

安全注意事项

许可证

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

pgEdge Postgres MCP Serverofficial

Latest Blog Posts

MCP directory API