SAE MCP 自研可行性评估：基于 OpenAPI 让 CloudQ 管理阿里云 Serverless 应用

背景

在跨云日志分析和跨云 MCP 迁移两篇文章中，我们已经把阿里云 SLS MCP 部署到 FC，让智能顾问 CloudQ 具备了跨云查询日志的能力。但还有一类阿里云资源——SAE（Serverless 应用引擎）——目前没有官方 MCP 支持，也不在 alibaba-cloud-ops-mcp-server 的覆盖范围内（仅支持 ECS / VPC / RDS / OSS / 云监控）。

对于希望通过 CloudQ 一站式管理跨云资源的客户，是否值得自研一个 SAE MCP？本文从 API 完备度、技术方案、工作量、成本等维度做完整评估。

评估结论：高度可行。SAE OpenAPI 完整、SDK 成熟，沿用现有 FC 部署经验，约 4.5 天即可完成 MVP（7 个只读工具），月成本仅约 ¥15。

一、SAE OpenAPI 能力评估

阿里云 SAE 提供了完整的 OpenAPI（API 版本：2019-05-06），覆盖应用全生命周期管理。核心 API 分类：

分类	关键 API	用途
应用管理	`ListApplications`	列出命名空间下所有应用
	`DescribeApplicationConfig`	获取应用详细配置（CPU/内存/镜像等）
	`DescribeApplicationStatus`	查询应用运行状态
实例管理	`DescribeApplicationInstances`	查询应用下所有实例
	`RestartApplication`	重启应用
	`RescaleApplication`	手动扩缩容
部署管理	`DeployApplication`	部署/更新应用
部署管理	`RollbackApplication`	回滚到历史版本
日志查询	SLS 集成日志	SAE 日志默认投递到 SLS，可通过 SLS API 查询
监控	`DescribeMetric`	查询应用 CPU/内存/QPS 等指标
命名空间	`DescribeNamespaceList`	列出所有命名空间
自动弹性	`DescribeApplicationScalingRules`	查询弹性规则

API 完备度评估：SAE OpenAPI 覆盖度高，几乎所有控制台操作都有对应 API。SDK 支持 Java/Python/Go/Node.js/PHP/.NET 等多语言，开发友好。

二、技术方案设计

2.1 整体架构

CloudQ 通过 FC 部署的自研 SAE MCP Server 管理阿里云 SAE 应用（与现有 SLS MCP 协同工作）

2.2 部署平台对比

方案	优点	缺点	推荐
阿里云 FC	全托管/弹性/AK不跨云/与现有方案一致	SSE需极速模式+预置实例	★★★ 推荐
阿里云 SAE	更长生命周期/适合常驻服务	成本略高于FC闲时	备选
腾讯云跳板机	与现有跳板机统一	AK跨云/内存压力/已迁移过	不推荐

建议：沿用现有 FC 部署方案，复用观测云 MCP / SLS MCP 的部署经验，降低维护成本。

三、MCP 工具设计

建议封装的 MCP 工具列表（按优先级）：

工具名	对应 SAE API	说明	优先级
`sae_list_namespaces`	DescribeNamespaceList	列出命名空间	P0
`sae_list_applications`	ListApplications	列出应用（按命名空间过滤）	P0
`sae_describe_application`	DescribeApplicationConfig	查看应用详细配置	P0
`sae_describe_application_status`	DescribeApplicationStatus	查看应用运行状态	P0
`sae_list_instances`	DescribeApplicationInstances	列出应用实例	P0
`sae_get_metrics`	DescribeMetric	查询 CPU/内存/QPS 指标	P1
`sae_get_logs`	调用 SLS API（SAE日志默认投SLS）	查询应用日志	P1
`sae_describe_scaling_rules`	DescribeApplicationScalingRules	查看弹性规则	P2
`sae_restart_application`	RestartApplication	重启应用（写操作）	P2 谨慎
`sae_rescale_application`	RescaleApplication	手动扩缩容（写操作）	P2 谨慎

权限边界建议：

P0/P1（只读）：默认开放，使用 SAE 只读 RAM 角色（含 sae:Describe*, sae:List*）

P2（写操作）：建议分独立 RAM 子账号+独立 MCP 端点+审计日志，避免误操作

四、实施工作量评估

