de en es ja ko ru zh

PostgreSQL MCP Server

Name: PostgreSQL MCP Server
Author: HenkDz

by HenkDz

Overview Schema Related Servers Score Discussions

TypeScript

Remote

PostgreSQL MCP 服务器

铁匠徽章

提供 PostgreSQL 数据库管理功能的模型上下文协议 (MCP) 服务器。该服务器可协助分析现有 PostgreSQL 设置、提供实施指导、调试数据库问题、管理架构、迁移数据以及监控数据库性能。

版本 0.2.0

Related MCP server: PostgreSQL MCP Server

特征

该服务器提供以下工具：

1. 数据库分析和设置

1.1. 分析数据库（ `analyze_database` ）

分析 PostgreSQL 数据库配置和性能指标：

配置分析
性能指标
安全评估
优化建议

// Example usage
{
  "analysisType": "performance" // Optional: "configuration" | "performance" | "security"
}

1.2. 获取设置说明（ `get_setup_instructions` ）

提供分步 PostgreSQL 安装和配置指南：

特定于平台的安装步骤
配置建议
安全最佳实践
安装后任务

// Example usage
{
  "platform": "linux", // Required: "linux" | "macos" | "windows"
  "version": "15", // Optional: PostgreSQL version
  "useCase": "production" // Optional: "development" | "production"
}

1.3. 调试数据库（ `debug_database` ）

调试常见的 PostgreSQL 问题：

连接问题
性能瓶颈
锁冲突
复制状态

// Example usage
{
  "issue": "performance", // Required: "connection" | "performance" | "locks" | "replication"
  "logLevel": "debug" // Optional: "info" | "debug" | "trace"
}

2. 模式管理

2.1. 获取架构信息（ `get_schema_info` ）

获取数据库或特定表的详细架构信息：

数据库中的表列表
列定义
约束（主键、外键等）
索引

// Example usage
{
  "tableName": "users" // Optional: specific table to get info for
}

2.2. 创建表（ `create_table` ）

创建具有指定列的新表：

定义列名称和类型
设置可空约束
设置默认值

// Example usage
{
  "tableName": "users", // Required
  "columns": [ // Required
    { "name": "id", "type": "SERIAL", "nullable": false },
    { "name": "username", "type": "VARCHAR(100)", "nullable": false },
    { "name": "email", "type": "VARCHAR(255)", "nullable": false },
    { "name": "created_at", "type": "TIMESTAMP", "default": "NOW()" }
  ]
}

2.3. 修改表（ `alter_table` ）

修改现有表：

添加新列
修改列类型或约束
删除列

// Example usage
{
  "tableName": "users", // Required
  "operations": [ // Required
    { "type": "add", "columnName": "last_login", "dataType": "TIMESTAMP" },
    { "type": "alter", "columnName": "email", "nullable": false },
    { "type": "drop", "columnName": "temporary_field" }
  ]
}

2.4. 获取枚举（ `get_enums` ）

获取有关 PostgreSQL ENUM 类型的信息。

// Example usage
{
  "schema": "public", // Optional
  "enumName": "user_status" // Optional
}

2.5. 创建枚举（ `create_enum` ）

在数据库中创建一个新的 ENUM 类型。

// Example usage
{
  "enumName": "order_status", // Required
  "values": ["pending", "processing", "shipped", "delivered"], // Required
  "schema": "public", // Optional
  "ifNotExists": true // Optional
}

3.数据迁移

3.1. 导出表数据（ `export_table_data` ）

将表数据导出为 JSON 或 CSV 格式：

使用 WHERE 子句过滤数据
限制行数
选择输出格式

// Example usage
{
  "tableName": "users", // Required
  "outputPath": "./exports/users.json", // Required
  "where": "created_at > '2023-01-01'", // Optional
  "limit": 1000, // Optional
  "format": "json" // Optional: "json" | "csv"
}

3.2. 导入表数据（ `import_table_data` ）

从 JSON 或 CSV 文件导入数据：

导入前可选择截断表
支持不同格式
自定义 CSV 分隔符

// Example usage
{
  "tableName": "users", // Required
  "inputPath": "./imports/users.json", // Required
  "truncateFirst": false, // Optional
  "format": "json", // Optional: "json" | "csv"
  "delimiter": "," // Optional: for CSV files
}

3.3. 数据库间复制（ `copy_between_databases` ）

在两个 PostgreSQL 数据库之间复制数据：

使用 WHERE 子句过滤数据
选择性地截断目标表

// Example usage
{
  "sourceConnectionString": "postgresql://user:password@localhost:5432/source_db", // Required
  "targetConnectionString": "postgresql://user:password@localhost:5432/target_db", // Required
  "tableName": "users", // Required
  "where": "active = true", // Optional
  "truncateTarget": false // Optional
}

4. 监控

4.1. 监控数据库（ `monitor_database` ）

PostgreSQL数据库实时监控：

数据库指标（连接数、缓存命中率等）
表指标（大小、行数、死元组）
主动查询信息
锁信息
复制状态
可配置警报

// Example usage
{
  "includeTables": true, // Optional
  "includeQueries": true, // Optional
  "includeLocks": true, // Optional
  "includeReplication": false, // Optional
  "alertThresholds": { // Optional
    "connectionPercentage": 80,
    "longRunningQuerySeconds": 30,
    "cacheHitRatio": 0.95,
    "deadTuplesPercentage": 10,
    "vacuumAge": 7
  }
}

5. 功能

5.1. 获取函数（ `get_functions` ）

获取有关 PostgreSQL 函数的信息。

// Example usage
{
  "functionName": "calculate_total", // Optional
  "schema": "public" // Optional
}

5.2. 创建函数（ `create_function` ）

创建或替换 PostgreSQL 函数。

// Example usage
{
  "functionName": "get_user_count", // Required
  "parameters": "", // Required (empty if no params)
  "returnType": "integer", // Required
  "functionBody": "SELECT count(*) FROM users;", // Required
  "language": "sql", // Optional
  "volatility": "STABLE", // Optional
  "schema": "public", // Optional
  "security": "INVOKER", // Optional
  "replace": true // Optional
}

5.3. 删除函数（ `drop_function` ）

删除一个 PostgreSQL 函数。

// Example usage
{
  "functionName": "old_function", // Required
  "parameters": "integer", // Optional: required for overloaded functions
  "schema": "public", // Optional
  "ifExists": true, // Optional
  "cascade": false // Optional
}

6. 行级安全性（RLS）

6.1. 启用 RLS ( `enable_rls` )

在表上启用行级安全性。

// Example usage
{
  "tableName": "sensitive_data", // Required
  "schema": "secure" // Optional
}

6.2. 禁用 RLS ( `disable_rls` )

禁用表上的行级安全性。

// Example usage
{
  "tableName": "sensitive_data", // Required
  "schema": "secure" // Optional
}

6.3. 创建 RLS 策略（ `create_rls_policy` ）

创建行级安全策略。

// Example usage
{
  "tableName": "documents", // Required
  "policyName": "user_can_see_own_docs", // Required
  "using": "owner_id = current_user_id()", // Required
  "check": "owner_id = current_user_id()", // Optional
  "schema": "public", // Optional
  "command": "SELECT", // Optional
  "role": "app_user", // Optional
  "replace": false // Optional
}

6.4. 编辑 RLS 策略（ `edit_rls_policy` ）

编辑现有的行级安全策略。

// Example usage
{
  "tableName": "documents", // Required
  "policyName": "user_can_see_own_docs", // Required
  "schema": "public", // Optional
  "roles": ["app_user", "admin_user"], // Optional: New roles (empty or omit to keep existing/use default)
  "using": "owner_id = current_user_id() OR is_admin(current_user_id())", // Optional: New USING expression
  "check": "owner_id = current_user_id()" // Optional: New WITH CHECK expression
}

6.5. 删除 RLS 策略（ `drop_rls_policy` ）

