如何向客户演示 MCP 服务器

今天分发一个 MCP 服务器是什么样子

大多数 MCP 服务器都以本地进程起步。客户端通过 stdio 启动它们——服务器是一个子进程，在 stdin 和 stdout 上讲 JSON-RPC。Claude Desktop、Cursor 和 Conduit 都是这样。在云的意义上没有什么需要部署。客户端 就是部署本身。

Claude Desktop 已经把自己这一侧简化了很多：打包成 .mcpb 桌面扩展的本地服务器可以在 Settings → Extensions 中一键安装，远程服务器则可以作为自定义连接器添加。手写配置如今是留给未按这种方式 打包的服务器的退路——给出一段用于 claude_desktop_config.json:

{
  "mcpServers": {
    "your-product": {
      "command": "npx",
      "args": ["-y", "@you/mcp-server"]
    }
  }
}

你把它贴进 Slack 会话或一份 PDF。潜在客户要安装 Node，安装 Claude Desktop（macOS、Windows，以及面向 Ubuntu 和 Debian 的 Linux 测试版），在各平台不同的路径下找到配置文件，在不破坏 JSON 的前提下粘贴进去，彻底退出应用——关掉窗口还不够——再重新打开。把服务器打包成扩展能省掉其中大部分步骤，能打包就该打包。但无论走哪条路，剩下的部分都还在：登录 Anthropic，挑一个自己付费的模型，再到别人的应用里从工具列表中找你的服务器。

如果服务器是远程的，做法会变，但格局不变。你发布一个 Streamable HTTP 的 URL——Render、Fly.io、FastMCP Cloud、Smithery，或者一台 VPS——然后对方把它粘贴到 that 一个支持远程 MCP 的客户端里。托管回答的是“另一台机器能否访问这个进程”。它没有回答“一个不懂技术的潜在客户是否有应用、有模型，并且有理由把它打开”。

为什么“把配置发给他们就行”行不通

潜在客户不是开发者

在 Application Support 文件夹里编辑 JSON 文件、安装 npx、以及因为 Windows 需要 npx.cmd 而去调试 ENOENT——对写这个服务器的人来说，这是很平常的一个周二。但作为与买家的第一次会面，这并不合理。一键安装的扩展格式已经消除了其中大部分麻烦，这是实打实的改进——但那一次点击，仍然发生在买家必须先安装并登录的别人的应用里，而剩下的步骤你无法掌控。

你的产品出现在竞争对手的客户端里

就算成功了，潜在客户打开的也不是你的产品。他打开的是 Claude、ChatGPT 或 Cursor。你的工具只是别人品牌之下、别人窗口之中的一个条目，旁边还摆着他早已连接的其他东西。你把演示预算花在了另一家公司的新用户引导漏斗上。他记住的会是自己已经付费的那个助手，而不是你请他粘贴的那个连接器。

模型和首屏都不由你决定

Claude Desktop 只与 Claude 对话。你没法把演示指向更便宜的模型，没法指向为隔离机房准备的本地 Ollama，也没法指向那个恰好很会调用你工具的模型。你没法设定系统提示词、空状态，或标题栏里的名字。对方最先看到的是 Anthropic 的产品。如果工具 本身就是产品，这个位置很不利。

几种方案的比较

把 MCP 工具摆到潜在客户面前有三种方式。托管服务器是前两行里的一列，而不是第四个选项——URL 仍然需要一个客户端。

如果潜在客户绝不会安装软件，而你也愿意待在数据路径上，就选托管式聊天。如果他本来就住在 Claude Desktop 里，而你只需要证明工具存在，就选 Claude Desktop。如果演示本身就是产品，就选桌面客户端：你的工具、你选的模型，跑在一台你不必照看的机器上。

改为交付你自己的客户端

Conduit 是一个开源的桌面 AI 客户端。它在 Windows、macOS 和 Linux 上通过本地 stdio 和远程 streamable HTTP 使用 MCP。潜在客户下载安装包，添加一个提供商密钥（或者指向 Ollama），然后在连接器页面添加你的服务器——填命令和参数，或者一个 URL。如果你的远程服务器已发布到官方 MCP 注册表，他还可以按名称搜索并一键添加。连接器运行在他自己的机器上，不经过我们。

如果你的服务器是远程的，并且已发布到 官方 MCP 注册表, ，那么潜在客户什么都不用输入：他在连接器页面按名字搜索你的产品，一键添加即可。Conduit 会把注册表筛选为发布了 streamable HTTP 远程端点的服务器，对只支持 SSE 的条目会给出理由并拒绝，而不是等到后面才失败。如果服务器需要认证，它使用 OAuth 2.1——潜在客户在浏览器中登录，令牌保存在他自己的操作系统密钥链里，既不会进入界面，也不会到你手上。

仅此一点，这就已经是一场不同于 Claude Desktop 的演示了。对方不会被锁定在一个模型家族里，可以完全在本地运行。除非服务器把某个工具标记为只读，否则它会先询问。对话留在他磁盘上的 SQLite 里。模型请求从他的机器直接发往他配置的提供商。中间没有 Conduit 的服务器——正因如此，仅仅使用 Conduit 作为客户端，并不会让 you 你成为这段对话的处理者。

有两个限制，直说：第一，除非你在那份副本的 设置 → 品牌 中改掉名字，或者从源码构建一个打包好的 OEM 版本，否则对方安装的仍然是 Conduit 。第二，除非你的服务器在注册表里，否则连接器还是要他自己输入；而无论哪种情况，构建产物都不会在出厂时就指向它——这一层打包能力今天还不是一个可下载的安装包。 白标页面 是为同时需要这两者的人准备的计划。本页描述的正是那个计划要解决的分发问题。

今天已经交付的内容

与白标页表格相同的状态，缩减到一次演示真正需要的部分。

安装包没有经过操作系统代码签名，因此 Windows SmartScreen 和 macOS Gatekeeper 会在首次启动时发出警告。请在对方点击之前先告知，或者和他一起从源码构建。详情见 安装文档.

常见问题

下载 Conduit

如果这场演示只有做成带品牌、已接好线的构建才成立， 请阅读白标状态 and 并发起一个设计伙伴讨论.