GLM-4.7 MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ZAI_API_KEY | Yes | Your Z.ai API key for accessing GLM-4.7 model |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| glm_askA | Quick question to GLM - no tools, fast response. Use for: explanations, analysis, brainstorming, quick answers. Does NOT have access to files or tools - pure generation. Cost: ~10x cheaper than Claude Haiku. Use liberally. Args: question: Your question or prompt model: "haiku" (fastest) or "sonnet" (better quality) Returns: GLM's response |
| glm_summarizeA | Summarize text using GLM. Use for: document summaries, meeting notes, code explanations. Args: text: The text to summarize style: "concise", "detailed", "bullet-points", "executive" model: "haiku" or "sonnet" Returns: Summarized text |
| glm_explainA | Explain code or a concept using GLM. Use for: understanding code, learning concepts, documentation. Args: code_or_concept: Code snippet or concept to explain context: Additional context (e.g., language, framework) model: "haiku" or "sonnet" Returns: Explanation |
| glm_analyzeA | Analyze codebase using GLM with read access. Use for: understanding code structure, finding patterns, architecture analysis, dependency mapping. Has READ-ONLY access: Read, Glob, Grep, LS, Bash (safe commands). Args: task: Analysis task to perform working_directory: Project directory (defaults to current) model: "haiku" or "sonnet" Returns: Analysis results |
| glm_reviewA | Code review by GLM agent. Use for: security review, performance analysis, best practices. Args: code_or_file: Inline code or file path to review review_focus: "general", "security", "performance", "style", "bugs" working_directory: Directory context for file paths model: "haiku" or "sonnet" Returns: Code review with findings and suggestions |
| glm_find_bugsA | Find potential bugs in code using GLM. Use for: bug detection, edge case analysis, error prone patterns. Args: code_or_file: Inline code or file path to analyze working_directory: Directory context for file paths model: "haiku" or "sonnet" Returns: List of potential bugs with explanations |
| glm_implementA | GLM agent with write access for implementation tasks. Use for: writing code, creating files, making changes, refactoring. Has FULL access including Write and Edit. WARNING: This can modify files. Args: task: Implementation task to perform working_directory: Project directory (REQUIRED) allowed_tools: Tools to allow (default: full coding set) model: "haiku" or "sonnet" Returns: Agent's output including changes made |
| glm_refactorA | Refactor code using GLM. Use for: improving code structure, applying patterns, cleanup. Args: file_path: Path to file to refactor instructions: Refactoring instructions working_directory: Project directory model: "haiku" or "sonnet" Returns: Refactored code and explanation |
| glm_write_testsA | Generate unit tests for a file using GLM. Use for: test generation, coverage improvement, TDD support. Args: file_path: Path to file to test test_framework: "pytest", "jest", "vitest", "unittest" working_directory: Project directory model: "haiku" or "sonnet" Returns: Generated test file |
| glm_documentA | Add or update documentation for a file using GLM. Use for: adding docstrings, generating README, documenting APIs. Args: file_path: Path to file to document style: "google", "sphinx", "numpy", "javadoc" working_directory: Project directory model: "haiku" or "sonnet" Returns: File with added documentation |
| glm_generate_readmeA | Generate a README.md for a project using GLM. Use for: creating project documentation, onboarding. Args: working_directory: Project directory style: "standard", "comprehensive", "minimal" model: "haiku" or "sonnet" Returns: Generated README.md content |
| glm_statusA | Check GLM MCP server status and configuration. Returns: Status information about the GLM server setup |
| glm_compare_costsA | Compare costs between Claude and GLM. Args: tokens_input: Input tokens to compare tokens_output: Output tokens to compare Returns: Cost comparison table |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 13 tools
Most tools have clearly distinct roles (e.g., summarize vs. explain vs. implement), but a few pairs are close: glm_review and glm_find_bugs both analyze code, and glm_explain could be seen as a specialized glm_ask. Overall, the boundaries are clear enough that an agent will usually pick the right tool, with only minor potential for confusion.
All tools share the 'glm_' prefix and use snake_case, and most follow a verb or verb_noun pattern (e.g., glm_summarize, glm_implement, glm_write_tests). The one notable deviation is glm_status, which uses a noun instead of an action, slightly breaking the pattern. Otherwise, the naming is consistent and readable.
With 13 tools, the set is well-scoped for a GLM-powered coding assistant. Each tool serves a distinct function—question answering, summarization, explanation, analysis, review, bug finding, implementation, refactoring, test generation, documentation, README generation, status checking, and cost comparison—and none feel redundant.
The tool surface covers the full development lifecycle: from asking questions and explaining concepts to analyzing, implementing, refactoring, testing, and documenting code. Minor gaps include a dedicated 'fix' tool (though implement/refactor can handle it) and a generic conversation tool (though glm_ask covers it). No critical workflows are missing.