What can you do with this server?

Run Zhipu GLM chat completions and explore available GLM models via the AceDataCloud API. * Generate chat completions (glm_chat_completions): send a required messages array of role/content dicts to any supported GLM model and get the response back as JSON. * Choose among 8 models: glm-5.3, glm-5.2 (default), glm-5, glm-5-turbo, glm-5.1, glm-4.7, glm-4.6, glm-3-turbo — useful for Chinese language tasks and reasoning. * Tune sampling and output: temperature, top_p, top_logprobs, logprobs, n, seed, stop, max_tokens/max_completion_tokens, presence/frequency penalty, logit_bias, response_format, stream + stream_options, modalities/audio, prediction, service_tier, reasoning_effort. * Tool use: pass tools, tool_choice, and parallel_tool_calls for function calling; web_search_options for search-backed answers. * Metadata/context: user identifier, store, and free-form metadata. * List models (glm_list_models): discover the GLM models exposed by AceDataCloud with descriptions. * Read the usage guide (glm_get_usage_guide): inline parameters, examples, and best practices. * Connect flexibly: hosted OAuth, hosted API token (Bearer header), or local stdio (pip install mcp-glm with ACEDATACLOUD_API_TOKEN).

How do I use io.github.AceDataCloud/mcp-glm?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@io.github.AceDataCloud/mcp-glm write a short poem about AI" 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.

io.github.AceDataCloud/mcp-glm

Official

by AceDataCloud

Overview Schema Source Related Servers Discussions Admin

Python

Remote

MCP GLM Server

A Model Context Protocol (MCP) server for Zhipu GLM chat completions via the AceDataCloud platform.

Features

GLM chat completions: Call Zhipu GLM models through a uniform MCP tool
Model discovery: List the GLM models exposed by AceDataCloud
Usage guide: Inline tool returning the API usage guide

Related MCP server: AiChat MCP Server

Connect: hosted OAuth, API token, or local stdio

The hosted endpoint is https://glm.mcp.acedata.cloud/mcp. Choose one route for the MCP client:

Route	When to use it	Credential setup
Hosted OAuth	The client supports remote MCP OAuth	Add only the URL, then sign in to AceDataCloud and approve access. No token needs to be pasted into client configuration.
Hosted API token	The client cannot finish OAuth, or you need an explicit integration credential	Send an AceDataCloud API token in the `Authorization: Bearer …` header. Keep it in a local secret store or environment variable.
Local stdio	The client runs a local MCP process	Install `mcp-glm` and pass `ACEDATACLOUD_API_TOKEN` to that process. It still calls the AceDataCloud API.

The hosted service advertises OAuth metadata and Dynamic Client Registration (DCR). DCR registers the client application; it is not an API key. OAuth signs you in and the client sends the resulting Bearer token; it may reuse or create an API credential for the account. Browser sign-in still requires an AceDataCloud account. The hosted service can be metered: review current service documentation and displayed pricing before a real operation. Do not configure both an OAuth login and a fixed Authorization header for the same server.

Hosted OAuth examples

Claude and Claude Desktop chat: Add a remote custom connector in Customize → Connectors → Add custom connector, enter https://glm.mcp.acedata.cloud/mcp, select sign-in, and choose Register automatically if Claude asks how to register its OAuth client. Complete consent. Claude Desktop's local claude_desktop_config.json is a separate setup. Claude connector guide.
Claude Code: claude mcp add --transport http --scope user glm https://glm.mcp.acedata.cloud/mcp, then claude mcp login glm. Check /mcp. Claude Code MCP guide.
Cursor: Add a remote server with only https://glm.mcp.acedata.cloud/mcp. For a project, merge the entry below into <project>/.cursor/mcp.json; for personal use, use ~/.cursor/mcp.json. Cursor MCP guide.
VS Code / Copilot: Run MCP: Add Server, select HTTP, enter https://glm.mcp.acedata.cloud/mcp, then finish the browser sign-in. New portable workspace configs use <project>/.mcp.json; the VS Code-specific format below uses <project>/.vscode/mcp.json or the user profile. Check MCP: List Servers. VS Code MCP setup.
Codex: codex mcp add glm --url https://glm.mcp.acedata.cloud/mcp, then codex mcp login glm. Its user settings are in ~/.codex/config.toml. Official Codex MCP guide.

