Skip to main content
Glama
zstackio

ZStack MCP Server

Official
by zstackio
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

ZStack MCP Server

让 AI 能够动态查询和调用 ZStack Cloud 的 2000+ API 的 MCP Server。

功能特性

  • API 搜索: 根据关键词搜索 ZStack API，支持模糊匹配

  • API 描述: 获取 API 的详细参数说明

  • API 执行: 执行 ZStack API 并返回结果

  • 监控指标搜索: 搜索可用的监控指标

  • 监控数据获取: 获取指定指标的监控数据

Related MCP server: CloudStack MCP Server

安装

# 从 PyPI 安装
pip install zstack-mcp-server

# 或者使用 uv
uv pip install zstack-mcp-server

💡 也可以不安装，直接用 uvx 或 pipx run 一键运行（见下方使用方式）

配置

设置以下环境变量：

export ZSTACK_API_URL="http://localhost:8080"  # ZStack API 地址
export ZSTACK_ALLOW_ALL_API="false"             # 是否允许写操作（可选，默认 false）

# 认证方式一：用户名密码（会自动登录获取 Session）
export ZSTACK_ACCOUNT="admin"                   # 账户名
export ZSTACK_PASSWORD="your-password"          # 密码（明文）

# 认证方式二：直接传入 SessionID（优先级更高，设置后忽略用户名密码）
export ZSTACK_SESSION_ID="your-session-uuid"    # 已有的 Session UUID

# 查询响应控制（可选）
export ZSTACK_QUERY_DEFAULT_LIMIT="50"          # Query API 默认 limit（设 0 禁用）
export ZSTACK_RESPONSE_SIZE_LIMIT="65536"       # 响应大小上限，字节（设 0 禁用）

认证方式说明

方式

环境变量

说明

用户名密码

ZSTACK_ACCOUNT + ZSTACK_PASSWORD

自动登录获取 Session

Session ID

ZSTACK_SESSION_ID

直接使用已有 Session（优先级更高）

💡 如果同时设置了 ZSTACK_SESSION_ID 和用户名密码，会优先使用 Session ID

安全说明

默认情况下，只允许调用只读 API，包括：

  • Query* - 查询类

  • Get* - 获取类

  • List* - 列表类

  • Describe* - 描述类

  • Check* - 检查类

  • Count* - 计数类

  • 其他只读操作...

如需调用写操作 API（如 CreateVmInstance、DeleteVolume 等），需要设置：

export ZSTACK_ALLOW_ALL_API="true"

⚠️ 警告: 启用写操作后，AI 可以执行创建、删除、修改等危险操作，请谨慎使用！

查询响应控制

Query API 默认注入 limit=50，防止一次拉取全量数据撑满模型上下文窗口。响应超过 64KB 时会自动裁剪 inventories 列表，保证返回合法 JSON。

环境变量

默认值

说明

ZSTACK_QUERY_DEFAULT_LIMIT

50

Query API 未指定 limit 时自动注入的默认值，设 0 禁用

ZSTACK_RESPONSE_SIZE_LIMIT

65536

响应大小上限（字节），超过后裁剪，设 0 禁用

  • 显式传入 limit 时不会被覆盖

  • 裁剪发生时响应中会包含 _truncation 字段，提示使用 limit/start 翻页或 fields 精简返回字段

使用方式

作为 MCP Server 运行

# 使用 uvx 直接运行（无需安装）
uvx zstack-mcp-server

# 或使用 pipx
pipx run zstack-mcp-server

# 如果已安装，直接运行
zstack-mcp-server

SSE 模式运行

默认使用 stdio 传输。若需 SSE 模式，可用命令行或环境变量切换：

# 命令行方式
uvx zstack-mcp-server --transport sse --host 0.0.0.0 --port 8000

# 环境变量方式
export MCP_TRANSPORT="sse"
export MCP_HOST="0.0.0.0"
export MCP_PORT="8000"
export MCP_PATH="/sse"  # 可选
uvx zstack-mcp-server

说明：也兼容 FASTMCP_HOST / FASTMCP_PORT / FASTMCP_MOUNT_PATH（FastMCP 原生环境变量）

Streamable HTTP 模式运行

# 命令行方式
uvx zstack-mcp-server --transport streamable-http --host 0.0.0.0 --port 8000 --streamable-path /mcp

