Provides deep PostgreSQL context including live schemas as DDL, index health, foreign key associations, query execution plans, and performance statistics.
Detects TimescaleDB extensions and flags its capabilities within PostgreSQL.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@pg-context Explain the query plan for SELECT * FROM orders WHERE user_id = 42"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Model Context Protocol (MCP) server that gives AI coding assistants deep PostgreSQL context: live schemas as DDL, index health, foreign key associations, query execution plans, and performance statistics.
pg-context connects directly to your PostgreSQL database in read-only mode and exposes tools and resources for AI assistants such as Cursor, Claude Code, Cline, and Antigravity.
Generic SQL tools often execute arbitrary queries without giving the AI assistant structural context. This causes models to guess column names, hallucinate relations, and generate invalid joins.
pg-context resolves this problem by providing:
Zero-guess schema context: Exports real table structures formatted as PostgreSQL CREATE TABLE DDL statements with foreign key comments and index definitions.
Read-only security: Automatically sets default_transaction_read_only = ON on every client connection and rejects mutating SQL statements (such as DROP, DELETE, UPDATE, INSERT, TRUNCATE, ALTER).
Optimization insights: Detects unindexed foreign keys, high sequential scan ratios, unused indexes, and slow queries from pg_stat_statements.
Extension awareness: Identifies PostGIS, TimescaleDB, and pgvector extensions.
Related MCP server: PostgreSQL MCP Server
You can run pg-context directly via npx without manual installation:
npx -y pg-context-mcpOr install it globally:
npm install -g pg-context-mcp
pg-context-mcppg-context reads connection parameters from environment variables or standard PostgreSQL connection strings:
Variable | Description | Default |
| Standard PostgreSQL connection URI |
|
| Database host |
|
| Database port |
|
| Database name |
|
| Database user |
|
| Database password |
|
| Enable SSL connection ( |
|
| Comma-separated list of target schemas |
|
| Connection pool size |
|
| Schema cache TTL in seconds |
|
| Default row limit for |
|
| Hard upper limit for |
|
Add the following entry to your claude_desktop_config.json or Antigravity MCP settings:
{
"mcpServers": {
"pg-context": {
"command": "npx",
"args": ["-y", "pg-context-mcp"],
"env": {
"DATABASE_URL": "postgresql://user:password@localhost:5432/my_database"
}
}
}
}Add the following to your Cursor MCP configuration (.cursor/mcp.json or Cursor Settings > Features > MCP):
{
"mcpServers": {
"pg-context": {
"command": "npx",
"args": ["-y", "pg-context-mcp"],
"env": {
"DATABASE_URL": "postgresql://user:password@localhost:5432/my_database"
}
}
}
}Add this configuration into cline_mcp_settings.json:
{
"mcpServers": {
"pg-context": {
"command": "npx",
"args": ["-y", "pg-context-mcp"],
"env": {
"DATABASE_URL": "postgresql://user:password@localhost:5432/my_database"
}
}
}
}pg-context exposes 12 MCP tools:
Tool | Parameters | Description |
| none | Lists all non-system schemas in the database. |
|
| Lists tables and views with sizes, estimated row counts, and comments. |
|
| Returns full structural DDL of a table including columns, types, defaults, NOT NULL, foreign keys, and indexes. |
|
| Displays foreign key relationships as readable |
|
| Displays indexes, definitions, sizes, and scan counts. |
|
| Identifies unindexed foreign keys, sequential scan warnings, and unused indexes. |
|
| Executes read-only queries with enforced limits and returns Markdown tables. |
|
| Returns query execution plans from PostgreSQL |
| none | Returns PostgreSQL version, total database size, connection counts, and buffer settings. |
|
| Returns sequential vs index scans, live rows, dead rows, and maintenance dates. |
|
| Fetches top slowest queries recorded by |
| none | Lists installed PostgreSQL extensions and flags capabilities for PostGIS, TimescaleDB, and pgvector. |
pg-context exposes 3 MCP resources:
Resource URI | MIME Type | Description |
|
| Full DDL dump of all tables across configured schemas. |
|
| DDL definition for an individual table. |
|
| Database health overview: storage sizes, dead rows, and optimization alerts. |
# Clone the repository
git clone https://github.com/mewsyy/pg-context.git
cd pg-context
# Install dependencies
npm install
# Run test suite
npm test
# Build TypeScript
npm run build
# Start local server
npm startMIT (c) Semen
Get full structural details of a table as CREATE TABLE DDL, including columns, data types, constraints, foreign keys, and indexes
| Name | Required | Description | Default |
|---|---|---|---|
| table | Yes | Table name to describe | |
| schema | No | Schema name where table resides (default: "public") | public |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full responsibility of disclosing behavioral traits. It explains the output format (DDL) but omits critical details such as whether the operation is read-only, what happens if the table does not exist, or any permission requirements. This incomplete disclosure leaves the agent without a clear safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the primary action ('Get full structural details of a table as CREATE TABLE DDL') and then lists included elements. Every word 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description reasonably covers the core output (DDL components) but lacks information about error handling, return format (e.g., plain text string), or behavior on missing tables. Given no output schema, slightly more detail would be beneficial, though the current text is adequate for many use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes both parameters (table required, schema optional with default). The description adds no additional meaning beyond the schema, such as value formats, constraints, or usage examples. Given 100% schema coverage, the baseline of 3 is appropriate as the description does not detract but also does not enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves full structural details of a table in CREATE TABLE DDL format, listing specific components (columns, data types, constraints, foreign keys, indexes). This directly distinguishes it from sibling tools like list_tables, list_foreign_keys, and list_indexes which return only subsets of table information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus its siblings. For example, it does not explain that list_foreign_keys or list_indexes are preferred when only those elements are needed, or that describe_table is the comprehensive option. The lack of contextual direction forces the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get query execution plan via PostgreSQL EXPLAIN (or EXPLAIN ANALYZE) to debug performance bottlenecks
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | SQL query to explain | |
| analyze | No | If true, runs EXPLAIN (ANALYZE, BUFFERS, VERBOSE) to measure actual execution time |
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 fails to disclose that EXPLAIN ANALYZE actually executes the SQL query, which may have side effects (e.g., modifying data, locking). It also does not mention prerequisites (e.g., permissions) or output format. The parameter description for analyze does hint at execution, but the tool-level description omits this critical behavioral trait.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 15 words that is front-loaded with the core purpose. Every word contributes meaning without redundancy. This is an example of efficient, focused writing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description should at least hint at the return format (e.g., 'returns a text plan'). More critically, it omits the side-effect of execution when using ANALYZE. For a moderately complex tool with potential destructive behavior, this is a significant gap. 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters having descriptions. The description adds the PostgreSQL EXPLAIN context and the purpose of debugging, but these do not significantly enhance the semantic understanding of the parameters beyond what the schema already provides. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (Get), the resource (query execution plan), and the mechanism (PostgreSQL EXPLAIN / EXPLAIN ANALYZE). It explicitly ties the tool to debugging performance bottlenecks, which distinguishes it from sibling tools like read_query (data retrieval) and suggest_indexes (index recommendations).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for performance debugging ('to debug performance bottlenecks'). However, it provides no explicit guidance on when not to use this tool (e.g., for read queries without performance concerns) nor does it mention alternatives among siblings. Usage context is present but not fully elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get high-level PostgreSQL database runtime information: version, size, active connection count, and server settings
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 clearly indicates a read-only operation ('Get'), which is accurate. However, it does not mention any potential side effects, required permissions, or performance impacts, though none are likely given the simple read nature. The description is sufficient but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately conveys the purpose and scope. Every word serves a purpose, with no unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should ideally detail the return structure. It lists the high-level items (version, size, etc.) but leaves ambiguity (e.g., units for 'size', format of 'server settings'). For a tool with no parameters and no annotations, the description is adequate but not fully complete for precise agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema description coverage is 100% (vacuously). The description does not need to add parameter details, and it correctly omits any. Baseline for 0 parameters is 4, and the description provides no conflicting or missing information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose ('Get high-level PostgreSQL database runtime information') and lists specific items (version, size, active connection count, server settings). This distinctly separates it from sibling tools like get_table_stats (table-level) and get_slow_queries (query-level).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for overview database info, but it does not explicitly state when to use it over alternatives like get_table_stats or list_schemas. With 11 sibling tools, some guidance on choosing this tool would be beneficial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve top slowest queries recorded by pg_stat_statements extension (if enabled in PostgreSQL)
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of slow queries to return (default: 15) |
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 dependency on the 'pg_stat_statements' extension being enabled, which is a critical behavioral trait. However, it does not mention whether the tool is read-only, if it requires special permissions, or how it handles missing extensions (e.g., error vs. empty result).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that conveys the core purpose and a key dependency. No extraneous text; every word adds value. Could be slightly more concise by removing 'recorded by' but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter (single optional integer) and no output schema, the description is mostly adequate but misses context about return format (e.g., list of queries, metrics like execution time, I/O). Sibling tools suggest a performance-oriented context, but the description doesn't clarify what 'slowest' means (e.g., by total time, mean time, or max time).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 100%, the schema already documents the 'limit' parameter with a default and description. The tool description adds no additional semantics beyond what the schema provides, meeting the baseline 3. The description does not explain how the limit affects results (e.g., ties, ordering).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves top slowest queries, with a specific verb ('Retrieve') and resource ('pg_stat_statements extension'). It distinguishes itself from siblings like 'read_query' or 'explain_query' by targeting performance monitoring rather than general query execution or analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for database performance tuning (slow queries) but does not explicitly state when to use this tool versus alternatives like 'explain_query' for individual query analysis or 'get_table_stats' for schema-level performance. No exclusions or prerequisites are mentioned beyond the extension dependency.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get scan statistics, tuple counts, dead row accumulation, and maintenance history for tables
| Name | Required | Description | Default |
|---|---|---|---|
| table | No | Optional table name to retrieve detailed metrics for a single table | |
| schema | No | Schema name (default: "public") | public |
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 correctly indicates a read operation (non-destructive), but does not mention potential performance impact, system catalog access, or whether results vary by database role. The description is accurate but somewhat thin for a statistics tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that immediately communicates the tool's function. Every word is meaningful, and there is no redundant or extraneous information. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description enumerates the main output categories (scan statistics, tuple counts, dead rows, maintenance history), which is helpful given the lack of an output schema. However, it does not explain what happens when the table parameter is omitted (e.g., returns stats for all tables in the schema), nor does it detail the return structure. Still, it covers the key aspects adequately for a tool with only two optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning to the parameters beyond what the schema already provides (table name, schema name, defaults). It does not clarify parameter interactions or format constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and lists exact resources: scan statistics, tuple counts, dead row accumulation, and maintenance history for tables. This clearly distinguishes it from sibling tools like list_tables (just table names) or describe_table (schema info), making the purpose obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when table statistics are needed, but it offers no explicit guidance on when to prefer it over alternatives like describe_table or get_database_info, nor does it mention restrictions (e.g., required permissions) or cases to avoid. 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.
List installed PostgreSQL extensions with version information and specialized framework detection (PostGIS, TimescaleDB, pgvector)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description solely carries the burden. It correctly indicates a read-only operation (listing) but does not disclose any other behavioral traits such as authorization requirements, performance impact, or that it is safe to call frequently. This is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence of 15 words that is front-loaded with the core action. Every word serves a purpose, with no redundancy or filler. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with no output schema, the description adequately covers the purpose and distinguishes key outputs (version info, framework detection). It could be more explicit about the return format (e.g., list of objects), but the current level is sufficient for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so baseline is 4 as per rubric. The description adds no parameter-specific meaning because there are none, but it correctly describes what the tool returns without needing to reference parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List installed PostgreSQL extensions'), the output ('version information and specialized framework detection'), and distinguishes it from siblings like list_schemas or list_tables, which focus on different database objects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly conveys when to use this tool (when you need to see installed extensions and their versions). Among siblings, no other tool serves this purpose, so context is clear. However, it provides no explicit exclusions or alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List foreign key relationships between tables to understand data model associations and joins
| Name | Required | Description | Default |
|---|---|---|---|
| table | No | Optional table name to filter relations for a specific table | |
| schema | No | Schema name (default: "public") | public |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It indicates a read-only operation but does not clarify the default scope (e.g., lists all foreign keys if no table is specified) or any permission requirements. The description is adequate but lacks explicit behavioral boundaries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence of 13 words. It is front-loaded with the verb and resource, and every word serves a purpose. No redundant or unnecessary content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two optional parameters and no output schema. The description is concise but does not indicate what the output looks like (e.g., list of objects with from/to columns). For a data model exploration tool, specifying the return format would improve completeness. Given the complexity, a score of 3 is fair.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both parameters have descriptions). The description adds no additional meaning beyond the schema; it does not clarify input formats or provide examples. Baseline of 3 is appropriate given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and the resource 'foreign key relationships', with a purpose ('to understand data model associations and joins'). It distinguishes well from sibling tools like 'list_tables' and 'describe_table' by focusing on relationships between tables.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for understanding data model associations, but it does not explicitly state when to use this tool versus alternatives (e.g., 'describe_table' for column details, 'list_indexes' for indexes). No exclusion criteria or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List indexes on tables with sizes and scan usage statistics to evaluate index health
| Name | Required | Description | Default |
|---|---|---|---|
| table | No | Optional table name to filter indexes | |
| schema | No | Schema name (default: "public") | public |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses that the tool returns sizes and scan usage statistics for health evaluation, indicating a read-only, analytical behavior. While it doesn't detail internal implementation or performance impact, the provided information is sufficient for an agent to understand the tool's non-destructive, information-returning nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence. It front-loads the action (List), specifies the resource (indexes on tables), and adds value (with sizes and scan usage statistics to evaluate index health). No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description skillfully conveys the tool's purpose and key return data (sizes, scan usage statistics). It is complete enough for an agent to decide when to call it among 12 siblings. A minor gap: it could explicitly list the output fields for total clarity, but the health evaluation context compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The tool description ('with sizes and scan usage statistics to evaluate index health') adds overall context but does not provide new semantic information about the two parameters beyond what the schema already describes (optional table filter and schema name with default).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists indexes on tables with specific return fields (sizes and scan usage statistics) and a clear purpose (evaluate index health). This distinguishes it from siblings like list_tables (tables), list_foreign_keys (foreign keys), and suggest_indexes (suggestions, not listing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for evaluating index health but provides no explicit guidance on when to use this tool versus alternatives like suggest_indexes or get_table_stats. No when-not or exclusion criteria are mentioned, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available database schemas (excluding system schemas like pg_catalog and information_schema)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 explicitly states that system schemas (pg_catalog, information_schema) are excluded, which adds value beyond the tool name. However, it does not disclose other potential behaviors like ordering or limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action and resource, containing no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with no parameters and no output schema, the description provides all necessary information: what is listed and what is excluded. It is complete for its complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the schema coverage is 100%. The description does not need to add parameter details, and the baseline score of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and resource 'database schemas', with a specific exclusion of system schemas, which distinguishes it from sibling tools like list_tables or describe_table.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only states what the tool does without explicit guidance on when to use it or when to prefer alternatives. The purpose is implied but no context is provided for scenarios where it should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all tables and views in a given schema with estimated row counts, sizes, and comments
| Name | Required | Description | Default |
|---|---|---|---|
| schema | No | PostgreSQL schema name (default: "public") | public |
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 row counts are 'estimated', implying inexactness, and mentions sizes and comments. However, it does not clarify that this is a read-only operation, whether it queries system catalogs, performance implications, or permission requirements. Some transparency but gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that starts with the action and resource, then specifies the additional details returned. Every word adds value; no fluff. Perfectly concise for a 1-param tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description informs the user about the return content (estimated row counts, sizes, comments). It does not specify the return format (e.g., list of objects), ordering, or whether it includes all tables/views. Still, it covers the main expected output adequately for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter with 100% description coverage (including default value and meaning). The tool description does not add to parameter semantics beyond listing return fields. With full schema coverage, baseline score of 3 is appropriate; the description provides no extra parameter context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists tables and views in a given schema, and specifies the additional information provided (estimated row counts, sizes, comments). This distinguishes it from siblings like list_schemas and describe_table, as it targets schema-level table enumeration with metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing to know the schema name via list_schemas first) or when to prefer describe_table for detailed table info. No usage context or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a safe read-only SQL query (SELECT, WITH, SHOW) with strict LIMIT enforcement and formatting
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | Read-only SQL query to execute | |
| limit | No | Maximum number of rows to return (default: 100, max: 1000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description proactively discloses key behavioral traits: the tool enforces strict LIMIT enforcement and formatting, and is restricted to read-only queries (SELECT, WITH, SHOW). There are no annotations to contradict or rely on, so the description carries the full burden and handles it well. A slight deduction for not mentioning return format or error handling behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loades the purpose and then adds constraints. It is concise and every phrase adds value. Minor deduction for not using line breaks or bullet points to separate the query types and enforcement rules, though it is still clear as is.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a simple SQL executor with high schema coverage, the description sufficiently covers its core function and constraints. The lack of output schema is acceptable for a query tool; the description implies formatted output. However, it could mention potential error cases (e.g., malformed SQL, privilege issues) or that results are returned in a tabular format to be fully complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% – the input schema already documents the 'sql' and 'limit' parameters with descriptions. The description adds general context about LIMIT enforcement and formatting but does not elaborate on parameter syntax, validation rules, or behavior beyond what is in the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('Execute'), the resource ('SQL query'), and narrows the scope with 'safe read-only', listing permitted SQL commands (SELECT, WITH, SHOW). It explicitly mentions enforcement of LIMIT and formatting rules, setting it apart from potentially similar query or analysis tools in the sibling list. This leaves no ambiguity about the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly states when to use the tool via the 'safe read-only' qualifier and the listed SQL commands. The sibling tools include read-only informational tools (e.g., list_schemas, explain_query) and write-related tools; however, no explicit 'when not to use' or direct comparison to siblings is provided. The context is clear but exclusions are omitted, warranting a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze query patterns, scan ratios, and missing foreign key indexes to provide index recommendations
| Name | Required | Description | Default |
|---|---|---|---|
| table | No | Optional specific table name to analyze | |
| schema | No | Schema name (default: "public") | public |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions 'analyze' and 'recommendations' but does not state whether the tool is read-only, requires special permissions, or has performance implications (e.g., scanning query statistics). The side effects or limitations are unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and front-loaded. It avoids unnecessary words. However, it could be slightly more structured (e.g., separating inputs and outputs) but still earns a high score for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of index recommendation (no output schema), the description is incomplete. It does not explain what the output looks like (e.g., a list of suggested indexes with columns and estimated impact) or how it differs from closely related sibling tools like list_foreign_keys or get_slow_queries.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The tool description does not add additional meaning beyond the parameter descriptions in the schema (e.g., 'table' is optional, 'schema' defaults to 'public'). No extra semantics are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Analyze... to provide index recommendations'), specifies the inputs (query patterns, scan ratios, missing foreign key indexes), and distinguishes from siblings like list_indexes (which lists existing indexes) and get_slow_queries (which retrieves slow queries).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention conditions like 'when optimizing query performance' or exclude cases like 'when only current indexes are needed' (use list_indexes instead).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0describe_tableexplain_queryget_database_infoget_slow_queriesget_table_statslist_extensionslist_foreign_keyslist_indexeslist_schemaslist_tablesread_querysuggest_indexesEach tool targets a distinct aspect of PostgreSQL database introspection: schemas, tables, relationships, indexes, query execution, performance stats, and extensions. There is no overlap in purpose.
All tools follow a consistent verb_noun pattern in snake_case (e.g., list_schemas, describe_table, read_query), making the API predictable and easy to navigate.
With 12 tools, the server covers the key areas of database analysis without being bloated. Each tool serves a distinct role, and the count is appropriate for the domain.
The set covers schema exploration, table details, indexing, query analysis, performance monitoring, and extension information. No obvious gaps for a read-only database context server.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hosted MCP server for PostgreSQL diagnostics: slow queries, missing indexes, connection pressure.
Analytical memory for AI agents: a real Postgres queried in plain English over MCP. One command.
The Cortex MCP server provides read-only access to real-time engineering context from the Cortex developer portal, allowing AI coding assistants to answer natural language questions about your organization's catalog (microservices, libraries, domains, teams, infrastructure), scorecards (engineering standards and best practices), initiatives (goals and deadlines), and Engineering Intelligence metrics. It includes tools for querying documentation, tracking personal entities, and accessing AI-assisted insights across the entire Cortex ecosystem.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mewsyy/pg-context'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
