iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Giving an AI agent the same slow PostgreSQL query and a simple speed target across three MCP servers produced more than a rewritten query: it also produced repeated executions, broad verification, and indexes the task had not explicitly permitted or prohibited. In a small 2026 case study, the authors report that making permissions and verification rules explicit changed those behaviors. The results are useful for understanding agent-tool interaction, not for declaring a best PostgreSQL MCP server.
What the experiment tested
In a September 30, 2026 article, the authors gave the same agent—identified as Claude Code on Claude Opus 5—the same data, query, and one-line request with Supabase, Neon, and Postgres MCP Pro. The prompt was: “This query takes 34 seconds. Make it at least 10 times faster.” The query searched a Formula 1 lap-times database for each driver’s best lap, using a correlated subquery to find the minimum lap time. The authors used the BIRD Mini-Dev Formula 1 database, with its laptimes table expanded to 1.6 million rows.
They wrapped each server in Baton, which recorded what the agent was trying to do on each call and gave it a way to report complaints. The authors say the intent logs helped explain why calls happened, where a log of tool calls alone would show only what happened. That is their account of this instrumentation, not an independently assessed property of the tools.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →The figures below are the article’s reported outcomes from nine stock-server runs. They are not an independently audited benchmark.
#1 Best Overall
| Server | Run | Agent time | Original slow-query executions | Index created? |
|---|---|---|---|---|
| Supabase | 1 | 513 s | 4 | Yes |
| Supabase | 2 | 218 s | 3 | No |
| Supabase | 3 | 211 s | 1 | Yes |
| Neon | 1 | 309 s | 2 | Yes, 2 indexes |
| Neon | 2 | 290 s | 1 | No |
| Postgres MCP Pro | 1 | 159 s | 1 | Yes |
| Postgres MCP Pro | 2 | 224 s | 2 | Yes |
| Postgres MCP Pro | 3 | 196 s | 2 | Yes |
| Postgres MCP Pro | 4 | 143 s | 1 | Yes |
Across those runs, the reported agent completion times ranged from 143 to 513 seconds, and the original query ran one to four times per run. Seven of nine runs created an index, although the authors say the query rewrite alone was sufficient. The differences in server and run counts, alongside a single workload, do not support a general server ranking.
Why the agent did more work than the query rewrite required
Timing and result rows took separate calls
The authors observed that the agent commonly used EXPLAIN ANALYZE to get timing, then executed the query again to inspect result rows. One initial run to establish a baseline was useful; they considered the extra executions avoidable. When a tool returns timing but not the rows needed for comparison, an agent may make another call to fill that gap.
Rank #2
The task left index permissions implicit
The prompt asked for a faster query but did not say whether the agent could change indexes. The authors say the agent inferred that trying an index was acceptable. In seven of the nine stock runs, it created one, even though the rewritten query was sufficient in this case. The observation is about this task and agent; it does not establish how other agents interpret similar prompts.
Recommended Free Tools
Verification expanded to the full driver set
To check whether the rewrite preserved results, the agent reran the original slow query across all 800 race drivers rather than only the target nationality. In one 513-second session, the authors report that this check timed out twice and consumed 241 seconds. After an index was created, the check completed in 14 seconds, and the agent left the index in place.
This illustrates a verification trap: a correctness check can cost more than the proposed change if it repeats a slow baseline over a broader set than the requested result requires. The case study does not establish that the agent’s full-dataset approach was the only valid verification method.
What changed when the tool made the rules explicit
The authors forked Postgres MCP Pro and added a tune_query tool. It accepts flags specifying whether the query text may change and whether indexes may be added. The described defaults allow query changes and disallow indexes. The tool runs the query once and returns its plan, timing, rows, and a hash of the full result. It also provides a statement for hashing a rewrite so the agent can compare result hashes instead of rerunning the original query.
The response includes a rule reflecting the chosen flags. One example was: “Rewrite only. Do not create indexes. Verify with verify_sql; do not re-run the original.” In the authors’ design, that instruction appears in the response the agent is already reading, while the baseline result and hash reduce the need to make extra calls for timing, rows, or equivalence checking.
Free tools Windows power users keep installed
One-click scans. No signup required.
In three reported runs with rewriting allowed and index creation disallowed, agent times were 124, 179, and 132 seconds. Each run executed the slow query once, created no index, and did not rerun the original for verification. The article compares that 124-to-179-second range with 143-to-513 seconds across the stock runs. Because the samples are small and the run counts differ, this is evidence of changed behavior in this test, not proof of a universal speed improvement or a general server advantage.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Tool details and limitations the test surfaced
A requested timeout was not accepted by Neon’s tool
The article says the agent tried to pass a timeout argument to Neon’s run_sql tool during verification. Neon rejected the unknown argument, after which the agent ran without a cap. The author treated this as a feature request exposed by the agent’s behavior. This is a report about the tested setup, not a statement about current Neon capabilities.
Transaction wrapping affected maintenance statements in the tested setup
The authors report that Postgres MCP Pro wraps statements in a transaction, and PostgreSQL refuses VACUUM and CREATE INDEX CONCURRENTLY inside a transaction. The agent encountered this after creating an index and filed feedback. The article says Supabase and Neon allowed those statements in the tested setup. These observations can depend on server version and configuration; they are not current compatibility guarantees.
Some refusals did not appear in the session error rate
The article reports a 0% session error rate even though the refusals appeared in otherwise normal-looking tool responses. The authors use this as an example of why a server-level metric may not capture every frustrating agent interaction. It is a specific observation from their test, not a claim about how all MCP server error metrics work.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →How to interpret the comparison
The useful comparison is about workflow, not a podium. In this experiment, the relevant questions were whether the agent could retrieve timing and rows together, whether rewrite and index permissions were clear, how result equivalence was checked, and whether the execution context accepted maintenance commands. Total completion time and the number of baseline executions show the cost of the whole interaction, but each figure reflects this query, data, agent, configuration, and small number of runs.
- For tool builders: returning baseline rows alongside timing and a result hash can remove reasons for redundant calls; explicit action constraints can reduce ambiguity about indexes.
- For agent users: prompts or tool responses can specify which changes are allowed and how verification should be done, rather than leaving permissions and the verification strategy unstated.
- For evaluators: count repeated baseline executions and inspect the reason for each call, not just whether the final query was faster. A one-query, nine-run case study is not enough to predict behavior across workloads or servers.
As author Dave Eyler put the intervention: “Nothing in that tool is clever. It settles the one question the agent was guessing at, it hands over the baseline so the agent doesn’t go back for it, and it puts the rule in the response the agent is already reading instead of in a description it skimmed at startup.”
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
