How to Save Bloated MCP with Code Mode | ZenStack

Skip to main content

⚡Explore your database the modern way with ZenStack Studio. Try it out →

Is MCP Dead Because of Agent Skills?​

It sometimes feels like AI is not just disrupting the old world, like SaaS, but also consuming its own children in the new one. Less than a year ago, the Model Context Protocol (MCP) was the industry's "golden child", with every vendor and platform scrambling to integrate it. Then, just 6 months later, the spotlight shifted again—this time to Agent Skills, the younger sibling that seems to have stolen much of the thunder from MCP.

Suddenly, "MCP is dead" is all over social media, just like "SaaS is dead" before. However, this is a typical social media's nature to use extreme words to trigger emotions and manufacture virality. Let's first hear what their parents, Anthropic, said when they donated MCP to the Linux Foundation and released Agent Skills as an open standard at the end of 2025:

We've also seen how complementary skills and MCP servers are. MCP provides secure connectivity to external software and data, while skills provide the procedural knowledge for using those tools effectively. Partners who've invested in strong MCP integrations were a natural starting point.

— Mahesh Murag, Product manager at Anthropic

Here's the real-world industry experience on how that actually works:

Skills vs MCP tools for agents: when to use what

If you want to explore more about the double-edged sword of the MCP, here is a good article that got hyped on HackerNews:

MCP is Dead; Long Live MCP!

I agree with the author's point of view that the remote http MCP server is actually the game-changer and will be a key linchpin in organizational and enterprise adoption, shifting from vibe-coding to agentic engineering.

As a consequence, the built-in support for OAuth is a good feature that was ever added, if not the best. This is definitely one of the most important things for organizational and enterprise adaptation, which could be well illustrated by the example below in the above article:

An engineer leaves your team? Revoke their OAuth token and access to the MCP server; they never had access to other keys and secrets to start with.

That's why I also wrote a post to demonstrate how to create an HTTP MCP server with OAuth support from scratch to enable AI access to the database safely:

Turning Your Database Into an MCP Server With Auth

MCP Is Bloated​

My blog post gained quite a few attention within the ZenStack community. Given how neat the ZenStack solution is, I expected to see a variety of MCP servers with integrated Auth released.

Unfortunately, it's never happened. I didn't realize the reason until the following GitHub issue was created by one user:

[Feature Request] Optimized Schema Generation for MCP Servers

TLDR, the context window is bloated to 400K even when the user tried to load a single tool that the MCP server provided, making it infeasible to use. This "context bloating" issue is one of the most criticized issues of MCP, and it is why people are switching to Skill instead. For example, here is what the official Playwright GitHub says about Playwright CLI vs Playwright MCP

Modern coding agents increasingly favor CLI–based workflows exposed as SKILLs over MCP because CLI invocations are more token-efficient: they avoid loading large tool schemas and verbose accessibility trees into the model context, allowing agents to act through concise, purpose-built commands.

ZenStack's approach actually amplified this issue to the greatest extent. The reason is that the tools exposed by the ZenStack MCP server are the ORM's query API, which is a superset of Prisma ORM's query API. One of its strengths is that it allows nested relation queries. This means you can traverse all the models in your entire database from a single function call, something like this:

const users = await db.user.findMany({<br>select: {<br>id: true,<br>name: true,<br>posts: {<br>// relation-level filter<br>where: {<br>tags: { some: { name: "typescript" } },<br>},<br>select: {<br>id: true,<br>title: true,

tags: {<br>// deep filter<br>where: { name: "typescript" },<br>select: { name: true },<br>},

comments: {<br>where: {<br>body: { contains: "great" },<br>},<br>// switch to include here — we want all Comment columns<br>include: {<br>author: {<br>select: { id: true, name: true },<br>},<br>},<br>},<br>},<br>},<br>},<br>});

While water can carry a boat, it can also overturn it. The JSON schema generated for even a single MCP server tool becomes bloated, encompassing the entire application's schema.

A simple fix is to limit the depth of nested relation traversals to simplify the JSON schema. However, I consider this more of a workaround than a real solution:

It is neither practical nor scalable, as it can only select a limited portion of the model, making it infeasible for large projects.

It loses the strength of the query API. What could have been accomplished with a single query now needs several request/response cycles, impacting...