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가 대화 중에 호출할 수 있는 도구가 됩니다.
유용한 경우:
진짜 제2의 의견. 같은 모델을 두 번 묻는 것이 아니라 독립적인 프론티어 모델.
매우 큰 컨텍스트. 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 앱에 캡차로 잠겨 있어 외부 클라이언트를 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에게 같은 질문을 하고 비교하세요. 두 모델이 의견이 다르면 실제 신호입니다. 같은 모델을 두 번 묻는 것은 대부분 그렇지 않습니다.
맞지 않는 더 많은 소스. 1M 토큰 창을 사용하면 몇 개의 파일을 선별하는 대신 src/**/*.ts 전체를 전달할 수 있습니다.
glm_askarg | type | default | notes |
| string | — | 필수 |
| string[] | — | 컨텍스트로 포함할 파일: 리터럴 경로 및/또는 글로브 ( |
| 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 토큰 |
| 8,192 토큰 |
| 24,576 토큰 |
max_tokens는 예산 위에 답변을 위한 공간을 남기기 위해 자동으로 상향됩니다.
glm_ask는 운영자가 설정한 루트 내에서만 읽습니다. 호출자는 그 안에서 좁힐 수 있지만, 선택하거나 벗어날 수는 없습니다.
루트는 GLM_MCP_ROOTS에서 가져오며, 콜론으로 구분된 절대 경로입니다.
설정되지 않으면 루트는 서버가 시작된 디렉터리입니다. Claude는 프로젝트당 하나의 서버를 시작하므로 각 서버는 자체 프로젝트로 제한되며 대부분의 설정은 전혀 필요하지 않습니다.
cwd는 루트 내에서 해석되어야 합니다. 그렇지 않으면 호출이 조용히 루트로 좁혀지지 않고 완전히 거부됩니다. 조용히 빈 답변을 주는 것은 이유를 설명하는 오류보다 나쁩니다.
모든 파일의 실제 경로는 루트 안에 있어야 합니다. 따라서 트리 내부의 심볼릭 링크가 외부를 가리키면 외부로 해석되어 거부됩니다. 이는 글로브가 탐색하기 전에 확인되므로 외부에 루트를 둔 패턴은 절대 탐색하지 않습니다.
거부된 경로는 누락된 파일과 마찬가지로 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는 리터럴 경로와 글로브 패턴을 자유롭게 혼합하여 허용합니다. 일치 항목은 전체 목록에서 파일 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, 디바이스 또는 소켓은 서버가 반환되지 않을 수 있는 읽기로 차단하는 대신 거부됩니다.
잘림은 코드 포인트에서 발생하므로 이모지를 반으로 나누지 않습니다.
누락, 읽을 수 없음, 거부된 파일은 건너뛰고 보고되며 치명적이지 않습니다. 잘못된 항목 하나가 좋은 파일도 포함하는 호출을 실패시키지 않습니다.
z.ai의 코드화된 오류는 실행 가능한 것으로 변환됩니다: 1113(잔액 없음), 1210(추론 필요), 3007(잘못된 자격 증명 유형 — 위의 Credentials 참조).
요청은 ZAI_BASE_URL이 다른 것을 지정하지 않는 한 https://api.z.ai/api/anthropic으로 전송됩니다. 키는 이름이 지정된 호스트로 전송되므로 신뢰하는 엔드포인트에만 지정하세요.
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로 승인해야 합니다. 그리고 그 출처는 게시된 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