任务	工作量	说明
RAM 子账号 + 权限策略	0.5 天	创建只读子账号，授予 sae:Describe/List 权限
MCP Server 框架搭建	0.5 天	复用 mcp-server-aliyun-observability 的 SSE 框架
P0 工具开发（5个）	1.5 天	调用阿里云 Python SDK 封装
P1 工具开发（2个）	1 天	含 SLS 日志查询集成
FC 部署 + 测试	0.5 天	复用 FC 部署脚本
CloudQ 接入 + 端到端验证	0.5 天	智能顾问添加自定义 MCP 连接
合计 MVP（仅只读）	4.5 天	覆盖 7 个查询类工具
P2 写操作工具（可选）	+1.5 天	含审批流和审计日志

五、参考实现（伪代码）

5.1 项目结构

sae-mcp-server/

├── bootstrap                  # FC 启动脚本

├── server.py                  # MCP Server 主入口

├── tools/

│   ├── applications.py        # 应用管理工具

│   ├── instances.py           # 实例管理工具

│   ├── logs.py                # 日志查询（调 SLS）

│   └── metrics.py             # 监控查询

├── sae_client.py              # SAE SDK 封装

└── requirements.txt           # 含 mcp + alibabacloud_sae20190506

5.2 核心代码示例

from mcp.server import Server
from alibabacloud_sae20190506.client import Client as SaeClient
from alibabacloud_tea_openapi import models as open_api_models
import os

ak = os.environ['ALIYUN_ACCESS_KEY_ID']
sk = os.environ['ALIYUN_ACCESS_KEY_SECRET']
config = open_api_models.Config(
    access_key_id=ak, access_key_secret=sk,
    endpoint='sae.cn-hangzhou.aliyuncs.com'
)
sae = SaeClient(config)

server = Server('sae-mcp')

@server.tool()
async def sae_list_applications(namespace_id: str):
    """列出 SAE 命名空间下所有应用"""
    resp = sae.list_applications({'NamespaceId': namespace_id})
    return [{'app_id': a.app_id, 'app_name': a.app_name, 'status': a.status}
            for a in resp.body.data.applications]

@server.tool()
async def sae_describe_application(app_id: str):
    """获取应用详细配置"""
    resp = sae.describe_application_config({'AppId': app_id})
    return resp.body.data.to_map()

5.3 bootstrap 启动脚本

#!/bin/bash
pip install mcp alibabacloud-sae20190506 alibabacloud-sls20201230 -q
python3 server.py \
  --transport sse \
  --transport-port 9000

六、与现有 SLS MCP 的协同

SAE 应用日志默认会投递到 SLS。CloudQ 可以这样组合使用两个 MCP：

SAE MCP：查询应用列表、状态、配置、实例、指标

SLS MCP：根据 SAE MCP 返回的应用 ID/名称，去 SLS 查询对应日志

形成"应用元数据查询 + 日志深度分析"的完整链路。

七、风险与建议

风险	等级	应对
SAE OpenAPI 限频	中	FC 端做缓存（如 30s 缓存应用列表）
RAM 权限过大	高	严格使用最小权限策略，只读优先
写操作误触发	高	P2 工具独立部署+审批流
多地域支持	低	SAE Endpoint 支持多 region，参数化即可
大查询结果撑爆上下文	中	所有列表类工具默认 limit=20

八、推荐实施路径

Day 1-2：RAM 配置 + MCP 框架 + 5 个 P0 只读工具

Day 3：FC 部署 + 本地联调

Day 4：CloudQ 接入 + 端到端验证

Day 5：补充 P1 工具（指标 + 日志查询）

Week 2（可选）：P2 写操作工具，独立审批

九、最终结论

评估维度	结论
API 完备度	优 — SAE OpenAPI 覆盖完整
SDK 支持	优 — Python SDK 成熟
开发难度	低 — 可复用现有 FC 部署经验
工作量	5天 — MVP 一周内完成
成本	极低 — FC 按调用计费 ~¥15/月
安全性	高 — AK 不出阿里云，HTTPS + Bearer 鉴权
与现有架构契合度	高 — 与 SLS MCP / 观测云 MCP 一致

总结：当前阿里云生态对 SAE 的 MCP 支持是空白的，但 SAE OpenAPI 的完备度很高，沿用现有 FC 部署经验自研一个 SAE MCP 是完全可行的方案。

核心优势：1) AK/SK 不出阿里云的安全闭环；2) 与现有 SLS MCP 形成"应用元数据 + 日志深度分析"的完整链路；3) MVP 一周内可交付，月成本约 ¥15。

对于希望通过 CloudQ 一站式管理跨云资源的场景，自研 SAE MCP 的 ROI 非常高。建议立即启动开发，让 CloudQ 具备完整的 SAE 管理能力。