MCP PostgreSQL Operations

Overview Schema Source Related Servers Discussions Admin

get_table_schema_info

Retrieve column definitions, keys, indexes, constraints, and table metadata for a specific PostgreSQL table or all tables to analyze database structure and relationships.

Instructions

[Tool Purpose]: Retrieve detailed schema information for specific table or all tables in a database

[Exact Functionality]:

Retrieve detailed column information including data types, constraints, defaults
Display primary keys, foreign keys, indexes, and other table constraints
Show table-level metadata such as size, row count estimates

[Required Use Cases]:

When user requests "table schema", "column info", "table structure", etc.
When detailed table design information is needed for development
When analyzing database structure and relationships

[Strictly Prohibited Use Cases]:

Requests for actual data inside tables
Requests for table structure changes or DDL operations
Requests for performance statistics (use other tools for that)

Input Schema

Name	Required	Description	Default
`table_name`	No	Specific table name to analyze (if None, shows all tables)
`schema_name`	No	Schema name to search in (default: "public")	public
`database_name`	Yes	Database name to query (REQUIRED - specify which database to analyze)

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv3.4.3Oct 27, 2026

addedInput schema / properties / database_name / description

Added value: +"Database name to query (REQUIRED - specify which database to analyze)"

addedInput schema / properties / schema_name / description

Added value: +"Schema name to search in (default: \"public\")"

addedInput schema / properties / table_name / description

Added value: +"Specific table name to analyze (if None, shows all tables)"

Changed8 schema fields changedv3.4.2Oct 25, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
- removedInput schema / properties / database_name / title
```
Removed value: -"Database Name"
```
- removedInput schema / properties / schema_name / title
```
Removed value: -"Schema Name"
```
- addedInput schema / properties / table_name / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
```
- removedInput schema / properties / table_name / title
```
Removed value: -"Table Name"
```
- removedInput schema / properties / table_name / type
```
Removed value: -"string"
```
- removedOutput schema / properties / result / title
```
Removed value: -"Result"
```
- removedOutput schema / title
```
Removed value: -"_WrappedResult"
```
Addedv1.0.0Jan 3, 2026

TDQS

A3.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries the full burden, and it does disclose the read-only analytical nature of the call plus what categories of metadata come back (constraints, indexes, size, row-count estimates). It omits cost/latency characteristics and any permission prerequisites, which matter for a catalog scan across all tables when table_name is null.

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 bracketed section headers front-load purpose, then functionality, then use cases, making it easy to scan. There is some redundancy between the opening sentence and the first functionality bullet ('detailed schema information' vs 'detailed column information'), which costs it a point.

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?

An output schema exists, so return-value explanation is a bonus rather than a requirement, yet the description still characterizes the payload well. Combined with clear prohibitions, an agent has enough to call this correctly; only the sibling disambiguation and null-table_name cost implications are missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with each parameter documented in the schema itself (including the null-means-all-tables semantics for table_name and the 'public' default for schema_name). The description adds only the high-level 'specific table or all tables' framing and does not discuss schema_name or the database_name requirement, so baseline 3 applies.

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?

States a specific verb and resource ('Retrieve detailed schema information for specific table or all tables in a database') and the functionality bullets enumerate exactly what is returned (columns, types, constraints, keys, indexes, size). It does not name or differentiate from the near-identical sibling get_database_schema_info, so an agent must infer the scope boundary itself.

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?

Explicit 'Required Use Cases' with concrete trigger phrases ('table schema', 'column info', 'table structure') plus a 'Strictly Prohibited Use Cases' block that rules out data reads, DDL, and performance stats. The exclusions are real routing guidance, but the alternatives are only gestured at ('use other tools for that') rather than named, even though siblings like get_table_size_info and get_index_usage_stats exist.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server