# 环境变量方式
export MCP_TRANSPORT="streamable-http"
export MCP_HOST="0.0.0.0"
export MCP_PORT="8000"
export MCP_STREAMABLE_PATH="/mcp"  # 可选
uvx zstack-mcp-server

说明：也兼容 FASTMCP_STREAMABLE_HTTP_PATH

HTTP 头认证（多租户模式）

在 SSE 或 streamable-http 模式下，管理员可以启动一个共享的 MCP Server，多个用户通过 HTTP 头传入各自的凭据，实现多租户隔离。

支持的 HTTP 头：

HTTP Header

对应环境变量

说明

X-ZStack-Account

ZSTACK_ACCOUNT

账户名

X-ZStack-Password

ZSTACK_PASSWORD

密码

X-ZStack-Session-Id

ZSTACK_SESSION_ID

已有 Session（优先级高于账号密码）

X-ZStack-API-URL

ZSTACK_API_URL

ZStack 管理节点地址（可代理多套环境）

凭据优先级：HTTP 头 > 环境变量

典型用法：

# 管理员启动共享 MCP Server
ZSTACK_ALLOW_ALL_API=false uvx zstack-mcp-server --transport streamable-http --host 0.0.0.0 --port 8000

用户在 MCP 客户端配置中添加 HTTP 头即可使用各自的账号：

{
  "mcpServers": {
    "zstack": {
      "transport": "streamable-http",
      "url": "http://mcp-server:8000/mcp",
      "headers": {
        "X-ZStack-Account": "user-a",
        "X-ZStack-Password": "password-a",
        "X-ZStack-API-URL": "http://zstack-env-1:8080"
      }
    }
  }
}

特性：

  • 同一账号的 Session 会自动缓存复用，不会每次请求都创建新 Session

  • 不同 X-ZStack-API-URL 的请求会路由到不同的 ZStack 环境

  • stdio 模式下无 HTTP 头，自动回退到环境变量认证，行为不变

在 Claude Desktop 中配置

在 claude_desktop_config.json 中添加：

方式一：使用用户名密码

{
  "mcpServers": {
    "zstack": {
      "command": "uvx",
      "args": ["zstack-mcp-server"],
      "env": {
        "ZSTACK_API_URL": "http://your-zstack-server:8080",
        "ZSTACK_ACCOUNT": "admin",
        "ZSTACK_PASSWORD": "your-password",
        "ZSTACK_ALLOW_ALL_API": "false"
      }
    }
  }
}

方式二：使用 Session ID

{
  "mcpServers": {
    "zstack": {
      "command": "uvx",
      "args": ["zstack-mcp-server"],
      "env": {
        "ZSTACK_API_URL": "http://your-zstack-server:8080",
        "ZSTACK_SESSION_ID": "your-session-uuid",
        "ZSTACK_ALLOW_ALL_API": "false"
      }
    }
  }
}

💡 将 ZSTACK_ALLOW_ALL_API 设为 "true" 可启用写操作（创建/删除/修改等）

可用工具

1. search_api

根据关键词搜索 ZStack API。

参数:

  • keywords (list[str]): 搜索关键词，如 ["Query", "Vm"]

  • category (str, 可选): 按分类过滤

  • limit (int, 默认 15): 最多返回数量

2. describe_api

获取指定 API 的详细参数说明。

参数:

  • api_name (str): API 名称，如 "QueryVmInstance"

3. execute_api

执行 ZStack API。

参数:

  • api_name (str): API 名称

  • parameters (dict): API 参数

4. search_metric

搜索可用的监控指标。

参数:

  • keywords (list[str]): 搜索关键词

  • namespace (str, 可选): 按命名空间过滤（支持模糊匹配，如 vm/host）

  • limit (int, 默认 20): 最多返回数量

  • match_mode (str, 默认 or): 关键词匹配模式（and/or）

  • prefer_namespaces (list[str], 可选): 优先排序的命名空间列表（默认 ["ZStack/VM","ZStack/Host"]）

💡 提示：不确定 namespace 时可先不传，返回结果会带 namespace 值供选择 💡 默认 match_mode=or（多关键词并集）；如需交集请显式传 and 💡 指标名称在不同 namespace 可能重名，建议指定 namespace 或 prefer_namespaces 以确保排序优先