删除行级安全策略。

// Example usage
{
  "tableName": "documents", // Required
  "policyName": "old_policy", // Required
  "schema": "public", // Optional
  "ifExists": true // Optional
}

6.6. 获取 RLS 策略（ `get_rls_policies` ）

获取行级安全策略。

// Example usage
{
  "tableName": "documents", // Optional
  "schema": "public" // Optional
}

7. 触发器

7.1. 获取触发器（ `get_triggers` ）

获取有关 PostgreSQL 触发器的信息。

// Example usage
{
  "tableName": "audit_log", // Optional
  "schema": "public" // Optional
}

7.2. 创建触发器（ `create_trigger` ）

创建一个 PostgreSQL 触发器。

// Example usage
{
  "triggerName": "log_user_update", // Required
  "tableName": "users", // Required
  "functionName": "audit_user_change", // Required
  "schema": "public", // Optional
  "timing": "AFTER", // Optional
  "events": ["UPDATE"], // Optional
  "when": "OLD.email IS DISTINCT FROM NEW.email", // Optional
  "forEach": "ROW", // Optional
  "replace": false // Optional
}

7.3. 删除触发器（ `drop_trigger` ）

删除 PostgreSQL 触发器。

// Example usage
{
  "triggerName": "old_trigger", // Required
  "tableName": "users", // Required
  "schema": "public", // Optional
  "ifExists": true, // Optional
  "cascade": false // Optional
}

7.4. 设置触发器状态（ `set_trigger_state` ）

启用或禁用 PostgreSQL 触发器。

// Example usage
{
  "triggerName": "log_user_update", // Required
  "tableName": "users", // Required
  "enable": false, // Required: true to enable, false to disable
  "schema": "public" // Optional
}

先决条件

Node.js >= 18.0.0
PostgreSQL 服务器（用于目标数据库操作）
对目标 PostgreSQL 实例的网络访问

安装

通过 Smithery 安装

要通过Smithery自动为 Claude Desktop 安装 postgresql-mcp-server：

npx -y @smithery/cli install @HenkDz/postgresql-mcp-server --client claude

手动安装

克隆存储库
安装依赖项：
```
npm install
```
构建服务器：
```
npm run build
```

添加到 MCP 设置文件（例如，在您的 IDE 设置或全局 MCP 配置中）：

有几种方法可以配置服务器的连接字符串，其优先顺序如下：

工具特定参数：如果在调用特定工具时在参数中直接提供了connectionString ，则该值将用于该调用。
CLI 参数：您可以在使用-cs或--connection-string参数启动服务器时提供默认连接字符串。
环境变量：如果以上均未提供，服务器将查找POSTGRES_CONNECTION_STRING环境变量。

如果通过任何一种方法都找不到连接字符串，则需要数据库连接的工具将会失败。

在 MCP 设置中使用 CLI 参数的示例：

{
  "mcpServers": {
    "postgresql-mcp": {
      "command": "node",
      "args": [
        "/path/to/postgresql-mcp-server/build/index.js",
        "--connection-string",
        "postgresql://username:password@server:port/dbname"
        // Optionally, add "--tools-config", "/path/to/your/mcp-tools.json"
      ],
      "disabled": false,
      "alwaysAllow": []
      // Note: 'env' block for POSTGRES_CONNECTION_STRING can still be used as a fallback
      // if --connection-string is not provided in args.
    }
  }
}

使用环境变量的示例（如果不使用 CLI 参数）：

{
  "mcpServers": {
    "postgresql-mcp": {
      "command": "node",
      "args": [
        "/path/to/postgresql-mcp-server/build/index.js"
        // Optionally, add "--tools-config", "/path/to/your/mcp-tools.json"
      ],
      "disabled": false,
      "alwaysAllow": [],
      "env": {
        "POSTGRES_CONNECTION_STRING": "postgresql://username:password@server:port/dbname"
      }
    }
  }
}

使用--connection-string CLI 参数或POSTGRES_CONNECTION_STRING环境变量使得connectionString参数对于大多数工具调用而言成为可选项。

工具配置

服务器支持通过外部 JSON 配置文件过滤启用哪些工具。

CLI 选项：使用-tc <path>或--tools-config <path>指定工具配置文件的路径。
文件格式：JSON 文件应包含一个带有enabledTools键的对象，该对象包含一个工具名称字符串数组。
示例mcp-tools.json ：
```
{
  "enabledTools": [
    "get_schema_info",
    "analyze_database",
    "export_table_data"
  ]
}
```
行为：
- 如果提供了配置文件并且该配置文件有效，则仅启用列出的工具。
- 如果未提供文件、文件无效或无法读取，则所有工具将默认启用。
- 服务器将根据此配置记录启用了哪些工具。

发展

npm run dev - 使用热重载启动开发服务器
npm run lint - 运行 ESLint
npm test - 运行测试（如果已配置）

安全注意事项

连接安全
- 服务器根据以下优先级确定数据库连接字符串：
  1. 工具参数中直接提供的connectionString 。
  2. --connection-string启动服务器时使用的 CLI 参数。
  3. POSTGRES_CONNECTION_STRING环境变量。
- 确保连接字符串（尤其是带有凭据的连接字符串）得到安全管理。
- 通过pg (以前@vercel/postgres ) 使用连接池。
- 验证连接字符串。
- 支持 SSL/TLS 连接（通过连接字符串配置）。
查询安全
- 执行预定义的操作；尽可能避免任意 SQL 执行。
- 在适用的情况下使用参数化查询来防止 SQL 注入。
- 记录操作以供审计。
验证
- 通过连接字符串依赖于 PostgreSQL 的身份验证机制。
- 安全地管理您的数据库凭据。如果可以避免，请勿在客户端请求中对其进行硬编码；在配置服务器时，建议使用--connection-string CLI 选项或POSTGRES_CONNECTION_STRING环境变量。

最佳实践

使用--connection-string CLI 选项或POSTGRES_CONNECTION_STRING环境变量安全地配置默认数据库连接字符串。
如果工具需要连接到与默认数据库不同的数据库，请直接在该工具的参数中提供connectionString 。
始终使用具有适当凭据的安全连接字符串，最好通过POSTGRES_CONNECTION_STRING环境变量进行配置。
遵循敏感环境的生产安全建议。
使用monitor_database工具定期监控和分析数据库性能。
保持 PostgreSQL 版本为最新版本。
独立实施适当的备份策略。
使用连接池实现更好的资源管理（内部处理）。
实施适当的错误处理和日志记录。
定期进行安全审核和更新。

错误处理

服务器实现以下错误处理：

连接失败
查询错误
无效输入
权限问题

错误以标准 MCP 错误格式返回。

贡献

分叉存储库
创建功能分支
提交你的更改
推送到分支
创建拉取请求

执照

该项目根据 AGPLv3 许可证获得许可 - 有关详细信息，请参阅 LICENSE 文件。

Available Tools

18 tools

pg_analyze_databaseC

Analyze PostgreSQL database configuration and performance

ParametersJSON Schema

Name	Required	Description	Default
`connectionString`	No	PostgreSQL connection string (optional if POSTGRES_CONNECTION_STRING environment variable or --connection-string CLI option is set)
`analysisType`	No	Type of analysis to perform

TDQS

C2.9/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 mentions analysis but doesn't disclose behavioral traits such as whether it's read-only or has side effects, performance impact, required permissions, or output format. This is inadequate for a tool that interacts with a database.

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, efficient sentence with zero waste. It's front-loaded and appropriately sized, making it easy to parse without unnecessary details.

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 the complexity of database analysis, lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the analysis entails, potential impacts, or return values, leaving significant gaps for an AI agent to understand the tool's behavior.

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%, so the schema fully documents the two parameters. The description adds no additional meaning beyond implying analysis types, which the schema already covers with the enum. Baseline 3 is appropriate as the schema does the heavy lifting.

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 action ('Analyze') and resource ('PostgreSQL database configuration and performance'), making the purpose understandable. However, it doesn't differentiate from sibling tools like pg_debug_database or pg_monitor_database, which might have overlapping analysis functions, so it misses full sibling distinction.

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. With multiple sibling tools like pg_debug_database and pg_monitor_database that could involve analysis, the description lacks any context or exclusions, leaving the agent to guess based on tool names alone.

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

