MCP Server for PostgreSQL: Querying a Database Through an AI Agent

Answering a one-off question about your data usually means pulling in an analyst: finding the right tables, remembering the relationships, writing SQL, exporting the result. An MCP server for PostgreSQL lets you take the same path through an agent instead. You ask a question in plain language, the agent inspects the schema, builds the query, and explains the result.

What tasks fit here

It's best to start with reading and exploration:

• describe the tables and relationships in an unfamiliar database;
• count orders, signups, or errors over a period;
• find outliers and gaps in the data;
• prepare SQL for a report and explain each part of the query.

Deleting rows, migrations, and bulk updates are a poor first scenario. Even a good model can misread a business rule. MCP speeds up working with PostgreSQL, but transactions and backups don't stop mattering because of it.

Start with a dedicated user

Don't connect the agent as the database owner. Create a separate role, grant it connection access, access to the relevant schema, and SELECT only on the tables it needs. If there's a replica for analytics, use that instead of the primary database.

It's also worth capping query execution time and the number of rows returned. That protects against more than just a model mistake — an ordinary bad query without a LIMIT can tie up a production database for a while too.

How to connect PostgreSQL in Doka

For a quick test, the reference package @modelcontextprotocol/server-postgres works well. In Doka, open the "MCP Servers" tab, add a server, and set:

• Name: PostgreSQL — analytics.
• Command: npx.
• Arguments, one per line: -y, @modelcontextprotocol/server-postgres, then a connection string like postgresql://readonly:password@localhost:5432/analytics.

Save the server and ask: "describe the available schemas and tables, don't make any changes." If you're using a different MCP server, take the command and the connection string's variable name from its README — implementations differ and don't all accept parameters the same way.

The connection string contains a password and is stored in the app's local configuration. For ongoing use, it's better to pick a server that accepts the secret through an environment variable, or use a password with minimal permissions and rotate it regularly.

Does data really stay local?

If PostgreSQL is on your computer or an internal network, the MCP server runs locally, and Doka is set to a local model, the query and result never have to go to a cloud AI. That's what makes it a private setup.

But "local" doesn't automatically mean "safe." The result can end up in a log, a chat export, or a computer backup. Personal and financial data still need the same storage rules as any regular analytics export.

How to check the quality of an answer

Ask the agent to show the SQL before running it, and to explain why it picked those tables and filters. For numbers that matter, it helps to cross-check the result with a control query. A good phrasing looks like this:

Find the number of paid orders in June. Show me the SQL first. Read-only, add a reasonable LIMIT for examples, and list your assumptions separately.

The general pattern for different database engines is covered in the article on databases through MCP, and Doka is free to download.