摘要MCP Server Docker容器化部署教程涵盖Dockerfile编写、多阶段构建、环境变量注入、健康检查和云端部署AWS/Aliyun附docker-compose完整配置。MCP部署上线 Docker容器化与云端部署我第一次部署MCP Server到服务器是直接SSH上去python server.py跑的。第二天服务器重启了Server没了用户找过来说工具用不了。后来我又改成nohup后台跑结果日志文件越来越大把磁盘撑满了。折腾了三轮我才意识到这种裸跑方式根本没法维护。这篇讲我用Docker容器化部署MCP Server的完整方案从Dockerfile到docker-compose到云端上线一条龙。Dockerfile编写 MCP Server容器化容器化的核心好处是环境一致性和可复现。开发机上能跑的容器里也能跑不用再担心在我机器上是好的这种问题。写MCP Server的Dockerfile有几个要点。第一是选择基础镜像。Python应用我用python:3.12-slim比完整版镜像小很多又有足够的基础工具。别用alpine编译Python依赖时各种缺库会让人崩溃。第二是多阶段构建。第一阶段安装依赖第二阶段拷贝依赖和代码到精简镜像里。这样最终镜像不带编译工具体积小且更安全。第三是注意MCP的Streamable HTTP传输模式。stdio模式只能在本地用部署到网络必须用Streamable HTTP。FastMCP支持通过mcp.run(transportstreamable-http)启动HTTP服务默认监听8000端口。第四是健康检查。Docker的HEALTHCHECK指令配合一个健康检查端点让容器编排系统能自动感知Server是否存活。Streamable HTTP部署2025年3月26日MCP协议引入Streamable HTTP替代原来的HTTPSSE。新方案有几个关键变化。移除了单独的/sse端点所有通信统一走/mcp端点。服务器可以选择无状态模式不需要维持长连接。客户端发POST请求服务器可以选择返回普通HTTP响应或升级为SSE流式响应。这对部署的影响很大。无状态模式意味着Server可以水平扩展前面挂负载均衡器就行不用考虑会话粘性。而且纯HTTP实现可以和现有的中间件、API网关、CDN等基础设施良好兼容。部署时有个安全要点。Streamable HTTP默认不带认证任何人拿到地址就能连。必须在Server代码里加token校验或者用反向代理比如nginx在入口层做鉴权。docker-compose编排单容器部署用docker run就够了但生产环境通常要搭配Redis、数据库等辅助服务。docker-compose把这些服务定义在一个文件里一条命令全部启动。我的compose编排包含三个服务。MCP Server本体Redis做缓存还有一个健康检查的辅助容器。服务之间通过内部网络通信只有MCP Server的端口对外暴露。compose还定义了健康检查、重启策略、资源限制、日志配置。重启策略设为unless-stopped容器崩溃自动重启但手动停止不会自动拉起。资源限制防止某个容器吃光内存导致整台机器挂掉。完整代码下面是完整的部署配置包含Server代码、Dockerfile、docker-compose和健康检查。先是要部署的MCP Server支持Streamable HTTP。# app/server.py# 支持Streamable HTTP的MCP Server# 依赖 mcp redis uvicornimportosimporttimeimportjsonfrommcp.server.fastmcpimportFastMCP# 从环境变量读取配置 容器化部署的标准做法HOSTos.environ.get(MCP_HOST,0.0.0.0)PORTint(os.environ.get(MCP_PORT,8000))API_TOKENos.environ.get(MCP_API_TOKEN,)mcpFastMCP(deploy-demo-server)mcp.tool()defhealth_check()-str:健康检查工具 返回服务器状态信息returnjson.dumps({status:healthy,timestamp:time.time(),server:deploy-demo-server,version:1.0.0,},ensure_asciiFalse)mcp.tool()defecho(message:str)-str:回显工具 用于测试连通性returnf收到消息{message}服务器时间{time.strftime(%H:%M:%S)}mcp.tool()defget_config()-str:返回当前服务器配置 脱敏后展示returnjson.dumps({host:HOST,port:PORT,transport:streamable-http,has_auth:bool(API_TOKEN),},ensure_asciiFalse)if__name____main__:# 以Streamable HTTP模式启动# 这是2025-03-26之后的推荐传输方式mcp.run(transportstreamable-http,hostHOST,portPORT)接下来是依赖清单。# app/requirements.txt # Python依赖清单 固定版本保证可复现 mcp1.0.0 redis5.0.0 uvicorn0.30.0 pydantic2.0.0然后是Dockerfile。# Dockerfile # 多阶段构建 先装依赖再拷代码 最终镜像精简 # # 第一阶段 构建阶段 安装依赖 # FROM python:3.12-slim AS builder # 设置工作目录 WORKDIR /build # 先只拷贝依赖清单 利用Docker缓存层加速构建 # 只要requirements.txt没变 这一层就命中缓存不会重新安装 COPY app/requirements.txt . # 安装依赖到指定目录 方便第二阶段拷贝 RUN pip install --no-cache-dir --prefix/install -r requirements.txt # # 第二阶段 运行阶段 精简最终镜像 # FROM python:3.12-slim # 设置工作目录 WORKDIR /app # 从构建阶段拷贝已安装的Python依赖 COPY --frombuilder /install /usr/local # 拷贝应用代码 COPY app/ . # 设置环境变量 默认值可通过docker-compose覆盖 ENV MCP_HOST0.0.0.0 ENV MCP_PORT8000 ENV MCP_API_TOKEN # 暴露MCP Server监听端口 EXPOSE 8000 # 健康检查 每30秒检测一次 连续3次失败标记为unhealthy # 超时5秒内没响应算失败 HEALTHCHECK --interval30s --timeout5s --retries3 \ CMD python -c import urllib.request; urllib.request.urlopen(http://localhost:8000/mcp, timeout3) || exit 1 # 启动命令 CMD [python, server.py]然后是docker-compose配置。# docker-compose.yml# 多服务编排 包含MCP Server和Redisversion:3.9services:# MCP Server主服务mcp-server:build:context:.dockerfile:Dockerfilecontainer_name:mcp-serverports:# 主机8000端口映射到容器8000端口-8000:8000environment:-MCP_HOST0.0.0.0-MCP_PORT8000# 从.env文件读取敏感配置-MCP_API_TOKEN${MCP_API_TOKEN}-REDIS_URLredis://redis:6379/0depends_on:# 等Redis启动后再启动Serverredis:condition:service_healthyrestart:unless-stopped# 资源限制 防止单容器吃光主机资源deploy:resources:limits:memory:512Mcpus:1.0# 日志配置 防止日志文件无限增长logging:driver:json-fileoptions:max-size:10mmax-file:3networks:-mcp-network# Redis缓存服务redis:image:redis:7-alpinecontainer_name:mcp-redis# Redis自带健康检查healthcheck:test:[CMD,redis-cli,ping]interval:10stimeout:3sretries:3restart:unless-stopped# Redis数据持久化 卷映射volumes:-redis-data:/datanetworks:-mcp-network# 命名卷 用于Redis数据持久化volumes:redis-data:# 内部网络 Server和Redis通过服务名互相访问networks:mcp-network:driver:bridge还需要一个环境变量文件。# .env # 敏感配置放在这里 不要提交到代码仓库 # 加到.gitignore里 MCP_API_TOKENyour-secret-token-here最后是nginx反向代理配置用于加TLS和鉴权。# nginx.conf # 反向代理配置 加TLS终止和Token鉴权 server { listen 443 ssl; server_name mcp.example.com; # TLS证书配置 ssl_certificate /etc/nginx/ssl/cert.pem; ssl_certificate_key /etc/nginx/ssl/key.pem; # MCP Server代理 location /mcp { # Token鉴权 检查Authorization头 # 不带正确Token的请求直接返回401 if ($http_authorization ! Bearer your-secret-token-here) { return 401; } proxy_pass http://mcp-server:8000; proxy_http_version 1.1; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; # SSE流式响应需要关闭缓冲 proxy_buffering off; proxy_cache off; # 长连接超时设长一点 proxy_read_timeout 300s; } # 健康检查端点 不需要鉴权 location /health { proxy_pass http://mcp-server:8000/mcp; access_log off; } }云平台部署容器化之后上云就简单了。我对比过AWS和Azure两种方案。AWS方案用ECSElastic Container Service跑Fargate。把Docker镜像推到ECRElastic Container RegistryECS任务定义里指定镜像和资源配额Fargate自动分配计算资源。前面挂ALBApplication Load Balancer做流量分发和TLS终止。优点是Fargate无需管理服务器按实际运行时间计费。缺点是配置项多初次上手学习曲线陡。Azure方案用Container Apps。把镜像推到ACRAzure Container RegistryContainer Apps直接部署自动扩缩容。它底层基于Kubernetes但屏蔽了复杂性配置比ECS简单。前面挂Azure Front Door做全局负载均衡和TLS。优点是配置简单和Azure生态集成好。缺点是社区资料比AWS少。两个平台的共同点是只要你的Docker镜像能正常跑部署过程就是推镜像加配几行参数。这就是容器化的价值一次构建到处部署。部署后的监控我用Prometheus加Grafana。MCP Server暴露一个/metrics端点输出Prometheus格式的指标包括请求数、延迟分布、错误率。Grafana配一个dashboard实时展示。告警规则设两条一条是错误率超过5%触发一条是P99延迟超过1秒触发。效果验证本地部署验证流程如下。第一步构建并启动。执行docker-compose up --build -dcompose会自动构建镜像、创建网络、启动Server和Redis两个容器。第二步检查容器状态。执行docker-compose ps两个容器的State都应该显示为Up (healthy)。如果显示unhealthy用docker-compose logs mcp-server查看日志排查问题。第三步测试连通性。用curl发一个MCP初始化请求。curl-XPOST http://localhost:8000/mcp\-HContent-Type: application/json\-d{jsonrpc:2.0,id:1,method:initialize,params:{protocolVersion:2025-06-18,capabilities:{},clientInfo:{name:test,version:1.0}}}正常情况下Server返回初始化响应包含协议版本和Server信息。第四步测试工具调用。先调tools/list获取工具列表再调tools/call执行echo工具验证端到端链路通畅。常见问题与避坑坑一容器里Server监听了127.0.0.1导致外部访问不了。这是最高频的坑。FastMCP默认host可能是localhost容器内localhost只绑定了loopback接口外部无法访问。解决办法是显式设置host0.0.0.0绑定所有网卡接口。我在环境变量里把MCP_HOST默认设为0.0.0.0就是为了避免这个问题。坑二Dockerfile里COPY顺序不对导致缓存失效。如果你先COPY代码再pip install每次改一行代码依赖就得重装一遍。正确顺序是先COPY requirements.txt再pip install最后COPY代码。这样只要依赖清单没变依赖安装层就命中缓存构建飞快。坑三SSE流式响应被nginx缓冲导致客户端收不到数据。nginx默认开启proxy_buffering会把响应攒一批再发给客户端。MCP的SSE流式响应需要实时推送被缓冲后客户端一直等到超时。解决办法是在nginx的location块里加proxy_buffering off和proxy_cache off上面配置里已经加了。坑四健康检查端点设计不当。我一开始用MCP的initialize请求做健康检查但这个请求需要完整的JSON-RPC格式太重了。后来我加了一个轻量的HTTP GET端点专门做健康检查返回200就行不涉及MCP协议逻辑。注意Docker的HEALTHCHECK和负载均衡器的健康检查要区分开前者检查容器是否存活后者检查服务是否可接流量。坑五没设置资源限制导致OOM。有次我的Server因为一个死循环把内存吃到4G把整台机器拖垮了。docker-compose里加deploy.resources.limits限制内存和CPU超了会被杀掉重启不至于影响其他服务。Kubernetes环境同理一定要配requests和limits。小结MCP Server从本地开发到生产部署核心就三步。写好支持Streamable HTTP的Server代码打Docker镜像用compose或云平台编排运行。Dockerfile用多阶段构建保持镜像精简依赖和代码分层拷贝利用缓存加速。compose把Server和辅助服务Redis等编排在一起配合健康检查和重启策略实现自愈。云平台部署本质就是推镜像加配参数AWS用ECS加FargateAzure用Container Apps按团队熟悉度选。上线后别忘了加监控和告警。请求量、延迟、错误率这三个指标盯住出了问题第一时间能发现。容器化加自动化部署的组合让MCP Server的运维成本降到最低你只需要专注写好工具逻辑。相关推荐测试与调试MCP Inspector、单元测试、集成测试传输层详解stdio vs SSE vs Streamable HTTP版本管理协议版本协商与向后兼容 
长河君 · 2026/8/14 16:13:28 · 阅读 1.2k 部署上线：Docker容器化与云端部署
摘要MCP Server Docker容器化部署教程涵盖Dockerfile编写、多阶段构建、环境变量注入、健康检查和云端部署AWS/Aliyun附docker-compose完整配置。MCP部署上线 Docker容器化与云端部署我第一次部署MCP Server到服务器是直接SSH上去python server.py跑的。第二天服务器重启了Server没了用户找过来说工具用不了。后来我又改成nohup后台跑结果日志文件越来越大把磁盘撑满了。折腾了三轮我才意识到这种裸跑方式根本没法维护。这篇讲我用Docker容器化部署MCP Server的完整方案从Dockerfile到docker-compose到云端上线一条龙。Dockerfile编写 MCP Server容器化容器化的核心好处是环境一致性和可复现。开发机上能跑的容器里也能跑不用再担心在我机器上是好的这种问题。写MCP Server的Dockerfile有几个要点。第一是选择基础镜像。Python应用我用python:3.12-slim比完整版镜像小很多又有足够的基础工具。别用alpine编译Python依赖时各种缺库会让人崩溃。第二是多阶段构建。第一阶段安装依赖第二阶段拷贝依赖和代码到精简镜像里。这样最终镜像不带编译工具体积小且更安全。第三是注意MCP的Streamable HTTP传输模式。stdio模式只能在本地用部署到网络必须用Streamable HTTP。FastMCP支持通过mcp.run(transportstreamable-http)启动HTTP服务默认监听8000端口。第四是健康检查。Docker的HEALTHCHECK指令配合一个健康检查端点让容器编排系统能自动感知Server是否存活。Streamable HTTP部署2025年3月26日MCP协议引入Streamable HTTP替代原来的HTTPSSE。新方案有几个关键变化。移除了单独的/sse端点所有通信统一走/mcp端点。服务器可以选择无状态模式不需要维持长连接。客户端发POST请求服务器可以选择返回普通HTTP响应或升级为SSE流式响应。这对部署的影响很大。无状态模式意味着Server可以水平扩展前面挂负载均衡器就行不用考虑会话粘性。而且纯HTTP实现可以和现有的中间件、API网关、CDN等基础设施良好兼容。部署时有个安全要点。Streamable HTTP默认不带认证任何人拿到地址就能连。必须在Server代码里加token校验或者用反向代理比如nginx在入口层做鉴权。docker-compose编排单容器部署用docker run就够了但生产环境通常要搭配Redis、数据库等辅助服务。docker-compose把这些服务定义在一个文件里一条命令全部启动。我的compose编排包含三个服务。MCP Server本体Redis做缓存还有一个健康检查的辅助容器。服务之间通过内部网络通信只有MCP Server的端口对外暴露。compose还定义了健康检查、重启策略、资源限制、日志配置。重启策略设为unless-stopped容器崩溃自动重启但手动停止不会自动拉起。资源限制防止某个容器吃光内存导致整台机器挂掉。完整代码下面是完整的部署配置包含Server代码、Dockerfile、docker-compose和健康检查。先是要部署的MCP Server支持Streamable HTTP。# app/server.py# 支持Streamable HTTP的MCP Server# 依赖 mcp redis uvicornimportosimporttimeimportjsonfrommcp.server.fastmcpimportFastMCP# 从环境变量读取配置 容器化部署的标准做法HOSTos.environ.get(MCP_HOST,0.0.0.0)PORTint(os.environ.get(MCP_PORT,8000))API_TOKENos.environ.get(MCP_API_TOKEN,)mcpFastMCP(deploy-demo-server)mcp.tool()defhealth_check()-str:健康检查工具 返回服务器状态信息returnjson.dumps({status:healthy,timestamp:time.time(),server:deploy-demo-server,version:1.0.0,},ensure_asciiFalse)mcp.tool()defecho(message:str)-str:回显工具 用于测试连通性returnf收到消息{message}服务器时间{time.strftime(%H:%M:%S)}mcp.tool()defget_config()-str:返回当前服务器配置 脱敏后展示returnjson.dumps({host:HOST,port:PORT,transport:streamable-http,has_auth:bool(API_TOKEN),},ensure_asciiFalse)if__name____main__:# 以Streamable HTTP模式启动# 这是2025-03-26之后的推荐传输方式mcp.run(transportstreamable-http,hostHOST,portPORT)接下来是依赖清单。# app/requirements.txt # Python依赖清单 固定版本保证可复现 mcp1.0.0 redis5.0.0 uvicorn0.30.0 pydantic2.0.0然后是Dockerfile。# Dockerfile # 多阶段构建 先装依赖再拷代码 最终镜像精简 # # 第一阶段 构建阶段 安装依赖 # FROM python:3.12-slim AS builder # 设置工作目录 WORKDIR /build # 先只拷贝依赖清单 利用Docker缓存层加速构建 # 只要requirements.txt没变 这一层就命中缓存不会重新安装 COPY app/requirements.txt . # 安装依赖到指定目录 方便第二阶段拷贝 RUN pip install --no-cache-dir --prefix/install -r requirements.txt # # 第二阶段 运行阶段 精简最终镜像 # FROM python:3.12-slim # 设置工作目录 WORKDIR /app # 从构建阶段拷贝已安装的Python依赖 COPY --frombuilder /install /usr/local # 拷贝应用代码 COPY app/ . # 设置环境变量 默认值可通过docker-compose覆盖 ENV MCP_HOST0.0.0.0 ENV MCP_PORT8000 ENV MCP_API_TOKEN # 暴露MCP Server监听端口 EXPOSE 8000 # 健康检查 每30秒检测一次 连续3次失败标记为unhealthy # 超时5秒内没响应算失败 HEALTHCHECK --interval30s --timeout5s --retries3 \ CMD python -c import urllib.request; urllib.request.urlopen(http://localhost:8000/mcp, timeout3) || exit 1 # 启动命令 CMD [python, server.py]然后是docker-compose配置。# docker-compose.yml# 多服务编排 包含MCP Server和Redisversion:3.9services:# MCP Server主服务mcp-server:build:context:.dockerfile:Dockerfilecontainer_name:mcp-serverports:# 主机8000端口映射到容器8000端口-8000:8000environment:-MCP_HOST0.0.0.0-MCP_PORT8000# 从.env文件读取敏感配置-MCP_API_TOKEN${MCP_API_TOKEN}-REDIS_URLredis://redis:6379/0depends_on:# 等Redis启动后再启动Serverredis:condition:service_healthyrestart:unless-stopped# 资源限制 防止单容器吃光主机资源deploy:resources:limits:memory:512Mcpus:1.0# 日志配置 防止日志文件无限增长logging:driver:json-fileoptions:max-size:10mmax-file:3networks:-mcp-network# Redis缓存服务redis:image:redis:7-alpinecontainer_name:mcp-redis# Redis自带健康检查healthcheck:test:[CMD,redis-cli,ping]interval:10stimeout:3sretries:3restart:unless-stopped# Redis数据持久化 卷映射volumes:-redis-data:/datanetworks:-mcp-network# 命名卷 用于Redis数据持久化volumes:redis-data:# 内部网络 Server和Redis通过服务名互相访问networks:mcp-network:driver:bridge还需要一个环境变量文件。# .env # 敏感配置放在这里 不要提交到代码仓库 # 加到.gitignore里 MCP_API_TOKENyour-secret-token-here最后是nginx反向代理配置用于加TLS和鉴权。# nginx.conf # 反向代理配置 加TLS终止和Token鉴权 server { listen 443 ssl; server_name mcp.example.com; # TLS证书配置 ssl_certificate /etc/nginx/ssl/cert.pem; ssl_certificate_key /etc/nginx/ssl/key.pem; # MCP Server代理 location /mcp { # Token鉴权 检查Authorization头 # 不带正确Token的请求直接返回401 if ($http_authorization ! Bearer your-secret-token-here) { return 401; } proxy_pass http://mcp-server:8000; proxy_http_version 1.1; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; # SSE流式响应需要关闭缓冲 proxy_buffering off; proxy_cache off; # 长连接超时设长一点 proxy_read_timeout 300s; } # 健康检查端点 不需要鉴权 location /health { proxy_pass http://mcp-server:8000/mcp; access_log off; } }云平台部署容器化之后上云就简单了。我对比过AWS和Azure两种方案。AWS方案用ECSElastic Container Service跑Fargate。把Docker镜像推到ECRElastic Container RegistryECS任务定义里指定镜像和资源配额Fargate自动分配计算资源。前面挂ALBApplication Load Balancer做流量分发和TLS终止。优点是Fargate无需管理服务器按实际运行时间计费。缺点是配置项多初次上手学习曲线陡。Azure方案用Container Apps。把镜像推到ACRAzure Container RegistryContainer Apps直接部署自动扩缩容。它底层基于Kubernetes但屏蔽了复杂性配置比ECS简单。前面挂Azure Front Door做全局负载均衡和TLS。优点是配置简单和Azure生态集成好。缺点是社区资料比AWS少。两个平台的共同点是只要你的Docker镜像能正常跑部署过程就是推镜像加配几行参数。这就是容器化的价值一次构建到处部署。部署后的监控我用Prometheus加Grafana。MCP Server暴露一个/metrics端点输出Prometheus格式的指标包括请求数、延迟分布、错误率。Grafana配一个dashboard实时展示。告警规则设两条一条是错误率超过5%触发一条是P99延迟超过1秒触发。效果验证本地部署验证流程如下。第一步构建并启动。执行docker-compose up --build -dcompose会自动构建镜像、创建网络、启动Server和Redis两个容器。第二步检查容器状态。执行docker-compose ps两个容器的State都应该显示为Up (healthy)。如果显示unhealthy用docker-compose logs mcp-server查看日志排查问题。第三步测试连通性。用curl发一个MCP初始化请求。curl-XPOST http://localhost:8000/mcp\-HContent-Type: application/json\-d{jsonrpc:2.0,id:1,method:initialize,params:{protocolVersion:2025-06-18,capabilities:{},clientInfo:{name:test,version:1.0}}}正常情况下Server返回初始化响应包含协议版本和Server信息。第四步测试工具调用。先调tools/list获取工具列表再调tools/call执行echo工具验证端到端链路通畅。常见问题与避坑坑一容器里Server监听了127.0.0.1导致外部访问不了。这是最高频的坑。FastMCP默认host可能是localhost容器内localhost只绑定了loopback接口外部无法访问。解决办法是显式设置host0.0.0.0绑定所有网卡接口。我在环境变量里把MCP_HOST默认设为0.0.0.0就是为了避免这个问题。坑二Dockerfile里COPY顺序不对导致缓存失效。如果你先COPY代码再pip install每次改一行代码依赖就得重装一遍。正确顺序是先COPY requirements.txt再pip install最后COPY代码。这样只要依赖清单没变依赖安装层就命中缓存构建飞快。坑三SSE流式响应被nginx缓冲导致客户端收不到数据。nginx默认开启proxy_buffering会把响应攒一批再发给客户端。MCP的SSE流式响应需要实时推送被缓冲后客户端一直等到超时。解决办法是在nginx的location块里加proxy_buffering off和proxy_cache off上面配置里已经加了。坑四健康检查端点设计不当。我一开始用MCP的initialize请求做健康检查但这个请求需要完整的JSON-RPC格式太重了。后来我加了一个轻量的HTTP GET端点专门做健康检查返回200就行不涉及MCP协议逻辑。注意Docker的HEALTHCHECK和负载均衡器的健康检查要区分开前者检查容器是否存活后者检查服务是否可接流量。坑五没设置资源限制导致OOM。有次我的Server因为一个死循环把内存吃到4G把整台机器拖垮了。docker-compose里加deploy.resources.limits限制内存和CPU超了会被杀掉重启不至于影响其他服务。Kubernetes环境同理一定要配requests和limits。小结MCP Server从本地开发到生产部署核心就三步。写好支持Streamable HTTP的Server代码打Docker镜像用compose或云平台编排运行。Dockerfile用多阶段构建保持镜像精简依赖和代码分层拷贝利用缓存加速。compose把Server和辅助服务Redis等编排在一起配合健康检查和重启策略实现自愈。云平台部署本质就是推镜像加配参数AWS用ECS加FargateAzure用Container Apps按团队熟悉度选。上线后别忘了加监控和告警。请求量、延迟、错误率这三个指标盯住出了问题第一时间能发现。容器化加自动化部署的组合让MCP Server的运维成本降到最低你只需要专注写好工具逻辑。相关推荐测试与调试MCP Inspector、单元测试、集成测试传输层详解stdio vs SSE vs Streamable HTTP版本管理协议版本协商与向后兼容