Cursor project config (OAuth):

{
  "mcpServers": {
    "glm": {"url": "https://glm.mcp.acedata.cloud/mcp"}
  }
}

VS Code-specific workspace config (OAuth):

{
  "servers": {
    "glm": {"type": "http", "url": "https://glm.mcp.acedata.cloud/mcp"}
  }
}

Hosted API token

Sign in at AceDataCloud Platform, open the service page, and obtain an API credential. A fixed Bearer header is useful when your client lacks OAuth; an invalid header does not fall back to OAuth in Claude Code. The header value is sensitive, so keep it out of committed files and screenshots.

For Claude Code, the shell expands the token when you add the server; treat the saved user MCP config as a secret:

export ACEDATACLOUD_API_TOKEN='YOUR_API_TOKEN'
claude mcp add --transport http --scope user glm https://glm.mcp.acedata.cloud/mcp \
  --header "Authorization: Bearer $ACEDATACLOUD_API_TOKEN"

For a Claude Code project config, put a variable reference in <project>/.mcp.json and set that variable in the environment that launches Claude Code:

{
  "mcpServers": {
    "glm": {
      "type": "http",
      "url": "https://glm.mcp.acedata.cloud/mcp",
      "headers": {"Authorization": "Bearer ${ACEDATACLOUD_API_TOKEN}"}
    }
  }
}

Cursor uses a different environment-variable syntax in ~/.cursor/mcp.json or an uncommitted project config:

{
  "mcpServers": {
    "glm": {
      "url": "https://glm.mcp.acedata.cloud/mcp",
      "headers": {"Authorization": "Bearer ${env:ACEDATACLOUD_API_TOKEN}"}
    }
  }
}

In VS Code, run MCP: Open User Configuration and merge this server plus its masked input; ${input:...} is for VS Code's user/workspace format and is not portable to the Agent Host .mcp.json format:

{
  "inputs": [
    {"id": "acedata-glm-token", "type": "promptString", "description": "AceDataCloud API token", "password": true}
  ],
  "servers": {
    "glm": {
      "type": "http",
      "url": "https://glm.mcp.acedata.cloud/mcp",
      "headers": {"Authorization": "Bearer ${input:acedata-glm-token}"}
    }
  }
}

For Cline, use its MCP configuration UI or CLI file ~/.cline/data/settings/cline_mcp_settings.json; its remote transport value is streamableHttp. For JetBrains AI Assistant, add a remote URL from Settings → Tools → AI Assistant → Model Context Protocol (MCP). For Zed, use a context_servers entry with the URL only for OAuth or add a local Bearer header. These clients have different configuration schemas; follow their current UI rather than copying another client's JSON. Cline · JetBrains · Zed.

Local stdio

Install the package and give the local process an API token:

python -m pip install mcp-glm
export ACEDATACLOUD_API_TOKEN='YOUR_API_TOKEN'
mcp-glm

For Claude Desktop local MCP, merge this entry into the file opened by its developer settings (~/Library/Application Support/Claude/claude_desktop_config.json on macOS). uvx requires uv on PATH:

{
  "mcpServers": {
    "glm": {
      "command": "uvx",
      "args": ["mcp-glm"],
      "env": {"ACEDATACLOUD_API_TOKEN": "YOUR_API_TOKEN"}
    }
  }
}

Keep this user-level file private. Self-hosted HTTP uses mcp-glm --transport http --port 8000; expose it only with suitable network and TLS controls. Local execution still calls the AceDataCloud API.

Check before using the service

