How to Add a Remote MCP Server to GLM

How do I add a remote MCP server to GLM?

You don't — and that is the useful answer, not a technicality. MCP support lives in the client application, not in the model. GLM is Z.ai's model family, with GLM-5.3 as the current flagship, and it runs inside harnesses like Claude Code, OpenCode, and Cline. The MCP server connects to the harness, using that harness's normal MCP configuration, and the model reaches the server's tools through it.

One footnote so a stray docs page doesn't confuse you later: Z.ai's platform does document an API-level MCP route, where a chat/completions call carries an MCP server URL and Z.ai acts as the MCP client server-side. That is for developers calling the API directly — it is neither a chat.z.ai connector nor a harness, so it doesn't change the answer above.

The practical consequence is the good news: if you already had an MCP server connected in Claude Code and then switched the model to GLM, there is nothing to redo. The connection carries over untouched. And a server configured once works identically whether the session is running GLM, Claude, or anything else.

What follows is how to get GLM running in a harness that speaks MCP, since that is the part that actually has GLM-specific gotchas.

Route A: GLM inside Claude Code

Z.ai runs an Anthropic-compatible endpoint, so Claude Code can drive GLM directly. Add an env block to ~/.claude/settings.json:

{
  "env": {
    "ANTHROPIC_AUTH_TOKEN": "your-zai-api-key",
    "ANTHROPIC_BASE_URL": "https://api.z.ai/api/anthropic",
    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "glm-4.7",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "glm-5.3[1m]",
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "glm-5.3[1m]",
    "CLAUDE_CODE_AUTO_COMPACT_WINDOW": "1000000"
  }
}

Four details account for most failures here:

• The base URL is /api/anthropic — not /api/paas/v4, which is Z.ai's general OpenAI-style endpoint and won't work in this position. (If a different tool needs an OpenAI-protocol URL, a Coding Plan wants the coding-only endpoint /api/coding/paas/v4 rather than the general one, so that calls draw on the plan instead of account balance.)
• The variable is ANTHROPIC_AUTH_TOKEN — not ANTHROPIC_API_KEY
• The [1m] suffix on the model id is an opt-in for GLM's 1M-token context, paired with the CLAUDE_CODE_AUTO_COMPACT_WINDOW value above — not a required id form. Bare glm-5.3 is equally valid and simply runs without the 1M window, so a working setup using it is not broken. If Claude Code says the [1m] model does not exist, update Claude Code
• Restart the session after changing settings; the env block is read at startup, so a running session will not pick it up

Set every model tier rather than just one. Z.ai's installer maps all three tiers to GLM-4.7 by default, so naming only the Sonnet tier can quietly leave the others on an older model with no error to tell you.

Then add the MCP server the ordinary Claude Code way — this part has nothing to do with GLM:

claude mcp add --transport http my-server https://mcp.example.com/mcp

and run /mcp inside Claude Code to complete the browser OAuth.

Route B: GLM in OpenCode or Cline

The same principle applies. OpenCode and Cline both run GLM — via Z.ai's provider or OpenRouter — and both speak MCP at the harness level, so the server connects the same way regardless of which model is active. Follow whichever harness's own MCP setup you are using; the server config is identical to what you'd write for any other model.

Note: Z.ai's own chat app has no documented custom connector support as of August 2026, so you can't add an MCP server at chat.z.ai directly. The harness is the route.

Prerequisites

• A Z.ai account with a GLM Coding Plan API key — Lite, Pro, or Max, from $18/mo as of August 2026; pricing may change
• Claude Code installed (Route A), or OpenCode / Cline (Route B)

Telling the two failures apart

Because the model and the MCP server are configured independently, the most valuable diagnostic skill here is knowing which one broke:

• Model errors mention Z.ai, quotas, or the model name
• Server errors mention the MCP server by name, or OAuth

They are independent — fix them separately, and don't let a Z.ai auth error send you re-checking a server config that was never involved.

Two more specific ones:

• Settings changed but nothing happened. Restart the Claude Code session; the env block is read at startup.
• GLM works but the server's tools are missing. The env block only swaps the model. Run /mcp in Claude Code to check the server's status and complete OAuth if it is still pending.

A worked example

Tempreon is a hosted MCP server that carries your context between tools, and it makes the harness-versus-model point concrete:

claude mcp add --transport http tempreon https://api.tempreon.com/functions/v1/tempreon-mcp/mcp

Run /mcp to complete the browser OAuth. Note what the Z.ai key does and doesn't do here: it routes the model, and nothing else. The server authorizes separately through its own OAuth flow, so a Z.ai model key never authorizes the server and vice versa — the two are fully independent.

That independence is the reason a preference you teach the model in a GLM session is still there in a Claude session the next day. The account-holder walkthrough is in the GLM setup doc.