GLM 5.3 MCP: Tool Calling Tested and One Costly Regression

Z.AI shipped GLM 5.3 in August 2026, and if you run MCP servers it is worth a look.

The pitch is long-horizon agent work. A 1M-token context window, 131,072 max output tokens, and reasoning baked in.

But release notes do not tell you how a model behaves against your tool schemas. So I tested it.

I pointed GLM 5.3 at a live MCP server with four deeply nested tools. Then I ran the same eight prompts — three times each — through GLM 5.2, GLM 5.1, and Claude Haiku 4.5.

The headline: GLM 5.3 shapes nested arguments better than any GLM before it. It also quietly broke something GLM 5.2 did well.

Skip this and you will either underrate the model or get bitten by the regression in production.

What Is GLM 5.3?

GLM 5.3 is Z.AI's reasoning model for software engineering and long-horizon agents. It is the successor to GLM 5.2.

Here is the spec sheet, taken from the OpenRouter model API rather than a marketing page:

Spec	GLM 5.3	GLM 5.2
Context window	1,048,576	1,048,576
Max output	131,072	262,144
Input / 1M	$1.40	$1.19
Output / 1M	$4.40	$3.74
Cached input / 1M	$0.26	$0.22
Structured outputs	Not supported	Supported

Two things stand out. Max output halved versus GLM 5.2, and structured outputs disappeared from the supported parameter list.

That second one is not a footnote. I come back to it below, because it changes how you build.

Pricing is up roughly 18% on GLM 5.2. Still cheap next to a frontier model, and cheaper per token than Claude Haiku 4.5 on output.

How I Tested GLM 5.3 MCP Tool Calling

Tool selection is the easy part. Most decent models pick the right tool from a short list.

The hard part is argument shaping — filling a nested JSON schema without violating it.

So I used the MCP Playground complex test server. Four tools, all with deep nesting, enums, and numeric bounds.

The tools were create_user_profile, process_order, analyze_data, and configure_workflow.

I wrote eight prompts, two per tool. Each had one obviously correct tool and enough detail to fill a nested payload.

I ran the full set three times per model — 24 calls each — so one lucky pass could not carry a result.

Then I scored three things, in order of how much they matter:

1. Tool picked — did it choose the right tool?
2. Schema-valid — did the arguments pass Ajv validation against the tool's real inputSchema?
3. Server-accepted — did the live MCP server actually execute the call without a validation error?

That third check is the one people skip. A call can look fine and still be rejected by the server.

GLM 5.3 vs GLM 5.2 vs Haiku 4.5: The Results

Eight prompts, three runs, four models — 24 tool calls per model against the live server:

Model	Tool picked	Schema-valid	Server-accepted	Median latency
GLM 5.3	24/24	24/24	24/24	13.2s
GLM 5.2	24/24	20/24	20/24	5.4s
GLM 5.1	24/24	6/24	6/24	9.9s
Claude Haiku 4.5	24/24	23/24	23/24	3.3s

GLM 5.3 got a clean sweep — 24 for 24. Every call valid, every call accepted by the server, in all three runs.

GLM 5.2 dropped four. Nearly all of them on the same tool, configure_workflow, and mostly the same field.

It kept passing an object where the schema wanted a string for nextStep. It also passed null once for an optional string.

That second one is a classic. Optional does not mean nullable, and plenty of models conflate the two.

GLM 5.1 was the real surprise. It picked the right tool all 24 times, then emitted truncated JSON on 18 of them.

The arguments simply stop mid-object, with a finish_reason of tool_calls. Six failures per run, every run. If you are still on GLM 5.1 with nested schemas, check your error logs.

Haiku 4.5 was not perfect either. It dropped one call on the same nextStep field that tripped GLM 5.2.

That tells you something useful: the hardest field in the suite defeated three of four models. Only GLM 5.3 got it right every time.

The honest caveat: GLM 5.3 is slow. Median 13.2 seconds against Haiku's 3.3.

It burned about 12,000 completion tokens across eight calls. GLM 5.2 used under 4,000 for the same work.

That is the reasoning tax. You pay it in latency and output tokens, and you get accuracy back.

The Structured Outputs Regression

Here is the part that will cost you an afternoon if you upgrade blind.