5. get_metric_data

获取监控数据。

参数:

  • namespace (str): 命名空间

  • metric_name (str): 指标名称

  • start_time (str|int, 可选): 开始时间 (ISO 或秒级时间戳)

  • end_time (str|int, 可选): 结束时间 (ISO 或秒级时间戳)

  • period (int, 默认 60): 采样周期(秒)

  • labels (list[str]|dict, 可选): 标签过滤，如 ["VMUuid=xxx"] 或 {"VMUuid":"xxx"}

  • summary_only (bool, 可选): 仅返回统计信息（点数/最大/最小/平均/方差/标准差）

数据量提示:

  • 返回点数估算：ceil((end_time - start_time) / period) * series_count

  • series_count 为不同 label 组合数量；不传 labels 时可能返回多组序列

  • 建议通过缩短时间范围、增大 period 或增加 labels 过滤避免输出过大

6. get_metric_summary

获取监控指标的聚合 TopN（按 label_key 分组）。

参数:

  • namespace (str): 命名空间

  • metric_name (str): 指标名称

  • label_key (str): 标签键，如 VMUuid/HostUuid

  • metric_names (list[str], 可选): 多指标合并（如 in/out）

  • start_time (str|int, 可选): 开始时间 (ISO 或秒级时间戳)

  • end_time (str|int, 可选): 结束时间 (ISO 或秒级时间戳)

  • period (int, 默认 60): 采样周期(秒)

  • aggregate (str, 默认 max): 单指标聚合方式 (max/avg/sum/min)

  • combine (str, 默认 sum): 多指标合并方式 (sum/avg/max/min)

  • threshold_op (str, 可选): 阈值比较符 (>,>=,<,<=,==,!=)

  • threshold_value (number, 可选): 阈值数值

  • top_n (int, 默认 10): 返回条数

  • resolve_resource (str, 可选): vm 或 host，用于解析名称

Query API 条件语法

对于 Query 类 API，conditions 参数支持以下操作符：

操作符

含义

示例

=

等于

name=test

!=

不等于

state!=Deleted

>

大于

cpuNum>4

>=

大于等于

memorySize>=1073741824

<

小于

createDate<2024-01-01

<=

小于等于

?=

模糊匹配(LIKE，部分版本为 like)

name?=%test%

!?=

模糊不匹配

~=

正则匹配

name~=.*test.*

!~=

正则不匹配

=null

为空

description=null

!=null

不为空

in

在列表中

state?=Running,Stopped

not in

不在列表中

state!?=Deleted,Destroyed

conditions 格式:

{
    "conditions": [
        {"name": "uuid", "op": "=", "value": "xxx"},
        {"name": "state", "op": "in", "value": "Running,Stopped"}
    ]
}

示例交互

用户问: "帮我查一下 UUID 为 ae6e57a0 开头的 VM 的详情"

AI 会:

  1. 调用 search_api(keywords=["Query", "Vm", "Instance"])

  2. 调用 describe_api(api_name="QueryVmInstance")

  3. 调用 execute_api(api_name="QueryVmInstance", parameters={"conditions": [{"name": "uuid", "op": "?=", "value": "ae6e57a0%"}]})

开发

# 克隆仓库
git clone https://github.com/zstackio/zstack-mcp-server.git
cd zstack-mcp-server

# 安装开发依赖
pip install -e ".[dev]"

# 运行测试
pytest

License

MIT

Available Tools

6 tools
describe_apiA

获取指定 ZStack API 的详细参数说明

Args: api_name: API 名称，如 "QueryVmInstance"

Returns: API 的精简信息。对于 Query API，仅返回核心参数和 queryableFields。

ParametersJSON Schema
NameRequiredDescriptionDefault
api_nameYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior3/5

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

Without annotations, the description partially compensates by noting that the tool returns '精简信息' (concise information) and for Query APIs only core parameters and queryableFields. However, it does not disclose safety traits (e.g., read-only nature), auth requirements, or error handling.

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

Conciseness5/5

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

The description is extremely concise with two short sentences plus a returns line. Every sentence is essential and front-loaded with the purpose. No wasted verbiage.

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 tool's simplicity, the description is fairly complete. It mentions the return format (concise info) and a special case (Query APIs). The presence of an output schema reduces the need to detail return fields. However, it lacks context on prerequisites or typical use scenarios.

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?