https://glm.mcp.acedata.cloud/health returning {"status":"ok"} checks endpoint reachability only.
Confirm that the MCP client loads tools. glm_list_models is a reference tool; it does not verify downstream API access or balance.
If you need a full API check, call glm_chat_completions with your own valid input after reviewing current service documentation and displayed pricing.

For 401, check which auth route the client used and whether the token or OAuth session is valid. A 403 may mean an account permission or content moderation failure; read the returned error. Insufficient balance and downstream service failures need their own diagnosis. A listed tool or submitted task does not prove a successful result.

Available Tools

Tool	Description
`glm_chat_completions`	Run a GLM chat completion call
`glm_list_models`	List available GLM models
`glm_get_usage_guide`	Get the API usage guide

Documentation

License

MIT — see LICENSE.

Available Tools

3 tools

glm_chat_completionsAInspect

Create a GLM chat completion using the AceDataCloud GLM API.

Sends messages to the specified GLM model and returns the generated response.
Supports all GLM models: glm-5.3, glm-5.2, glm-5, glm-5-turbo, glm-5.1, glm-4.7, glm-4.6, glm-3-turbo.

Use this when:
- You need to chat with a Zhipu GLM model
- You need Chinese language understanding or generation
- You want to use GLM's reasoning capabilities

Returns:
    JSON response containing the chat completion result.

ParametersJSON Schema

Name	Required	Description	Default
`n`	No	How many chat completion choices to generate. Default 1.
`seed`	No	Random seed for deterministic sampling.
`stop`	No	Stop sequences where the API will stop generating tokens.
`user`	No	End-user identifier for abuse monitoring.
`audio`	No	Parameters for audio output.
`model`	No	The GLM model to use. Options: glm-5.3, glm-5.2, glm-5, glm-5-turbo, glm-5.1, glm-4.7, glm-4.6, glm-3-turbo. Default is glm-5.2.	glm-5.2
`store`	No	Whether to store the output of this request. Default False.
`tools`	No	List of tools the model may call.
`top_p`	No	Nucleus sampling probability mass. Default 1.
`stream`	No	Whether to stream partial message deltas. Default False.
`logprobs`	No	Whether to return log probabilities of output tokens. Default False.
`messages`	Yes	Conversation messages. Each message is a dict with 'role' and 'content' keys. Required.
`metadata`	No	Key-value pairs for storing additional information.
`logit_bias`	No	Modify the likelihood of specified tokens appearing in the completion.
`max_tokens`	No	Maximum number of tokens to generate.
`modalities`	No	Output types to generate (e.g. ['text', 'audio']).
`prediction`	No	Static predicted output content for latency reduction.
`temperature`	No	Sampling temperature between 0 and 2. Higher = more random. Default 1.
`tool_choice`	No	Controls which tool is called. Can be 'none', 'auto', or a dict.
`service_tier`	No	Service tier: auto, default, flex, scale, priority. Default auto.
`top_logprobs`	No	Number of most likely tokens to return at each token position.
`stream_options`	No	Options for streaming response.
`response_format`	No	Response format specification (e.g. {"type": "json_object"}).
`presence_penalty`	No	Presence penalty between -2.0 and 2.0. Positive values increase topic variety. Default 0.
`reasoning_effort`	No	Reasoning effort level: minimal, low, medium, high. Default medium.
`frequency_penalty`	No	Frequency penalty between -2.0 and 2.0. Positive values decrease repetition. Default 0.
`web_search_options`	No	Options for web search tool.
`parallel_tool_calls`	No	Enable parallel function calling. Default True.
`max_completion_tokens`	No	Upper bound for tokens that can be generated for a completion.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the behavioral disclosure burden. It states that messages are sent to the model and a JSON response is returned, which covers the basic operation. However, it omits details like authentication needs, rate limits, streaming behavior, or error semantics, leaving gaps for a 29-parameter API.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well organized with a purpose statement, use-case bullets, and a returns section. However, some content is redundant: the opening sentence and second sentence overlap, the model list repeats the schema enum, and the first 'Use this when' bullet restates the core purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the large parameter count, the schema fully documents parameters and an output schema exists, so the description does not need to explain return values in depth. It provides purpose, model scope, and usage scenarios. It could be more complete on operational constraints, but it covers the main decisions an agent needs to make.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter already has documentation. The description adds the model list, but that duplicates the model enum in the schema. It does not meaningfully enrich parameter understanding beyond what the schema already provides, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

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: 'Create a GLM chat completion using the AceDataCloud GLM API.' It then explains the core action (sending messages and returning generated responses) and clearly separates this tool from siblings like glm_list_models and glm_get_usage_guide.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'Use this when' section gives concrete triggers: chatting with Zhipu GLM, Chinese language tasks, and reasoning capabilities. It does not explicitly name sibling alternatives or exclusion criteria, but the context is clear enough to guide selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

