Show HN: Cloud-Ready Postgres MCP Server (opens in new tab)

I built this to fill a specific need. It's not really made to talk to Claude Desktop (although it can). It's built to take multiple connections from agents who bring their own LLM (via API key or whatever) and provide context to the LLM model. Yes, it does import the standard Python MCP package, however it does quite a few non-standard things in order to achieve the multi-tenancy. I encourage you to look at the code.

From HN guidelines:

> Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something.

We are hackers here. Building is good. Sharing is good. All this is true even if you personally know how to do what is being shared, and it is easy for you. I promise you there are people who encounter every sharing post here and do not think what is posted is easy.

You do have to implement every functionality that you want to expose.

Yep gonna be easy

Q: show me the top 5 customers by total sales

A: System.Data.Odbc.OdbcException (0x80131937): ERROR [57014] ERROR: canceling statement due to statement timeout;

Q: Why do I get this error

A: Looks like it needs an index, let me create that for you. Done. Rerunnign query.

could not close temporary statistics file "pg_stat_tmp/global.tmp": No space left on device

Q: Why this error

A: 429 Too Many Requests

Rub hands... great next 10 years to be a backend dev.

Probably nothing. "Expose the database to the pointy-haired boss directly, as a service" is an idea as old a computing itself. Even SQL itself was originally an iteration of that idea. Every BI system (including PowerBI and Tableau) were supposed to be that.

It doesn't work because the PHB doesn't have the domain knowledge and doesn't know which questions to ask. (No, it's never as simple as group-by and top-5.)

It won’t be that easy. First off, most databases in the wild are not well documented. LLMs benefit from context, and if your tables/columns have non-intuitive or non-descriptive names, the SQL may not even work. Second, you might benefit from an LLM fine-tuned on writing code and/or an intelligent Agent that checks for relevancy and ambiguity in user input prior to attempting to answer the question. It would also help if the agent executed the query to see how it answered the user’s question. In other words “reasoning”… pg-mcp simply exposes the required context for Agents to do that kind of reasoning.

There are LLM SQL benchmarks. [1] And state of the art solution is still only at 77% accuracy. Would you trust that?

[1] https://bird-bench.github.io/

So you will ask "What is our churn?", get a random result, and then turn your whole marketing strategy around wrong number?

Thats cute.

There are hundreds of text-to-SQL companies and integrations already. What's different about this that makes you react like that?

is that true? i'd like that, but i get the sense that this mcp stuff is more oriented around programming assistant and agent applications.

i suppose the desktop app can use it, but how good is it for this general purpose "chat with the database for lightweight analytics" use cases is it worth the trouble of dealing with some electron app to make it work?

didn't Tableau (and some other BI solutions) have this feature out of the box?

Good catch.

OP, exposing your application without authentication is a serious security risk!

Quick anecdote: Last week, I ran a Redis container on a VPS with an exposed port and no password (rookie mistake). Within 24 hours, the logs revealed someone attempting to make my Redis instance a slave to theirs! The IP traced back to Tencent, the Chinese tech giant... Really weird. Fortunately, there was nothing valuable stored in it.

Xata.io looks very interesting!!! I was thinking about building an intelligent agent for pg-mcp as my net project but it looks like you did a lot of the hard work already. When thinking about the "AI Stack" I usually separate concerns like this:

  UI <--> Agent(s) <--> MCP Server(s) <--> Tools/Resources
             |
           LLM(s)

It's coming...

The biggest contribution is the LLM compatible metadata that describes the tool and its argument. It is trivial to adopt. In python you can use FASTMcp to add a decorator to a function, and as long as that function returns a JSON string you are in business. The decorator extracts the arguments and doc strings and presents that to the LLM.

Indeed. Anything you do with MCP can be done in more traditional ways.

The use case for pg-mcp is server deployment - local running is just for dev purposes. HTTP/SSE enables multiple concurrent connections and network access, which stdio can't provide.

+1

My first foray into using MCP was via Claude Desktop. Would be great if you packaged your tool such that one could add it with a few lines in their ‘~/Library/Application Support/Claude/claude_desktop_config.json’

It's not complicated at all.

All it does is expose methods as a "tool" which is then brought back to your LLM and defined with its name, description and input parameters.

E.g. Name: "MySqlTool", Description: "Allows arbitrary MySQL queries to the XYZ database", Parameters: "string: sqlToExecute"

The MCP Client (e.g. Claude Desktop, Claude Code), is configured to talk to an MCP server via stdio or sse, and calls a method like "tools/list", the server just sends a list back (in JSON) of all the tools, names, descriptions, params.

Then, if the LLM gets a query that mentions e.g. do a web search, or a web scraping, etc, it just outputs a tool use token then stops inferencing. Then the code calls that tool via stdio/sse (json-rpc), to the MCP server, which just runs that method, returns the result, then its added to the message history in the LLM, then inferencing runs again from the beginning.

It's very simple and this is actually good example.

1. You add this MCP to your DB (make sure it is securely connected to your AI of choice of course)

2. Ask anything about your data, ask to make graphs, ask to make scheduled tasks, ask to analyze queries and show optimizations and so on.

3. Profit, literally. No need to pay BI companies thousands each month.

The main things that made MCP hard for me to understand at first is that it’s both transport agnostic (so no leveraging semantic HTTP) and is an async task management protocol as well as a tool use protocol. The name itself is also poorly chosen. I would call it Tool Use Protocol.

Think about each MCP implementer like an agent’s input/output device.

Well the key it wants is for Anthropic and you can’t run those models locally.

The pg-mcp server doesn’t need an API key. Those variables are only needed to run the example claude-client. You can write your own agent to talk to whatever LLM you like.