With 0% schema description coverage, the description adds value by providing an example ('如 'QueryVmInstance'') for the 'api_name' parameter, which clarifies the expected format beyond the schema's title. This helps in choosing the correct value.

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 the tool's purpose: to get detailed parameter descriptions for a specified ZStack API. It uses a specific verb ('获取') and resource ('API 的详细参数说明'), and distinguishes from sibling tools like 'execute_api' and 'search_api' by its focus on description.

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

Usage Guidelines3/5

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

The description implies use when needing parameter details for a specific API, but does not explicitly state when to prefer this over alternatives like 'search_api' or 'execute_api'. No exclusions or when-not guidance are provided.

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

execute_apiA

执行 ZStack API

注意: 默认只允许调用只读 API（Query/Get/List 等）。 如需调用写操作 API，请设置环境变量 ZSTACK_ALLOW_ALL_API=true

Args: api_name: API 名称，如 "QueryVmInstance" parameters: API 参数字典 对于 Query API，conditions 格式为: [{"name": "字段名", "op": "操作符", "value": "值"}, ...] 分页: limit（默认 50）、start（偏移量） 字段选择: fields（减少返回数据量）

Returns: API 执行结果 (JSON 格式)

Example: execute_api( api_name="QueryVmInstance", parameters={ "conditions": [ {"name": "uuid", "op": "like", "value": "ae6e57a0%"} ] } )

ParametersJSON Schema
NameRequiredDescriptionDefault
api_nameYes
parametersYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

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

No annotations provided, so description carries full burden. Discloses authorization restriction (read-only by default) and how to enable writes. Does not mention rate limits or side effects, but covers key behavioral trait.

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

Conciseness5/5

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

Well-structured with labeled sections (default behavior, args, returns, example). Each sentence adds necessary information without redundancy.

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

Completeness5/5

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

Covers all essential aspects: purpose, authorization, parameter details, return type, and example. Given presence of output schema, description is complete.

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

Parameters5/5

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

Schema coverage is 0%, but description adds rich meaning: api_name is an API name like 'QueryVmInstance', parameters is a dictionary with conditions format, pagination (limit, start), and field selection. Example clarifies usage.

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?

Description clearly states the verb 'execute' and resource 'ZStack API', and distinguishes from sibling tools like describe_api and search_api which have different purposes.

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?

Provides explicit context: default read-only, environment variable to enable writes. Includes details on parameter format, pagination, and field selection. Lacks explicit when-not or alternatives but siblings are distinct.

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

get_metric_dataA

获取 ZStack 监控数据

Args: namespace: 命名空间，如 "ZStack/VM", "ZStack/Host" metric_name: 指标名称，如 "CPUUsedUtilization" start_time: 开始时间（ISO 或秒级时间戳） end_time: 结束时间（ISO 或秒级时间戳） period: 采样周期(秒)，默认 60 labels: 标签过滤，如 ["VMUuid=xxx"] 或 {"VMUuid":"xxx"} summary_only: 仅返回统计信息（点数/最大/最小/平均/方差/标准差）

注意: 返回数据量与时间跨度和 period 成正比。可用估算公式: 点数 ≈ ceil((end_time - start_time) / period) * series_count series_count 为不同 label 组合数量；若不传 labels，可能返回多组系列 （例如指标包含 CPUNum/VMUuid 等 label 时每个组合都会产出一组序列）。 为避免输出过大：缩短时间范围、增大 period 或增加 labels 过滤。

Returns: 监控数据点列表

ParametersJSON Schema
NameRequiredDescriptionDefault
namespaceYes
metric_nameYes
start_timeNo
end_timeNo
periodNo
labelsNo
summary_onlyNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations provided, the description carries the full behavioral disclosure burden. It explains data volume behavior, includes an estimation formula, and warns about large outputs. However, it omits error handling (e.g., invalid namespace) and authentication requirements. While informative, it is not fully transparent.

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

Conciseness4/5

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

