Pamela Fox, an independent software developer who writes a technical blog, published a walkthrough this month of four distinct ways to connect an AI agent to a PostgreSQL database through MCP, Anthropic’s protocol for tool calling. Her real subject is not performance. It is how much authority a database owner is willing to hand an agent that might misread a request.
At the loosest end of Fox’s spectrum sits a single tool built to run whatever SQL text it is handed against the database, no restrictions attached. She shows it working smoothly with GitHub Copilot on a database of bee sightings, then names the obvious hazard: a tool built to answer a question will just as happily execute an instruction to erase data, because nothing in its design tells the two apart.
One rung down, Fox locks the same tool to read-only queries, and she does it in layers rather than trusting one check. A Python library parses each query into a syntax tree and rejects anything that isn’t a plain SELECT statement, a database-level setting forces every connection into a read-only transaction, and a dedicated low-privilege database role backs both up. She is explicit that a tool’s own read-only label is a suggestion to the client, not an enforced guarantee, and that only code running inside the database can make the promise stick.
Further down still, Fox retires SQL from the agent’s hands entirely. Instead of a general query tool, she defines narrow functions, one for searching bee species by name, another for searching sighting records, each accepting a few named parameters that get merged into a fixed query template. An agent working with these tools cannot construct anything destructive because it is never given the ability to construct a query at all. The cost is coverage: a question outside the set of templates the developer anticipated simply cannot be answered, and Fox recommends logging those misses as a backlog of feature requests.
For cases where deletion legitimately belongs in an agent’s hands, Fox reaches for elicitation, a capability in the MCP specification that lets a server pause a tool call and send a confirmation prompt back through the client. Her example tool for deleting a bee record halts mid-execution and waits for the user to explicitly approve or cancel before anything is removed, which reproduces the confirmation dialog a human administrator would expect from any delete button in a normal admin interface.
Fox’s own recommendation sorts the four tiers by use case rather than by preference: unrestricted SQL belongs in prototypes that never see a real user, read-only access suits open-ended analytics, and typed, templated tools are what she reaches for once a system is user-facing and in production. Her one rule that spans every tier is that database-level permissions should never depend solely on the MCP server’s own code behaving correctly, since a bug in that layer should not be the only thing standing between a careless prompt and a dropped table.
The piece lands in a week when AI Insiders has covered agents being issued real API keys and account credentials, and Fox’s ladder is the same underlying problem, restated for the database layer specifically. A team wiring an agent into a production Postgres instance should be able to name which of Fox’s four tiers they chose and state plainly what a wrong guess at that tier would cost them.
Pamela Fox described the four-tier approach to safe PostgreSQL MCP servers on her personal blog, published in August 2026.
