postgres-mcp-readonly

Server Quality Checklist

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

Latest release: v1.1.1
Disambiguation4/5
Most tools have clearly distinct purposes (querying, counting, previewing, explaining, validating). However, validate_insert is a subset of validate_sql, and table_info can duplicate indexes/constraints/relationships for a single table, creating minor confusion.
Naming Consistency4/5
All tools use the same 'db.' prefix and snake_case, which is consistent. However, the second part mixes nouns (databases, schema, query) and verbs (validate_insert, explain, watch), so the pattern is not strictly verb_noun but still predictable.
Tool Count5/5
14 tools is well within the ideal range for a dedicated read-only database server. Each tool addresses a distinct need without excessive redundancy, and the count feels appropriate for the scope.
Completeness5/5
The server covers all typical read-only operations: listing databases, inspecting schema, querying, counting, previewing, sampling, explaining, and validating writes without executing. It also includes incremental polling, making it a comprehensive surface for a read-only Postgres MCP server.
Average 3.6/5 across 14 of 14 tools scored. Lowest: 2.7/5.
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 carries the full burden of behavioral disclosure. It does not mention how the limit parameter affects results, whether all columns are returned, the ordering of rows, or the default behavior. This is a significant gap for a data-access 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 a single efficient sentence, front-loaded with the verb. It earns its place, but omits information about the other parameters and behavioral details, so it is concise rather than comprehensive.
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 tool with no output schema and no annotations, the description is too sparse. It does not explain return format, default limit, or database behavior. The presence of three parameters and a rich sibling context demands more detail.
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 coverage is 0%, so the description must explain parameters. It adds meaning to the 'table' parameter by noting it can be schema-qualified, but the 'limit' and 'database' parameters are completely undocumented. This is partial compensation at best.
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 action ('Preview rows from a table') and specifies the input format ('using table or schema.table name'). It is distinguishable from siblings like db.query and db.count based on the verb 'preview', though it doesn't 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The context is implied by the name 'preview', but the description does not state exclusions, prerequisites, or when to prefer db.query or other siblings.
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 carries the full burden of behavioral disclosure. It reveals that the tool returns different output depending on mode, but does not explicitly state that the operation is read-only, nor does it explain behavior around the 'filter' or 'database' parameters. The term 'Inspect' implies non-mutating behavior, but some edge cases remain undisclosed.
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: two short sentences that immediately convey the core purpose and the two key usage modes. Every word earns its place, and the most important information is front-loaded.
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 no output schema, no annotations, and 3 unspecified parameters, the description only partially completes the picture. It explains what the tool does and the mode options, but lacks details on 'filter' and 'database' parameters, default behavior, and any side effects. It is adequate for a simple inspection tool but leaves clear gaps.
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?
The input schema has 3 parameters with 0% schema description coverage, so the description must compensate for all parameter meanings. It only explains the 'mode' parameter ('summary' vs 'full') and leaves 'filter' and 'database' entirely unexplained. This is a significant gap given the lack of schema 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 a specific verb ('Inspect') and resource ('database schema'), and distinguishes the two modes ('summary' for table list, 'full' for columns and keys). It is easily distinguishable from sibling tools like db.table_info, though it does not explicitly call out the difference.
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 gives clear guidance on when to use each mode ('Use mode='summary' for table list or mode='full' for columns and keys'), which is useful. However, it does not explain when this tool should be preferred over sibling tools like db.table_info or db.indexes, leaving the cross-tool decision to the agent.
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 reveals that values are distinct and non-null, which is useful, but it does not mention whether sampling is random, how ordering works, what happens for columns with no non-null values, or if database parameter is required. The behavior is partially transparent but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is grammatically clear and front-loaded with the main verb. It is concise and free of fluff, but it could benefit from additional structural elements like examples or parameter explanations to aid understanding.
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?
This tool has 4 parameters, no output schema, and no annotations. The description is too brief to convey the expected return structure (e.g., mapping of column to sample values), edge cases, or the role of the 'database' parameter. It is not complete enough for an agent to correctly invoke this tool without additional inference.
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%, and the description does not explain the 'limit' or 'database' parameters. It only hints at 'columns' via 'selected columns'. The description fails to compensate for the lack of schema descriptions, leaving two parameters semantically unexplained.
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 ('Return') and clearly identifies the resource ('small distinct non-null sample values for selected columns in a table'). It distinguishes this tool from siblings like db.query (full query execution) and db.preview (likely raw row preview) by emphasizing sampling of distinct non-null values per column.
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 implied usage is to explore actual data values in columns, but there is no explicit statement about when to use this over alternatives (e.g., db.preview, db.query). No exclusions or alternative tool names are mentioned, so guidance is only implicit.
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?
No annotations are provided, so the description carries the burden of behavioral disclosure. It clearly states that statements are not executed, which is a key safety behavior. However, it does not disclose what happens on success/failure (e.g., return format, errors), or any potential side effects like lock acquisition or permission checks during EXPLAIN.
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?
A single concise sentence that states the action, scope, and mechanism. Every word earns its place; there is no filler or 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?
The tool has 4 parameters (2 required), no output schema, and no annotations. The description covers core intent but omits important operational details such as return behavior, error handling, and the role of optional parameters. Given the sibling tools and complexity, the description is not complete enough for reliable 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. It explains the 'mode' values (SELECT, INSERT, UPDATE, DELETE) and implies the 'sql' parameter is the statement. However, it provides no guidance on the optional 'params' (bind parameters) or 'database' parameters, which are left entirely to 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 identifies a specific verb ('Validate') and resource ('SELECT, INSERT, UPDATE, or DELETE statements'), and clearly distinguishes from execution by noting it validates 'without executing them'. However, it does not explicitly differentiate from the sibling tool db.validate_insert, which may overlap for INSERT statements.
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: use when you want to validate SQL statements without executing them. It does not mention explicit alternatives or exclusions, but the mechanism (EXPLAIN without ANALYZE) implies a safe, non-mutating validation approach. No when-not-to-use guidance is given.
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 full burden. It discloses the key non-execution behavior, which is valuable safety information. However, it omits return format, handling of multiple statements, database selection behavior, and potential errors, leaving transparency incomplete.
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 sentence with no redundant words. It is front-loaded with the core function and immediately states the input scope, making it highly concise and well-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?
Given the tool has 3 parameters, no annotations, and no output schema, the description is too thin. It omits parameter semantics, output format, and any constraints beyond SELECT/WITH. The agent would need to infer too much about how to use the tool correctly.
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 explain all three parameters. It only hints at `sql` via 'statements' but does not clarify the meaning of `params` or `database`. This is insufficient for correct invocation.
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 function: returning PostgreSQL EXPLAIN plans for SELECT/WITH statements. The phrase 'without executing them' distinguishes it from query-executing tools like db.query, making the purpose unmistakable.
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 this tool should be used when non-executing query plans are needed, but it does not explicitly name alternatives or provide when-to-use vs when-not-to-use guidance. The distinction from db.query is implicit via 'without executing them' but never stated as a comparison.
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?
No annotations are provided, so the description carries the full burden. It discloses the read-only nature implicitly by 'List' and explains the optional table scoping, but it does not mention output format, error handling, permissions, or behavior when the table does not exist. Adequate but lacks depth.
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 front-loads the action ('List constraints'), specifies the target resource, and enumerates the included constraint types. Every phrase adds value with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with only two optional parameters and no output schema, the description covers the core functionality. However, it omits explanation of the 'database' parameter, the meaning of 'user tables' (as opposed to system tables), and any return structure. This leaves some gaps for an agent to resolve.
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 for parameter semantics. It indirectly references the 'table' parameter ('one table'), but the 'database' parameter is not explained at all. There is no mention of parameter optionality, allowed values, or defaults, leaving significant ambiguity.
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 ('List') and clearly identifies the resource (constraints for user tables). It further specifies the scope ('all user tables or one table') and enumerates the constraint types (primary keys, foreign keys, unique constraints, checks), distinguishing it from sibling tools like db.indexes and db.relationships.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving constraints, with an optional 'table' parameter to target a single table. However, it provides no explicit guidance on when to use this tool versus alternatives, and no exclusion criteria or prerequisites are mentioned. The context is clear but not fully specified.
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 carries the full burden. It clarifies that the tool lists indexes for 'user tables' (implying exclusion of system tables), which is useful scope context. However, it does not disclose the return format, behavior for invalid table names, or any permission requirements, leaving some behavioral aspects undisclosed.
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 sentence that is concise, front-loaded, and free of redundancy. It conveys the core information efficiently, earning a top score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool, the description covers the main purpose and table parameter usage, but it is incomplete in explaining the 'database' parameter and the output structure. With no output schema or annotations, the description should provide more detail about what the listing returns and how the database parameter affects the query.
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?
Since schema description coverage is 0%, the description must compensate. It explains the 'table' parameter (accepts table or schema.table name) and implies that omitting it lists all user tables. However, the 'database' parameter is not mentioned at all, leaving its semantics completely unexplained.
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 function: 'List PostgreSQL indexes for all user tables or one table'. It specifies the resource (PostgreSQL indexes) and scope (all user tables or one table), and even mentions how to specify the table ('table or schema.table name'). This distinguishes it from sibling tools like db.constraints or db.table_info.
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 gives some usage context (e.g., listing for all tables or a specific table) but does not explicitly mention when to use this tool versus alternatives, nor does it provide exclusions or when-not-to-use guidance. It implies usage for index listing but lacks comparisons to sibling tools.
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 must carry the behavioral burden. It notes 'exact' row count, implying precision, but does not disclose return format, performance implications, or side effects. For a simple read-only operation, this is minimal but lacks richer behavioral context.
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, front-loaded sentence: 'Get exact row count for a table. Use table or schema.table name.' No wasted words; every clause contributes either purpose or parameter format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple count tool, the description omits the return type (e.g., integer), the semantics of the `database` parameter, and any usage guidance relative to sibling tools. Given no annotations and no output schema, the description leaves notable gaps in the full context an agent might need.
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 0%, so the description must compensate. It clarifies that `table` accepts either a table name or schema.table format, which adds value. However, the optional `database` parameter is not mentioned, leaving its meaning ambiguous. Thus, partial compensation only.
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 'Get exact row count for a table' clearly states the action (get), the resource (row count for a table), and the specificity ('exact' distinguishes from estimates). It differentiates from siblings like db.preview or db.sample_values by focusing specifically on count.
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 no explicit when-to-use or alternative comparisons. It only gives parameter format guidance ('Use table or schema.table name'), which is not usage context. The absence of exclusions or alternative references leaves the agent to infer when this tool is appropriate.
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 carries the full burden of behavioral disclosure. It transparently indicates a read-only listing operation, but it does not describe output format, database parameter behavior, or whether system tables are excluded. The behavior is straightforward and consistent with the description, though minimal.
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, focused sentence with no filler. It front-loads the verb 'List' and immediately states the resource and scope, making it extremely concise 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?
Given the absence of annotations, output schema, and parameter descriptions, the tool is simple but still leaves gaps. The database parameter is unexplained, and the return format is unspecified. The description is a bare minimum, not a complete guide for an agent to invoke the tool with confidence.
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. It clarifies that the table parameter is optional, allowing 'all user tables or one table,' but it provides no explanation of the database parameter. This leaves one of two parameters semantically undocumented, which is a significant gap.
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 action (List) and resource (foreign-key relationships), and specifies the scope as all user tables or one table. This distinguishes it from sibling tools like db.constraints and db.schema, which cover broader constraint or schema information.
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: to list foreign-key relationships, either across all user tables or for a single table. It does not explicitly name alternatives or exclusions, but the usage intent is evident and directly communicated.
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 full burden of behavioral disclosure. It explains the stateless incremental fetch pattern, but omits important traits: what happens when lastCursor is null, how to derive the next cursor from the response, behavior for deletions or out-of-order inserts, and any rate limiting or consistency guarantees.
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 short sentences, front-loaded with the core behavior and usage pattern. Every word earns its place with no redundant or filler content.
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 5 parameters, no annotations, no output schema, and the complexity of cursor-based polling, the description is under-specified. It does not explain the return shape, how to obtain the next cursor, handling of initial lastCursor=null, or potential pitfalls (e.g., non-unique cursorColumn). This leaves significant ambiguity for 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?
Schema has 0% description coverage, so the description must compensate. It explicitly explains the relationship between cursorColumn and lastCursor, but leaves batchSize, database, and the default/purpose of lastCursor (null case) unexplained. Partial compensation for the two key cursor parameters.
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 ('Fetch') and resource ('one incremental batch'), and clearly states the core mechanism (cursorColumn > lastCursor). It distinguishes db.watch from general query tools like db.query by emphasizing incremental, cursor-based fetching.
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 phrase 'Repeat client-side for polling' explicitly frames this as a polling tool and indicates a client-driven loop. It does not name alternative tools or list exclusions, but the incremental polling context is clear enough to imply when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the transparency burden. The verb 'Inspect' strongly conveys a read-only, non-destructive operation, and the list of inspected elements adds behavioral context about the scope of the operation. However, it does not mention return format or potential errors, leaving a small gap.
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, front-loaded sentence that lists all relevant outputs without filler. Every word contributes to the tool's purpose, and it is immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema) and the absence of annotations, the description provides adequate context by enumerating the exact metadata returned. It lacks detail on return structure, but the list of items is sufficient for an agent to understand what to expect.
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?
The schema has 0% description coverage, so the description must compensate. It explicitly refers to 'one table' which clarifies the 'table' parameter, but gives no guidance on the 'database' parameter, including its optionality or purpose. The description adds minimal value beyond the parameter names themselves.
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 ('Inspect') and clearly identifies the resource ('one table') and the exact information returned: columns, indexes, constraints, foreign-key relationships, and triggers. This distinguishes it from sibling tools like db.indexes or db.constraints, which each cover only one aspect.
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 when to use this tool (when you need comprehensive metadata about a single table) but does not explicitly contrast it with specialized siblings such as db.indexes or db.schema. No when-not guidance or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and it delivers: it states that rows are never inserted via EXPLAIN without ANALYZE, and adds a behavioral constraint about parameterized validation being single-statement. This provides substantial transparency beyond the raw schema.
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 sentences, front-loaded with the main purpose and immediately followed by the key constraint. Every sentence adds value, with no fluff or repetition of schema details.
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 covers the core purpose and safety guarantee, but lacks details on return behavior (there is no output schema) and does not explain the 'database' parameter. Given the moderate complexity and absence of annotations, this leaves notable gaps.
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. It only mentions 'parameterized validation' as a concept but does not explain the meaning or usage of the 'params' array or the 'database' parameter. This is insufficient for the three parameters present.
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 validates INSERT statements without executing them, using a specific verb ('Validate') and resource ('INSERT statements'). This distinguishes it from sibling tools like db.validate_sql and db.explain by focusing specifically on INSERT statements.
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 gives clear context: use this to validate INSERT statements without side effects, and notes a key constraint that parameterized validation must be single-statement. It does not explicitly name alternatives or exclusions, but the dedicated purpose is evident.
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 carries the full burden. It transparently indicates a read-only listing operation ('List') and mentions the default alias, but it does not disclose potential details like whether the output includes connection strings, sorting order, or how the default is highlighted. For a simple listing tool, this is adequate but not rich.
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 front-loads the main purpose. Every word adds value, with no redundancy or filler. It is an exemplary model of efficient communication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (no parameters, no output schema, simple read-only listing), the description is complete. It covers what the tool does (list aliases) and the special aspect (default alias), which is all a user needs to know for invocation and interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% schema coverage, so there are no parameter semantics to clarify. The baseline for 0 params is 4, and the description appropriately adds context about what will be listed (aliases and default), which is useful beyond the empty 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 'List' and a distinct resource 'configured database aliases', and adds the important nuance of 'currently selected default alias'. This clearly distinguishes it from sibling tools like db.schema or db.query, which operate on database structures and data.
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: to see available database aliases and the default one, use this tool. However, it does not explicitly state when to prefer this over alternatives, nor does it mention any exclusions or related tools. The usage context is clear but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing read-only behavior, support for multi-statement non-parameterized queries, and the constraint that parameterized queries must be single-statement. It adds meaningful behavioral context beyond the bare schema.
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?
Two sentences, front-loaded with the purpose, and each sentence adds distinct value—first stating what it does, second stating a key constraint. No waste.
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 4-parameter tool with no output schema, the description covers the main behaviors and constraints well. It does not describe the database parameter or result format, but the core usage is clear and sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains 'sql' as SELECT/WITH statements, 'params' as parameterized query values, and 'maxRows' as optional row limits. 'database' is not explicitly described, but the overall parameter meaning is significantly enriched.
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 runs one or more read-only SELECT queries, which is a specific verb+resource action. It distinguishes from siblings like db.count, db.explain, and db.validate_sql by focusing on executing SELECT queries directly.
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 context on when multi-statement queries are allowed (non-parameterized SELECT/WITH) and requires single-statement for parameterized queries. However, it does not explicitly mention alternatives or when to prefer other sibling tools like db.preview or db.count, so usage guidance is implied rather than explicit.
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:

[![postgres-mcp-readonly MCP server](https://glama.ai/mcp/servers/mahin1995/postgres-mcp-readonly/badges/card.svg)](https://glama.ai/mcp/servers/mahin1995/postgres-mcp-readonly)

Score Badge

Copy to your README.md:

[![postgres-mcp-readonly MCP server](https://glama.ai/mcp/servers/mahin1995/postgres-mcp-readonly/badges/score.svg)](https://glama.ai/mcp/servers/mahin1995/postgres-mcp-readonly)

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/mahin1995/postgres-mcp-readonly'

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