The GLM Subagent MCP server lets you delegate coding and text tasks to a cheaper GLM model (~10x cheaper than Claude Opus), while your main agent handles orchestration and review.
glm_agent — Run GLM as a full coding agent in your repo with file tools (read, write, edit, list directories, bash commands). Supports dry_run mode to preview diffs without writing files, returns usage stats, and prints a git-checkpoint revert line after every real run.
glm_delegate — Pure text generation via GLM (no file access). Useful for writing code snippets, docs, or any text task. Supports optional system prompt, context injection, reasoning mode, and output format control.
glm_recommend — Free local advisory (no API call). Recommends whether to use GLM or the main model based on task complexity, context size, sensitivity, vision input, and more. Returns a recommendation, suggested model, confidence level, and reasons.
glm_status — Free local status check (no API call). Shows current peak window, active model, cumulative usage ledger totals (usage.jsonl), and config health.
Key features:
Cost savings: GLM tokens are ~10x cheaper; main model only pays for orchestration and review.
Peak-aware routing: Automatically selects cheaper models during China peak hours (14–18 UTC+8).
Safety: Dry-run mode, git revert lines, key isolation, and data residency warnings.
Integration: Works with Claude Code, GitHub Copilot, VS Code, Cursor, Windsurf, Claude Desktop, and any MCP client. Can be run via npm or Docker.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@GLM Subagent MCP Ask glm to review and fix the bug in server.js"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
GLM (Zhipu / Z.ai) as a ~10x cheaper delegate for your AI coding agent. Your expensive
main model — Claude Opus, Copilot's default, or Codex — orchestrates and reviews; GLM does
the actual work, billed on cheap GLM tokens. GLM exposes an Anthropic-compatible /v1/messages
endpoint, so it drops into anything that already speaks Anthropic. This repo wraps it as an
MCP server with four tools, plus one-command installers for Claude Code, GitHub Copilot,
and Codex. The same server powers every edition.
flowchart TD
You["You"]
Main["Main agent (Claude Opus / Copilot / Codex)<br/>orchestrates + reviews"]
Srv["glm MCP server (stdio)<br/>4 tools"]
Rt["Router<br/>peak-aware model pick + cost bias"]
Zai[/"Z.ai Anthropic endpoint<br/>POST /v1/messages"/]
Loop["glm_agent tool loop<br/>read_file / write_file / edit_file<br/>list_dir / run_bash — on your repo"]
Led[("usage.jsonl<br/>every GLM call: model + tokens")]
Repo[("your repo")]
You --> Main -->|"glm_agent(task, workdir)"| Srv
Srv --> Rt --> Zai
Zai -->|"tool calls"| Loop
Loop -->|"tool results"| Zai
Loop -->|"reads / writes / runs"| Repo
Zai --> Led
Srv -->|"summary + GLM STATS<br/>(model, tokens, est. cost)"| Main
Main -->|"review · diff · revert"| YouPlain-English walkthrough:
You ask the main agent for work.
The main agent delegates via glm_agent — it passes a goal plus an absolute workdir.
The server's router picks a GLM model (peak-aware) and calls the Z.ai /v1/messages
endpoint; the cost bias keeps GLM the default.
GLM runs its own agent loop (read_file / write_file / edit_file / list_dir /
run_bash) directly against your repo, then stops with a summary.
The server returns a concise summary + a GLM STATS block (model, tokens, est. cost) to
the main agent.
The main agent reviews; every GLM call is also appended to the usage.jsonl ledger.
Token economics. Delegated work bills GLM tokens (~10x cheaper). The main model only
pays for orchestration + review. A near-100% GLM share requires the full-GLM launcher
(claude/glm-code.mjs), because a hybrid main agent always carries
per-turn session context — that context is the floor on its token share.
Related MCP server: GLM-4.6 MCP Server
Tool | Cost | What it does |
| GLM tokens | GLM as a real coding agent in your repo (read/write/edit/run). |
| GLM tokens (opt-in) | Pure text generation — text in, text out. Hidden by default ( |
| free (local) | GLM-vs-main-model advisory: which engine, which GLM model, confidence, and reasons. No GLM call. |
| free (local) | Peak window, active model, usage-ledger totals (proof of GLM spend), and config health. No GLM call. |
Live progress. glm_agent streams MCP progress notifications while it runs —
current iteration, token count, and tok/s — shown live in Claude Code and mapped to
tool.execution_progress in VS Code Copilot. This heartbeat also keeps long calls alive on clients that
reset their timeout on progress, and cancelling a run stops GLM promptly (partial changes are shown
and revertable). max_tokens defaults to auto (uncapped/generous; the orchestrating agent may
pass a number to cap a call). The server uses an idle/stall timeout (GLM_STALL_TIMEOUT_MS, 2 min),
so an actively-streaming turn is never cut off. If a very long run is still cancelled by your client's
tool-call timeout, raise it with MCP_TOOL_TIMEOUT / CLAUDE_CODE_MCP_TOOL_IDLE_TIMEOUT.
npx glm-mcp-claude --key YOUR_ZAI_KEYInstalls globally by default (user-scoped): the MCP server, a full-tool glm subagent, a
PreToolUse auto-routing hook, and an optional glm-code full-GLM launcher. Restart
Claude Code, then run glm_status to confirm api_key_loaded: true.
Full details: claude/README.md.
npx glm-mcp-copilot --key YOUR_ZAI_KEY # current workspace
npx glm-mcp-copilot --global --key YOUR_ZAI_KEY # every workspaceInstalls the MCP server in agent mode, a GLM custom agent (subagent), a PreToolUse
auto-routing hook, and delegation instructions files. Reload the VS Code window, open
Copilot Chat in Agent mode, start the glm server.
Full details: copilot/README.md.
Install the published Codex package:
npx glm-mcp-codex --key YOUR_ZAI_KEYInstalls a Codex MCP registration, a glm custom agent, the glm-delegate skill, and an advisory
UserPromptSubmit/PreToolUse hook. The config gives GLM tools a 30-minute timeout and prompts before
mutating calls. Restart Codex, review the hook with /hooks, and run glm_status.
Full details: codex/README.md.
The standalone glm-mcp package — no installer needed
for Cursor, Windsurf, Claude Desktop, Glama, etc.:
{
"mcpServers": {
"glm": {
"command": "npx",
"args": ["-y", "glm-mcp"],
"env": { "GLM_API_KEY": "YOUR_ZAI_KEY" }
}
}
}For containers, the repo-root Dockerfile runs the same server:
docker build -t glm-mcp .
docker run --rm -i -e GLM_API_KEY=YOUR_ZAI_KEY glm-mcpThe server boots and answers MCP introspection without a key — set GLM_API_KEY only for
actual GLM calls.
Claude Code -> | GitHub Copilot (VS Code) -> | Codex -> | |
npm package |
|
|
|
Install |
|
|
|
MCP server | user-scoped ( | VS Code agent mode ( |
|
Subagent |
|
|
|
Auto-routing hook | PreToolUse, | PreToolUse, fires on all calls ( | UserPromptSubmit + PreToolUse, advisory only |
Delegation policy | appended to |
|
|
Full-GLM launcher |
| — | |
Docs |
Parity. All three editions expose the same four tools and a subagent while using the same
server underneath. Codex uses its native custom-agent, skill, and hook surfaces; its hook is advisory
only and must be trusted by the user. Only Claude ships the standalone glm-code full-GLM launcher.
All knobs live in .env (git-ignored). Location per edition: Claude
~/.claude/glm-mcp/.env (set during install); Copilot ~/.glm-mcp/glm-mcp/.env; Codex
~/.codex/glm-mcp/.env. Codex sets tool_timeout_sec = 1800 because its default MCP tool timeout is
60 seconds. Full reference with comments: claude/glm-mcp/.env.example.
Var | Default | Meaning |
| — | Your Z.ai / Zhipu GLM Coding Plan key. Required for GLM calls. |
|
| Anthropic-compatible endpoint ( |
|
|
|
|
| How hard to favor GLM. |
|
| GLM caps in-flight requests (~1); keep at 1 unless your tier allows more. |
|
|
|
|
| Hard per-call limit applied only when |
|
| Generous default used when the cap is off. |
|
| Retries on 429 / concurrency / 5xx with exponential backoff. |
|
| Per GLM HTTP request timeout (5 min). |
|
| Max tool-loop turns for |
|
| Per- |
|
| Candidate model(s) for |
|
| Candidate model(s) for |
|
| The cheap model (used in the full-GLM launcher's Haiku slot). |
|
| Peak window start, China hour (UTC+8). |
|
| Peak window end (exclusive), China hour (UTC+8). |
China peak window is 14:00–18:00 (UTC+8). The glm-5.x family carries a surcharge at peak
(~3x peak / ~2x off-peak), so when auto lands on a glm-5.x model at peak the router routes
less work to GLM; if you list a no-surcharge model (e.g. GLM_PEAK_MODEL=glm-5.2,glm-4.7) the
router prefers it at peak and GLM stays fine to use. The cost bias keeps GLM the default either
way — even at peak it is cheaper than the main model.
What stays on the main model: sensitive / secret code, vision input, parallel fan-out,
128K context, latency-tight loops, and heavy dependent tool-loops (the router's hard overrides).
usage.jsonl ledger — every GLM call is appended on disk with model + input_tokens +
output_tokens. Claude: ~/.claude/glm-mcp/usage.jsonl; Copilot:
~/.glm-mcp/glm-mcp/usage.jsonl. Independent of the Z.ai dashboard.
glm_status — prints the cumulative ledger totals (calls, tokens, per-model counts).
=== GLM STATS === block — printed after every glm_agent run: model, tokens delegated,
iterations, files changed, est. cost vs Opus.
If the ledger is empty, GLM was never called — the work ran on the main model.
dry_run: true on glm_agent — GLM proposes a full diff and writes nothing; approve before
applying.
Git checkpoint revert line — printed after every real glm_agent run (when the workdir is a
git repo), so you can undo in one command.
Key isolation — GLM_API_KEY lives only in the git-ignored .env; it is never baked into
the npm packages (scripts/publish-server.mjs scans every pack for .env / usage.jsonl /
node_modules and fails loudly).
Data residency — GLM traffic goes to Z.ai servers in China. Keep secrets and regulated code
on the main model; the router's sensitive flag forces it there.
CI (see .github/workflows/ci.yml) runs: syntax checks on the server
and every installer/hook/script, the keyless stdio smoke (scripts/smoke-stdio.mjs)
that asserts the four-tool MCP handshake with no key on disk, a Docker introspection test
(initialize piped into the built image), and an npm-pack secret scan
(scripts/publish-server.mjs). PRs welcome — see
CONTRIBUTING.md.
MIT © djerok · Canonical repo: https://github.com/djerok/glm-mcp
Run GLM as a real coding agent with its OWN file tools (read/write/edit/list/bash); it works your repo end-to-end on GLM tokens (~10x cheaper than Opus). Prefer this over doing repo work yourself. Pass task + absolute workdir. Returns a concise summary+stats (use dry_run to preview a diff first). Not for sensitive, huge-context, or heavy dependent-tool-loop work.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | The coding task for GLM to carry out end-to-end in the repo. | |
| model | No | Model id or 'auto' (default, peak-aware). | |
| format | No | concise (default: summary+stats+changed files) or detailed (adds full diff). dry_run always shows the diff. | |
| context | No | Optional extra context/constraints (GLM can also read files itself). | |
| dry_run | No | If true, GLM proposes a diff and writes nothing (preview before applying). Default false. | |
| workdir | No | Absolute path to the project root GLM should operate in. Defaults to the server's cwd; always pass it explicitly. | |
| thinking | No | Enable GLM reasoning mode for harder tasks. Default false. | |
| max_tokens | No | Max output tokens per turn (ceiling; billed for actual). Default generous. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and openWorldHint=true, so the description adds context about cost (~10x cheaper than Opus) and the scope of file tools (read/write/edit/list/bash). It does not reiterate the destructive nature but adds complementary details. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each serving a distinct purpose: what the tool does, when to use it, and return value format. Front-loaded with the core capability, no redundant words. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 params, destructive, no output schema), the description covers purpose, usage guidelines, behavioral traits (cost, file tools), return value (summary+stats), and limitations. It is fully adequate for informed selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds meaning beyond schema by emphasizing 'Pass task + absolute workdir', explaining dry_run preview behavior, and noting default model is 'auto' (peak-aware). This adds moderate value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Run' and resource 'GLM as a real coding agent with its own file tools', specifying it works the repo end-to-end. It distinguishes from siblings (glm_delegate, etc.) by highlighting the agent's file-accessing capabilities and cost efficiency.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises 'Prefer this over doing repo work yourself' and lists exclusions: 'Not for sensitive, huge-context, or heavy dependent-tool-loop work.' This provides clear when-to-use and when-not-to-use guidance, with implied alternatives via sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Text-in/text-out subtask on GLM (~10x cheaper than Opus); returns text only. GLM has no file/tool access -- put everything in task+context. For file edits use glm_agent instead. Not for sensitive, long-debugging, large-refactor, or parallel work.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | The instruction for GLM. Be explicit and self-contained, e.g. 'Write a React component that...'. | |
| model | No | Model id or 'auto' (default). e.g. glm-5.2, glm-4.7, glm-4.5-air. 'auto' picks peak-aware. | |
| format | No | concise (default) or detailed metadata. | |
| system | No | Optional system prompt to steer GLM's role/format. | |
| context | No | Supporting material GLM needs: code to modify, file contents, specs, examples. GLM has no file access. | |
| thinking | No | Enable GLM reasoning mode for harder tasks (slower). Default false. | |
| max_tokens | No | Max output tokens (ceiling; billed for actual). Default generous. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses that GLM has no file/tool access (beyond annotations), cost comparison, and that output is text only. It does not detail potential side effects, but annotations (readOnlyHint=false, destructiveHint=false) provide baseline; the description adds context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences: first covers purpose and cost, second states limitations and alternatives. No redundant words, front-loaded with key info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers purpose, limitations, alternatives, and parameter usage. No output schema exists, but 'returns text only' is sufficient. Missing details on error handling, but overall adequate for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage, but the description adds value by advising 'put everything in task+context' and emphasizing self-contained instructions. This clarity goes beyond basic schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is for delegating a text-in/text-out subtask to GLM, highlights cost advantage over Opus, and distinguishes from sibling 'glm_agent' for file edits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (simple text subtasks) and when not to ('Not for sensitive, long-debugging, large-refactor, or parallel work'), and recommends 'glm_agent' for file edits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free local advisory (no GLM call): given a task profile, returns GLM-vs-Opus, model, confidence, and reasons. Call when unsure which engine to use.
| Name | Required | Description | Default |
|---|---|---|---|
| steps | No | Approx number of dependent sequential steps. >20 forces Opus (goal drift). | |
| vision | No | True if input includes images/screenshots/GUI/computer-use (forces Opus). | |
| chinese | No | True if Chinese or Chinese-English bilingual (GLM strength, +1). | |
| sensitive | No | True if proprietary/security-critical (forces Opus). | |
| task_type | No | Closest task category. Default 'general'. | |
| complexity | No | Default 'medium'. | |
| input_tokens | No | Approx context size needed. >128K forces Opus (GLM degrades past ~100K). | |
| long_horizon | No | True if many sequential steps / multi-hour autonomy. | |
| tool_pattern | No | Tool-use shape: single one-shot call / short independent fanout (GLM-ok) vs heavy dependent agentic loop (forces Opus). | |
| needs_parallel | No | True if it needs several concurrent agents (forces Opus). | |
| unfamiliar_api | No | True if it uses a niche/post-cutoff/internal API GLM can't know (-2; paste docs or use Opus). | |
| latency_sensitive | No | True if a tight interactive loop (forces Opus). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds value by stating 'Free local advisory (no GLM call),' confirming no side effects and no cost, which aligns with readOnlyHint. It could also mention that input stays local, but the provided information is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two sentences) and front-loaded with the core purpose. Every word earns its place, with no fluff. It achieves maximal information density in minimal space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (12 parameters, all well-described in schema) and the presence of sibling tools, the description is complete. It states that the tool is advisory and free, specifies the return format, and the schema covers all parameter semantics. No output schema is needed as the return format is described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add additional parameter semantics beyond what the schema already provides (e.g., '>20 forces Opus'). The schema descriptions are detailed and include decision-relevant hints. The description's summary of return values is useful but not parameter-specific.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool's purpose: 'given a task profile, returns GLM-vs-Opus, model, confidence, and reasons.' It uses a specific verb ('recommend'), specifies the resource ('GLM vs Opus for a task'), and distinguishes from sibling tools like glm_agent and glm_delegate which are for actual execution, not advisory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly says 'Call when unsure which engine to use,' providing clear context for when to use this tool. It does not explicitly state when not to use it or list alternatives, but the sibling tool names (glm_agent, glm_delegate, glm_status) imply they are for different tasks. A clear guidance with exclusions would improve it to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free local status: peak window, active model, GLM usage ledger (proof of GLM tokens spent), and config health. No GLM call.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds specifics about what status attributes are included (peak window, active model, etc.), providing useful context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that efficiently communicates the tool's purpose and scope with no extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers what the tool returns (status components) for a simple read-only tool with no output schema. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is 100%. The description does not need to add parameter details, and it doesn't. Baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides status information: peak window, active model, GLM usage ledger, and config health. It also distinguishes from siblings with 'No GLM call,' indicating this tool does not perform GLM actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates the tool is for checking status without invoking GLM, but does not explicitly state when to use it over siblings or provide exclusions. The sibling context implies distinct purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: glm_agent performs full repo work with file access, glm_delegate handles text-only subtasks, glm_recommend advises on model choice, and glm_status shows usage and config. There is no overlap or ambiguity.
All tool names follow a consistent 'glm_' prefix followed by a descriptive word (agent, delegate, recommend, status). The pattern is uniform with lowercase and underscores, making it easy to understand each tool's function.
With 4 tools, the set is well-scoped for the server's purpose of providing GLM subagent capabilities. Each tool justifies its existence, covering distinct modes of interaction without unnecessary bloat or deficiency.
The tool surface covers the full lifecycle: doing work (agent and delegate), getting advice on which to use (recommend), and monitoring usage (status). There are no obvious gaps for the intended use case of a GLM subagent.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Pay-per-call GLM 5.3 MCP tool via x402 on Base. Reasoning, tool-calls, OpenAI-compatible.
Coding agents from Claude Code, Cursor and Codex claim jobs and lock files on one shared board.
No-data MCP handoff for local Claude Code to Codex harness moves. $49 lifetime.
Source-checked CLI guides and model-aware planning for Claude Code, Codex, and Grok Build.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/djerok/glm-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
