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

Servidor MCP de PostgreSQL

insignia de herrería

Un servidor de Protocolo de Contexto de Modelo (MCP) que proporciona funciones de gestión de bases de datos PostgreSQL. Este servidor ayuda a analizar las configuraciones existentes de PostgreSQL, proporciona orientación para la implementación, depura problemas de la base de datos, gestiona esquemas, migra datos y supervisa el rendimiento de la base de datos.

Versión 0.2.0

Related MCP server: PostgreSQL MCP Server

Características

El servidor proporciona las siguientes herramientas:

1. Análisis y configuración de la base de datos

1.1. Analizar la base de datos ( `analyze_database` )

Analiza la configuración de la base de datos PostgreSQL y las métricas de rendimiento:

Análisis de configuración
Métricas de rendimiento
Evaluación de seguridad
Recomendaciones para la optimización

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

1.2. Obtener instrucciones de configuración ( `get_setup_instructions` )

Proporciona una guía paso a paso para la instalación y configuración de PostgreSQL:

Pasos de instalación específicos de la plataforma
Recomendaciones de configuración
Mejores prácticas de seguridad
Tareas posteriores a la instalación

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

1.3. Base de datos de depuración ( `debug_database` )

Depurar problemas comunes de PostgreSQL:

Problemas de conexión
Cuellos de botella en el rendimiento
Conflictos de bloqueo
Estado de replicación

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

2. Gestión de esquemas

2.1. Obtener información del esquema ( `get_schema_info` )

Obtenga información detallada del esquema para una base de datos o una tabla específica:

Lista de tablas en una base de datos
Definiciones de columnas
Restricciones (claves primarias, claves externas, etc.)
Índices

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

2.2. Crear tabla ( `create_table` )

Crear una nueva tabla con columnas específicas:

Definir nombres y tipos de columnas
Establecer restricciones que acepten valores nulos
Establecer valores predeterminados

// 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. Alterar tabla ( `alter_table` )

Modificar tablas existentes:

Agregar nuevas columnas
Modificar tipos de columnas o restricciones
Columnas de caída

// 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. Obtener enumeraciones ( `get_enums` )

Obtenga información sobre los tipos ENUM de PostgreSQL.

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

2.5. Crear enumeración ( `create_enum` )

Crea un nuevo tipo ENUM en la base de datos.

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

3. Migración de datos

3.1. Exportar datos de tabla ( `export_table_data` )

Exportar datos de la tabla a formato JSON o CSV:

Filtrar datos con la cláusula WHERE
Limitar el número de filas
Elija el formato de salida

// 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. Importar datos de tabla ( `import_table_data` )

Importar datos desde archivos JSON o CSV:

Opcionalmente, truncar la tabla antes de importarla
Soporte para diferentes formatos
Delimitadores CSV personalizados

// 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. Copiar entre bases de datos ( `copy_between_databases` )

Copiar datos entre dos bases de datos PostgreSQL:

Filtrar datos con la cláusula WHERE
Truncar opcionalmente la tabla de destino

// 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. Monitoreo

4.1. Base de datos de monitor ( `monitor_database` )

Monitoreo en tiempo real de la base de datos PostgreSQL:

Métricas de base de datos (conexiones, tasa de aciertos de caché, etc.)
Métricas de tabla (tamaño, número de filas, tuplas muertas)
Información de consulta activa
Información de bloqueo
Estado de replicación
Alertas configurables

// 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. Funciones

5.1. Obtener funciones ( `get_functions` )

Obtenga información sobre las funciones de PostgreSQL.

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

5.2. Crear función ( `create_function` )

Crear o reemplazar una función 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. Función de eliminación ( `drop_function` )

Eliminar una función PostgreSQL.

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

6. Seguridad a nivel de fila (RLS)

6.1. Habilitar RLS ( `enable_rls` )

Habilitar seguridad a nivel de fila en una tabla.

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

6.2. Deshabilitar RLS ( `disable_rls` )

Deshabilitar la seguridad a nivel de fila en una tabla.

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

6.3. Crear una política RLS ( `create_rls_policy` )

Crear una política de seguridad a nivel de fila.

// 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. Editar la política RLS ( `edit_rls_policy` )

Editar una política de seguridad de nivel de fila existente.

// 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. Política de eliminación de RLS ( `drop_rls_policy` )

Eliminar una política de seguridad a nivel de fila.

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

6.6. Obtener políticas de RLS ( `get_rls_policies` )

Obtenga políticas de seguridad a nivel de fila.

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

7. Desencadenantes

7.1. Obtener disparadores ( `get_triggers` )

Obtenga información sobre los desencadenadores de PostgreSQL.

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

7.2. Crear disparador ( `create_trigger` )

Crear un disparador de 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. Disparador de caída ( `drop_trigger` )

Eliminar un disparador de PostgreSQL.

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

7.4. Establecer el estado del disparador ( `set_trigger_state` )