The description is front-loaded with purpose and parameter list, then a helpful note. While the note is valuable, it is somewhat lengthy. The structure is clear, but could be slightly more concise.

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 7 parameters, no annotations, and an output schema (not shown), the description covers key aspects: return type, data volume estimation, and summary_only details. It explains the note thoroughly but does not mention error scenarios or output schema specifics, which are assumed from the output schema. Overall fairly complete.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must compensate. It explains every parameter with examples and clarifications (e.g., namespace examples, labels format, time format). It adds value beyond the schema, making all parameters understandable despite the schema's vagueness.

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

Purpose4/5

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

The description clearly states '获取 ZStack 监控数据' (get ZStack monitoring data) and explains it returns a list of data points. However, it doesn't differentiate from sibling tools like get_metric_summary or search_metric, which could also retrieve monitoring data. The purpose is clear but lacks explicit distinction.

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 provides extensive guidance on usage, including a detailed note on data volume estimation and how to avoid large outputs by adjusting time range, period, or labels. It implies when to use parameters but does not explicitly compare with sibling tools for when to use this tool over alternatives.

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

get_metric_summaryB

获取监控指标的聚合 TopN（按 label_key 分组）

Args: namespace: 命名空间，如 "ZStack/VM", "ZStack/Host" metric_name: 指标名称，如 "CPUOccupiedByVm" label_key: 标签键，如 "VMUuid", "HostUuid" metric_names: 可选，多指标合并（如 in/out） start_time: 开始时间（ISO 或秒级时间戳） end_time: 结束时间（ISO 或秒级时间戳） period: 采样周期(秒)，默认 60 aggregate: 单指标聚合方式，可选 "max"|"avg"|"sum"|"min" combine: 多指标合并方式，可选 "sum"|"avg"|"max"|"min" threshold_op: 阈值比较符，如 >,>=,<,<=,==,!= threshold_value: 阈值数值 top_n: 返回条数，默认 10 resolve_resource: 可选 "vm" 或 "host"，用于解析名称

Returns: 聚合后的 TopN 列表

ParametersJSON Schema
NameRequiredDescriptionDefault
namespaceYes
metric_nameYes
label_keyYes
metric_namesNo
start_timeNo
end_timeNo
periodNo
aggregateNomax
combineNosum
threshold_opNo
threshold_valueNo
top_nNo
resolve_resourceNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.3/5.0
Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It implies a read-only query but does not explicitly state side effects, permissions, or rate limits. The return type is mentioned but not detailed.

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

Conciseness4/5

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

The description is front-loaded with the purpose, followed by a structured parameter list and return statement. It is appropriately sized for 13 parameters, though the parameter descriptions could be slightly more compact.

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

Completeness3/5

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

Given the complexity (13 parameters, no annotations, output schema exists but not described), the description covers parameter semantics and return type. However, it lacks examples, error conditions, and explicit read-only indication, leaving gaps in understanding the full context.

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

Parameters5/5

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

The schema has 0% parameter description coverage, yet the description provides detailed explanations for all 13 parameters, including examples and valid options (e.g., aggregate: 'max'|'avg'|'sum'|'min'). This fully compensates for the missing schema descriptions.

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

Purpose4/5

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

The description clearly states that the tool retrieves aggregated TopN of monitoring metrics grouped by label_key. This is specific and differentiates it from sibling tools like get_metric_data, but does not explicitly contrast them.

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?

No guidance is provided on when to use this tool vs alternatives (e.g., get_metric_data or search_metric). The description does not mention prerequisites, limitations, or when not to use it.

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

search_apiA

根据关键词搜索 ZStack API

Args: keywords: 搜索关键词列表，如 ["Query", "Vm"] 或 ["Create", "Volume"] 支持驼峰拆分匹配，如搜索 "vm" 可以匹配 "QueryVmInstance" category: 可选，按分类过滤，如 "vm", "volume", "network" limit: 最多返回数量，默认 15

Returns: 匹配的 API 列表，包含名称、描述、分类、调用类型

ParametersJSON Schema
NameRequiredDescriptionDefault
keywordsYes
categoryNo
limitNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations, the description carries full burden and adequately explains the search behavior, camelCase matching, filtering, and return fields. It implicitly indicates a read-only operation, though it does not explicitly state no side effects.

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

Conciseness5/5

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

The description is concise and well-structured: purpose statement, then Args section with each parameter explained, then Returns. Every sentence adds value without redundancy.

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

Completeness5/5

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

