Building Faster by Letting the Agent Work: My Experience Using GLM 4.6 and MCP Servers
I recently spun up a small personal SaaS idea and needed a simple landing page. Nothing complicated, just a clean frontend hosted on Cloudflare Pages, built with Astro and Tailwind CSS v4.1 (released January 2025). Normally I enjoy these quick projects, but this time I used it as an opportunity to experiment with a different way of working. Instead of relying on tab hopping, documentation hunting and prompting, I wanted to see what would happen if I handed the research work and part of the debugging process to an agent powered by MCP.
This post is a breakdown of what I wanted to do, how I used GLM 4.6 and z.ai's MCP servers to get there, and what I learned along the way.
What I Wanted To Do
The goal was straightforward:
- Build a new landing page for one of my personal SaaS ideas
- Use modern, clean tools, Astro, Tailwind v4.1 and deployment on Cloudflare Pages
- Reduce the usual overhead of searching documentation, checking migration notes and validating examples
- See how far MCP based workflows can replace manual browsing
Essentially I wanted a test case that was real but low pressure. A small UI task is perfect for evaluating whether AI based agents add genuine engineering leverage or just novelty.
Setting Up the Toolchain
Inside the GLM Coding Plan (Max tier), z.ai includes multi model capabilities, GLM 4.6 and the Model Context Protocol infrastructure. These two MCP servers did most of the lifting:
webSearchPrime
Searches the web and returns structured results, titles, metadata, site names, summaries and links.
webReader
Fetches page content directly and returns a parseable version, including the main text.
This combination solved the biggest LLM limitation, which is outdated training data. Models only know what was available during training. Tools bridge this gap by retrieving current information on demand.
I paired these with the Claude Code CLI so the model could directly understand and modify my workspace. Once everything was wired up, the workflow felt more like working with a small research assistant who also had access to my local code.
Setting Up MCP Servers
Before you can use MCP servers, they need to be configured separately from your z.ai subscription. Here is how to set up webSearchPrime and webReader:
Step 1: Get Your z.ai API Key
Log into your z.ai account and generate an API key from your dashboard. You will need this for authentication.
Step 2: Configure Claude Code CLI
Add the MCP servers to your Claude Code configuration. You can do this by editing your .claude.json file or using the claude mcp add command.
Example configuration structure:
{
"mcpServers": {
"webSearchPrime": {
"command": "npx",
"args": ["-y", "@z-ai/search-mcp-server"],
"env": {
"Z_AI_API_KEY": "your-api-key-here"
}
},
"webReader": {
"command": "npx",
"args": ["-y", "@z-ai/reader-mcp-server"],
"env": {
"Z_AI_API_KEY": "your-api-key-here"
}
}
}
}Step 3: Restart Claude Code
After adding the configuration, restart Claude Code CLI. The MCP servers should now be available for the model to use.
Step 4: Verify the Setup
Test by asking the model to search for documentation or fetch a webpage. You should see it using the webSearchPrime and webReader tools automatically.
For detailed setup instructions, see the z.ai Quick Start Guide.
How I Used MCP in Practice
1. Fetching the right documentation automatically
I asked the agent to pull official documentation for Astro, Tailwind CSS v4.1 and Cloudflare Pages deployment details. It used webSearchPrime to find the authoritative sources, then webReader to fetch and understand them. No guessing. No outdated examples.
Accuracy felt high, roughly 85 to 90 percent based on manual checks.
2. Validating my existing code
With the Claude Code CLI connected, the model scanned my project and compared it with the documentation it had just read.
It spotted issues such as:
- Incorrectly structured Tailwind directives
- A missing config entry
- An unused component import
- A mismatch between my Astro layout and the example from the docs
The important part is that these were not hallucinations. Each issue traced back to official documentation the agent had retrieved moments earlier.
3. Applying fixes automatically
Once the agent identified problems, it generated minimal and correct updates. In this project, every suggested fix applied without breakage.
This eliminated a lot of the "spot the typo" time that frontend work usually involves.
4. Reducing browser dependency
This was the unexpected win.
I stopped opening documentation pages manually. The agent handled:
- Searching
- Reading
- Validating
- Comparing against my code
- Fixing
I found myself writing actual code more than I was researching it. For a small project, this translated to hours saved.
What I Learned
Lesson 1, Retrieval beats recall
LLMs do not need to know everything. In fact, they should not. When models retrieve information instead of relying on stored knowledge, accuracy improves noticeably.
Frameworks move too fast. Tool assisted retrieval solves the version drift problem.
Lesson 2, Workspace awareness is transformative
A model reading documentation is useful.
A model reading documentation and inspecting your codebase is powerful.
The difference is subtle but significant. It mimics how an engineer operates, understanding the environment before proposing changes.
Lesson 3, Tools stabilise the model
When the model has to guess, it hallucinates.
When the model has tools, it validates.
MCP servers add guardrails. They constrain the answers to what is retrieved, which increases reliability.
Lesson 4, Agent driven search reduces cognitive load
The real productivity gain is not automation.
It is the removal of context switching.
Instead of juggling:
- Search tabs
- Versioned docs
- Blog posts
- Examples
- Migration guides
the agent does the filtering, and I stay focused on the actual implementation.
Lesson 5, This is closer to real engineering collaboration than chat based prompting
Prompting feels like asking questions.
Workflow tooling feels like delegation.
This is a critical point for anyone trying to move from simple AI usage to engineering leverage.
Pain Points
No workflow is perfect. These were the limitations I encountered:
- If documentation is behind heavy client side rendering, extraction quality dips.
- The agent cannot understand framework conventions that are not documented.
- Sometimes search results included less relevant sources.
- Retrieval accuracy depends partly on how well the docs are structured.
These are acceptable trade offs, but worth noting.
Why I Will Keep Using This Workflow
For a task as small as a landing page, the time saved was significant. Because MCP brought the model the latest information, the risk of it suggesting outdated patterns disappeared. And because it understood my workspace, it detected problems early and fixed them reliably.
The broader takeaway is that AI workflows are moving away from prompting and toward tool based execution. Models behave differently when given:
- Access to live data
- Access to code
- Access to structured tools
- A stable workflow loop
This is the direction engineering is heading.
Closing Thoughts
This experiment started as a small personal SaaS landing page and ended up reshaping how I think about AI in engineering. Using GLM 4.6 with z.ai’s MCP servers gave me a workflow that felt less like chatting with a model and more like collaborating with an assistant who could read, search, analyse and update code.
It is not fully autonomous, and it does not need to be. Autonomy is not the goal. Leverage is.
And for the first time, the workflow delivered real leverage.
Try It Yourself
If you want to explore this workflow, z.ai offers access to GLM 4.6 and MCP infrastructure through their GLM Coding Plan (Max tier). I have been using it for this type of work and found it genuinely useful.
You can get 10-20% off the Coding Plan using this referral link. Black Friday Special: Currently offering up to 65% off on select plans!