一个 MCP 服务器，将 Z.ai 的 GLM 模型（GLM-5.3 及其同系列模型）作为工具暴露在 Claude Code 和 Claude Desktop 中。
Claude Desktop 固定使用自己的模型提供商：当它启动内嵌的 Claude Code 时，会强制将 ANTHROPIC_BASE_URL 指向 Anthropic 的端点，并从子环境中移除 ANTHROPIC_API_KEY / ANTHROPIC_AUTH_TOKEN。因此 GLM 无法驱动桌面会话。本服务器走另一条路——GLM 成为 Claude 在对话中途可以调用的工具。
适用于：
真正的第二意见。 一个独立的顶尖模型，而不是同一个模型问两次。
超大的上下文。 GLM-5.3 拥有 1,000,000 token 的窗口，因此你可以向它提供远超普通会话容量的源码材料。
廉价的批量工作。 将繁重的工作路由到 glm-4.7，把昂贵的模型留给推理。
只需注册一次（用户级作用域），即可在机器上的每个项目中使用——无需逐项目配置：
claude mcp add --scope user glm -- npx -y @nocompromiseai/glm-mcp或者从本地检出安装：
npm install && npm run build
claude mcp add --scope user glm -- node /absolute/path/to/glm-mcp/dist/index.js重启 Claude Code / Claude Desktop 以使其生效。使用 claude mcp list 验证。
需要 Node 20 或更高版本，以及一个带有余额或 Coding Plan 的 z.ai API 密钥。
Related MCP server: CCGLM MCP Server
服务器从不硬编码密钥。它按以下顺序解析一个密钥：
ZAI_API_KEY
~/.config/zai/api-key
ZCode 存储在 ~/.zcode/v2/config.json 中的 api.z.ai 密钥——仅当设置了 GLM_MCP_ALLOW_ZCODE_KEY=1 时
第 3 步是有意设为可选的。它读取属于另一个应用程序的凭据，这应该是你做出的决定，而不是你发现的行为。一切都在执行安装的机器上运行：你的密钥、你的 z.ai 账户、你的账单。
请注意，ZCode Start Plan 令牌在此处不可用——该端点对 ZCode 应用进行了验证码锁定，并以 3007 拒绝外部客户端。你需要一个带有 Coding Plan 或余额的 api.z.ai 密钥。
注册后，让 Claude 使用它。实际上你会说类似 “使用 glm_ask 审查 src/auth 中的竞态条件” 的话——但底层调用看起来像这样：
{
"prompt": "Does the refresh logic have a race condition? Point at the lines.",
"files": ["src/auth/**/*.ts"],
"reasoning": "high"
}回复带有页脚，包含模型、token 使用量以及推理量：
The refresh path in session.ts:88 reads `expiresAt` before taking the lock ...
[glm-5.3 · in 4210 / out 380 tok · reasoned 2170 chars]它真正擅长的两件事：
会提出不同意见的第二意见。 向 Claude 和 GLM 提出相同问题并比较。两个模型意见不同是真正的信号；同一个模型问两次大多不是。
超出容量的源码。 凭借 1M token 的窗口，你可以将 src/**/*.ts 整体交给它，而不是精心挑选少量文件。
glm_ask参数 | 类型 | 默认值 | 说明 |
| string | — | 必需 |
| string[] | — | 要作为上下文包含的文件：字面路径和/或 glob 模式（ |
| string | 服务器 cwd | 相对 |
| string |
| 来自 |
|
|
| 越高越慢 |
| string | — | 可选的系统提示词 |
| number | 8192 | 输出上限 |
glm_models列出配置账户上可用的模型 id。
GLM-5.3 总是进行推理。 没有思考块的请求会被 z.ai 错误 1210 拒绝，因此对于该模型，reasoning: "none" 会被静默提升为 "low"。其同系列模型（glm-5.2、glm-5-turbo、glm-4.6、glm-4.7）没有此限制。
| 思考预算 |
| 2,048 tokens |
| 8,192 tokens |
| 24,576 tokens |
max_tokens 会自动提高，以便在预算之上为答案留出空间。
glm_ask 仅在操作者设置的根目录内读取。调用者可以在其中缩小范围；它既不能选择也不能逃逸这些根目录。
根目录来自 GLM_MCP_ROOTS，以冒号分隔的绝对路径。
未设置时，根目录是服务器启动时所在的目录。Claude 为每个项目启动一个服务器，因此每个服务器都被限制在自己的项目内，大多数设置无需任何配置。
cwd 必须解析到根目录内。如果不是，调用会被直接拒绝，而不是静默缩小到根目录——静默的空答案比说明原因的报错更糟糕。
每个文件的真实路径必须落在根目录内，因此树内指向外部的符号链接会解析到外部并被拒绝。这在 glob 遍历之前检查，因此根目录在外的模式永远不会遍历。
被拒绝的路径会像缺失文件一样出现在 Notes 中，并注明你使用的拼写。一个被拒绝的条目永远不会导致同时包含有效文件的调用失败。
无论根目录如何设置，服务器永远不会读取自己的凭据——~/.config/zai/api-key、~/.zcode/v2/config.json 和 /proc/self/environ——通过解析后的真实路径而非拼写进行比较。
GLM_MCP_ALLOW_ANY_PATH=1 会刻意且明确地关闭限制，与 GLM_MCP_ALLOW_ZCODE_KEY 的工作方式相同。它会扩大根目录；但不会重新打开那三个文件。
如果你跨多个项目读取文件，请在升级前在 MCP 注册中设置 GLM_MCP_ROOTS。 每个服务器都以其启动时所在的项目为根，因此在 0.2.0 之前，从一个项目询问另一个项目的文件会静默工作，之后会被拒绝。注册默认带有 env: {}，因此必须刻意添加：
"env": { "GLM_MCP_ROOTS": "/Users/you/project-a:/Users/you/project-b" }绝对路径同样受到限制，但这造成的破坏远没有听起来那么严重：对作者自己工具的调查发现，没有调用者会传递绝对路径。
files 接受字面路径和 glob 模式，可自由混合。匹配项会按文件身份在整个列表中进行排序和去重，因此重叠的模式永远不会发送同一个文件两次。
支持的语法： *、**、?、[a-z]、[!a-z]、{a,b} 以及 \ 转义。
. 和 .. 相对于 cwd 解析，因此 ./src/** 和 ../neighbour/src/** 有效。
磁盘上存在的路径即使名称包含元字符也会按字面读取——真实的 report[final].md 会被读取，而不是进行模式匹配。
隐藏（点）条目仅在模式明确写出点时才会匹配。
匹配不到任何内容的模式会像缺失文件一样在 Notes 中报告。
符号链接目录仅在模式明确指定时才会被跟随（linked/*.ts）。通配符永远不会跟随它们，指向目录的链接也永远不会被列为文件。
在 Windows 上，使用正斜杠：C:/src/**/*.ts 和 //server/share/src/*.ts 被视为绝对路径。\ 在所有平台上都是转义字符。
Glob 展开会跳过 node_modules、.git、dist、build、coverage、.next、.turbo、vendor 和 target，因此 **/*.ts 匹配的是你的源码，而不是 1,700 个依赖类型定义挤占预算。
这仅适用于展开——字面的 node_modules/foo/x.d.ts 会原样通过。在模式中明确指定目录也会覆盖跳过，因为调用者明确要求：node_modules/foo/**/*.d.ts 会按预期匹配。
将 GLM_MCP_GLOB_IGNORE 设置为逗号分隔的列表以替换默认集合（GLM_MCP_GLOB_IGNORE=dist,.venv）；空值则完全禁用跳过。
每个限制都会停止触发它的操作，并在 Notes 中说明，指出设置该限制的变量——任何内容都不会被静默截断或静默丢弃。
限制 | 变量 | 默认值 |
总上下文字符数（包括页眉和分隔符） |
| 800,000 |
单文件大小（在读取文件前检查） |
| 5 MB |
Glob 遍历深度 |
| 24 |
每次调用检查的目录条目数 |
| 200,000 |
Glob 展开的墙钟时间预算 |
| 10,000 |
总 |
| 1,024 |
请求超时 |
| 600,000 |
只读取常规文件。FIFO、设备或套接字会被拒绝，而不是让服务器阻塞在可能永远不会返回的读取上。
截断按码点进行，因此永远不会把一个 emoji 切成两半。
缺失、不可读和被拒绝的文件会被跳过并报告，绝不会致命：一个坏条目不会导致同时包含有效文件的调用失败。
z.ai 的编码错误会被转换为可操作的信息：1113（余额不足）、1210（需要推理）、3007（凭据类型错误——请参阅上面的“凭据”部分）。
请求发送到 https://api.z.ai/api/anthropic，除非 ZAI_BASE_URL 另有指定。你的密钥会发送到它所指定的任何主机，因此请仅将其指向你信任的端点。
npm test # unit tests: globs, key resolution, confinement, limits
npm run verify:ignore # acceptance gate: glob ignore semantics
npm run verify:globs # acceptance gate: glob path handling
npm run verify:confinement # acceptance gate: the path trust boundary
npm run verify:limits # acceptance gate: every resource limit actually fires
npm run smoke # drives the server over stdio as a real MCP client (needs a key)除 smoke 之外的所有测试都是封闭的，并在 Node 20、22 和 24 上的 CI 中运行。smoke 会进行实时 API 调用，因此需要手动运行。
每个验收门禁都是在它所门禁的变更之前编写的，并且针对它所编写的代码会失败，因此它断言行为而非描述行为。它们构建真实的夹具树——真实文件、真实符号链接、真实 FIFO、真实伪造的 $HOME——并在模块加载前必须设置好配置的子进程中运行。
通过 npm 可信发布从 CI 发布，并带有来源证明——没有长期有效的 npm 令牌。每个版本都会暂存，需要维护者使用 2FA 批准后才能安装，其来源证明将发布的 tarball 与此仓库及构建它的工作流绑定。
由 Jerold Billings 构建，创始人——No Compromise AI, LLC。
错误和问题：请提交 issue。安全问题：请使用
Send a prompt to a Z.ai GLM model (default GLM-5.3) and return its answer. GLM-5.3 is an independent frontier model with a million-token context window, so this is useful for a genuine second opinion from a different model, for cross-checking reasoning, and for analysing far more source material at once than fits in a normal context. Optionally pass file paths to include as context. Model and reasoning are the latency levers: thinking tokens are generated before the first character of the answer, and the thinking budget spans 2,048 at 'low' against 24,576 at 'max' — a twelve-fold spread. Route mechanical work (extract, summarise, reformat, classify) to glm-5.3-flash or glm-4.6 at 'low'; glm-4.6 alone can go further, to 'none' — glm-5.3-flash cannot run with reasoning off, so its 'none' is raised to 'low'. Keep GLM-5.3 at 'high' or 'max' for design review, cross-checking reasoning, and hunting a subtle bug. glm-4.6 and glm-4.7 accept reasoning 'none'; GLM-5.3 and glm-5.3-flash cannot, so 'low' is their shallowest setting.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Directory that relative file paths resolve against. Defaults to the server's cwd. | |
| files | No | Optional files to include as context: literal paths and/or glob patterns (e.g. "src/**/*.ts"). Each glob expands to its matching files, sorted and de-duplicated across the whole list; a pattern that matches nothing is reported in the response notes. A path that exists on disk is used literally even when it contains glob characters. Glob expansion skips node_modules, .git and build output by default; naming a directory in the pattern (node_modules/foo/**/*.d.ts) or setting GLM_MCP_GLOB_IGNORE overrides that. Relative paths — ./ and ../ prefixes included — resolve against 'cwd'. Every file arrives with cat -n style line numbers, so answers can cite path:line and mean it; a literal path may carry an inclusive line range ("src/auth/session.ts:40-120") to send just that region, numbered with the file's own line numbers rather than renumbered from 1. | |
| model | No | GLM model id. Defaults to glm-5.3 (the frontier flagship); glm-5.3-flash and glm-4.6 are the fast routes, and glm_models lists every id the account offers with a one-line role. | |
| prompt | Yes | The question or instruction to send to GLM. | |
| system | No | Optional system prompt. | |
| messages | No | The conversation so far: prior turns this call continues, in order, each {role, content}. `prompt` stays required and is sent as the FINAL user turn — do not repeat it inside messages. Roles are "user" and "assistant"; any other is refused here, before anything is sent, naming the value you sent. No ordering is imposed — replay a real transcript as it happened. With `files`, the file context rides the FIRST turn and is never repeated on the newest, so the thread keeps a stable prefix: a follow-up reads its context from cache instead of re-prefilling it. The history spends the same character budget as the files, so a long thread leaves less room for file context — the cut is reported in the notes. | |
| reasoning | No | Reasoning depth — the largest latency lever in this tool: thinking tokens are generated before the first character of the answer, and the budget runs 2,048 at 'low', 8,192 at 'high', 24,576 at 'max'. Use 'none' or 'low' for mechanical work — extract, summarise, reformat; use 'high' or 'max' to review a design, cross-check reasoning, or hunt a subtle bug. GLM-5.3 and glm-5.3-flash always reason: GLM-5.3 rejects 'none' outright, while glm-5.3-flash accepts it and silently reasons anyway, so 'none' is raised to 'low' for both. | |
| max_tokens | No | Max output tokens — a hard cap. The request never exceeds it; the thinking budget scales down to fit beneath it, always leaving room for the answer, but never below the API minimum of 1024. A cap below 2048 — the API's budget minimum plus the least room that still constitutes an answer — cannot hold both and is refused rather than silently raised; on GLM-5.3 and glm-5.3-flash, which always reason, the only fix is a higher cap. A cap over the model's published ceiling is likewise refused before anything is sent (131,072 for GLM-5.3). Omit it and the model's own default applies (65,536 for GLM-5.3). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior, and it is exceptionally thorough. It explains thinking-token generation before the answer, reasoning budget ranges, model-specific constraints ('glm-5.3-flash cannot run with reasoning off, so its none is raised to low'), file context placement on the first turn, history consuming character budget, and max_tokens cap behavior including refusals. This is far beyond a basic safety profile.
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 long but information-dense; every sentence carries either a use-case, a latency lever, or a routing rule. It is front-loaded with the core action and value proposition before diving into details. Some redundancy with the schema's reasoning and model descriptions exists, but for a tool this complex the length is justified.
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 covers operational nuances such as file globbing behavior, line numbers, message ordering, reasoning constraints, and max_tokens caps. It mentions response notes for unmatched globs and history cuts, which implies a structured return. It does not fully spell out the output format, but for a chat-completion tool 'return its answer' plus the notes mention is reasonably complete given the lack of an output schema.
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% and each parameter already has rich documentation, so the baseline is 3. The tool description adds high-level guidance about model/reasoning selection, but it mostly reinforces what is already in the parameter schemas rather than introducing new parameter-level meaning. The schema descriptions alone are sufficient for parameter understanding.
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 opens with a specific verb and resource: 'Send a prompt to a Z.ai GLM model (default GLM-5.3) and return its answer.' It clearly explains the tool's function and even suggests use cases. However, it does not explicitly differentiate from the sibling tools glm_review and glm_models, relying on the tool name and general context to separate them.
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 gives clear context for when to use the tool: 'for a genuine second opinion from a different model, for cross-checking reasoning, and for analysing far more source material at once than fits in a normal context.' It also provides detailed routing advice among models and reasoning levels, e.g., 'Route mechanical work (extract, summarise, reformat, classify) to glm-5.3-flash or glm-4.6 at low.' It does not explicitly say when to use glm_review or glm_models instead, so no true alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the GLM model ids available on the configured Z.ai account, each with a one-line role; an id this server's model table does not know is listed bare.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses useful behavior: each model id is annotated with a one-line role, and unknown ids are rendered bare. It does not mention authentication or rate limits, but for a simple read-only enumeration this is not a significant gap.
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 sentence that front-loads the action and includes only essential details about the output format and the special handling of unknown ids. Every clause adds value with no redundancy.
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?
For a zero-parameter list tool with no output schema, this description is complete: it tells the agent what will be returned, how roles appear, and how unknown ids are presented. Nothing critical is missing for invoking and interpreting the tool.
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?
The tool has zero parameters and an empty input schema, so there is nothing for the description to clarify. The baseline of 4 applies because the schema already fully covers parameter semantics.
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?
States a specific verb and resource: lists GLM model ids from the configured Z.ai account. It also adds useful output semantics (one-line role, unknown ids listed bare), which makes it clearly distinct from sibling tools glm_ask and glm_review.
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 makes the context clear: use this tool when you need to enumerate available model ids. It does not explicitly name alternatives or when-not-to-use, but the sibling tool names and the list-oriented wording make the intended usage obvious enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Review a change with a Z.ai GLM model (default GLM-5.3) and return a VERDICT: the reply is the reviewer's analysis and always ends with a final line that is exactly VERDICT: PASS or VERDICT: CHANGES_REQUIRED — the same vocabulary bin/glm-review reads, so a shell pipeline can consume the result. Pass the change as a unified diff and the requirement it was meant to implement as spec: review against intent is what catches silent scope-narrowing, and the reviewer is warned off both recorded pathologies — findings that are padded or fabricated, and work that is stubbed, mocked or hardcoded rather than implemented. A reply that is a bare verdict with no analysis behind it comes back as an error, never as a clean review. This server never runs git and inspects no repository state on its own: the diff comes from the caller, and files resolve exactly as glm_ask resolves them. Reviews default to reasoning 'high' — the depth the glm_ask routing guidance reserves for review and bug-hunting — and a different model than the one that wrote the code is worth choosing where you can, because a model re-reading its own work reliably under-reports.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Directory that relative file paths resolve against. Defaults to the server's cwd. | |
| diff | No | The unified diff to review, as your tooling produced it. The server never runs git — the caller supplies the change under review, and this argument is how. Either diff or files must be present; with neither, the call is refused rather than answered with a verdict about nothing. | |
| spec | No | What the change was meant to do — the requirement, ticket or plan it was written against. Reaches the reviewer verbatim. Review against intent is the only check on silent scope-narrowing, this loop's recorded failure mode; with no spec the reviewer can only infer intent from the diff itself. | |
| files | No | Optional files as review context, resolved exactly as glm_ask resolves them (same confinement to the operator's roots, same per-model character budget, same notes): literal paths and/or glob patterns (e.g. "src/**/*.ts"). Each glob expands to its matching files, sorted and de-duplicated across the whole list; a pattern that matches nothing is reported in the response notes. A path that exists on disk is used literally even when it contains glob characters. Glob expansion skips node_modules, .git and build output by default; naming a directory in the pattern (node_modules/foo/**/*.d.ts) or setting GLM_MCP_GLOB_IGNORE overrides that. Relative paths — ./ and ../ prefixes included — resolve against 'cwd'. | |
| model | No | GLM model id. Defaults to glm-5.3 (the frontier flagship); glm-5.3-flash and glm-4.6 are the fast routes, and glm_models lists every id the account offers with a one-line role. | |
| reasoning | No | Reasoning depth — same levels as glm_ask, but the default here is 'high' rather than 'low': a review is the work the routing guidance reserves 'high' for, and a reviewer skimming on the 2,048-token 'low' budget is the rubber stamp with extra steps. Use 'max' (24,576 tokens) for a large or subtle change, and 'low' only for a re-check you expect to be mechanical. GLM-5.3 and glm-5.3-flash always reason, so 'low' is their shallowest setting. | |
| max_tokens | No | Max output tokens — a hard cap. The request never exceeds it; the thinking budget scales down to fit beneath it, always leaving room for the answer, but never below the API minimum of 1024. A cap below 2048 — the API's budget minimum plus the least room that still constitutes an answer — cannot hold both and is refused rather than silently raised; on GLM-5.3 and glm-5.3-flash, which always reason, the only fix is a higher cap. A cap over the model's published ceiling is likewise refused before anything is sent (131,072 for GLM-5.3). Omit it and the model's own default applies (65,536 for GLM-5.3). A review severed by too small a cap loses its verdict line and is returned as an error, so size it for the analysis plus the verdict. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With zero annotations, the description carries the full burden and discharges it thoroughly: it discloses the exact verdict line grammar, that a bare verdict is returned as an error, that the server never runs git and inspects no repository state, that calls with neither diff nor files are refused, and that the reviewer is explicitly warned against padded/fabricated findings and stubbed/mocked/hardcoded work. This is rich behavioral disclosure well beyond what any structured field provides.
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 long but front-loaded with the most critical fact — the exact VERDICT contract — before any parameter framing. Every sentence carries real content, from refusal behavior to the reasoning-depth default to the model-advice caveat. It is dense prose rather than concise prose, and a few points repeat what the schema already says, but nothing is filler.
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?
For a 7-parameter tool with no annotations and no output schema, this description is nearly complete: it specifies the return contract, error/refusal conditions, default model and reasoning level, cross-tool file-resolution semantics, and both recorded failure modes the reviewer is guarded against. The only deferrals are reasonable ones — glob-ignore overrides and character budgets live in the files parameter schema, and depth beyond routing is delegated to glm_ask's guidance.
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 coverage is 100% and the schema's own parameter descriptions are already unusually detailed, so the baseline is 3. The description adds genuine value on top: the rationale for the diff+spec pairing ('review against intent is what catches silent scope-narrowing') and the model-selection heuristic that a model re-reading its own work under-reports, which appears in no schema field. Some default and reasoning-guidance content is duplicated between description and schema, keeping this at 4 rather than 5.
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 states a specific verb and resource — 'Review a change with a Z.ai GLM model' — and defines a concrete, distinctive output contract: a reply ending in exactly 'VERDICT: PASS' or 'VERDICT: CHANGES_REQUIRED'. This clearly distinguishes it from siblings glm_ask (asking) and glm_models (listing models) through the review-specific verdict vocabulary and the diff+spec input pairing.
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 places glm_review within the glm_ask routing guidance ('the depth the glm_ask routing guidance reserves for review and bug-hunting') and gives actionable advice — supply a diff against spec rather than just a diff, and choose a different model than the one that wrote the code. However, it never explicitly states when to prefer glm_review over glm_ask or vice versa; that routing is inferred from the sibling names and the verdict contract rather than stated outright.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
glm_ask and glm_review both send prompts to GLM, which could cause some overlap, but glm_review's strict VERDICT format and diff/spec input make its purpose clearly distinct. glm_models is wholly separate.
glm_ask and glm_review follow a consistent verb-first pattern, while glm_models breaks it by using a noun instead of a verb like list_models. Minor deviation, but the prefix keeps the family recognizable.
Three tools is within the ideal 3-15 range and each tool earns its place: one for general prompting, one for structured review, and one for model discovery. The scope is tightly focused.
For a GLM-oriented server, the surface covers the core needs: asking questions, reviewing changes against a spec, and listing available models. No obvious dead ends or missing operations within the stated purpose.
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.
Agent personas for Claude. 16 tools, 13 personas, 3 workflows. Zero extra API cost. Free.
Connect Claude to Fathom meeting recordings, transcripts, and summaries
Talk to your public-facing AI from any MCP client — Claude, ChatGPT, Cursor, Cline, Windsurf.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/No-Compromise-AI/glm-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