Given the output schema exists, the description appropriately mentions return fields. It covers all important aspects: purpose, parameters, and output format, leaving no critical gaps.

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

Parameters5/5

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

Schema coverage is 0%, so the description fully explains each parameter: keywords (list, examples, matching), category (optional filter with examples), limit (default 15). It adds significant meaning beyond the schema titles.

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 it searches ZStack API by keywords, with examples and matching mechanism. It distinguishes from sibling tools like describe_api, execute_api, and metric tools, which serve different purposes.

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 provides clear usage via keyword examples and optional filters, but does not explicitly contrast with sibling tools. However, the naming and context make it obvious when to use this tool versus alternatives.

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

search_metricA

搜索可用的 ZStack 监控指标

Args: keywords: 搜索关键词，如 ["CPU", "Usage"] 或 ["Memory"] 支持驼峰拆分匹配 namespace: 可选，按命名空间过滤（支持模糊匹配），如 "ZStack/VM", "vm", "host" limit: 最多返回数量，默认 20 match_mode: 关键词匹配模式，"and" 或 "or"，默认 "or" prefer_namespaces: 优先排序的命名空间列表（默认 ["ZStack/VM","ZStack/Host"]）

Returns: 匹配的监控指标列表，包含名称、描述、命名空间、可用标签

ParametersJSON Schema
NameRequiredDescriptionDefault
keywordsYes
namespaceNo
limitNo
match_modeNoor
prefer_namespacesNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description provides behavioral details such as camelCase splitting, fuzzy matching, default values, and sorting preferences. It describes return values, making the tool fairly transparent for a search operation.

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

Conciseness4/5

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

The description is moderately long but well-organized with an Args section and bullet points. Every sentence adds value, though it could be slightly more concise without losing information.

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

Completeness5/5

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

Given the existence of an output schema, the description covers all necessary context: parameter details, return value summary, and usage. It is complete for a search tool with 5 parameters and required fields.

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

Parameters5/5

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

Schema coverage is 0%, but the description explains each parameter thoroughly: keywords (with examples), namespace (fuzzy match), limit (default), match_mode (enum logic), prefer_namespaces (default list). This adds significant value beyond the bare schema.

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

Purpose4/5

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

The description clearly states '搜索可用的 ZStack 监控指标', which identifies the tool's purpose as searching monitoring metrics. It provides details on parameters but does not explicitly differentiate from sibling tools like search_api.

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

Usage Guidelines3/5

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

The description explains how to use each parameter with examples and defaults, but lacks guidance on when to use this tool versus alternatives like get_metric_data or search_api. Usage is implied but not explicitly stated.

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. Dates show when Glama detected each change.

  1. 6 tool updatesv0.1.6
    • First observeddescribe_api
    • First observedexecute_api
    • First observedget_metric_data
    • First observedget_metric_summary
    • First observedsearch_api
    • First observedsearch_metric
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: describe_api provides API details, execute_api calls APIs, search_api finds APIs, and similarly for metrics (get_metric_data, get_metric_summary, search_metric). There is no overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., describe_api, get_metric_data, search_metric). No deviations or mixed conventions.

Tool Count5/5

With 6 tools covering API exploration/execution and metric data retrieval/aggregation/search, the count is well-scoped for a ZStack server. No tool feels extraneous, and the set is not overly sparse.

Completeness5/5

The tool set fully covers the domain: users can explore APIs (search, describe), execute any API (including write operations if configured), and access monitoring metrics (raw data, summary/aggregation, search). No obvious gaps hinder common workflows.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • CloudStack MCP Server

    mozg31337
    F
    license
    Not graded
    quality
    D
    maintenance
    Enables comprehensive management of CloudStack infrastructure through natural language, providing access to over 735 API methods for virtual machines, networking, and storage. It features enterprise-grade security with a safety confirmation system for destructive operations and extensive API coverage.
    -

  • Cloud Pilot MCP

    vitalemazo
    A
    license
    Not graded
    quality
    C
    maintenance
    Provides AI agents with natural language control over AWS, Azure, GCP, and Alibaba Cloud infrastructure through dynamic API discovery and execution. Supports 51,900+ cloud operations and includes OpenTofu integration for complete infrastructure lifecycle management.
    3
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/zstackio/zstack-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server