Avanti Fellows PostgreSQL MCP Server

Official

by avantifellows

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no overlap: count_rows counts rows, describe_table provides schema details, list_tables enumerates tables, query executes SQL, sample_data retrieves sample rows, and search_columns finds columns by name. The descriptions reinforce these unique functions, making misselection unlikely.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with snake_case, such as count_rows, describe_table, list_tables, query, sample_data, and search_columns. This uniformity makes the tool set predictable and easy to navigate for an agent.
Tool Count5/5
With 6 tools, the server is well-scoped for a PostgreSQL exploration and querying purpose. Each tool earns its place by covering essential database operations like discovery, inspection, and data retrieval without being overly complex or sparse.
Completeness4/5
The tool set provides strong coverage for exploring and querying a PostgreSQL database, including discovery (list_tables, search_columns), inspection (describe_table), and data retrieval (count_rows, sample_data, query). A minor gap is the lack of write operations (e.g., insert, update, delete), but this aligns with a read-only focus, and agents can work around it for analysis tasks.
Average 4.3/5 across 6 of 6 tools scored. Lowest: 3.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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

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 discloses that it excludes system schemas and returns a JSON array with specific fields, which adds useful behavioral context. However, it doesn't cover aspects like rate limits, permissions, or pagination, leaving some gaps.
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 front-loaded with the core purpose in the first sentence, followed by additional context and return details in a structured way. Every sentence adds value without waste, making it highly efficient.
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 low complexity (0 parameters) and the presence of an output schema, the description is complete enough for a list operation. It explains what is returned and exclusions, but could slightly improve by mentioning sibling tools for more context.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, and the baseline for 0 params is 4, as it avoids unnecessary details.
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 with a specific verb ('List') and resource ('tables in the database'), and distinguishes it from siblings by mentioning it returns tables from all schemas. However, it doesn't explicitly differentiate from tools like 'describe_table' or 'search_columns' beyond scope.
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 guidance by stating 'Use this to discover what data is available,' which suggests when to use it, but doesn't explicitly mention when not to use it or name alternatives like 'search_columns' for more specific queries.
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 discloses the tool's read-only nature through context ('Get sample rows') and mentions the limit constraint ('max: 100'), but doesn't cover other behavioral aspects like error conditions, permissions needed, or performance characteristics that would be helpful for an agent.
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 well-structured and appropriately sized. It starts with the core purpose, provides usage context, then details parameters and return values in clear sections. Every sentence adds value with no wasted words.
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 moderate complexity (3 parameters, 1 required), no annotations, but with an output schema (implied by 'Returns: JSON array of sample rows'), the description is reasonably complete. It covers purpose, usage, parameters, and returns, though additional behavioral context would improve completeness for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant value beyond the input schema, which has 0% description coverage. It provides clear explanations for all three parameters including defaults and constraints (e.g., 'default: public', 'default: 10, max: 100'), which the schema only indicates through titles and default values without explanation.
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 with a specific verb ('Get') and resource ('sample rows from a table'), making it easy to understand what it does. However, it doesn't explicitly differentiate from sibling tools like 'query' or 'describe_table', which could also help understand data structure.
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 ('for understanding what data looks like without writing a full query'), which implicitly distinguishes it from 'query' (for full queries) and 'describe_table' (for schema info). However, it doesn't explicitly state when NOT to use it or name specific alternatives.
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 full burden. It states the basic operation and return format ('JSON with count'), but doesn't disclose permissions needed, rate limits, error conditions, or whether it's a read-only operation (though implied by 'Count').
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?
Perfectly structured: purpose statement first, then Args and Returns sections. Every sentence earns its place with no wasted words. The formatting makes it easy to scan.
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 moderate complexity (3 parameters, no annotations, but has output schema), the description is mostly complete. It covers parameters well and mentions the return format. However, it lacks behavioral context like permissions or limitations that would be helpful for a database tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/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 clearly explains all 3 parameters: table_name, schema_name (with default), and where (with syntax guidance 'without WHERE keyword'). This adds significant value beyond the bare 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 clearly states the specific action ('Count rows') and resource ('in a table'), with optional filtering via WHERE clause. It distinguishes from siblings like query (which returns data) and list_tables (which lists tables).
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 usage for counting rows with optional filtering, but doesn't explicitly state when to use this vs. alternatives like query (which could also count) or describe_table (for metadata). No explicit 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that this is a read operation (implied by 'Get') and describes the return format (JSON with columns, primary keys, foreign keys), which is helpful. However, it doesn't mention potential errors (e.g., if table doesn't exist), permissions needed, or rate limits, leaving some behavioral aspects unclear.
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 perfectly structured: a clear purpose statement, usage guidance, and well-organized parameter/return sections. Every sentence earns its place, with no redundant information. The bullet-point style for Args and Returns enhances readability without wasting space.
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 moderate complexity (2 parameters, read-only operation) and the presence of an output schema (which handles return value documentation), the description is nearly complete. It covers purpose, usage, parameters, and return format adequately. The only minor gap is lack of error case documentation, but the output schema reduces the need for extensive return value explanation.
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 schema description coverage is 0%, so the description must compensate. It provides meaningful context for both parameters: table_name is clearly explained as 'Name of the table', and schema_name gets additional context with 'Schema name (default: public)', which clarifies its optional nature and typical value. This adds significant value beyond the bare 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 clearly states the specific action ('Get detailed schema information') and resource ('for a table'), distinguishing it from siblings like list_tables (which lists tables) or query (which executes queries). It explicitly mentions what information is returned (column names, types, nullability, defaults), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('Use this to understand table structure before querying'), which clearly differentiates it from query (for actual data retrieval) and sample_data (for data preview). It implicitly suggests alternatives like list_tables for table enumeration, making usage context clear.
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 key behavioral traits: it's read-only, restricts to SELECT queries, and mentions error handling ('or error message'). It could improve by adding details like rate limits or result size limits.
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 appropriately sized and front-loaded, with the core purpose in the first sentence, usage guidelines in the second, and clear sections for Args and Returns. Every sentence adds value without redundancy.
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 complexity (SQL execution), no annotations, and an output schema present, the description is complete enough: it covers purpose, usage, behavioral constraints, parameter meaning, and return values, making it self-sufficient for an AI agent.
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 schema has 0% description coverage, but the description compensates by explaining the 'sql' parameter as 'A SELECT query to execute,' adding meaning beyond the bare schema. It doesn't provide syntax examples or constraints, but this is adequate given the single parameter.
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 a specific verb ('Execute') and resource ('read-only SQL query against the database'), distinguishing it from siblings like count_rows or describe_table by focusing on general query execution rather than specific operations.
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 explore data, debug issues, or validate assumptions') and explicitly states 'Only SELECT queries are allowed,' which helps differentiate it from potential write operations. However, it doesn't explicitly mention when to use alternatives like sample_data or search_columns.
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 of behavioral disclosure. It effectively describes the search behavior (case-insensitive partial matching) and return format (JSON array with tables). However, it doesn't mention potential limitations like result size, pagination, or performance considerations for large databases.
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 perfectly structured and concise: purpose statement, usage guidance, parameter explanation, and return format in four clear lines. Every sentence earns its place with no wasted words, and information is front-loaded appropriately.
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 moderate complexity (search across tables), no annotations, and the presence of an output schema (which handles return value documentation), the description is complete. It covers purpose, usage context, parameter semantics, and behavioral traits adequately for the agent to use it correctly.
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 schema has 0% description coverage, so the description must compensate. It clearly explains the 'search_term' parameter as 'Partial column name to search for (case-insensitive),' adding crucial semantic context beyond the bare schema. The description fully documents the single parameter's purpose and behavior.
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: 'Search for columns by name across all tables.' This specifies the verb (search), resource (columns), and scope (across all tables), distinguishing it from siblings like 'describe_table' (single table) or 'list_tables' (tables only).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides usage guidance: 'Useful when you know a column name but not which table it's in.' This clearly indicates when to use this tool versus alternatives like 'describe_table' (for specific table details) or 'query' (for data retrieval).
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-postgres MCP server](https://glama.ai/mcp/servers/avantifellows/mcp-postgres/badges/card.svg)](https://glama.ai/mcp/servers/avantifellows/mcp-postgres)

Score Badge

Copy to your README.md:

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

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

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