pg_copy_between_databasesC

Copy data between two databases

ParametersJSON Schema

Name	Required	Description	Default
`sourceConnectionString`	Yes
`targetConnectionString`	Yes
`tableName`	Yes
`where`	No
`truncateTarget`	No

TDQS

C2.8/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 the full burden of behavioral disclosure. 'Copy data between two databases' implies a write operation to the target database, but it doesn't disclose critical traits like whether this requires specific permissions, if it's a bulk operation, what happens on failure, or if there are rate limits. For a tool with 5 parameters and no annotation coverage, this is a significant gap in 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?

The description is a single, efficient sentence with zero waste. It's appropriately sized for the tool's name and gets straight to the point without unnecessary elaboration. Every word earns its place in conveying the core functionality.

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 the complexity (5 parameters, no annotations, no output schema, and 0% schema coverage), the description is inadequate. It doesn't explain what the tool returns, how parameters interact, or the operational context. For a data copying tool with multiple configuration options, more completeness is needed to guide effective use.

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 0%, meaning none of the 5 parameters have descriptions in the schema. The tool description doesn't mention any parameters or provide meaning beyond the basic action. It fails to compensate for the lack of schema documentation, leaving parameters like 'where' and 'truncateTarget' completely unexplained in context.

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 'Copy data between two databases' clearly states the verb (copy) and resource (data between databases). It's specific about the action but doesn't differentiate from sibling tools like pg_export_table_data or pg_import_table_data, which might handle similar data movement operations. The purpose is unambiguous but lacks sibling distinction.

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. With siblings like pg_export_table_data and pg_import_table_data that might handle similar data transfer tasks, there's no indication of when this tool is preferred or what specific scenarios it addresses. No exclusions or prerequisites are mentioned.

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

pg_debug_databaseC

Debug common PostgreSQL issues

ParametersJSON Schema

Name	Required	Default
`connectionString`	No
`issue`	Yes
`logLevel`	No	info

TDQS

C2/5.0

Behavior2/5

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

With no annotations, the description carries full burden but only hints at behavior ('debug') without details on actions (e.g., read-only vs. destructive), side effects, or output. It fails to disclose critical traits like whether it modifies data, requires specific permissions, or handles errors.

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 with no wasted words, making it appropriately concise. However, it's under-specified rather than optimally structured for clarity.

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 3-parameter tool with no annotations, no output schema, and 0% schema coverage, the description is incomplete. It lacks details on behavior, parameters, and expected outcomes, making it inadequate for effective tool selection and invocation.

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 0%, so the description must compensate but adds no parameter meaning. It doesn't explain what 'connectionString', 'issue', or 'logLevel' do, leaving all three parameters undocumented beyond their schema enums.

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

Purpose2/5

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

The description 'Debug common PostgreSQL issues' states a general purpose but lacks specificity about what 'debug' entails (e.g., diagnostics, analysis, fixes) and doesn't distinguish from siblings like pg_analyze_database or pg_monitor_database. It's vague about the verb and resource scope.

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

Usage Guidelines1/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 is provided. It doesn't mention prerequisites, context, or exclusions, leaving the agent to guess based on the generic description and sibling names.

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

pg_execute_mutationC

Execute data modification operations (INSERT/UPDATE/DELETE/UPSERT) - operation="insert/update/delete/upsert" with table and data. Examples: operation="insert", table="users", data={"name":"John","email":"john@example.com"}

ParametersJSON Schema

Name	Required	Description	Default
`connectionString`	No	PostgreSQL connection string (optional)
`operation`	Yes	Mutation operation: insert (add rows), update (modify rows), delete (remove rows), upsert (insert or update)
`table`	Yes	Table name for the operation
`data`	No	Data object with column-value pairs (required for insert/update/upsert)
`where`	No	WHERE clause for update/delete operations (without WHERE keyword)
`conflictColumns`	No	Columns for conflict resolution in upsert (ON CONFLICT)
`returning`	No	RETURNING clause to get back inserted/updated data
`schema`	No	Schema name (defaults to public)	public

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states this is for data modification operations, implying mutations, but doesn't cover critical behaviors: no mention of permissions required, transaction handling, error behavior, or what happens on failure. The example shows basic usage but lacks depth on constraints, side effects, or safety considerations 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.

Conciseness4/5

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

The description is appropriately concise with two sentences: a clear purpose statement followed by a concrete example. The example efficiently demonstrates key parameters. No wasted words, though it could be slightly more structured by separating usage notes from the example.

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 complex mutation tool with 8 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain return values, error handling, transaction behavior, or security implications. The example helps but doesn't compensate for missing behavioral context needed for safe database operations.

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%, so the schema already documents all 8 parameters thoroughly. The description adds minimal value beyond the schema: it mentions operation, table, and data in the example but doesn't explain parameter interactions (e.g., when 'where' is required) or provide additional context. Baseline 3 is appropriate when schema does the heavy lifting.

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's purpose: 'Execute data modification operations (INSERT/UPDATE/DELETE/UPSERT)' with specific verbs and resources. It distinguishes from sibling tools like pg_execute_query by focusing on mutations rather than queries, though it doesn't explicitly name alternatives. The example reinforces the purpose but doesn't fully differentiate from all siblings.

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. It mentions the operation types but doesn't explain when to choose insert vs update vs delete vs upsert, nor does it reference sibling tools like pg_execute_query for read operations or pg_manage_* tools for schema changes. Usage context is implied but not explicit.

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

pg_execute_queryA

Execute SELECT queries and data retrieval operations - operation="select/count/exists" with query and optional parameters. Examples: operation="select", query="SELECT * FROM users WHERE created_at > $1", parameters=["2024-01-01"]

ParametersJSON Schema

Name	Required	Description
`connectionString`	No	PostgreSQL connection string (optional)
`operation`	Yes	Query operation: select (fetch rows), count (count rows), exists (check existence)
`query`	Yes	SQL SELECT query to execute
`parameters`	No	Parameter values for prepared statement placeholders ($1, $2, etc.)
`limit`	No	Maximum number of rows to return (safety limit)
`timeout`	No	Query timeout in milliseconds

TDQS

A3.5/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. While it mentions the tool executes queries with parameters and examples, it lacks critical behavioral details: it doesn't disclose safety limits (though 'limit' parameter exists in schema), authentication needs (connectionString handling), error handling, or return format. The description adds minimal value beyond basic operation explanation.

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 appropriately sized and front-loaded with the core purpose in the first sentence. The example adds practical value without being verbose. However, the second sentence could be slightly more structured, and there's some redundancy between the operation explanation and the example.

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 the complexity of a database query tool with 6 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain return formats, error conditions, connection handling, or safety implications despite the 'limit' parameter suggesting row limiting behavior. For a tool with this level of complexity, more contextual information 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?

Schema description coverage is 100%, so the baseline is 3. The description adds some value by explaining the 'operation' parameter with examples ('operation="select", query="SELECT * FROM users..."'), but doesn't provide additional semantics beyond what the schema already documents for other parameters like 'limit' or 'timeout'.

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's purpose with specific verbs ('Execute SELECT queries and data retrieval operations') and distinguishes it from sibling tools like 'pg_execute_mutation' by emphasizing read-only operations. It explicitly mentions the supported operations (select/count/exists) and provides concrete examples.

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 provides clear context about when to use this tool ('Execute SELECT queries and data retrieval operations') and implies when not to use it (for mutations, which would be handled by 'pg_execute_mutation'). However, it doesn't explicitly name alternatives or provide exclusion criteria beyond the operation types.

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