glm_get_usage_guideAInspect

Get a comprehensive guide for using the GLM tools.

Provides detailed information on how to use the GLM tools effectively,
including parameters, examples, and best practices.

Returns:
    Complete usage guide for GLM tools.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the burden of behavioral disclosure. It states 'Returns: Complete usage guide for GLM tools,' which indicates the output, but it does not mention side effects, authentication requirements, or whether the guide is static or dynamically generated. This is minimally adequate for a read-only documentation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is somewhat repetitive: the first sentence says 'Get a comprehensive guide,' the second says 'Provides detailed information,' and the third repeats 'Complete usage guide.' It is front-loaded and short, but the redundancy means not every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter tool with an output schema, the description is sufficiently complete. It states the purpose and the return value. It could add guidance on when to call it relative to other GLM tools, but this is not essential given the tool's simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the baseline is 4. The description mentions 'parameters' as part of the guide's content, but this is not a parameter-semantics issue for the tool itself. No further explanation is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb+resource: 'Get a comprehensive guide for using the GLM tools,' and further details the content ('parameters, examples, and best practices'). This clearly distinguishes it from siblings like glm_list_models and glm_chat_completions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description makes the tool's purpose evident: it is for obtaining a guide to using GLM tools effectively. However, it does not explicitly state when not to use it or mention alternatives, though the sibling tools are clearly different in function.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

glm_list_modelsAInspect

List all available GLM models for the GLM API.

Returns a list of supported GLM models with descriptions.

Returns:
    Formatted list of available GLM models.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must carry behavioral disclosure. It indicates the tool returns a formatted list, which implies read-only behavior, but it does not explicitly mention safety, side effects, or any limitations. This is adequate for a simple listing tool but lacks depth.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short but contains redundancy, repeating the return information in the prose and the 'Returns:' line. It is not as sparse as ideal, but it is still generally concise and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For the tool's complexity, the description is fairly complete. It states what it does and what it returns, and since an output schema exists, it does not need to detail return values further. It lacks usage guidelines, but that is covered separately.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, and the schema coverage is 100% (empty schema). The baseline for 0 params is 4, and the description does not need to explain parameters. It adds no parameter details because none exist.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'List all available GLM models for the GLM API' with a specific verb-resource combination. It also adds that models come with descriptions, distinguishing it from sibling tools like glm_chat_completions and glm_get_usage_guide.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It does not mention any specific use cases, exclusions, or sibling tools, leaving the agent to infer usage solely from the name and basic purpose.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updatev0.1.2Aug 29, 2026

Changedglm_chat_completions2 fields changed

changedInput schema / properties / model / description

Previous value: -"The GLM model to use. Options: glm-5.2, glm-5, glm-5-turbo, glm-5.1, glm-4.7, glm-4.6, glm-3-turbo. Default is glm-5.2."New value: +"The GLM model to use. Options: glm-5.3, glm-5.2, glm-5, glm-5-turbo, glm-5.1, glm-4.7, glm-4.6, glm-3-turbo. Default is glm-5.2."

changedInput schema / properties / model / enum

