做云和运维的朋友应该都有过这种经历为了查一台ECS的实时状态先登录控制台翻几级菜单再切回聊天窗口把结果粘给同事。这类事本身不难但吞掉的时间和注意力相当可观。MCP Server这个概念出来之后我发现“查一下、看一下、改一下”这类操作逐渐可以交给AI客户端直接完成。这一篇是“每天了解一类MCP Server”系列里的云服务与基础设施篇聊聊这类MCP Server是什么、怎么选型、怎么在本地启动以及如何用阿里云ECS配合frp这种轻量隧道方案把本地MCP服务安全地暴露给远程环境使用。1. 先搞清楚这类MCP Server到底解决什么问题1.1 MCP Server是什么给AI配一个“工具柜”很多人第一次听说MCP Server会误以为它是个新框架或者新中间件。简单说MCPModel Context Protocol是一套标准协议让AI模型通过统一的方式调用外部工具和数据源。MCP Server就是这套协议的服务端它可以把云厂商API、数据库、文件系统、监控系统这些外部能力封装成AI客户端能识别和调用的“工具”。AI客户端是厨师MCP Server是备菜台你暴露出来的每一个工具就是一把锅铲。没有MCP ServerAI想查一台云服务器就得靠人手动把结果显示给它有了MCP ServerAI自己就能把工具拉起来用。MCP Server主要暴露三类能力工具Tools、资源Resources和提示词模板Prompts。在云服务与基础设施场景里日常用得最多的是工具。比如“查询ECS实例列表”“查看某个RDS实例的慢日志”“获取Kubernetes集群的Pod状态”这些都可以做成一个个工具函数。AI会读取工具描述、参数说明然后决定调用哪一个。这个过程看起来很魔法实际上背后就是一套JSON-RPC风格的通信协议只是协议细节被SDK封装掉了。1.2 云服务与基础设施场景里它的价值到底在哪云服务和基础设施操作的痛点不是“难”而是“碎”。查一台服务器要开控制台看日志要跳另一个页面查账单又是一个入口。更别说Kubernetes这种环境一条kubectl命令勉强能查到结果但要把事件、日志、资源占用串成一条线索人得来回折腾好久。MCP Server把这一整串动作收编进对话框。我在实际使用中最直观的感受是它砍掉了上下文切换成本。以前帮同事排查线上问题我要在IM、控制台、文档之间来回跳现在我在AI客户端里问一句“帮我看看华南区有哪些ECS在跑内存使用率超过80%的有哪些”AI会自己调工具、自己汇总答案。这个能力听起来不算炸裂但真正用起来尤其是在值班场景下能明显减少手忙脚乱。影响范围也不止个人效率。一个团队如果把常用的云资源查询、日志检索、部署状态检查都封装成MCP工具新人上手会变得很快。他们不需要背命令、背控制台路径只要会和AI聊天就行。当然这不是说运维和SRE会被替代而是把重复劳动交给工具人只需要盯住结果和异常。2. 选型云服务MCP Server的三种形态2.1 官方直出型省心但不一定够用现在很多云厂商和基础设施项目都开始自己做MCP Server。一些大厂在开发者社区和开源仓库里放出了官方MCP能力覆盖资源查询、日志读取、监控告警等常见操作。这类官方服务的最大优点是API跟随产品更新不太需要自己维护底层适配。但它也有明显短板。官方出品的MCP通常偏保守偏向“只读查询”和“常规操作”一些高风险变更动作不会放出来。而且官方服务的权限模型不一定贴合你的内部流程比如你想让AI只能查某个资源组下面的ECS官方工具可能做不到这么细的过滤。我个人建议官方MCP适合个人项目快速试用或者当作学习参考生产环境用它当主力往往差点意思。2.2 社区开源型按需挑选但要擦亮眼基础设施领域的社区开源MCP项目挺多Kubernetes、Docker、Nginx、Prometheus都有对应的MCP Server封装。这类项目的好处是“小而专”你只需要装一个针对K8s的不用背上一整个云平台的重型依赖。选的时候我一般看三个指标最近提交时间、README完整程度、Issue区的活跃度。一个项目如果半年没有新提交说明作者可能已经不在维护遇到Bug只能自己啃源码。社区项目还有个大坑是“播放器兼容性”。MCP协议本身还在演进不同客户端对同一套协议的支持程度不一样。有些项目在Claude Desktop上跑得好好的换到其他客户端就抽风。我通常会在本地先跑一遍MCP Inspector验证工具列表和调用结果确认没问题再接入日常使用的客户端。2.3 自建适配型生产环境最值得考虑的方向如果你所在团队已经有CMDB、发布系统、监控平台最合适的方式其实是自己包一层MCP Server。不要觉得写MCP Server很复杂它本质上就是写一批Python或TypeScript函数然后用FastMCP或官方SDK把它暴露成工具。你可以根据内部规范决定暴露哪些操作、怎么记录审计日志、怎么对接现有权限体系。我在生产项目里的经验是自建MCP Server不要一上来做“大而全”。先选取两三个高频场景比如“查实例状态”“查最近告警”“查部署进度”把它跑通再慢慢往里面加工具。自建的隐性收益是你会被迫梳理一遍内部API和工具链把很多散落的知识点整理成标准接口。3. 拆解一个典型云服务MCP Server的配置细节3.1 密钥与凭证最小权限不是口号这是云服务类MCP Server最需要认真对待的部分。AI客户端会自动调用工具一旦密钥权限过大出问题就是生产事故级别的。我强烈建议不要用主账号的AccessKey而是创建独立的RAM子用户按需授权。举一个具体例子如果MCP Server只负责查询ECS信息就给子用户挂AliyunECSReadOnlyAccess策略如果还要查RDS、OSS就分别加对应产品的只读权限。变更类操作单独做一个受限子用户密钥用完吊销或者轮换。密钥本身不要写死在项目代码或MCP配置JSON里应该从环境变量读取。很多客户端支持在MCP Server配置里指定env字段这就是标准做法。我在调试时踩过一个坑配置文件会被同步工具传到仓库里不小心把AccessKey提交到Git。后来我加了.gitignore并且养成了“配置里只放占位符、真实密钥一律走本地env文件”的习惯。这套习惯比任何安全工具都管用。3.2 工具粒度把高危操作关在门外MCP Server暴露哪些工具完全由你决定。我在设计工具列表时会把能力分成三层查询层、变更层、高危层。查询层包括查实例状态、查监控、查日志变更层包括启动停止实例、修改配置高危层包括删除资源、清理数据。默认情况下AI客户端能看到所有已注册的工具。如果你不想让AI随随便便执行删除操作就不要把高危工具注册进去或者把它们放在另一个不常连的MCP Server里。这不是技术做不到而是产品设计层面就要做的隔离。有些人会觉得“AI不会乱来”但在工具调用场景中误触发和幻觉导致的调用偏差是真实存在的尤其是长对话里模型状态容易漂移。3.3 传输方式stdio和HTTP/SSE怎么选MCP Server的传输方式常见有两种stdio和HTTP/SSE。stdio模式适合本地开发客户端直接拉起一个进程通过标准输入输出通信配置简单、调试直观缺点是没法远程访问而且进程生命周期跟着客户端走客户端一关服务就没了。HTTP/SSE模式则让MCP Server变成一个独立服务监听某个端口支持远程调用。这个模式更适合放在服务器上常驻或者给团队共享。要注意的是不同客户端对HTTP模式的支持不一样有些客户端只支持stdio有些两者都行。如果你打算用阿里云ECS加frp把本地服务暴露出去那么服务端最好用HTTP/SSE模式因为隧道转发的是网络端口。4. 实操本地启动一个云服务MCP Server的完整流程4.1 准备环境客户端和依赖我先说客户端选择。Claude Desktop和Cherry Studio是我常用的两个前者对MCP支持很原生后者在配置管理上更直观。Cline和Continue这类IDE插件也能连MCP适合在开发环境里用。不管选哪个底层逻辑都一样客户端按照配置文件拉起MCP Server进程然后通过协议通信。运行环境上Python 3.10以上是目前最稳妥的选择因为FastMCP和阿里云SDK都维护得比较活跃。项目目录建议用虚拟环境隔离别直接装在全局Python里不然依赖冲突会搞到你怀疑人生。mkdir aliyun-mcp cd aliyun-mcp python -m venv .venv source .venv/bin/activate pip install fastmcp alibabacloud_ecs20140526 alibabacloud_tea_openapi4.2 写一个最简的ECS查询MCP Server我提供一个精简但能跑的骨架核心逻辑是把阿里云ECS的DescribeInstances接口封装成一个MCP工具。代码里的字段调用方式在不同SDK版本里可能略有差异但整体结构可以作为参考。import os import json import logging import sys from fastmcp import FastMCP from alibabacloud_ecs20140526.client import Client from alibabacloud_ecs20140526 import models as ecs_models from alibabacloud_tea_openapi.models import Config as OpenApiConfig logging.basicConfig(streamsys.stderr, levellogging.INFO) mcp FastMCP(Aliyun-ECS-MCP) def build_client() - Client: config OpenApiConfig( access_key_idos.environ[ALIBABA_CLOUD_ACCESS_KEY_ID], access_key_secretos.environ[ALIBABA_CLOUD_ACCESS_KEY_SECRET], region_idos.environ.get(ALIBABA_CLOUD_REGION_ID, cn-hangzhou), ) return Client(config) mcp.tool() def list_ecs_instances(region: str ) - str: 查询当前账号下的ECS实例列表。region为空时使用环境变量里的默认地域。 client build_client() request ecs_models.DescribeInstancesRequest( region_idregion or os.environ.get(ALIBABA_CLOUD_REGION_ID, cn-hangzhou), ) response client.describe_instances(request) instances response.body.instances.instance if not instances: return 当前地域没有ECS实例 lines [] for inst in instances: lines.append( f实例ID: {inst.instance_id}, 名称: {inst.instance_name}, f状态: {inst.status}, 规格: {inst.instance_type} ) return \n.join(lines) if __name__ __main__: mcp.run()这里有两个细节想重点说明。第一日志一定要输出到stderr千万不要用print。stdio模式下stdout是MCP协议通道任何多余的print都会污染通信客户端直接报错。第二SDK初始化用了环境变量读取密钥这样配置文件和代码可以安全入库。4.3 本地启动与联调先过一遍MCP Inspector写完代码先在命令行验证。FastMCP提供了一个很方便的调试入口一条命令就能起服务fastmcp run server.py如果服务正常启动日志里会显示Transport模式默认是stdio。这时可以用MCP Inspector做可视化调试。运行fastmcp dev server.py会打开Inspector页面在里面能看到MCP Server暴露出来的工具列表还能手动传参调用list_ecs_instances返回结果直接展示在界面上。我第一次跑的时候工具列表一直刷不出来。查了半天发现是Python环境不对MCP客户端拉起的是系统Python而不是虚拟环境里的Python。后来我在配置里写死了虚拟环境的解释器绝对路径问题立刻消失。如果你的MCP Server也要配置给客户端记住这一点能省不少排查时间。4.4 注册进AI客户端以Claude Desktop为例Claude Desktop的MCP配置存放在claude_desktop_config.json里。我用编辑器打开配置文件把下面这一段加进mcpServers节点{ mcpServers: { aliyun-ecs: { command: /绝对路径/aliyun-mcp/.venv/bin/python, args: [/绝对路径/aliyun-mcp/server.py], env: { ALIBABA_CLOUD_ACCESS_KEY_ID: 你的AccessKeyId, ALIBABA_CLOUD_ACCESS_KEY_SECRET: 你的AccessKeySecret, ALIBABA_CLOUD_REGION_ID: cn-hangzhou } } } }之所以command直接指向虚拟环境里的python是为了避免客户端用系统Python拉起服务时缺依赖。保存配置后重启客户端如果MCP Server注册成功工具列表里能看到ECS查询相关的工具。首次联调建议直接问AI“帮我列出当前地域的ECS实例”看它是否自动调用工具并返回结果。4.5 用阿里云ECS加frp把本地MCP Server暴露给远程客户端场景是这样的你在办公室电脑上起了MCP服务但家里或者客户现场的电脑也想连。最简单的方案是搞一台有公网IP的阿里云ECS配合frp做一条隧道把本地端口转发到公网。注意frp本身是开源免费的内网穿透工具这里说的“免费”是软件授权层面免费ECS的带宽和IP资源还是要按云服务正常付费。先看服务端。在ECS上安装frp然后写frps配置bindPort 7000 auth.method token auth.token 替换成一串足够复杂的随机字符串启动frps后本地这台机器上运行frpc配置这样写serverAddr 你的ECS公网IP serverPort 7000 auth.method token auth.token 和frps保持一致 [[proxies]] name mcp-server type tcp localIP 127.0.0.1 localPort 8000 remotePort 8000本地MCP Server如果用HTTP模式跑在8000端口frpc会把ECS上的8000端口流量全部转发到本地127.0.0.1:8000。远程客户端配置MCP Server地址时填http://ECS公网IP:8000/sse这类HTTP端点即可。不同FastMCP版本的端点路径会有区别可能/sse也可能/mcp用MCP Inspector对远端地址扫一下最保险。这里必须强调安全。ECS安全组入方向不要对全网段开放7000和8000端口建议只放行你自己的办公网IP。frp的token用强随机字符串不要把默认值留上去。隧道用完之后如果不再需要直接把frpc进程停掉或者从安全组移除放行规则。内网穿透的正确用法是“按需开放、用完即收”不是长期把端口裸奔在公网上。5. 常见问题与排查技巧实录5.1 MCP连接失败先怀疑环境别怀疑协议MCP连接失败最常见的两类现象客户端提示连接已关闭或者工具列表加载不出来。排查时先把MCP Server拉到命令行单独跑一遍确认进程能正常启动。如果单独启动没问题那大概率是客户端的配置问题比如python解释器路径不对、工作目录不对、env没设置。还有个隐蔽问题就是stdio通道被污染。有人在server.py里加了print调试当时怎么也找不到原因后来把print全删掉通信立刻恢复。以后凡是写MCP Server调试请统一用logging写到stderr。5.2 云API调用失败的排查清单云API这块我整理了一份高频问题对照能覆盖我遇到的大部分情况。现象可能原因排查思路报错InvalidAccessKeyIdAccessKey不存在或已禁用检查env里的密钥去RAM控制台确认状态报错Forbidden子账号权限不足确认RAM策略是否包含对应API权限返回为空地域配错或者资源组不对确认region_id确认资源归属接口超时本地网络到云API链路慢调整SDK超时时间或换网络环境参数校验失败SDK版本和API版本不匹配打印完整请求体对照官方文档检查字段5.3 frp内网穿透我踩过的坑frp看着配置简单真跑起来问题不少。第一个坑是安全组忘记放行7000端口frpc连接一直被拒但ECS本地测试又是通的。第二个坑是token不一致frps和frpc两端的配置只要差一个字符日志里就是连续不断握手失败。第三个坑是remotePort端口冲突ECS上某个服务占了8000端口frp转发自然失败。碰到这类问题先看两端日志frp的日志信息量足够按时间线看就能定位。安全方面我再劝一句不要把MCP服务通过frp暴露到公网后就不管了。我见过有人图省事把整个运维MCP Server开在公网上只靠frp的token保护。token只是认证不是授权一旦泄露别人就能调用你的云API查询工具。生产环境至少要做三层frp token认证、安全组IP白名单、MCP Server本身的访问密钥校验。6. 用了一段时间之后的一点体会6.1 我实际用得最多的三个场景第一个场景是排障。AI直接拉取ECS状态、监控指标、最近事件然后按时间线整理给我从“手动查三步”变成“一句话拿到结论”。第二个场景是资源盘点。让AI按标签过滤ECS和RDS输出一张清单我直接拿去做成本核算。第三个场景是给团队演示新技术。以前要截图一堆控制台页面现在让AI实时展示查询结果演示既流畅又准确。这几个场景有个共同点都是只读操作。我目前没有把变更类工具开放给AI日常使用不是不信任而是生产变更需要审批和审计这些流程和MCP协议的天然形态还有距离。如果你一定要让AI执行变更建议自建Server里加入人工确认接口AI发起请求后先挂起等人在聊天窗口点确认。6.2 给新手的三个建议第一从只读工具起步。权限范围锁死AI再怎么发挥也不会造成破坏心态会稳很多。第二密钥和配置分离。环境变量是硬要求别图省事把密钥写进配置文件。第三把MCP Server当成内部小服务来设计日志、超时、异常处理都要有因为它不只是给你自己用以后团队其他人也会连。最后分享一个小技巧。除了把工具注册进去我习惯在MCP Server里预置几个提示词模板把“资源体检”“异常排查”这些常见需求写成人话模板。AI收到这类提示后会按照预设步骤连续调用多个工具比自由发挥稳定得多。这算是把日常经验沉淀进MCP Server里的一种方式谁用谁知道。