pg_execute_sqlA

Execute arbitrary SQL statements - sql="ANY_VALID_SQL" with optional parameters and transaction support. Examples: sql="CREATE INDEX ...", sql="WITH complex_cte AS (...) SELECT ...", transactional=true

ParametersJSON Schema

Name	Required	Description
`connectionString`	No	PostgreSQL connection string (optional)
`sql`	Yes	SQL statement to execute (can be any valid PostgreSQL SQL)
`parameters`	No	Parameter values for prepared statement placeholders ($1, $2, etc.)
`expectRows`	No	Whether to expect rows back (false for statements like CREATE, DROP, etc.)
`timeout`	No	Query timeout in milliseconds
`transactional`	No	Whether to wrap in a transaction

TDQS

A3.6/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden but only mentions transaction support. It doesn't disclose critical behavioral traits like whether this can execute destructive operations (DROP, DELETE), authentication requirements, rate limits, error handling, or what happens when expectRows mismatches query type.

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 efficiently structured in a single sentence with embedded examples, front-loading the core purpose. Every element (arbitrary SQL, parameter support, transaction support, examples) earns its place without redundancy.

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 powerful SQL execution tool with 6 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain return values, error behavior, security implications, or how parameters interact (e.g., transactional with expectRows). The complexity demands more complete guidance.

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%, so the schema already documents all parameters thoroughly. The description adds minimal value by mentioning 'optional parameters and transaction support' and providing examples that hint at sql parameter usage, but doesn't add meaningful semantics 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 ('Execute') and resource ('arbitrary SQL statements'), with specific examples showing the scope. It distinguishes from siblings like pg_execute_query and pg_execute_mutation by emphasizing 'arbitrary' SQL capability.

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 provides clear context with examples (CREATE INDEX, WITH complex_cte) and mentions transactional support, but doesn't explicitly state when to use this vs. specialized siblings like pg_execute_query for read-only operations or pg_execute_mutation for write operations.

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

pg_export_table_dataC

Export table data to JSON or CSV format

ParametersJSON Schema

Name	Required	Description	Default
`connectionString`	No
`tableName`	Yes
`outputPath`	Yes	absolute path to save the exported data
`where`	No
`limit`	No
`format`	No		json

TDQS

C2.8/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden but provides minimal behavioral context. It mentions output formats but doesn't disclose critical behaviors like: whether this requires write permissions to the output path, if it overwrites existing files, performance implications for large tables, authentication needs via connectionString, or error handling. The description doesn't contradict annotations (none exist), but fails to address important operational aspects.

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?

Extremely concise single sentence that front-loads the core purpose. Every word earns its place with no redundancy or unnecessary elaboration. The structure is optimal for a basic description.

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 6-parameter tool with no annotations and no output schema, the description is inadequate. It doesn't explain what the tool returns (success/failure indicators, file metadata), doesn't cover important behavioral aspects (permissions, file overwriting, error conditions), and leaves most parameters unexplained. The conciseness comes at the cost of completeness.

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 only 17% (1 of 6 parameters has a description). The description adds minimal value beyond the schema - it mentions JSON/CSV formats (covered by the enum) but doesn't explain parameter semantics like what 'where' clause syntax to use, how 'limit' interacts with filtering, or the purpose of 'connectionString' beyond being a string. It doesn't compensate for the low schema 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 clearly states the action ('Export') and resource ('table data') with specific output formats ('JSON or CSV format'). It distinguishes from siblings like pg_execute_query (which returns results directly) by focusing on file export, but doesn't explicitly differentiate from pg_copy_between_databases (which might also involve data movement).

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. It doesn't mention when to choose JSON vs CSV, when filtering/limiting is appropriate, or how it differs from siblings like pg_execute_query (which might return data without file export) or pg_copy_between_databases (which copies between databases).

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

pg_import_table_dataC

Import data from JSON or CSV file into a table

ParametersJSON Schema

Name	Required	Description	Default
`connectionString`	No
`tableName`	Yes
`inputPath`	Yes	absolute path to the file to import
`truncateFirst`	No
`format`	No		json
`delimiter`	No

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the import action but fails to describe critical behaviors: whether it overwrites existing data (hinted by 'truncateFirst' parameter but not explained), authentication needs (implied by 'connectionString' but not stated), error handling, or output format. This leaves significant gaps 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, efficient sentence that front-loads the core purpose without unnecessary words. Every part ('Import data from JSON or CSV file into a table') contributes directly to understanding the tool's function, making it appropriately concise.

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 mutation tool with 6 parameters, low schema coverage (17%), no annotations, and no output schema, the description is insufficient. It lacks details on behavior (e.g., data overwriting, error cases), parameter usage, and comparison to siblings, leaving the agent with inadequate context to use the tool effectively.

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 low (17%), with only 'inputPath' documented. The description adds minimal value by mentioning JSON/CSV formats, which aligns with the 'format' enum, but doesn't explain other parameters like 'connectionString', 'truncateFirst', or 'delimiter'. It partially compensates for the coverage gap but leaves most parameters semantically unclear.

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 action ('Import data') and resource ('from JSON or CSV file into a table'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like pg_export_table_data or pg_copy_between_databases, which would require more specific context about when to choose import vs. other data movement 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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., table must exist), compare to siblings like pg_copy_between_databases for database-to-database transfers, or specify scenarios where import is preferred over direct SQL execution via pg_execute_mutation.

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

pg_manage_commentsA

Manage PostgreSQL object comments - get, set, remove comments on tables, columns, functions, and other database objects. Examples: operation="get" with objectType="table", objectName="users", operation="set" with comment text, operation="bulk_get" for discovery

ParametersJSON Schema

Name	Required	Description
`connectionString`	No	PostgreSQL connection string (optional)
`operation`	Yes	Operation: get (retrieve comments), set (add/update comment), remove (delete comment), bulk_get (discovery mode)
`objectType`	No	Type of database object (required for get/set/remove)
`objectName`	No	Name of the object (required for get/set/remove)
`schema`	No	Schema name (defaults to public, required for most object types)
`columnName`	No	Column name (required when objectType is "column")
`comment`	No	Comment text (required for set operation)
`includeSystemObjects`	No	Include system objects in bulk_get (defaults to false)
`filterObjectType`	No	Filter by object type in bulk_get operation

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the core operations (get, set, remove, bulk_get) and provides examples, but doesn't mention important behavioral aspects like authentication requirements (connection string handling), error conditions, or whether operations are transactional/reversible. The examples help but don't fully compensate for the lack of annotation coverage.

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 appropriately sized with two sentences: one stating the purpose and scope, and another providing concrete examples. It's front-loaded with the core functionality and uses the examples efficiently to illustrate usage without unnecessary elaboration.

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 tool with 9 parameters, no annotations, and no output schema, the description is somewhat incomplete. While it covers the basic purpose and provides examples, it doesn't address important contextual aspects like return values (especially critical with no output schema), error handling, or the relationship between parameters (e.g., which parameters are required for which operations beyond the schema's 'required' field).

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?

With 100% schema description coverage, the schema already documents all 9 parameters thoroughly. The description adds minimal value beyond what's in the schema - it mentions 'operation' examples and 'objectType' examples but doesn't provide additional semantic context about parameter interactions or usage patterns beyond what the schema descriptions already state.

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's purpose with specific verbs ('get, set, remove') and resources ('PostgreSQL object comments'), and distinguishes it from siblings by focusing exclusively on comment management rather than broader database operations like query execution, user management, or constraint handling.

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 provides clear context for when to use the tool (managing comments on various database objects) and includes examples that illustrate different operations. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools for overlapping functionality.

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

pg_manage_constraintsB

Manage PostgreSQL constraints - get, create foreign keys, drop foreign keys, create constraints, drop constraints. Examples: operation="get" to list constraints, operation="create_fk" with constraintName, tableName, columnNames, referencedTable, referencedColumns

