When we released the first beta of the pgEdge Postgres MCP Server back in December, we were excited to see the community’s response to what we’d built. Since then, the team has been hard at work adding new capabilities, refining the user experience, and addressing the feedback we’ve received. I’m pleased to share what’s landed in Beta 2 (now available) and what’s coming in Beta 3 (currently in QA).

Beta 2: Write Access, Token Efficiency, and a Better CLI

Beta 2 represents a significant step forward in making the pgEdge Postgres MCP Server more capable and more efficient.

Write Access Mode

Perhaps the most requested feature since we launched has been the ability to do more than just query data. In Beta 2, we’ve introduced an optional write access mode that allows the LLM to execute DDL and DML statements when enabled.

This feature is disabled by default - safety first - but when you do enable it via the allow_writes configuration option, the server will permit CREATE, DROP, ALTER, INSERT, UPDATE, and DELETE operations. We’ve also added automatic schema metadata refresh after DDL operations, so get_schema_info always returns current information.

To ensure users are always aware when they’re connected to a write-enabled database, we’ve added visual warnings throughout the interfaces. The web client displays a prominent amber warning banner, whilst the CLI shows a [WRITE-ENABLED] indicator in the database listing and warns you when switching to such a database. We want there to be no ambiguity about what the LLM can and cannot do.

Token Management Improvements

Anyone who’s worked with LLMs knows that token usage matters - both for cost and for context window management. Beta 2 introduces several features designed to reduce token consumption.

The new count_rows tool provides a lightweight way to check the size of a table before querying it. Rather than fetching data only to discover you’ve got millions of rows, you can now get a count first and plan your query accordingly.

We’ve also added pagination support to query_database with an offset parameter, allowing you to page through large result sets without overwhelming the context window. The tool now fetches one extra row beyond your limit to indicate when more data is available.

Perhaps most significantly, query results are now returned in TSV format rather than JSON. This simple change delivers meaningful token savings when dealing with larger result sets, as TSV has considerably less structural overhead than JSON.

CLI Command Consistency

We’ve reorganised the CLI commands to be more intuitive and consistent. The LLM-related commands have been simplified (/set llm-provider becomes simply /set provider), and the standalone listing commands have been moved under a unified /list namespace. These might seem like small changes, but they make the CLI considerably more pleasant to use day-to-day.

Hybrid Chunking for the Knowledgebase Builder

The knowledgebase builder has received a significant upgrade with a new hybrid chunking algorithm. The previous approach could sometimes break content at awkward points, separating code from its explanation or splitting tables mid-row.

The new two-pass algorithm first splits at semantic boundaries, then merges undersized chunks. It preserves structural elements like code blocks, tables, and lists intact where possible, and includes full heading hierarchy tracking so chunks have proper context. This leads to noticeably better RAG results.

Beta 3: Custom Tools, LLM Database Switching, and More

Beta 3 is currently in QA, so I can’t give you an exact release date, but I can share what’s coming.

Custom Tools

This is the headline feature for Beta 3, and I’m particularly excited about it. Custom tools allow you to define your own database operations as callable MCP tools via YAML configuration.

We support three tool types. The first, sql, executes parameterised SQL queries with $1, $2 style placeholders. The second, pl-do, executes PL/* DO blocks (anonymous functions) with automatic result handling. The third, pl-func, creates temporary PL/* functions with proper RETURN types.

Language support includes plpgsql, plpython3u, plv8, and plperl. We’ve added an allowed_pl_languages configuration option per database so you can control which procedural languages are available, providing an additional security layer.

Why does this matter? It means you can expose complex business logic to the LLM without it needing to understand the implementation details. Define a tool called calculate_customer_lifetime_value, and the LLM can use it without needing to know the intricacies of the calculation. This opens up some genuinely powerful possibilities for domain-specific applications.

LLM Database Connection Switching

Another significant addition is the ability for the LLM itself to switch between configured database connections during a conversation.

Our CLI and web-based Natural Language Agents have always been able to switch between configured databases using the REST API, but third-party MCP clients like Claude Code and Cursor were restricted to using only the first configured database connection. This new feature exposes database switching as MCP tools, allowing any MCP client to work with multiple databases.

The new list_database_connections tool allows the LLM to discover what databases are available, whilst select_database_connection allows it to switch between them. This is disabled by default (via llm_connection_selection) and you can further restrict which databases are switchable using the per-database allow_llm_switching option.

Both the web client and CLI update in real-time when the LLM switches databases, so you always know which database you’re querying.

Improved UI and Error Handling

Beta 3 includes various quality-of-life improvements. The conversation history panel now opens by default in the web GUI, making it easier to access past conversations. We’ve improved error messages throughout - authentication failures now display helpful messages rather than cryptic RPC error codes, and the web GUI handles proxy errors gracefully rather than showing raw HTML.

We’ve also standardised the configuration file paths for consistency, with all config files now using the postgres-mcp prefix and searching /etc/pgedge/ first.

Bug Fixes

A notable fix in Beta 3 addresses an issue where DDL and DML statements could fail silently when allow_writes was enabled. The root cause was pgx’s prepared statement caching behaviour interacting poorly with non-SELECT statements. The query_database tool now correctly uses tx.Exec() for DDL and DML statements, whilst continuing to use tx.Query() for DML statements that include RETURNING clauses.

Looking Forward

We’re continuing to develop the pgEdge Postgres MCP Server based on community feedback and our own roadmap. If you haven’t tried it yet, Beta 2 is available now - and Beta 3 should follow shortly once it clears QA.

As always, we welcome feedback, bug reports, and feature requests via the GitHub repository. The MCP ecosystem is evolving rapidly, and we’re committed to ensuring the pgEdge Postgres MCP Server remains a first-class option for connecting LLMs to PostgreSQL databases.