A
licenseNot graded
qualityD
maintenanceEnables MCP clients to access and read mdbook documentation, including structure, content, and search.
4 npm
3
MIT
PostgreSQL Docs MCP
by sav-maya
Provides access to official, versioned PostgreSQL documentation, enabling listing available documentation versions, searching within a specific version, and reading documentation pages as Markdown with pagination.
Click on "Deploy 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., "@PostgreSQL Docs MCPlook up CREATE PUBLICATION in the PostgreSQL 15 docs and cite the page"
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.
PostgreSQL Docs MCP
A public, open-source Model Context Protocol server for the official, versioned PostgreSQL documentation.
It defaults to the current stable release and can search or read every online version—including archived, beta, and development documentation.
Tools
list_versions— list every documentation version available onlinesearch_docs— search within a specific PostgreSQL versionget_doc_page— read a documentation page as Markdown, with pagination for long pages
Related MCP server: Documentary MCP Server
Access and security
This is a read-only documentation server. It:
fetches only public pages from
www.postgresql.orgnever connects to a PostgreSQL database
does not need credentials, API keys, or environment variables
cannot execute SQL or modify PostgreSQL projects
Use it in Cursor
Install uv if needed,
then add this server to ~/.cursor/mcp.json:
{
"mcpServers": {
"postgres-docs": {
"command": "uvx",
"args": [
"--from",
"git+https://github.com/sav-maya/postgres-docs-mcp",
"postgres-docs-mcp"
]
}
}
}Restart Cursor after saving the file. The first launch downloads the server and
its dependencies. In Cursor Settings → Tools & MCP, postgres-docs should
appear as enabled with three tools.
Then ask Cursor questions normally. It calls the tools when documentation is needed. For example:
Which PostgreSQL documentation versions are available?Using the PostgreSQL 18 docs, explain logical replication conflicts.Look up CREATE PUBLICATION in PostgreSQL 15 and cite the source page.What changed in the JSON functions between PostgreSQL 16 and 18?
The version defaults to current. Mention a version in your prompt when you
need behavior from a specific release.
Run locally
Requires Python 3.10+ and uv.
git clone https://github.com/sav-maya/postgres-docs-mcp.git
cd postgres-docs-mcp
uv sync
uv run postgres-docs-mcpTo make Cursor launch the local clone, use an absolute path:
{
"mcpServers": {
"postgres-docs": {
"command": "uv",
"args": [
"--directory",
"/ABSOLUTE/PATH/TO/postgres-docs-mcp",
"run",
"postgres-docs-mcp"
]
}
}
}The server follows the official
Build an MCP server
guide: Python 3.10+, MCP Python SDK 2.x, typed @mcp.tool() functions,
httpx2, and stdio transport. It never writes logs to stdout; logs go to
stderr so they cannot corrupt MCP JSON-RPC messages.
Troubleshooting
Server does not appear: Restart Cursor, then check Cursor Settings → Tools & MCP for an error beside
postgres-docs.uvxis not found: Install uv, or replace"uvx"in the configuration with the absolute path printed bywhich uvxon macOS/Linux orwhere uvxon Windows.First launch fails: Confirm that GitHub and PyPI are reachable. The first launch downloads the repository and Python dependencies.
A version or page is unavailable: Call
list_versionsfirst. PostgreSQL publishes unsupported releases in its manual archive, while unreleased documentation usesdevel.Server code looks stale: Add
"--refresh"before"--from"in theuvxarguments, then restart Cursor.
Development
uv run pytestRelated project
This MCP server provides authoritative, version-specific PostgreSQL reference material. For curated practitioner guidance on schema design, indexing, query optimization, and common pitfalls, see Postgres Skills.
npx skills add neondatabase/postgres-skillsLicense
This is a community project. It is not affiliated with the PostgreSQL Global Development Group.
Available Tools
3 toolsget_doc_pageA
Read one page from the official PostgreSQL documentation as Markdown.
Use the page slug returned by search_docs. Long pages can be continued by calling this tool again with the next offset.
Args: page: Page slug, such as "sql-select" or "functions-json.html". version: "current", "devel", or a published version such as "18" or "9.6". offset: Character offset at which to start reading. max_chars: Maximum characters to return, from 1,000 to 50,000.
| Name | Required | Description | Default |
|---|---|---|---|
| page | Yes | ||
| offset | No | ||
| version | No | current | |
| max_chars | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.5/5.0
Behavior4/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 read semantics, Markdown output, offset-based pagination, and a max_chars range of 1,000–50,000. It doesn't cover rate limits or error behavior for invalid slugs/versions, but the key behavioral traits for a docs reader are present.
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?
Purpose is front-loaded in the first sentence, followed by usage routing and a compact Args list that is necessary given the empty schema descriptions. No wasted sentences.
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 format needn't be explained, and all four zero-description parameters are documented well enough to call correctly. Only error behavior and version-discovery via list_versions are left implicit.
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, and it does fully: every one of the four parameters is explained with meaning, example slug formats, allowed version values ('current', 'devel', '18', '9.6'), and max_chars bounds.
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?
States a specific verb and resource ('Read one page from the official PostgreSQL documentation as Markdown') and names the sibling that produces the required input ('page slug returned by search_docs'). An agent can distinguish it immediately from search_docs and list_versions.
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?
Explicitly routes the agent to search_docs for slugs and explains the continuation pattern for long pages via offset. It doesn't explicitly state when not to use it or mention list_versions, but the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_versionsA
List every PostgreSQL documentation version available online.
Includes current supported releases, prereleases, the development snapshot, and archived unsupported releases.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A3.8/5.0
Behavior4/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 does disclose the non-obvious breadth of the result set, including prereleases, the development snapshot, and archived unsupported releases, which an agent would not otherwise assume. It does not explicitly state that it is read-only or side-effect free.
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?
Front-loaded statement of what is listed, followed by a compact enumeration of the included categories; every sentence earns its place. Slightly redundant in repeating 'versions' twice, but no real 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?
An output schema exists, so return structure needn't be explained, and with zero parameters and no side effects there is little else an agent must know. The only gap is that it doesn't tell the agent that the listed versions are intended as inputs to the sibling doc-fetching tools.
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 tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. No per-parameter meaning is needed or missing.
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 ('List every PostgreSQL documentation version available online') and immediately bounds the scope to supported releases, prereleases, dev snapshot, and archived releases. It doesn't name a sibling, but the purpose is self-evidently distinct from search_docs and get_doc_page.
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?
Usage is only implied: the natural inference is 'call this first to discover which version identifiers the other tools accept,' but the description never says that or mentions how it relates to search_docs/get_doc_page. No exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_docsA
Search the official PostgreSQL documentation within one version.
Args: query: Search terms, such as "logical replication conflicts". version: "current", "devel", or a published version such as "18" or "9.6". limit: Number of results to return, from 1 to 20.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| version | No | current |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A3.7/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses the single-version scope and the limit range, but it does not discuss result ordering, pagination, authentication needs, or other operational behavior.
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 short, front-loaded with the core purpose, and uses a clean argument list. Every line contributes directly to selecting and invoking the tool.
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?
The output schema exists, so return values need not be described. The purpose and all parameters are covered, though the description could be more complete by explaining when to use this search tool instead of its siblings.
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%, but the description compensates by documenting all three parameters. It gives a concrete query example, enumerates acceptable version values with examples, and states the valid limit range.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: search the official PostgreSQL documentation. It also scopes the search to one version, which is useful context, but it does not explicitly distinguish this from siblings like get_doc_page or list_versions.
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?
The description explains what the tool does but gives no explicit guidance on when to use it versus get_doc_page or list_versions. The intended use as a search endpoint is implied, but no alternatives or exclusions are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
3 tool updates
v0.1.0- First observed
get_doc_page - First observed
list_versions - First observed
search_docs
TDQS
A4.2/5.0
Scored across 3 tools
Disambiguation5/5
Each tool has a clearly distinct purpose: search_docs finds pages, get_doc_page reads a specific page, and list_versions enumerates available versions. There is no overlap, and the descriptions explicitly link them (get_doc_page uses slugs returned by search_docs).
Naming Consistency5/5
All three names follow a consistent verb_noun snake_case pattern: search_docs, get_doc_page, list_versions. The convention is predictable and readable.
Tool Count5/5
Three tools is exactly the right scope for a documentation search server: discover, retrieve, and enumerate versions. Each tool earns its place with no redundancy.
Completeness4/5
The surface covers the core lifecycle of finding and reading docs, including version selection and pagination via offset/max_chars. Minor gaps like no table-of-contents browsing or in-page search exist, but agents can work around them using search_docs.
Related MCP Connectors
Comprehensive PostgreSQL documentation and best practices, including ecosystem tools
Search and read the official MariaDB documentation for every MariaDB product, plus release notes.
Versioned documentation registry and semantic search for AI tools and coding assistants.
Search and read Apple developer documentation, HIG, and WWDC transcripts as Markdown.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceEnables creating, listing, and searching project-based documentation with Markdown content, table of contents, full-text search, and multi-client support via Streamable HTTP transport.-
- FlicenseNot gradedqualityDmaintenanceIndexes public documentation sites into PostgreSQL and exposes retrieval-only MCP tools for listing sources, searching with citations, and fetching documents.5 npm-
- AlicenseNot gradedqualityBmaintenanceEnables agents to search and read public Ravensight documentation over unauthenticated remote HTTP, retrieving cited excerpts and Markdown sections with revision-aware pagination. Provides a browsable index of document IDs and sections, with read-only, free access that cannot touch customer studios or player data.MIT