ParametersJSON Schema

Name	Required	Description
`connectionString`	No	PostgreSQL connection string (optional)
`operation`	Yes	Operation: get (list constraints), create_fk (foreign key), drop_fk (drop foreign key), create (constraint), drop (constraint)
`schema`	No	Schema name (defaults to public)
`constraintName`	No	Constraint name (required for create_fk/drop_fk/create/drop)
`tableName`	No	Table name (optional filter for get, required for create_fk/drop_fk/create/drop)
`constraintType`	No	Filter by constraint type (for get operation)
`columnNames`	No	Column names in the table (required for create_fk)
`referencedTable`	No	Referenced table name (required for create_fk)
`referencedColumns`	No	Referenced column names (required for create_fk)
`referencedSchema`	No	Referenced table schema (for create_fk, defaults to same as table schema)
`onUpdate`	No	ON UPDATE action (for create_fk)
`onDelete`	No	ON DELETE action (for create_fk)
`constraintTypeCreate`	No	Type of constraint to create (for create operation)
`checkExpression`	No	Check expression (for create operation with check constraints)
`deferrable`	No	Make constraint deferrable (for create_fk/create operations)
`initiallyDeferred`	No	Initially deferred (for create_fk/create operations)
`ifExists`	No	Include IF EXISTS clause (for drop_fk/drop operations)
`cascade`	No	Include CASCADE clause (for drop_fk/drop operations)

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions operations but fails to describe critical behavioral traits: whether operations are read-only or destructive (e.g., 'drop' likely destroys data), permission requirements, transaction handling, error behavior, or rate limits. The description only lists operations without behavioral context, leaving significant gaps for a tool with potentially destructive actions.

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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by examples. It avoids redundancy and wastes no words, though the example could be more structured. For a tool with 18 parameters, this brevity is efficient, but it sacrifices completeness for 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 the tool's high complexity (18 parameters, multiple operations including destructive ones), no annotations, and no output schema, the description is incomplete. It lacks essential context: behavioral risks (e.g., data loss from 'drop'), permission needs, error handling, and output format. The examples help but don't compensate for the missing safety and operational guidance required for such a multifaceted tool.

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%, providing a strong baseline. The description adds minimal parameter semantics beyond the schema: it mentions 'operation="get" to list constraints' and 'operation="create_fk" with constraintName, tableName, columnNames, referencedTable, referencedColumns,' which slightly clarifies usage but doesn't add meaningful syntax, format, or interaction details that aren't already in the schema's parameter descriptions.

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's purpose: 'Manage PostgreSQL constraints - get, create foreign keys, drop foreign keys, create constraints, drop constraints.' This specifies the verb ('manage') and resource ('PostgreSQL constraints') with enumeration of specific operations. It distinguishes from siblings by focusing on constraints rather than other database objects like indexes, functions, or users, though it doesn't explicitly contrast with them.

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 provides implied usage through examples: 'Examples: operation="get" to list constraints, operation="create_fk" with constraintName, tableName, columnNames, referencedTable, referencedColumns.' This gives basic guidance on when to use certain operations but lacks explicit when/when-not rules, prerequisites, or comparisons to alternative tools like pg_manage_indexes or pg_execute_sql for similar tasks.

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

pg_manage_functionsA

Manage PostgreSQL functions - get, create, or drop functions with a single tool. Examples: operation="get" to list functions, operation="create" with functionName="test_func", parameters="" (empty for no params), returnType="TEXT", functionBody="SELECT 'Hello'"

ParametersJSON Schema

Name	Required	Description
`connectionString`	No	PostgreSQL connection string (optional)
`operation`	Yes	Operation to perform: get (list/info), create (new function), or drop (remove function)
`functionName`	No	Name of the function (required for create/drop, optional for get to filter)
`schema`	No	Schema name (defaults to public)
`parameters`	No	Function parameters - required for create operation, required for drop when function is overloaded. Use empty string "" for functions with no parameters
`returnType`	No	Return type of the function (required for create operation)
`functionBody`	No	Function body code (required for create operation)
`language`	No	Function language (defaults to plpgsql for create)
`volatility`	No	Function volatility (defaults to VOLATILE for create)
`security`	No	Function security context (defaults to INVOKER for create)
`replace`	No	Whether to replace the function if it exists (for create operation)
`ifExists`	No	Whether to include IF EXISTS clause (for drop operation)
`cascade`	No	Whether to include CASCADE clause (for drop operation)

TDQS

A3.5/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. While it mentions the three operations (get, create, drop), it doesn't disclose critical behavioral traits: whether create/drop operations are destructive, what permissions are required, whether operations are transactional, or what happens on errors. The examples show basic usage but lack comprehensive behavioral context for a multi-operation tool.

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 appropriately sized with two sentences: a clear purpose statement followed by specific examples. It's front-loaded with the core functionality and uses examples efficiently to illustrate usage. Every sentence serves a purpose, though the example could be slightly more structured.

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 complex tool with 13 parameters, three distinct operations (including destructive create/drop), no annotations, and no output schema, the description is insufficient. It doesn't explain what the tool returns for different operations, error handling, transaction behavior, or the implications of create/drop operations. The examples help but don't compensate for the missing behavioral context needed for safe 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 description coverage is 100%, so the schema already documents all 13 parameters thoroughly. The description adds minimal value beyond the schema by mentioning examples like 'parameters="" (empty for no params)', but doesn't provide additional semantic context about parameter interactions or operation-specific requirements that aren't already in the schema descriptions.

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's purpose: 'Manage PostgreSQL functions - get, create, or drop functions with a single tool.' It specifies the exact operations (get, create, drop) and the resource (PostgreSQL functions), distinguishing it from siblings like pg_manage_indexes or pg_manage_triggers that handle different database objects.

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 provides clear context for when to use this tool through examples: 'operation="get" to list functions, operation="create" with functionName="test_func"...' It implicitly suggests this is for PostgreSQL function management rather than other database operations, but doesn't explicitly state when not to use it or name alternatives among siblings.

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

pg_manage_indexesB

Manage PostgreSQL indexes - get, create, drop, reindex, and analyze usage with a single tool. Examples: operation="get" to list indexes, operation="create" with indexName, tableName, columns, operation="analyze_usage" for performance analysis

ParametersJSON Schema

Name	Required	Description
`connectionString`	No	PostgreSQL connection string (optional)
`operation`	Yes	Operation: get (list indexes), create (new index), drop (remove index), reindex (rebuild), analyze_usage (find unused/duplicate)
`schema`	No	Schema name (defaults to public)
`tableName`	No	Table name (optional for get/analyze_usage, required for create)
`indexName`	No	Index name (required for create/drop)
`includeStats`	No	Include usage statistics (for get operation)
`columns`	No	Column names for the index (required for create operation)
`unique`	No	Create unique index (for create operation)
`concurrent`	No	Create/drop index concurrently (for create/drop operations)
`method`	No	Index method (for create operation, defaults to btree)
`where`	No	WHERE clause for partial index (for create operation)
`ifNotExists`	No	Include IF NOT EXISTS clause (for create operation)
`ifExists`	No	Include IF EXISTS clause (for drop operation)
`cascade`	No	Include CASCADE clause (for drop operation)
`target`	No	Target name for reindex (required for reindex operation)
`type`	No	Type of target for reindex (required for reindex operation)
`minSizeBytes`	No	Minimum index size in bytes (for analyze_usage operation)
`showUnused`	No	Include unused indexes (for analyze_usage operation)
`showDuplicates`	No	Detect duplicate indexes (for analyze_usage operation)

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden but offers minimal behavioral disclosure. It mentions operations but doesn't cover critical aspects like authentication needs (connection string handling), potential data loss from drop/reindex, performance impact of concurrent operations, or error handling. The examples add some context but insufficient for a complex 19-parameter tool.

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 appropriately sized with two sentences: a clear purpose statement followed by specific examples. It's front-loaded with the core functionality, though the example formatting could be slightly cleaner. Every sentence adds value without redundancy.

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 complex tool with 19 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain return values, error conditions, or behavioral nuances across different operations. While the schema provides parameter documentation, the description fails to offer the holistic guidance needed for proper tool selection and 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?

