跑一个 server 的三种方式
本地：server 作为进程跑在和客户端同一台机器上，按需通过 stdio 拉起。这是今天大多数 MCP server 的用法，对单个开发者来说也是最简单的——没有部署，也不向网络暴露任何东西。
自托管远程：你把 server 跑在自己的基础设施上，客户端通过 HTTP 连它。当一个团队需要共享一个 server，或者 server 需要挨着住在你环境里的数据时，这么做才合理。
托管远程：厂商托管这个 server，你连它的端点，通常走 OAuth。你用控制权换「不用运维任何东西」——厂商负责可用性、更新和扩容。
什么时候本地就够了
如果你是一个人、把 server 连到自己的客户端，就跑本地。为一个单用户的问题把 server 部署到共享基础设施上，凭空多了一个攻击面、一份可用性义务和一份维护负担，却没有任何好处。
本地还把凭据留在你自己机器上，而不是放在别人能够到的 server 上——对文件系统或数据库这类 server 来说，这是实打实的安全优势。它的限制仅仅是：本地 server 只对那台机器可用，别人用不了，而且你合上笔记本它就不跑了。
什么时候该自托管一个远程 server
当多个人或多个 agent 需要同一个 server、或者 server 必须跑在某个特定位置时——在你网络内、挨着数据库、按一个独立于任何笔记本的节奏运行——自托管才值得。
它带着任何你对外暴露的服务都有的责任：认证，只让授权客户端能连；传输安全，让流量加密；监控，让你在它坏掉时能察觉。一个前面没有认证的远程 MCP server，对它能做的一切来说就是一扇敞开的门，对一个握着真实凭据的 server 而言是严重风险。我们那篇 MCP 安全红线的指南讲了哪些不能省。
什么时候托管服务合理
当 server 是由它所对接系统的厂商作为产品提供时——某个 SaaS 公司的官方 MCP server、由他们托管——托管服务是对的选择。你得到第一方维护、零运维负担，代价是你的访问要经过他们的基础设施。
要权衡的是信任和数据流向：托管 server 看得到你发给它的请求，所以敏感数据你可能宁愿自托管，哪怕存在托管选项。而对于连接一个你本来就在用的厂商自己的服务，托管通常不增加新的暴露，还省下实打实的功夫。
如果你的客户端只说 stdio 而 server 是远程的，你可能需要一座桥来连接两者——我们那篇讲 mcp-remote 的指南覆盖了这种情况。