Previous value: -[
-  "glm-5.2",
-  "glm-5",
-  "glm-5-turbo",
-  "glm-5.1",
-  "glm-4.7",
-  "glm-4.6",
-  "glm-3-turbo"
-]New value: +[
+  "glm-5.3",
+  "glm-5.2",
+  "glm-5",
+  "glm-5-turbo",
+  "glm-5.1",
+  "glm-4.7",
+  "glm-4.6",
+  "glm-3-turbo"
+]

3 tool updatesv0.1.0Aug 7, 2026
- First observedglm_chat_completions
- First observedglm_get_usage_guide
- First observedglm_list_models

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4/5.0

Scored 2026-08-31 10:10 across 3 tools

Disambiguation5/5

Each tool serves a clearly distinct purpose: usage guidance, chat completion generation, and model listing. There is no overlap or ambiguity between them, so an agent would never struggle to choose the right one.

Naming Consistency5/5

All tool names use the same glm_ prefix and a consistent lower_snake_case style. The verb-noun pattern is uniform (get_usage_guide, chat_completions, list_models), making the set predictable and easy to navigate.

Tool Count5/5

Three tools is well-scoped for a focused GLM chat completions server. Each tool earns its place, and the set feels neither bloated nor too thin.

Completeness4/5

The server covers the core lifecycle of chat completion: listing models and making completions, plus an onboarding guide. It lacks endpoints for embeddings or model-specific detail, but those are likely outside the intended scope.

Maintenance

ActivityNo data

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

mcp-openaiOAuth
io.github.AceDataCloud
MCP server for OpenAI API (chat completions, image generation, embeddings) via AceDataCloud
AI & Machine Learning Image & Video Processing
11
mcp-aichatOAuth
io.github.AceDataCloud
MCP server for AI dialogue using various LLM models via AceDataCloud
AI & Machine Learning
2
mcp-qwen-imageOAuth
io.github.AceDataCloud
MCP server for Qwen Image 3 AI image generation
AI & Machine Learning Image & Video Processing
1
mcp A
ai.llmse
Public MCP server for the LLM Search Engine
Search RAG Systems Developer Tools
102

Related MCP Servers

glm-image-mcp-server
AI & Machine Learning Image & Video Processing
ex-takashima
A
license
A
quality
D
maintenance
MCP server for generating images using Z.AI's glm-image model. Supports image generation with various sizes and qualities, and includes batch CLI functionality.
Updated 9 months ago (2026-01-17 13:54 UTC)
1
12 npm
MIT
AiChat MCP Serverofficial
AI & Machine Learning
AceDataCloud
A
license
B
quality
A
maintenance
An MCP server for AI dialogue via the AceDataCloud platform, supporting multi-model conversations including GPT-4/5, DeepSeek, Grok, and GLM.
Updated 2 days ago (2026-10-12 02:52 UTC)
4
935 PyPI
MIT
mcp-server-gpt-chat
AI & Machine Learning
codeChap
F
license
Not graded
quality
C
maintenance
MCP server for OpenAI ChatGPT API. Enables chat completions, vision analysis, embeddings, and model listing through natural language.
Updated 2 months ago (2026-08-26 15:46 UTC)
-
mcp-server-grok-chat
AI & Machine Learning Search Image & Video Processing
codeChap
F
license
Not graded
quality
C
maintenance
MCP server for the xAI Grok API, providing tools for chat completions, vision analysis, web/X search, embeddings, and model listing via stdio.
Updated 2 months ago (2026-08-26 15:46 UTC)
-

MCP GLM Server

Features

Connect: hosted OAuth, API token, or local stdio

Hosted OAuth examples

Hosted API token

Local stdio

Check before using the service

Available Tools

Documentation

License

Available Tools

Output Schema

TDQS

Output Schema

TDQS

Output Schema

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

glm-image-mcp-server

AiChat MCP Serverofficial

mcp-server-gpt-chat

mcp-server-grok-chat