Schema description coverage is 100%, so the baseline is 3. The description adds marginal value by mentioning examples like 'operation="create" with indexName, tableName, columns' and 'operation="analyze_usage" for performance analysis,' but doesn't provide additional semantic context beyond what's already documented in the comprehensive schema descriptions.

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's purpose: 'Manage PostgreSQL indexes - get, create, drop, reindex, and analyze usage with a single tool.' It specifies the exact operations and distinguishes this multi-operation index management tool from its siblings, which focus on other database aspects like constraints, functions, or queries.

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 provides implied usage through examples (e.g., 'operation="get" to list indexes'), but lacks explicit guidance on when to use this tool versus alternatives. It doesn't mention prerequisites like database connection requirements or differentiate from sibling tools like pg_manage_constraints for related tasks.

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

pg_manage_queryA

Manage PostgreSQL query analysis and performance - operation="explain" for EXPLAIN plans, operation="get_slow_queries" for slow query analysis, operation="get_stats" for query statistics, operation="reset_stats" for clearing statistics

ParametersJSON Schema

Name	Required	Description	Default
`operation`	Yes	Operation: explain (EXPLAIN/EXPLAIN ANALYZE query), get_slow_queries (find slow queries from pg_stat_statements), get_stats (query statistics with cache hit ratios), reset_stats (reset pg_stat_statements)
`connectionString`	No
`query`	No	SQL query to explain (required for explain operation)
`analyze`	No	Use EXPLAIN ANALYZE - actually executes the query (for explain operation)
`buffers`	No	Include buffer usage information (for explain operation)
`verbose`	No	Include verbose output (for explain operation)
`costs`	No	Include cost estimates (for explain operation)
`format`	No	Output format (for explain operation)	json
`limit`	No	Number of slow queries to return (for get_slow_queries operation)
`minDuration`	No	Minimum average duration in milliseconds (for get_slow_queries operation)
`orderBy`	No	Sort order (for get_slow_queries and get_stats operations)	mean_time
`includeNormalized`	No	Include normalized query text (for get_slow_queries operation)
`minCalls`	No	Minimum number of calls (for get_stats operation)
`queryPattern`	No	Filter queries containing this pattern (for get_stats operation)
`queryId`	No	Specific query ID to reset (for reset_stats operation, resets all if not provided)

TDQS

A3.6/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden but provides minimal behavioral disclosure. It mentions what each operation does but doesn't cover important behavioral aspects like: whether operations require specific permissions, if reset_stats is destructive/irreversible, performance implications of analyze=true, rate limits, or what the output looks like. For a tool with potentially destructive operations (reset_stats) and complex behaviors, 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.

Conciseness5/5

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

The description is extremely concise and front-loaded: a single sentence efficiently communicates the tool's scope and all four operations. Every word earns its place with zero waste or redundancy. The structure clearly presents the operation-to-purpose mapping in a compact format.

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 the tool's complexity (15 parameters, 4 distinct operations including potentially destructive reset_stats), no annotations, and no output schema, the description is inadequate. It doesn't explain what the tool returns, doesn't warn about the destructive nature of reset_stats, doesn't mention prerequisites like pg_stat_statements extension, and provides minimal guidance on parameter interactions across different operations.

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 high (93%), so the baseline is 3. The description adds minimal value beyond the schema - it maps operation values to their purposes but doesn't explain parameter interactions or provide additional context about when to use specific parameters. The schema already documents most parameters well, so the description doesn't significantly enhance understanding.

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's purpose: 'Manage PostgreSQL query analysis and performance' with specific operations listed (explain, get_slow_queries, get_stats, reset_stats). It distinguishes from siblings like pg_execute_query (execution) and pg_analyze_database (database-wide analysis) by focusing specifically on query-level performance analysis.

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 provides clear context for when to use each operation (e.g., 'operation="explain" for EXPLAIN plans'), but doesn't explicitly state when NOT to use this tool or mention specific alternatives among siblings. The operational breakdown gives good guidance on selecting the right operation within this tool.

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

pg_manage_rlsB

Manage PostgreSQL Row-Level Security - enable/disable RLS and manage policies. Examples: operation="enable" with tableName="users", operation="create_policy" with tableName, policyName, using, check

ParametersJSON Schema

Name	Required	Description
`connectionString`	No	PostgreSQL connection string (optional)
`operation`	Yes	Operation: enable/disable RLS, create_policy, edit_policy, drop_policy, get_policies
`tableName`	No	Table name (required for enable/disable/create_policy/edit_policy/drop_policy, optional filter for get_policies)
`schema`	No	Schema name (defaults to public)
`policyName`	No	Policy name (required for create_policy/edit_policy/drop_policy)
`using`	No	USING expression for policy (required for create_policy, optional for edit_policy)
`check`	No	WITH CHECK expression for policy (optional for create_policy/edit_policy)
`command`	No	Command the policy applies to (for create_policy)
`role`	No	Role the policy applies to (for create_policy)
`replace`	No	Whether to replace policy if exists (for create_policy)
`roles`	No	List of roles for policy (for edit_policy)
`ifExists`	No	Include IF EXISTS clause (for drop_policy)

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions operations but doesn't describe critical behavioral traits: whether these are destructive changes (e.g., dropping policies), authentication requirements (connection string usage), error handling, or side effects. The examples hint at parameter usage but don't explain system impact or safety considerations.

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 appropriately sized with two sentences: a clear purpose statement followed by concrete examples. It's front-loaded with the core functionality and uses the examples efficiently to illustrate usage without unnecessary elaboration. Every sentence serves a functional purpose.

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 the tool's complexity (12 parameters, multiple operations including potentially destructive ones like 'drop_policy'), no annotations, and no output schema, the description is incomplete. It doesn't address critical context: what the tool returns, error conditions, permission requirements, or the safety profile of different operations. For a database management tool with mutation capabilities, this creates significant gaps for an AI agent.

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%, so the schema already documents all 12 parameters thoroughly. The description adds minimal value beyond the schema by listing example parameter combinations in the examples clause, but doesn't provide additional semantic context like parameter interdependencies or operational constraints not captured in the schema.

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's purpose: 'Manage PostgreSQL Row-Level Security - enable/disable RLS and manage policies.' It specifies the verb ('manage') and resource ('PostgreSQL Row-Level Security') with concrete operations. However, it doesn't explicitly differentiate from sibling tools like pg_manage_constraints or pg_manage_schema, which also manage PostgreSQL database objects.

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 provides implied usage through examples ('Examples: operation="enable" with tableName="users", operation="create_policy" with tableName, policyName, using, check'), showing when to use specific operations. However, it lacks explicit guidance on when to choose this tool over alternatives (e.g., vs. pg_manage_constraints for security vs. constraint management) or prerequisites like database permissions.

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

pg_manage_schemaB

Manage PostgreSQL schema - get schema info, create/alter tables, manage enums. Examples: operation="get_info" for table lists, operation="create_table" with tableName and columns, operation="get_enums" to list enums, operation="create_enum" with enumName and values

ParametersJSON Schema

