PostgreSQL MCP Server (Read-Write)

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation3/5
The specialized tools (query, insert, update, delete, execute_ddl) each map to distinct SQL operations, but the generic execute tool can perform any of these operations, creating overlap and making tool selection less clear.
Naming Consistency4/5
Most tools use a simple verb form (query, insert, update, delete, execute), while execute_ddl uses a verb_noun pattern. This is a minor inconsistency but the naming is still predictable.
Tool Count5/5
Six tools is an appropriate scope for a PostgreSQL read-write server, providing dedicated operations without bloat.
Completeness5/5
The surface covers all core SQL operations (SELECT, INSERT, UPDATE, DELETE, DDL) plus a generic escape hatch for arbitrary SQL, so there are no obvious gaps.
Average 3.4/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of disclosing behavioral traits. It only says 'update data', which is obvious, but does not mention side effects, transactionality, required permissions, or any risks. The mutation implication is present but no additional context is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly states the tool's function. There is no unnecessary verbiage, and the information is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a mutation operation with no annotations, no output schema, and a very minimal description. It lacks usage guidance and behavioral transparency, and the presence of sibling tools like 'execute' and 'execute_ddl' creates ambiguity that is not addressed. The simple parameter schema is well-covered, but overall the description is incomplete for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the single parameter, and its description ('the UPDATE SQL statement to execute') accurately describes it. The tool description adds no further semantic value beyond what the schema already provides, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('execute UPDATE') and resource ('data in the table'), clearly distinguishing it from siblings like query, insert, and delete. It is clear and unambiguous, though it could be slightly more explicit about what 'update' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as the generic 'execute' or 'execute_ddl'. The description does not mention prerequisites, typical use cases, or exclusions, leaving the agent to infer the intended scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only restates the tool's core function. It does not mention whether the operation is safe/unsafe, whether it returns results, errors, or side effects, or any permission requirements. This is a minimal restatement rather than meaningful behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the main action and purpose. While it is very short, it contains no wasted words, though it could benefit from additional context as noted in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 1-parameter tool with good schema coverage, the description is functional but incomplete. It fails to clarify how this tool differs from the sibling 'execute' tool, nor does it describe return behavior or side effects, creating ambiguity that could lead to incorrect tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already includes a full description for the only parameter (sql), achieving 100% schema description coverage. The tool description adds no additional parameter semantics beyond what the schema provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as executing INSERT statements to add new data to tables, using a specific verb ('执行'/'execute') and resource ('INSERT 语句'/'INSERT statement'). This distinguishes it from sibling tools like query, update, and delete, which handle other types of SQL operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the generic 'execute' tool or 'execute_ddl'. The description does not mention exclusions, prerequisites, or alternative tools, leaving the agent to infer the appropriate context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'delete data from table' which implies destructive behavior, but offers no additional context about irreversibility, cascading effects, transaction handling, or permissions required. Without annotations, this is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that clearly communicates the core action without any wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations or output schema, the description is too sparse. It omits important context such as cautionary notes, exclusion from safe usage, and what the result of the operation might be. The simplicity of parameters does not compensate for the lack of behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the single parameter with a description of 'DELETE SQL statement to execute.' The tool description adds no further meaning or context beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes DELETE statements to remove data from tables, which is a specific verb+resource pairing. It distinguishes itself from sibling tools like query, insert, and update by explicitly naming the DELETE operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as update or execute. There are no prerequisites, caveats, or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool can perform DML and DDL, which implies potential data modifications and schema changes. Since no annotations are provided, this is useful context, but it does not elaborate on side effects, permissions, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but slightly redundant ('any SQL statement' and 'any SQL operation' repeat the same idea). It is still efficient and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a generic executor with no output schema and no annotations, the description should clarify expected return values, potential dangers (e.g., destructive DDL), and when it should be preferred over specific sibling tools. It does none of these, leaving significant gaps for safe and correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'sql' parameter, so the schema already documents it fully. The description adds no additional parameter-level meaning beyond restating that it executes SQL, keeping the score at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes any SQL statement (query, DML, DDL), identifying the verb (execute) and resource (SQL). It distinguishes from siblings by being the generic catch-all, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a universal fallback for any SQL operation, but it does not explicitly state when to use this tool over the more specific siblings like query, insert, update, or delete. It lacks clear when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It does state the tool only accepts SELECT statements and returns query results, which implies a read-only nature. However, it does not mention potential side effects, error handling, or result formatting, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short sentences that each convey useful information: the action (execute SELECT) and the purpose (read data). It is front-loaded and has no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for a simple tool, but it does not clarify how 'query' differs from the sibling 'execute' tool, which could cause confusion. It also does not describe the return format or any limitations. Given the minimal schema and no output schema, more contextual detail would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the parameter 'sql' is described as the SELECT query to execute. The tool description adds little beyond repeating 'SELECT', which is already in the schema. Thus, it meets the baseline but does not go beyond.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes SELECT queries and is used for reading data. This specific verb+resource combination (execute SELECT, read) distinguishes it from write-oriented siblings like insert, update, and delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool should be used for read operations ('用于读取数据'), which is clear context. However, it does not explicitly exclude other usages or mention alternatives such as the generic 'execute' tool, so it falls short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It explicitly mentions DROP and 'delete database objects', which signals destructive potential. However, it does not warn about irreversibility, locking, or permissions, leaving some behavioral gaps. The explicit mention of DROP earns a middle score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the core action and examples, and contains zero wasted words. It efficiently conveys purpose and scope, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and full schema coverage, the description provides sufficient context: what it does, when to use it, and what operations are possible. It lacks details about return values or side effects like transaction behavior, but these are less critical for DDL execution. The description is functionally complete for agent comprehension.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage for the single 'sql' parameter is 100%, so the schema fully documents the parameter's meaning. The description repeats that the parameter is a DDL SQL statement without adding extra formatting, syntax, or constraints. This matches the baseline of 3, as the description adds no meaningful value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('execute') with a clear resource ('DDL statements'), lists concrete examples (CREATE, ALTER, DROP), and states the overall purpose (create, modify, delete database objects). This strongly distinguishes it from sibling tools like query, insert, update, and delete, which handle DML.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly establishes when this tool should be used: for DDL statements that manage database objects. It doesn't explicitly name alternatives, but the context is unambiguous—users should choose this for schema operations, and other tools for data manipulation. No exclusions are needed given the semantic clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-server-postgresql-rw MCP server](https://glama.ai/mcp/servers/yanxxcloud/mcp-server-postgresql-rw/badges/card.svg)](https://glama.ai/mcp/servers/yanxxcloud/mcp-server-postgresql-rw)

Score Badge

Copy to your README.md:

[![mcp-server-postgresql-rw MCP server](https://glama.ai/mcp/servers/yanxxcloud/mcp-server-postgresql-rw/badges/score.svg)](https://glama.ai/mcp/servers/yanxxcloud/mcp-server-postgresql-rw)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/yanxxcloud/mcp-server-postgresql-rw'

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