GLM 5.3 does not honour response_format with a JSON schema. GLM 5.2 does.

I sent both models the same strict schema, three times each, asking for a city and a population.

GLM 5.2 returned clean, schema-valid JSON on all three runs. Every time, exactly the requested shape.

GLM 5.3 returned zero valid responses out of three. It wrapped output in markdown code fences and invented its own field names.

Instead of city it returned location. Instead of a number for population, it returned a nested object.

This tracks with the OpenRouter metadata. GLM 5.2 lists structured_outputs as a supported parameter; GLM 5.3 does not.

The good news for MCP: this does not affect tool calls. Tool arguments go through a different path, and that path is solid.

So if you need guaranteed JSON shapes, route that step to GLM 5.2 and keep GLM 5.3 for the agent loop.

Why GLM 5.3 Needs a Bigger Token Budget

My first test run made GLM 5.3 look worse than GLM 5.2. That was my fault, and it is worth explaining.

I had max_tokens set to 4,000 — fine for a normal model, far too tight for a reasoning one.

GLM 5.3 spent that budget thinking, then got cut off mid tool call. The result was unparseable arguments and one missing call entirely.

Raising the ceiling to 16,000 fixed it completely. Same prompts, same server, 8/8.

If GLM 5.3 seems to emit broken tool calls, check your token ceiling first. It is almost always this.

The failure is nasty because finish_reason still reads tool_calls, not length. Nothing tells you it truncated.

When to Use GLM 5.3 for MCP Servers

After the testing, here is where I would actually reach for it.

Use GLM 5.3 when:

• Your tools have deeply nested schemas with enums and numeric bounds
• A wrong write is expensive and you would rather wait 13 seconds than roll back
• You are running long agent chains that need a big context window
• You want frontier-ish argument accuracy at roughly a third of frontier pricing

Skip it when:

• You need structured JSON output — use GLM 5.2 instead
• Latency matters and your tools are simple — Haiku 4.5 was four times faster here
• You are doing high-volume smoke tests where GLM 4.7 Flash is good enough

For a wider sweep across providers, the best AI model for MCP tool calling comparison covers the rest of the field.

How to Test Your MCP Server With GLM 5.3

You do not need the script I wrote. Four steps in the browser:

1. Open MCP Agent Studio and paste your server URL.
2. Pick GLM 5.3 from the model picker, under Z.AI.
3. Send a prompt that should trigger your most complex tool.
4. Open the tool-call inspector and read the arguments it actually sent.

That fourth step is the whole point. Read the arguments, not just the answer.

A model can produce a convincing reply off a half-wrong tool call. The inspector is where that shows up.

If your tool descriptions are vague, fix those before blaming the model — tool description quality moves accuracy more than model choice does.

And before you point any agent at a production server, scan your MCP server for tool-poisoning and injection risks.

How MCP Playground Helps

MCP Playground is where I ran every model in this post. It is browser-based and free to start.

Connect any MCP server, pick GLM 5.3 or any of 60+ models, and watch each tool call as it happens. No API key wrangling.

The compare view runs two models on the same prompt side by side — which is exactly how I caught the GLM 5.2 null-versus-optional bug.

Frequently Asked Questions

Is GLM 5.3 better than GLM 5.2 for MCP? For tool calling, yes — 24/24 versus 20/24 on nested schemas across three runs. For structured JSON output, no. GLM 5.2 still wins there.

Does GLM 5.3 support parallel tool calls? In practice yes. It returned two tool calls in a single message when a prompt needed both, even though the parameter is not listed as supported.

Why are my GLM 5.3 tool calls truncated? Your max_tokens is too low. It is a reasoning model and spends tokens before emitting the call. Try 16,000.

How much does GLM 5.3 cost? $1.40 per 1M input tokens and $4.40 per 1M output, with cached input at $0.26. About 18% more than GLM 5.2.

Conclusion

GLM 5.3 is the most reliable GLM yet at filling nested MCP tool schemas. It swept my test where 5.2 dropped one and 5.1 fell apart.

You pay for it in latency and output tokens, and you give up structured outputs entirely. Plan around both.

The only benchmark that matters is your own server. Test any MCP server free, then switch between GLM 5.3 and 5.2 mid-chat and read the arguments each one sends.