Name	Required	Description
`connectionString`	No	PostgreSQL connection string (optional)
`operation`	Yes	Operation: get_info (schema/table info), create_table (new table), alter_table (modify table), get_enums (list ENUMs), create_enum (new ENUM)
`tableName`	No	Table name (optional for get_info to get specific table info, required for create_table/alter_table)
`schema`	No	Schema name (defaults to public)
`columns`	No	Column definitions (required for create_table)
`operations`	No	Alter operations (required for alter_table)
`enumName`	No	ENUM name (optional for get_enums to filter, required for create_enum)
`values`	No	ENUM values (required for create_enum)
`ifNotExists`	No	Include IF NOT EXISTS clause (for create_enum)

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions operations but doesn't clarify critical traits: whether operations are read-only or destructive (e.g., create_table alters database state), authentication needs (connectionString is optional but implications unclear), error handling, or transaction behavior. The examples add some context but leave major gaps for a multi-operation tool with potential mutations.

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 efficiently structured in two sentences: a purpose statement followed by operation examples. Each example earns its place by illustrating parameter usage. However, the examples are somewhat terse and could be more clearly formatted, slightly reducing readability.

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 the tool's complexity (9 parameters, multiple operations including mutations), no annotations, and no output schema, the description is incomplete. It doesn't address return values, error conditions, side effects, or prerequisites (e.g., database permissions). For a schema management tool with potential destructive operations, this leaves significant gaps for an AI agent.

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%, so the schema already documents all 9 parameters thoroughly. The description adds minimal value beyond the schema: it mentions operation examples and ties some parameters to operations (e.g., tableName for create_table), but doesn't explain semantics like column structure details or ifNotExists behavior. This meets the baseline for high schema 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 clearly states the tool manages PostgreSQL schema with specific operations (get schema info, create/alter tables, manage enums). It distinguishes from siblings like pg_execute_query or pg_manage_indexes by focusing on schema operations rather than queries, indexes, or other database aspects. However, it doesn't explicitly contrast with all siblings like pg_manage_constraints or pg_manage_functions.

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 provides examples that imply when to use different operations (e.g., operation='get_info' for table lists), giving some contextual guidance. However, it lacks explicit when-not-to-use advice or clear alternatives among siblings (e.g., when to use pg_manage_constraints instead for constraint operations). The examples serve as usage hints but aren't comprehensive guidelines.

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

pg_manage_triggersA

Manage PostgreSQL triggers - get, create, drop, and enable/disable triggers. Examples: operation="get" to list triggers, operation="create" with triggerName, tableName, functionName, operation="drop" with triggerName and tableName, operation="set_state" with triggerName, tableName, enable

ParametersJSON Schema

Name	Required	Description
`connectionString`	No	PostgreSQL connection string (optional)
`operation`	Yes	Operation: get (list triggers), create (new trigger), drop (remove trigger), set_state (enable/disable trigger)
`schema`	No	Schema name (defaults to public)
`tableName`	No	Table name (optional filter for get, required for create/drop/set_state)
`triggerName`	No	Trigger name (required for create/drop/set_state)
`functionName`	No	Function name (required for create operation)
`timing`	No	Trigger timing (for create operation, defaults to AFTER)
`events`	No	Trigger events (for create operation, defaults to ["INSERT"])
`forEach`	No	FOR EACH ROW or STATEMENT (for create operation, defaults to ROW)
`when`	No	WHEN clause condition (for create operation)
`replace`	No	Whether to replace trigger if exists (for create operation)
`ifExists`	No	Include IF EXISTS clause (for drop operation)
`cascade`	No	Include CASCADE clause (for drop operation)
`enable`	No	Whether to enable the trigger (required for set_state operation)

TDQS

A3.5/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions operations like create, drop, and set_state, which imply mutations, but fails to describe critical behaviors such as permissions needed, whether changes are reversible, error handling, or side effects (e.g., cascade drops). This leaves significant gaps for a tool with multiple mutation operations.

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 front-loaded with the core purpose and includes examples that are directly relevant. However, the example list is somewhat lengthy and could be streamlined. Most sentences earn their place by clarifying usage, but there is minor redundancy in parameter mentions.

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 the complexity (14 parameters, multiple mutation operations) and lack of annotations and output schema, the description is incomplete. It does not cover behavioral aspects like authentication needs, rate limits, or return formats, which are crucial for safe and effective use. This is inadequate for a tool with such scope and potential impact.

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%, so the schema already documents all 14 parameters thoroughly. The description adds minimal value by listing some parameters in examples (e.g., triggerName, tableName for operations), but does not provide additional semantics beyond what the schema offers. This meets the baseline for high schema coverage.

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 manages PostgreSQL triggers with specific verbs (get, create, drop, enable/disable) and distinguishes it from siblings like pg_manage_functions or pg_manage_constraints by focusing exclusively on triggers. It provides concrete examples of operations, making the purpose highly specific and actionable.

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 offers clear context on when to use each operation (e.g., operation='get' to list triggers, operation='create' with specific parameters), but it does not explicitly state when not to use this tool or mention alternatives among siblings. The examples provide implicit guidance, though explicit exclusions or comparisons are missing.

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

pg_manage_usersB

Manage PostgreSQL users and permissions - create, drop, alter users, grant/revoke permissions. Examples: operation="create" with username="testuser", operation="grant" with username, permissions, target, targetType

ParametersJSON Schema

Name	Required	Description
`connectionString`	No	PostgreSQL connection string (optional)
`operation`	Yes	Operation: create (new user), drop (remove user), alter (modify user), grant (permissions), revoke (permissions), get_permissions (view permissions), list (all users)
`username`	No	Username (required for create/drop/alter/grant/revoke/get_permissions, optional filter for list)
`password`	No	Password for the user (for create operation)
`superuser`	No	Grant superuser privileges (for create/alter operations)
`createdb`	No	Allow user to create databases (for create/alter operations)
`createrole`	No	Allow user to create roles (for create/alter operations)
`login`	No	Allow user to login (for create/alter operations)
`replication`	No	Allow replication privileges (for create/alter operations)
`connectionLimit`	No	Maximum number of connections (for create/alter operations)
`validUntil`	No	Password expiration date YYYY-MM-DD (for create/alter operations)
`inherit`	No	Inherit privileges from parent roles (for create/alter operations)
`ifExists`	No	Include IF EXISTS clause (for drop operation)
`cascade`	No	Include CASCADE to drop owned objects (for drop/revoke operations)
`permissions`	No	Permissions to grant/revoke: ["SELECT", "INSERT", "UPDATE", "DELETE", "TRUNCATE", "REFERENCES", "TRIGGER", "ALL"]
`target`	No	Target object name (for grant/revoke operations)
`targetType`	No	Type of target object (for grant/revoke operations)
`withGrantOption`	No	Allow user to grant these permissions to others (for grant operation)
`schema`	No	Filter by schema (for get_permissions operation)
`includeSystemRoles`	No	Include system roles (for list operation)

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure but offers minimal information. It mentions operations like 'create' and 'drop' which imply mutations, but doesn't clarify critical behaviors such as authentication requirements, whether operations are reversible, potential side effects (e.g., cascade deletions), or error handling. For a complex tool with 20 parameters and no annotations, this is a significant gap.

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 appropriately sized and front-loaded, starting with the core purpose and immediately providing concrete examples. The two sentences are efficient with zero waste, though it could be slightly more structured by separating purpose from examples. Every sentence earns its place by clarifying the tool's scope.

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 the tool's high complexity (20 parameters, multiple operations including destructive ones like 'drop'), lack of annotations, and no output schema, the description is incomplete. It doesn't address behavioral aspects like safety warnings, permission requirements, or expected return formats. For a multi-operation tool with potential destructive actions, more contextual guidance 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?

Schema description coverage is 100%, so the schema already documents all 20 parameters thoroughly. The description adds marginal value by listing example operations ('create', 'grant') and mentioning a few parameters (username, permissions, target, targetType) in examples, but doesn't provide additional semantic context beyond what's in the schema. This meets the baseline for high schema coverage.

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's purpose with specific verbs ('manage', 'create', 'drop', 'alter', 'grant/revoke') and resources ('PostgreSQL users and permissions'). It distinguishes itself from sibling tools like pg_execute_query or pg_manage_schema by focusing exclusively on user management operations rather than general queries or schema objects.

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 provides implied usage through examples ('operation="create" with username="testuser"'), but lacks explicit guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., database connection requirements) or compare with sibling tools like pg_manage_query for permission-related queries, leaving the agent to infer appropriate contexts.

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

