Z.ai の GLM モデル（GLM-5.3 およびその兄弟モデル）を Claude Code と Claude Desktop 内のツールとして公開する MCP サーバーです。
Claude Desktop は独自のモデルプロバイダーを固定しています。組み込みの Claude Code を起動するとき、ANTHROPIC_BASE_URL を Anthropic のエンドポイントに強制し、子環境から ANTHROPIC_API_KEY / ANTHROPIC_AUTH_TOKEN を削除します。そのため、GLM はデスクトップセッションを駆動できません。このサーバーは別のルートを取ります。GLM は Claude が会話の途中で呼び出せるツールになります。
役立つ場面:
本当のセカンドオピニオン。 独立したフロンティアモデルであり、同じモデルに二回尋ねるのではありません。
非常に大きなコンテキスト。 GLM-5.3 は 1,000,000 トークンのウィンドウを持つため、通常のセッションに収まらないはるかに多くのソースマテリアルを渡すことができます。
安価な大量作業。 雑務を 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 アプリに CAPTCHA でロックされており、外部クライアントは 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"
}応答には、モデル、トークン使用量、推論量を示すフッターが含まれます:
The refresh path in session.ts:88 reads `expiresAt` before taking the lock ...
[glm-5.3 · in 4210 / out 380 tok · reasoned 2170 chars]本当に得意な2つのこと:
異なるセカンドオピニオン。 Claude と GLM に同じ質問をして比較します。2つのモデルが異なる意見を出すのは本当のシグナルです。同じモデルに二回尋ねても、ほとんど意味がありません。
収まらないほどのソース。 1M トークンのウィンドウがあれば、少数のファイルを厳選する代わりに src/**/*.ts を丸ごと渡せます。
glm_ask引数 | 型 | デフォルト | 備考 |
| string | — | 必須 |
| string[] | — | コンテキストとして含めるファイル: リテラルパスおよび/またはグロブ ( |
| string | server 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 はプロジェクトごとに1つのサーバーを起動するため、各サーバーは自身のプロジェクトに制限され、ほとんどのセットアップでは設定は一切不要です。
cwd はルート内に解決される必要があります。そうでない場合、呼び出しは静かにルートに絞り込まれるのではなく、完全に拒否されます。静かに空の回答を返すよりも、理由を説明するエラーの方がましです。
各ファイルの実際のパスはルート内に収まる必要があります。そのため、ツリー内のシンボリックリンクが外を指している場合、それは外に解決され拒否されます。これはグロブが走る前にチェックされるため、外にルートを持つパターンがトラバースすることはありません。
拒否されたパスは、欠落ファイルとまったく同じように Notes に表示され、使用したスペルが示されます。拒否されたエントリが1つあっても、良いファイルも指定している呼び出しが失敗することはありません。
ルートが何と言おうと、サーバーは自身の認証情報を読み取ることはありません。~/.config/zai/api-key、~/.zcode/v2/config.json、/proc/self/environ は、スペルではなく解決された実際のパスで比較されます。
GLM_MCP_ALLOW_ANY_PATH=1 は、GLM_MCP_ALLOW_ZCODE_KEY と同じように、意図的かつ明示的に制限をオフにします。ルートを広げますが、その3つのファイルを再び開くことはありません。
複数のプロジェクトにまたがってファイルを読む場合は、アップグレード前に MCP 登録で GLM_MCP_ROOTS を設定してください。 各サーバーは起動されたプロジェクトにルートがあるため、あるプロジェクトから別のプロジェクトのファイルについて尋ねることは 0.2.0 以前は静かに機能していましたが、それ以降は拒否されます。登録には env: {} が含まれているため、これは意図的に追加する必要があります:
"env": { "GLM_MCP_ROOTS": "/Users/you/project-a:/Users/you/project-b" }絶対パスも制限されますが、それは聞こえるほど壊れることはありません。この作者自身のツールの調査では、それらを渡す呼び出し元は見つかりませんでした。
files はリテラルパスとグロブパターンを自由に混在して受け入れます。マッチはリスト全体でファイル ID によってソートされ重複排除されるため、重複するパターンが同じファイルを二度送ることはありません。
サポートされる構文: *、**、?、[a-z]、[!a-z]、{a,b}、および \ エスケープ。
. と .. は cwd に対して解決されるため、./src/** や ../neighbour/src/** が機能します。
ディスク上に存在するパスは、名前にメタ文字が含まれていてもリテラルに読み取られます。実際の report[final].md はパターンマッチではなく読み取られます。
隠し（ドット）エントリは、パターンがドットを明示的に指定した場合のみマッチします。
何もマッチしないパターンは、欠落ファイルとまったく同じように Notes に報告されます。
シンボリックリンクされたディレクトリは、パターンが明示的に名前を指定した場合のみ追跡されます（linked/*.ts）。ワイルドカードはそれらを追跡せず、ディレクトリへのリンクがファイルとしてリストされることはありません。
Windows ではフォワードスラッシュを使用してください: C:/src/**/*.ts と //server/share/src/*.ts は絶対パスとして扱われます。\ はすべてのプラットフォームでエスケープ文字です。
グロブ展開は 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 |
グロブ走査の深さ |
| 24 |
呼び出しごとに検査されるディレクトリエントリ数 |
| 200,000 |
グロブ展開のウォールクロック予算 |
| 10,000 |
合計 |
| 1,024 |
リクエストタイムアウト |
| 600,000 |
通常のファイルのみが読み取られます。FIFO、デバイス、ソケットは、戻らない可能性のある読み取りでサーバーをブロックする代わりに拒否されます。
切り詰めはコードポイントで行われるため、絵文字を半分に分割することはありません。
欠落、読み取り不能、拒否されたファイルはスキップされ報告されますが、致命的ではありません。1つの不良エントリがあっても、良いファイルも指定している呼び出しが失敗することはありません。
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 の信頼できる公開を介して provenance 付きで CI から公開されます。長期間有効な npm トークンはありません。すべてのリリースはステージングされ、インストール可能になる前にメンテナーが 2FA で承認する必要があります。また、その provenance は公開された tarball をこのリポジトリとそれを構築したワークフローに結び付けます。
Jerold Billings（創業者）によって構築されました — No Compromise AI, LLC。
バグや質問: イシューを開いてください。セキュリティ問題: 使用してください
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
