zenstackhq
[Feature Request] Optimized Schema Generation for MCP Servers
Hey there 👋
First of all, thank you for the awesome work you’re doing with ZenStack — it’s been really inspiring to follow, especially your blog post about connecting databases to MCP. That article motivated me to try building an MCP server using ZenStack for access-controlled tool functions.
Context
I’ve been experimenting with integrating ZenStack into an MCP server setup to enable AI access to a complex database through controlled tool functions. The idea was to leverage ZenStack’s model-based access control to safely expose data operations like User_findFirst, etc.
However, I ran into a major limitation when working with our database, which has a very large and complex schema. When I tried adding even a single tool (e.g., User_findFirst), the MCP console threw an error indicating that the token length was around 410k, while the available token limit was only about 130k.
Investigation
After some testing, it became clear that the issue stems from the schema size — both the Zod and JSON schemas generated by ZenStack are simply too large for MCP’s context limits.
Manually defining smaller or simplified schemas for every tool would be technically possible but not practical or scalable for large projects. This makes it currently infeasible to use ZenStack with MCP for any non-trivial database schema.
Feature Request / Discussion
Would it be possible to introduce a way to generate "optimized" or "compressed" schemas specifically for MCP servers?
For example:
- Partial schema generation: Include only fields used by the selected operation.
- Simplified schema export: Replace detailed type definitions with minimal references or summaries.
- Configurable schema depth: Allow developers to specify how deep related models should be expanded.
- Schema reuse / referencing: Use shared references to avoid repetition in Zod/JSON schemas.
- Minified JSON schema output: Optionally generate schemas in a minified format (no whitespace, reduced metadata) to significantly decrease payload size and reduce token usage during LLM interactions.
Why This Matters
Such optimization would:
- Make ZenStack much more practical for MCP-based AI integrations.
- Reduce token usage drastically.
- Maintain the benefits of access control and type safety.
- Enable developers with large or complex schemas to actually use ZenStack-powered MCP servers in production.
Summary
- Issue: ZenStack-generated schemas are too large for MCP context limits when working with big databases.
- Goal: Add support for schema optimization (e.g., depth limiting, partial exports, or simplified schemas).
- Benefit: Makes ZenStack viable for MCP + AI applications at scale.
Would love to hear your thoughts on whether this could fit into ZenStack’s roadmap or if there are any existing workarounds you’d recommend.
Thanks again for all your work - it’s an amazing project! 🙌
@baenio, First, I want to thank you for taking the time to test it with your real case and for providing such a detailed investigation and feasible request. I’m really sorry it didn’t work out. This again reminds me of the importance of verifying it with a real-world scenario. 😅
I believe you already identified the essential issue:
The Prisma API allows infinite recursion, which could traverse all related models. Therefore, the JSON schema of even a single tool like User-findFirst would probably include the entire schema of the whole application.
Given that, except using LLM with a larger context window like Gemini, I can’t think of any other workaround for now.
It is definitely on our roadmap. Since we have been working mainly on V3 recently, we'll likely resolve the issue there first and then backport the fix to V2. I guess we would go with the Configurable schema depth way for it.
Thanks a lot for the detailed follow-up, @jiashengguo — and no worries at all! I really appreciate you taking the time to investigate this and explain the reasoning behind it.
That absolutely makes sense regarding Prisma’s recursive API structure — it’s easy to forget how quickly that can explode into a massive schema once related models start expanding. It’s reassuring to know that configurable schema depth is already on the roadmap; that sounds like exactly the kind of control that would make this feasible for larger projects.
I totally understand that the focus is on V3 right now, and it’s great to hear this issue will likely be addressed there first. I’d be more than happy to help test it out once it’s available and provide feedback from a real-world setup.
Thanks again for the clarification and for being so open about the roadmap — it’s really encouraging to see how thoughtfully ZenStack is being developed. Excited to see how V3 evolves! 🚀