pg_monitor_databaseC

Get real-time monitoring information for a PostgreSQL database

ParametersJSON Schema

Name	Required	Description
`connectionString`	No
`includeTables`	No
`includeQueries`	No
`includeLocks`	No
`includeReplication`	No
`alertThresholds`	No	Alert thresholds

TDQS

C2.8/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Get real-time monitoring information,' implying a read-only operation, but doesn't specify whether this requires specific permissions, has rate limits, returns structured data, or involves any side effects. For a monitoring tool with 6 parameters and no annotation coverage, this is a significant gap in 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?

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.

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 the complexity (6 parameters, nested objects, no output schema, and no annotations), the description is incomplete. It doesn't address the tool's behavior, output format, or parameter usage, which are crucial for a monitoring tool with multiple configuration options. This leaves significant gaps for an AI agent to understand how to invoke it effectively.

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 at 17%, with only the 'alertThresholds' object having descriptions. The description doesn't add any meaning beyond the schema, such as explaining what 'includeTables' or 'connectionString' entail in the context of monitoring. It fails to compensate for the poor schema coverage, leaving most parameters semantically unclear.

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 ('Get') and resource ('real-time monitoring information for a PostgreSQL database'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from siblings like 'pg_analyze_database' or 'pg_debug_database', which might also provide database insights, so it misses full sibling differentiation.

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 like 'pg_analyze_database' or 'pg_debug_database'. It lacks context about prerequisites, such as needing a valid connection string, or exclusions, leaving the agent to infer usage based on the name alone.

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

B3.2/5.0

Disambiguation4/5

Most tools have distinct purposes targeting specific PostgreSQL management areas (e.g., schema, indexes, constraints), but some overlap exists. For example, pg_execute_mutation and pg_execute_sql both handle data modifications, and pg_manage_query's performance analysis overlaps with pg_analyze_database. However, descriptions help clarify boundaries, preventing major confusion.

Naming Consistency5/5

All tools follow a consistent 'pg_verb_noun' pattern with snake_case throughout (e.g., pg_manage_schema, pg_execute_query). This predictable naming convention makes it easy for agents to identify tool purposes and maintain readability across the set.

Tool Count4/5

With 18 tools, the count is slightly high but reasonable for a comprehensive PostgreSQL management server. It covers a wide range of database operations from queries to administration, though it might feel heavy for simpler use cases. Each tool appears to earn its place by addressing specific PostgreSQL features.

Completeness5/5

The tool set provides extensive coverage of PostgreSQL management, including CRUD operations (via pg_execute_mutation/query), schema management, performance monitoring, security (RLS, users), and data import/export. No obvious gaps are present; agents can handle full database lifecycles and advanced features without dead ends.

Maintenance

ActivityStale

ResponsivenessSyncing

Resources

Need Help?

Reddit Discussion

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

mcpOAuth
io.prisma
MCP server for managing Prisma Postgres.
Databases Developer Tools
247
PGAuditor
com.mcpgatepro
Hosted MCP server for PostgreSQL diagnostics: slow queries, missing indexes, connection pressure.
Databases Monitoring Observability
1
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
mcpOAuth
com.gibsonai
GibsonAI MCP server: manage your databases with natural language
Databases Search
233

Related MCP Servers

PostgreSQL MCP Server
Databases Code Execution
1Levick3
A
license
A
quality
D
maintenance
A Model Context Protocol server that enables interaction with PostgreSQL databases for analyzing setups, debugging issues, managing schemas, migrating data, and monitoring performance.
Updated a year ago (2025-04-29 11:20 UTC)
1
19
1
MIT
PostgreSQL MCP Server
Databases RAG Systems
ahmedmustahid
A
license
Not graded
quality
F
maintenance
A Model Context Protocol server providing dual transport (HTTP and Stdio) access to PostgreSQL databases, allowing AI assistants to query databases and fetch schema information through natural language.
Updated a year ago (2025-07-14 09:23 UTC)
101
31
MIT
Postgres MCP Pro
Databases Developer Tools Code Execution
moecodeshere
A
license
B
quality
D
maintenance
An open source Model Context Protocol server for PostgreSQL that provides database health analysis, index tuning, query plan exploration, and safe SQL execution for AI agents throughout the development process.
Updated a year ago (2025-08-03 17:45 UTC)
9
MIT
pg-mcp-server
Databases Developer Tools
stuzero
A
license
Not graded
quality
D
maintenance
A Model Context Protocol server for PostgreSQL databases that enables AI agents to connect, query, and explore multiple databases with schema discovery and extension context.
Updated a year ago (2025-09-10 13:01 UTC)
540
MIT

Appeared in Searches

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

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

PostgreSQL MCP 服务器

版本 0.2.0

特征

1. 数据库分析和设置

1.1. 分析数据库（ analyze_database ）

1.2. 获取设置说明（ get_setup_instructions ）

1.3. 调试数据库（ debug_database ）

2. 模式管理

2.1. 获取架构信息（ get_schema_info ）

2.2. 创建表（ create_table ）

2.3. 修改表（ alter_table ）

2.4. 获取枚举（ get_enums ）

2.5. 创建枚举（ create_enum ）

3.数据迁移

3.1. 导出表数据（ export_table_data ）

3.2. 导入表数据（ import_table_data ）

3.3. 数据库间复制（ copy_between_databases ）

4. 监控

4.1. 监控数据库（ monitor_database ）

5. 功能

5.1. 获取函数（ get_functions ）

5.2. 创建函数（ create_function ）

5.3. 删除函数（ drop_function ）

6. 行级安全性（RLS）

6.1. 启用 RLS ( enable_rls )

6.2. 禁用 RLS ( disable_rls )

6.3. 创建 RLS 策略（ create_rls_policy ）

6.4. 编辑 RLS 策略（ edit_rls_policy ）

6.5. 删除 RLS 策略（ drop_rls_policy ）

6.6. 获取 RLS 策略（ get_rls_policies ）

7. 触发器

7.1. 获取触发器（ get_triggers ）

7.2. 创建触发器（ create_trigger ）

7.3. 删除触发器（ drop_trigger ）

7.4. 设置触发器状态（ set_trigger_state ）

先决条件

安装

通过 Smithery 安装

手动安装

工具配置

发展

安全注意事项

最佳实践

错误处理

贡献

执照

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

MCP directory API

1.1. 分析数据库（ `analyze_database` ）

1.2. 获取设置说明（ `get_setup_instructions` ）

1.3. 调试数据库（ `debug_database` ）

2.1. 获取架构信息（ `get_schema_info` ）

2.2. 创建表（ `create_table` ）

2.3. 修改表（ `alter_table` ）

2.4. 获取枚举（ `get_enums` ）

2.5. 创建枚举（ `create_enum` ）

3.1. 导出表数据（ `export_table_data` ）

3.2. 导入表数据（ `import_table_data` ）

3.3. 数据库间复制（ `copy_between_databases` ）

4.1. 监控数据库（ `monitor_database` ）

5.1. 获取函数（ `get_functions` ）

5.2. 创建函数（ `create_function` ）

5.3. 删除函数（ `drop_function` ）

6.1. 启用 RLS ( `enable_rls` )

6.2. 禁用 RLS ( `disable_rls` )

6.3. 创建 RLS 策略（ `create_rls_policy` ）

6.4. 编辑 RLS 策略（ `edit_rls_policy` ）

6.5. 删除 RLS 策略（ `drop_rls_policy` ）

6.6. 获取 RLS 策略（ `get_rls_policies` ）

7.1. 获取触发器（ `get_triggers` ）

7.2. 创建触发器（ `create_trigger` ）

7.3. 删除触发器（ `drop_trigger` ）

7.4. 设置触发器状态（ `set_trigger_state` ）