Category: All posts
Nov 25, 2025

Posted by

Matvey Arye
TL;DR: The MCP ecosystem is about to change. Wrappers aren’t enough. As models gain power, the risk of letting them make bad engineering decisions grows—and the solution isn’t more access, it’s more judgment.
An MCP client can successfully execute a tool call while simultaneously making a terrible engineering decision. The API interaction works perfectly. The JSON payload is valid. The database accepts the command. Yet the result—a schema with unindexed foreign keys, a timestamp column that should have been timestamptz, or a misconfigured generic flag—is technical debt created at machine speed.
The problem lies in how the ecosystem currently builds MCP servers. Most developers are building wrappers. They take an existing API, dust it in magic MCP particles, and hand it to the model.
These wrappers assume that because the model knows the vocabulary of the API, it has the taste necessary to write good code.
Often, it doesn’t.
Wrappers expose capability. They faithfully pass commands to the underlying system. But most APIs are designed to be agnostic—they let you run DROP TABLE just as easily as they let you run SELECT. They define what is possible, not what is wise.
This gap is becoming dangerous as agents get faster.
The industry is currently rushing to adopt "Code Execution" (Anthropic) and "Code Mode" (Cloudflare). These are innovations that allow models to write scripts to orchestrate tools, rather than firing off inefficient, chatty JSON-RPC calls. This solves the efficiency problem and allows models to create better APIs.
But it does not solve the judgment problem.
If you give a client a "Code Mode" sandbox and a set of neutral API wrappers, you have simply given it a faster way to write bad code. A wrapper like execute_sql will happily execute a query that triggers a sequential scan on a billion-row table. The API is working exactly as designed. The agent failed because it lacked the experience to know better.
We realized that more access wasn't the answer. We needed a way to expose expertise.
We believe the future of MCP isn't just about accessing tools, but about embedding judgment. We call this concept an AI Guide.
An AI guide is an MCP server designed to teach a model how to think, not just what it can touch. Unlike a neutral API wrapper, a guide is intentionally opinionated. It encodes the specific patterns, preferences, and hard-earned lessons of experienced engineers.
Instead of simply handing the model a database connection and waiting for a CREATE TABLE command, a guide dictates the workflow. It acts less like a CLI and more like a senior engineer pairing with a junior.
We built pg-aiguide to test this distinction. It is a reasoning layer for Postgres that sits between the agent and the database.
At its core is a library of curated skills. These are structured workflows that model expert judgment. For example, when an agent attempts to design a schema, the guide does not simply ask “what tables do you want?” It pushes the agent through a deliberate design path:
Crucially, the guide pairs this reasoning with semantic search over authoritative documentation. When the model needs to understand a specific Postgres configuration, the guide retrieves the exact manual page. This grounds the model’s decisions in current facts, preventing it from hallucinating flags that haven't existed since Postgres 9.6.
Ironically, we are making all this knowledge accessible using an MCP tool, but one that exposes knowledge not capabilities.
Across the industry, everyone is converging on the same pattern: structured, retrieval-grounded reasoning. Claude’s Skills do this. OpenAI’s ReAct-inspired flows do this. Cursor and Windsurf’s reasoning chains do this. Even proprietary coding agents are evolving toward stepwise, verifiable workflows. The pattern is clear, but each implementation lives in a closed garden tied to a specific model provider or coding agent.
By building Guides using MCP tools, we make them portable. A guide becomes a tool that any model or agent can use.
Whether you load Claude, OpenAI, or a local Llama model, using Claude Code, Cursor or Windsurf the guide enforces the same engineering standards.
We are still early. We are currently expanding pg-aiguide to include:
The pattern of "dumb wrappers" has a ceiling. To build agents that can actually be trusted in production, we need tools that contain expertise.
We are building pg-aiguide in the open. If you are a Postgres expert, or if you are building agents and are tired of cleaning up their messes, come help us define what a "Guide" looks like.
About the author

Matvey Arye
TigerData Engineer