一个MCP服务器，同时管住6种AWS推理后端。从Amazon Bedrock、SageMaker端点，到跑在EC2 g6和g5g上的vLLM，再到Inferentia2和Trainium上的Gemma 4——全部从一个聊天会话里操作。
这套东西背后是一个Strands agent，面前摆着6种在AWS上服务模型的方式。跑起来意味着最多横跨4个区域的5个计费资源，其中两个跑在AWS Neuron芯片上，而且没有一个实例能从公网访问。
8个Python工具，覆盖全生命周期
服务器提供8个MCP工具，把列出、启动、健康检查、读日志、提问、拆除这些操作全部交给agent。它用工具回答“什么在跑、什么在计费”“inf2开始服务了吗”“给我看g6上的vLLM日志”“全部拆掉”，这些工具的算术和检查都在代码里跑，不靠模型猜。它还把demo 1的计数工具通过协议本身提供给Strands agent。
整个服务器就是一个文件，mcp_server.py，通过stdio启动。仓库根目录的.mcp.json把它注册给Claude Code，任何MCP客户端都能用同样的方式启动它。
三行JSON-RPC就够看清它提供什么。服务器跑在MCP Python SDK 2.1.1和它的MCPServer类上，协商的协议版本是2025-11-25，tools/list返回8个工具。
四条设计规则撑起整个文件
第一条，boto3是同步的，所以每次调用都通过asyncio.to_thread跑在工作线程里。这让一个工具能用asyncio.gather同时问4个区域。
第二条，每个工具都带MCP工具注解，客户端在调用之前就能分清哪个是清单查询、哪个会产生账单、哪个会删除东西。只读、写入、破坏性，三档分得清清楚楚。
第三条，服务器导入demo已经在用的两个模块，在它们周围加上AWS调用。boto3负责EC2、SSM、SageMaker，backends.py提供chat_once()，demo1_counting.py提供count()，subprocess负责拉起stage/up.sh和stage/down.sh。
第四条，启动是分离式的，输出落在stage/*.log里。
一次调用0.78秒，问遍5个AWS接口
list_backends会在4个区域里搜带标签的实例，问SSM每个运行中的实例是否已签到，问SageMaker端点的状态，再把正在计费的东西加起来。计数在工具里算好，agent直接引用。
什么都没启动的时候，它返回6个后端的状态：bedrock是"always on"，sagemaker是"not found"，g6、g5g、inf2、trn1都是"not launched"，billing_now为0，ec2_running为0。
这一次调用花了0.78秒，完成了5个AWS describe调用——每个区域一个EC2，外加一个SageMaker。每个运行中的实例还会再加一次SSM调用。
ask_backend_configured在5个后端都下线的情况下依然列出全部6个。它列出demo.env里带URL的每个后端，那个文件由stage/forward.sh写进stage目录，而且比转发本身活得更久。
launch_backends接受g6、inf2、trn1、g5g和sm中的任意组合。
热门跟贴