Habilitar o deshabilitar un disparador de PostgreSQL.

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

Prerrequisitos

Node.js >= 18.0.0
Servidor PostgreSQL (para operaciones de base de datos de destino)
Acceso de red a instancias de PostgreSQL de destino

Instalación

Instalación mediante herrería

Para instalar postgresql-mcp-server para Claude Desktop automáticamente a través de Smithery :

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

Instalación manual

Clonar el repositorio
Instalar dependencias:
```
npm install
```
Construir el servidor:
```
npm run build
```
Agregar al archivo de configuración de MCP (por ejemplo, en la configuración de su IDE o en una configuración global de MCP):
Hay algunas formas de configurar la cadena de conexión para el servidor, con el siguiente orden de precedencia:
1. Argumento específico de la herramienta : si se proporciona una connectionString directamente en los argumentos al llamar a una herramienta específica, ese valor se utilizará para esa llamada.
2. Argumento CLI : puede proporcionar una cadena de conexión predeterminada al iniciar el servidor utilizando el argumento -cs o --connection-string .
3. Variable de entorno : si no se proporciona ninguna de las anteriores, el servidor buscará una variable de entorno POSTGRES_CONNECTION_STRING .
Si no se encuentra ninguna cadena de conexión a través de ninguno de estos métodos, las herramientas que requieren una conexión a la base de datos fallarán.
Ejemplo de uso del argumento CLI en la configuración de MCP:
```
{
  "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.
    }
  }
}
```
Ejemplo que utiliza una variable de entorno (si no se utiliza el argumento 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"
      }
    }
  }
}
```
El uso del argumento CLI --connection-string o la variable de entorno POSTGRES_CONNECTION_STRING hace que el argumento connectionString sea opcional para la mayoría de las llamadas de herramientas.

Configuración de herramientas

El servidor admite el filtrado de qué herramientas están habilitadas a través de un archivo de configuración JSON externo.

Opción CLI : utilice -tc <path> o --tools-config <path> para especificar la ruta a su archivo de configuración de herramientas.
Formato de archivo : el archivo JSON debe contener un objeto con una clave enabledTools , que contiene una matriz de cadenas de nombres de herramientas.
Ejemplo mcp-tools.json :
```
{
  "enabledTools": [
    "get_schema_info",
    "analyze_database",
    "export_table_data"
  ]
}
```
Comportamiento :
- Si se proporciona el archivo de configuración y es válido, solo se habilitarán las herramientas enumeradas.
- Si no se proporciona el archivo, no es válido o no se puede leer, todas las herramientas se habilitarán de forma predeterminada.
- El servidor registrará qué herramientas están habilitadas en función de esta configuración.

Desarrollo

npm run dev : inicia el servidor de desarrollo con recarga activa
npm run lint - Ejecutar ESLint
npm test - Ejecutar pruebas (si está configurado)

Consideraciones de seguridad

Seguridad de la conexión
- El servidor determina la cadena de conexión a la base de datos según la siguiente precedencia:
  1. connectionString proporcionada directamente en los argumentos de una herramienta.
  2. --connection-string Argumento CLI utilizado al iniciar el servidor.
  3. Variable de entorno POSTGRES_CONNECTION_STRING .
- Asegúrese de que las cadenas de conexión (especialmente aquellas con credenciales) se administren de forma segura.
- Utiliza agrupación de conexiones a través de pg (anteriormente @vercel/postgres ).
- Valida cadenas de conexión.
- Admite conexiones SSL/TLS (configuración mediante cadena de conexión).
Seguridad de consultas
- Ejecuta operaciones predefinidas; evita la ejecución arbitraria de SQL siempre que sea posible.
- Utiliza consultas parametrizadas cuando sea aplicable para evitar la inyección de SQL.
- Registra operaciones para auditoría.
Autenticación
- Se basa en los mecanismos de autenticación de PostgreSQL a través de la cadena de conexión.
- Administre de forma segura las credenciales de su base de datos. Si es posible, no las codifique en las solicitudes de cliente; utilice preferentemente la opción CLI --connection-string o la variable de entorno POSTGRES_CONNECTION_STRING al configurar el servidor.

Mejores prácticas

Configure la cadena de conexión de base de datos predeterminada de forma segura utilizando la opción CLI --connection-string o la variable de entorno POSTGRES_CONNECTION_STRING .
Si una herramienta necesita conectarse a una base de datos diferente a la predeterminada, proporcione la connectionString directamente en los argumentos de esa herramienta.
Utilice siempre cadenas de conexión seguras con credenciales adecuadas, preferiblemente configuradas a través de la variable de entorno POSTGRES_CONNECTION_STRING .
Siga las recomendaciones de seguridad de producción para entornos sensibles.
Supervise y analice periódicamente el rendimiento de la base de datos utilizando la herramienta monitor_database .
Mantenga la versión de PostgreSQL actualizada.
Implementar estrategias de backup adecuadas de forma independiente.
Utilice la agrupación de conexiones para una mejor gestión de recursos (gestionada internamente).
Implementar el manejo y registro de errores adecuados.
Auditorías y actualizaciones de seguridad periódicas.

Manejo de errores

El servidor implementa el manejo de errores para:

Fallos de conexión
Errores de consulta
Entradas no válidas
Problemas de permisos

Los errores se devuelven en el formato de error MCP estándar.

Contribuyendo

Bifurcar el repositorio
Crear una rama de características
Confirme sus cambios
Empujar hacia la rama
Crear una solicitud de extracción

Licencia

Este proyecto está licenciado bajo la licencia AGPLv3: consulte el archivo de LICENCIA para obtener más detalles.

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.

Tool Schema Changelog

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

18 tool updatesAug 15, 2025
- First observedpg_analyze_database
- First observedpg_copy_between_databases
- First observedpg_debug_database
- First observedpg_execute_mutation
- First observedpg_execute_query
- First observedpg_execute_sql
- First observedpg_export_table_data
- First observedpg_import_table_data
- First observedpg_manage_comments
- First observedpg_manage_constraints
- First observedpg_manage_functions
- First observedpg_manage_indexes
- First observedpg_manage_query
- First observedpg_manage_rls
- First observedpg_manage_schema
- First observedpg_manage_triggers
- First observedpg_manage_users
- First observedpg_monitor_database

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

Servidor MCP de PostgreSQL

Versión 0.2.0

Características

1. Análisis y configuración de la base de datos

1.1. Analizar la base de datos ( analyze_database )

1.2. Obtener instrucciones de configuración ( get_setup_instructions )

1.3. Base de datos de depuración ( debug_database )

2. Gestión de esquemas

2.1. Obtener información del esquema ( get_schema_info )

2.2. Crear tabla ( create_table )

2.3. Alterar tabla ( alter_table )

2.4. Obtener enumeraciones ( get_enums )

2.5. Crear enumeración ( create_enum )

3. Migración de datos

3.1. Exportar datos de tabla ( export_table_data )

3.2. Importar datos de tabla ( import_table_data )

3.3. Copiar entre bases de datos ( copy_between_databases )

4. Monitoreo

4.1. Base de datos de monitor ( monitor_database )

5. Funciones

5.1. Obtener funciones ( get_functions )

5.2. Crear función ( create_function )

5.3. Función de eliminación ( drop_function )

6. Seguridad a nivel de fila (RLS)

6.1. Habilitar RLS ( enable_rls )

6.2. Deshabilitar RLS ( disable_rls )

6.3. Crear una política RLS ( create_rls_policy )

6.4. Editar la política RLS ( edit_rls_policy )

6.5. Política de eliminación de RLS ( drop_rls_policy )

6.6. Obtener políticas de RLS ( get_rls_policies )

7. Desencadenantes

7.1. Obtener disparadores ( get_triggers )

7.2. Crear disparador ( create_trigger )

7.3. Disparador de caída ( drop_trigger )

7.4. Establecer el estado del disparador ( set_trigger_state )

Prerrequisitos

Instalación

Instalación mediante herrería

Instalación manual

Configuración de herramientas

Desarrollo

Consideraciones de seguridad

Mejores prácticas

Manejo de errores

Contribuyendo

Licencia

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

MCP directory API

1.1. Analizar la base de datos ( `analyze_database` )

1.2. Obtener instrucciones de configuración ( `get_setup_instructions` )

1.3. Base de datos de depuración ( `debug_database` )

2.1. Obtener información del esquema ( `get_schema_info` )

2.2. Crear tabla ( `create_table` )

2.3. Alterar tabla ( `alter_table` )

2.4. Obtener enumeraciones ( `get_enums` )

2.5. Crear enumeración ( `create_enum` )

3.1. Exportar datos de tabla ( `export_table_data` )

3.2. Importar datos de tabla ( `import_table_data` )

3.3. Copiar entre bases de datos ( `copy_between_databases` )

4.1. Base de datos de monitor ( `monitor_database` )

5.1. Obtener funciones ( `get_functions` )

5.2. Crear función ( `create_function` )

5.3. Función de eliminación ( `drop_function` )

6.1. Habilitar RLS ( `enable_rls` )

6.2. Deshabilitar RLS ( `disable_rls` )

6.3. Crear una política RLS ( `create_rls_policy` )

6.4. Editar la política RLS ( `edit_rls_policy` )

6.5. Política de eliminación de RLS ( `drop_rls_policy` )

6.6. Obtener políticas de RLS ( `get_rls_policies` )

7.1. Obtener disparadores ( `get_triggers` )

7.2. Crear disparador ( `create_trigger` )

7.3. Disparador de caída ( `drop_trigger` )

7.4. Establecer el estado del disparador ( `set_trigger_state` )