1. 为什么我决定把 MCP 工具从本地搬到云端1.1 MCP 到底是什么协议很多人第一次接触 MCP 时都会纠结一个问题它到底是软件协议还是硬件协议这里直接给答案——MCPModel Context Protocol是纯软件协议和 USB、HDMI 这类硬件接口协议完全不沾边。它定义的是 AI 模型比如 Claude、GPT、本地大模型如何以标准化的方式去调用外部工具、读取数据源、执行动作。你可以把 MCP 理解成“AI 世界的 USB-C 接口”以前想让 AI 调用某个工具基本得为每个模型、每个工具单独写适配代码换一个组合就得重来一遍。MCP 出现之后工具方只需要实现一个 MCP Server模型方通过 MCP Client 去连接双方按一套统一的消息格式JSON-RPC通信适配成本大幅下降。所以当你看到 Playwright MCP、Chrome DevTools MCP、同花顺 MCP、Unity MCP 这些名词时它们本质上都是在做同一件事把某个具体能力封装成一个符合 MCP 协议的服务器让 AI 能够通过协议去调用。我的项目里也踩过类似的需求——团队需要一个汇率查询工具给 AI 助手用最开始我写了个本地脚本AI 问汇率我就手动跑一下后来发现这根本不是长久之计。1.2 本地 MCP 服务器的三个硬伤第一次我把 MCP Server 跑在开发机上当时觉得“能跑就行”结果真实用起来很快就发现问题了。第一只能本机访问。MCP Server 默认监听 localhostAI 客户端在同一台机器上才能连上。可实际场景里AI 客户端可能在用户的电脑上、在云端的工作流引擎里、甚至在手机端跨设备访问完全走不通。第二无法 7x24 小时稳定在线。开发机一合盖、一休眠、一断网服务就没了。可 AI 工具调用往往是随时发生的你凌晨三点被一条“工具不可用”的报错叫醒就知道有多痛苦。第三没法和其他云端应用协同。真实的业务链路里MCP 工具往往要跟数据库、定时任务、消息队列配合。本地服务器在内网云端应用根本访问不到更别提交互了。这三个硬伤叠加结论就非常明确MCP 工具要真正投入使用必须发布到云服务器上。1.3 这篇文章能帮你解决什么这篇文章不是讲 MCP 协议的理论知识而是完整的实战发布全流程。我会以一个“实时汇率查询工具”为例从本地编写 MCP Server 开始一步步讲清楚如何发布到云端并提供两条主流路径的完整操作步骤路径一使用 Railway 这类 PaaS 平台快速发布适合个人项目、原型验证路径二使用阿里云、华为云这类传统云服务器ECS手动部署适合生产环境、企业级应用。除了发布本身还会覆盖 Token 认证、跨域配置、线上调试、进程守护、NTP 时间同步这些发布之后绕不开的运维细节。全文所有步骤都是我实际验证过的直接照做就能跑通。2. 先写一个能跑的 MCP Server用 Python 做一个汇率查询工具2.1 工具选型为什么用 fastmcp 而不是官方 SDK写 MCP Server 主流的 Python 方案有两个官方mcpSDK 和fastmcp库。两者我都用过大部分场景我更推荐 fastmcp。对比项官方 mcp SDKfastmcp代码量需要手写较多样板代码装饰器即可注册工具代码量少启动方式需要手动处理 transport内置 run() 直接启动对新手友好度中等很高功能完整性完整支持协议覆盖常用功能足够用维护活跃度官方维护社区维护更新频繁FastMCP 的核心优势在于它把“注册工具、处理请求、启动服务”这几件事压缩到了几行代码里让你能把精力放在工具本身的业务逻辑上。对于发布到云服务器这个场景fastmcp 写出来的服务可以同时支持 HTTP、SSE、stdio 多种传输方式部署时选择很灵活。2.2 核心代码实现先搭一个项目目录mkdir mcp-exchange-tool cd mcp-exchange-tool python3 -m venv .venv source .venv/bin/activate pip install fastmcp httpx这里加httpx是为了发 HTTP 请求取实时汇率数据。选 httpx 而不是 requests是因为它的异步支持更好未来如果 MCP Server 要做并发请求处理httpx 可以直接切 async 模式不用换库。然后写核心文件server.pyfrom fastmcp import FastMCP import httpx mcp FastMCP(exchange-tool) mcp.tool() def get_exchange_rate(base: str, target: str CNY) - str: 获取实时汇率。base 是基础货币代码target 是目标货币代码例如 baseUSD, targetCNY。 url fhttps://api.exchangerate-api.com/v4/latest/{base.upper()} try: data httpx.get(url, timeout10).json() rate data[rates][target.upper()] return f1 {base.upper()} {rate:.4f} {target.upper()} except Exception as e: return f查询失败: {str(e)} if __name__ __main__: mcp.run()这段代码的核心在于mcp.tool()装饰器。它会把函数注册成 MCP 工具函数名、参数名、docstring 都会被自动映射为工具的元数据。AI 客户端在调用时会根据这些元数据来决定传什么参数。这也是为什么我强调docstring 一定要写清楚每个参数的含义和示例——模型真的会读它。2.3 本地验证MCP Inspector 的完整用法代码写完后先用 MCP Inspector 做本地验证。它相当于 MCP 的“调试器”可以可视化地看到工具列表、调用参数和返回结果。pip install mcp # 安装官方 SDK 只是为了拿到 inspector 命令 mcp dev server.py命令执行后浏览器访问http://localhost:6274打开 Inspector 界面。重点做两个操作第一查看 Tools 列表。正常情况能看到get_exchange_rate这个工具并且参数说明base、target应该完整。如果列表为空说明mcp.tool()装饰器没生效最常见的坑是函数上面忘了加装饰器或者函数被定义在了 if 语句块内。第二直接调用工具试一次。填 baseUSD、targetCNY点调用。如果返回值正常本地开发阶段就完成了。这一步千万别跳过。我见过太多人写了几百行代码直接上生产结果本地根本就没跑通过线上排查环境又比本地复杂得多白白折腾半天。3. 云平台选型Railway 一键部署与传统 ECS 手动部署的真实对比3.1 Railway最快发布路径及其问题Railway 是一个 PaaS 平台支持直接从 GitHub 仓库构建部署最大卖点是“省心”。你只需要把代码推到 GitHubRailway 检测到 Python 项目后会自动选择构建策略、安装依赖、启动服务最后分配一个 HTTPS 域名比如https://xxx.up.railway.app。我实际体验下来Railway 对 MCP Server 这种小型无状态服务非常友好。免费额度内可以跑一个小型服务部署速度也很快非常适合发布个人工具、做原型验证或者临时演示。但它有几个问题需要正视免费额度不是无限的超出后按量计费如果被恶意刷调用很容易烧钱国内访问延迟偏高跨地域调用时体验略差平台对“长时间空闲”的服务可能会自动休眠冷启动需要几秒钟。3.2 阿里云、华为云 ECS可控性最强但步骤多传统云服务器ECS适合生产环境。以阿里云和华为云为例你得到一台完整的 Linux 虚拟机有独立公网 IP可以自由安装 Nginx、自建防火墙规则、做 systemd 守护进程并且可以实现非常精细的访问控制。代价是学习成本和运维成本更高要自己处理安全组规则、操作系统初始化、依赖安装、进程守护、HTTPS 证书等一连串事情。如果对 Linux 操作不熟一开始确实会有些折腾但一旦跑通这套体系是最稳定可控的。3.3 免费资源怎么用阿里云有免费试用活动新用户可以在一定时间内免费使用一台低配 ECS适合熟悉手动部署流程。华为云同样提供免费试用额度注册后可以领取一台入门级云服务器对于练手来说完全够用。Railway 注册后也有免费额度够跑一个小型 MCP 服务一段时间。需要提醒的是尽量选择这些主流平台的正规免费试用不要碰来路不明的“免费云服务器”。那些资源往往不稳定而且安全风险很高拿来做对外服务是给自己找麻烦。3.4 端口、域名、HTTPS 这些基建提前准备无论走哪条部署路径有三个东西要提前想清楚第一是端口。MCP 基于 HTTP 传输通常跑在 8000、8080 这类自定义端口。如果用的是传统云服务器需要在云平台的安全组和服务器本地防火墙里同时放行对应端口漏掉任何一个都会导致外部无法访问。第二是域名。没有域名也能用 IP 加端口号直连但这意味着不容易配置 HTTPS而且维护麻烦。有条件就准备一个域名手动部署时用 Nginx 做反向代理配合 HTTPS 证书安全性和规范性都会好很多。第三是 HTTPS。MCP 客户端在远程环境中对 HTTP 明文请求的容忍度越来越低很多场景强制要求 HTTPS。Railway 这类平台天生带 HTTPS 域名传统 ECS 则需要自己申请证书并配置这部分在后面的手动部署章节会详细写。4. 在 Railway 发布 MCP 服务的分步实战4.1 把代码推送到 GitHub 仓库Railway 部署的前提是代码在 GitHub 上。先把项目推上去git init git add server.py git add requirements.txt git commit -m 初始提交汇率查询 MCP Server git branch -M main git remote add origin gitgithub.com:你的用户名/mcp-exchange-tool.git git push -u origin main注意requirements.txt必须存在Railway 是根据这个文件来识别 Python 项目并安装依赖的。内容就是fastmcp httpx uvicorn4.2 Railway 创建项目与配置环境变量登录 Railway点击 New Project选择 Deploy from GitHub repo找到刚才推送的仓库点 Deploy。Railway 会自动执行类似下面的逻辑识别到requirements.txt创建虚拟环境安装依赖然后尝试启动服务。这里最关键的配置是启动命令。在项目设置里找到 Commands把启动命令设置为uvicorn server:mcp.app --host 0.0.0.0 --port $PORT注意这里有个坑Railway 会注入一个 PORT 环境变量应用必须监听这个端口而不是自己固定写死 8000。上面命令里的$PORT就是为此服务的。另外mcp.run()内部本质上是在运行uvicorn加载一个 mcp 应用对象但更可靠的写法是直接让 uvicorn 加载 fastmcp 暴露出来的 ASGI 应用。如果启动报错找不到mcp.app在server.py里加一行app mcp.app然后启动命令改为uvicorn server:app --host 0.0.0.0 --port $PORT4.3 日志查看与发布失败的排错思路部署完成后点击项目进入 Deployments再点 View Logs 查看运行日志。常见的发布失败情况有三种第一种是“ModuleNotFoundError”通常是因为requirements.txt里漏写了某个依赖。先把本地.venv里pip freeze的结果和 requirements.txt 对比一下确保一致。第二种是“Port binding”类错误常见原因是启动命令里写死了端口没有用 Railway 注入的$PORT。第三种是“连接被拒绝”这种情况通常是服务还没就绪或者启动后进程崩溃退出。日志里如果有 traceback直接定位代码问题。我个人的建议是第一次部署时先用一个极简的 hello 工具版本确认整条链路通了之后再加完整业务逻辑。这样可以避免把“部署问题”和“业务代码问题”混在一起排查。5. 传统云服务器阿里云/华为云 ECS手动发布全流程5.1 初始化服务器Python 3.9 环境安装与踩坑手动部署比 PaaS 繁琐但可控性完全不同。先说服务器初始化。以 Ubuntu 22.04 系统为例ssh root你的服务器IP apt update apt upgrade -yUbuntu 22.04 自带 Python 3.10对 fastmcp 来说足够了。但如果你因为某些依赖兼容性必须使用 Python 3.9不要直接去改系统默认 Python正确做法是安装 pyenvapt install -y make build-essential libssl-dev zlib1g-dev \ libbz2-dev libreadline-dev libsqlite3-dev libffi-dev liblzma-dev curl -L https://github.com/pyenv/pyenv-installer/raw/master/bin/pyenv-installer | bash pyenv install 3.9.18或者更省事的方案用 Dockerpython:3.9-slim镜像。不过第一次手动部署时我建议先直接用系统自带 Python把流程跑通再考虑版本管理的事情。目标是从零开始发布成功而不是一上来就挑战最复杂的配置。还有一个高频坑云服务器是刚买的安全组默认只开放了 22 端口SSH。所以要在云平台控制台的安全组规则里把 8000或你计划用的端口加进去授权对象建议只填你的办公网络 IP不要写0.0.0.0/0。5.2 部署代码Git venv uvicorn 跑通在服务器上执行cd /opt git clone gitgithub.com:你的用户名/mcp-exchange-tool.git cd mcp-exchange-tool python3 -m venv .venv source .venv/bin/activate pip install -r requirements.txt然后先手动跑一次服务uvicorn server:app --host 0.0.0.0 --port 8000看到Application startup complete后在本地电脑上用 curl 验证curl -X POST http://服务器IP:8000/mcp \ -H Content-Type: application/json \ -d {jsonrpc:2.0,id:1,method:tools/list,params:{}}如果返回 JSON-RPC 响应且 tools 列表中有汇率查询工具说明服务正常。5.3 systemd 守护进程服务器重启不用管手动启动的服务在断开 SSH 后就会终止必须用 systemd 做成守护进程。创建服务文件vim /etc/systemd/system/mcp-exchange.service内容如下[Unit] DescriptionMCP Exchange Tool Afternetwork.target [Service] Userroot WorkingDirectory/opt/mcp-exchange-tool ExecStart/opt/mcp-exchange-tool/.venv/bin/uvicorn server:app --host 0.0.0.0 --port 8000 Restartalways RestartSec3 [Install] WantedBymulti-user.target注意ExecStart必须写绝对路径指向 venv 里的 uvicorn而不是直接写uvicorn。因为 systemd 服务环境里 PATH 往往不包含虚拟环境目录。启用并启动systemctl daemon-reload systemctl enable --now mcp-exchange systemctl status mcp-exchange从此以后哪怕服务器重启、进程崩溃systemd 都会自动把服务拉起来。5.4 Nginx 反向代理与 HTTPS 证书申请直接用 IP 加端口访问虽然能用但生产环境不推荐原因是没有 TLS 加密、端口暴露明显、也不方便后续加域名和访问控制。这里用 Nginx 做反向代理。安装 Nginxapt install -y nginx创建站点配置vim /etc/nginx/sites-available/mcp-exchangeserver { listen 80; server_name mcp.yourdomain.com; location /mcp/ { proxy_pass http://127.0.0.1:8000/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }启用站点重载 Nginxln -s /etc/nginx/sites-available/mcp-exchange /etc/nginx/sites-enabled/ nginx -t systemctl reload nginxHTTPS 证书用 Lets Encrypt通过 certbot 自动签发apt install -y certbot python3-certbot-nginx certbot --nginx -d mcp.yourdomain.com证书签发完成后Nginx 会自动把 80 端口重定向到 443。这时生成的 HTTPS 地址https://mcp.yourdomain.com/mcp就是你的 MCP Server 对外访问地址。6. 发布后的访问安全Token 认证和跨域配置6.1 裸奔的 MCP 端点有多危险很多人以为 MCP Server 和普通 API 不一样不需要鉴权。这是大错特错。MCP 工具的本质是“让 AI 能调用你写的函数”一旦服务公网可达且没有任何认证任何人都可以枚举你的工具列表并调用所有工具。试想一下如果你的 MCP 工具里有“查询数据库”或“发送通知”这类能力公网裸奔就相当于把数据库查询接口和发信接口免费对外开放。就算退一步哪怕你的工具只是查个汇率也可能被恶意脚本刷大量请求直接消耗你的服务器带宽和第三方 API 调用配额。6.2 给 MCP Server 加 Bearer TokenFastMCP 当前版本没有内置的 Token 拦截机制我在实际项目里最常用也最简单的方式是在 Nginx 层拦截。在站点配置里加一段判断逻辑location /mcp/ { if ($http_authorization !~* ^Bearer your-secret-token-here) { return 401; } proxy_pass http://127.0.0.1:8000/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; }这段配置生效后所有不带正确Authorization: Bearer token头的请求都会直接被 401 拒绝根本到不了 MCP Server 本身。更好的方案是升级到 Lua 防火墙或部署 API 网关但绝大多数项目用 Nginx 这层就足够了。使用 Railway 时没有 Nginx 可配置我会在应用代码里包一层简单的中间件做 Token 校验或者改用平台自带的访问控制能力。6.3 客户端里配置 Token 的格式发布完成后AI 客户端连接远程 MCP 时需要在配置里带上 Token。以 Claude Desktop / Cursor 这类支持远程 MCP 的客户端为例配置文件的格式类似这样{ mcpServers: { exchange-tool: { command: npx, args: [-y, mcp-remote, https://mcp.yourdomain.com/mcp], env: { MCP_REMOTE_AUTH_TOKEN: your-secret-token } } } }mcp-remote 工具的作用是把远程 MCP Server 桥接成 stdio 模式让本地客户端可以通过标准输入输出与远程服务交互。它能自动附加环境变量里的 Token实现认证。7. 线上验证与客户端接入MCP Inspector 实测7.1 用 MCP Inspector 连接线上地址发布完成后第一件事就是用 MCP Inspector 对线上地址做验证而不是直接去配客户端。这样可以最快地区分问题是出在网络、认证还是协议层。npx modelcontextprotocol/inspector打开 Inspector 后Transport Type 选择 HTTPURL 填https://mcp.yourdomain.com/mcpHeaders 里加上Authorization: Bearer your-secret-token然后点击 Connect。如果连接成功左侧会出现 Tools 列表。如果 401说明 Token 不对如果超时可能是网络或防火墙问题如果连接成功但没有工具把注意力放回代码层。7.2 在桌面客户端和 IDE 里挂载远程 MCP线上验证通过后就可以把远程 MCP 接入实际使用的 AI 客户端了。Cursor 这类 IDE 内置的 MCP 配置入口可以直接添加远程服务填入 URL 和认证信息。配置完成后在对话中问一句“USD 对 CNY 的汇率是多少”如果工具正常被调用就能看到工具执行的中间过程。接入过程如果遇到客户端反复提示“工具不可用”先回 Inspector 重新确认线上地址可访问再看客户端配置里的 URL 路径是否和实际发布路径完全一致。常见的错误是把https://mcp.yourdomain.com/mcp写成了https://mcp.yourdomain.com路径对不上自然连不上。7.3 高频故障排查401、超时、CORS、无响应下面这张表是我发布 MCP 服务后遇到频率最高的几类问题症状可能原因排查方向401 UnauthorizedToken 错误、请求头格式不对检查 Authorization 头是否以 Bearer 开头请求超时安全组未放行端口服务器负载过高用 curl 直连 IP 排除网络问题CORS 报错服务端未允许客户端来源在应用代码或 Nginx 层添加 Access-Control-Allow-Origin连接成功但工具列表为空工具注册失败、代码部署版本过旧回到本地 Inspector 验证返回 invalid requestJSON-RPC 格式不符合规范检查请求方法名是否正确如 tools/list其中 CORS 问题最隐蔽。很多客户端是从本地页面发起请求的跨域被浏览器拦截后表现各异。解决方式是在 FastMCP 初始化的地方设置允许来源或者更简单地在 Nginx 代理后加响应头add_header Access-Control-Allow-Origin * always; add_header Access-Control-Allow-Headers Authorization, Content-Type;这里Allow-Origin设置为*是测试用的宽松写法生产环境建议收敛为具体客户端域名。8. 生产环境运维进程守护、日志、NTP 时间同步千万别忽略8.1 服务异常重启与日志检查服务发布之后运维层面的配置决定你后续是“安逸”还是“天天救火”。第一节已经配置了 systemd 的Restartalways这保证了进程崩溃后能在几秒内自动拉起。但还有一个细节如果进程总是在启动后立刻崩溃systemd 会进入 restart loop。查看失败次数用systemctl status mcp-exchange日志方面systemd 的 journal 就是最简单的日志系统journalctl -u mcp-exchange -f-f参数是持续滚动查看最新日志。排查线上问题时先看这里的 traceback 和错误输出比在代码里瞎猜快得多。我还会挂一个最简单的健康检查定时任务每五分钟探测一次服务是否响应*/5 * * * * curl -fsS http://127.0.0.1:8000/health /dev/null || systemctl restart mcp-exchange注意这个健康检查地址需要在应用里先实现返回 200 就代表运行正常。如果连续探测失败任务会自动重启服务。8.2 NTP 时间同步Token 和 HTTPS 全看它这是最容易忽略的一个坑。云服务器漂移的时间会影响三件事HTTPS 证书校验、JWT 类 Token 的签发和验证、客户端与服务端之间的时间敏感逻辑。举例来说你的 MCP 服务使用了带过期时间的 Token服务端系统时间慢了半分钟可能刚签发的 Token 就被判定为过期。HTTPS 证书也有有效期概念系统时间偏差过大时证书链校验会直接失败。以华为云服务器为例标准做法是把时间同步源指向华为云 NTP 服务器apt install -y ntpdate ntpdate ntp.myhuaweicloud.com使用阿里云服务器则用ntpdate ntp.aliyun.com但这只是手动同步一次更可靠的是把时间同步做成定时任务apt install -y chrony修改/etc/chrony/chrony.confserver ntp.myhuaweicloud.com iburst重启 chronysystemctl restart chrony systemctl enable chrony配置完成后系统会持续保持时间同步。8.3 迭代更新与无感重启手动部署路径下更新 MCP 工具的流程可以是这样的服务器上拉取最新代码、安装新依赖、重启服务。cd /opt/mcp-exchange-tool git pull origin main source .venv/bin/activate pip install -r requirements.txt systemctl restart mcp-exchange这个流程虽然直接但在客户端正在调用时会打断正在执行的请求。如果想做到真正的无感更新可以借助 Nginx 的 upstream 多节点配置把两个服务实例组成一个小集群重启其中一个时流量自动切到另一个。对于个人项目有点大材小用但如果你服务的使用方是企业客户这一步非常值得投入。如果用的是 Railway 这类 PaaS更新体验就爽快很多每次往 GitHub push 新代码平台自动构建、自动替换旧实例整个过程完全不需要 SSH 操作。对于追求效率的场景PaaS 的自动部署机制真的很省心。9. 最后分享一点个人经验整个流程走下来我最大的体会是MCP Server 的开发和发布难点从来不在协议本身——fastmcp 已经把复杂度降到很低了——真正的分水岭在于你有没有把“网络、认证、进程守护、时间同步”这些生产环境的基础设施想清楚。这里给你一个实用建议第一次部署时先用一个只返回 hello world 的最简工具走通全链路再逐步把真实业务逻辑加上去。这样做能让你在“部署问题”和“业务代码问题”之间划出清晰界线不会在排查问题的时候把两者搅在一起。另外无论文章里的示例代码写得多简单实际项目里请务必在 MCP Server 外层加上 Token 认证和访问日志。MCP 工具一旦公网可访问它就不再只是你的开发机上的一个函数而是真正暴露在互联网上的一个服务节点。安全这块别偷懒。