把本地 MCP 工具临时暴露给 AI 客户端：用 cpolar 排查 Resource 为什么看不到

把本地 MCP 工具临时暴露给 AI 客户端：用 cpolar 排查 Resource 为什么看不到

搞了一个本地 MCP Server，规规矩矩注册了两个 Resource，本地跑起来一切正常。结果接到 AI 客户端一看——Resource 列表空空如也，一个都看不到。

这个问题在 MCP 开发者社区里太常见了，掘金上甚至有一条热帖就在问同一件事。原因通常不是 Resource 注册错了，而是客户端和服务器的网络链路没走通——尤其是当你的 MCP Server 跑在 SSE 或 Streamable HTTP 传输层上时，客户端无法主动回连到你的本地端口，resources/list请求根本没有到达服务器。

这篇就记录一个我自己的排查办法：用 cpolar 给本地 MCP Server 开一个临时公网地址，让 AI 客户端能直接回调进来，看看 Resource 列表到底有没有正常暴露。

1 什么场景下 Resource 会"看不到"

先明确一下这篇文章要解决的具体问题。

你的 MCP Server 可以长这样——用 Python FastMCP 或者 TypeScript SDK 写的一个服务器，在本地监听一个 HTTP 端口：

from mcp.server.fastmcp import FastMCP mcp = FastMCP("demo-server") @mcp.resource("config://app/settings") def get_settings() -> str: """返回应用配置项""" return "theme=dark\nlanguage=zh-CN\nmax_items=50" @mcp.resource("docs://help/about") def get_about() -> str: """返回关于页面内容""" return "# About\n\nThis is a demo MCP server." if __name__ == "__main__": mcp.run(transport="sse")

启动之后，服务器在http://localhost:8000/sse上等客户端连进来。

问题出在：当你把 MCP Server 配成 Streamable HTTP 或 SSE 模式时，客户端和服务器是双向通信的。客户端需要先连接到你的 SSE 端点，服务器才能通过这个长连接把 Resource 列表推回去。如果客户端在另一台机器上、或者在 Docker 容器里、或者在 AI Studio 的云端运行时里——它连不上你的localhost:8000，resources/list请求就永远发不出来。

这不是 Resource 注册错了，这是网络链路没打通。

2 环境准备：先确认本地能跑通

在动手暴露到公网之前，先确认本地环境一切正常。这一步花不了两分钟，但能帮你后面少走很多弯路。

2.1 确认 MCP Server 正常启动

终端执行：

python mcp_demo_server.py

看到类似这样的输出：

INFO: Started server process [12345] INFO: Waiting for application startup. INFO: Application startup complete. INFO: Uvicorn running on http://localhost:8000

说明服务器已经在本地 8000 端口上监听 SSE 连接了。

2.2 用 curl 快速验证 SSE 端点

开另一个终端，执行：

curl -N http://localhost:8000/sse

正常情况下你会看到 SSE 的初始化事件输出，类似：

event: endpoint data: /message?session_id=abc123 event: initialized data: {}

如果你看到Connection refused或者curl: (52) Empty reply from server，说明服务器本身就没起来，先回去修，不要急着往外穿透。

2.3 用 MCP Inspector 本地测一次 Resource

官方 MCP Inspector 是排查这类问题最趁手的工具：

npx @modelcontextprotocol/inspector

打开浏览器访问http://localhost:5173，在连接方式里选 "Streamable HTTP"，地址填http://localhost:8000/sse。连接成功后，点Resources标签页，你应该能看到刚才注册的两个 Resource。

这一轮本地测试过了，说明 Resource 注册本身没有问题。那为什么 AI 客户端看不见？多半是客户端那端连不回来。

3 用 cpolar 给 MCP Server 生成公网地址

本地确认正常，下一步就是让 AI 客户端能连到你的 MCP Server。你要做的不是改代码，也不是重写 Resource，而是在中间加一个公网跳板，让客户端能把回调请求发进来。

3.1 安装 cpolar

如果你机器上还没装 cpolar，按平台选一个命令：

macOS（Homebrew）：

brew install cpolar

Linux（一键脚本）：

curl -L https://www.cpolar.com/static/downloads/install-release-cpolar.sh | sudo bash

Windows：

去官网下载页面 https://www.cpolar.com/download 下载 Windows 安装包，双击安装。

3.2 注册并获取 token

cpolar 需要一个 token 来绑定你的账号。注册地址：

https://dashboard.cpolar.com

注册完成后进入仪表盘，在Auth Token页面复制你的 token，然后在终端执行：

cpolar authtoken 你的token

这条命令会把 token 写入配置文件，后续启动隧道时自动带上。

3.3 启动 HTTP 隧道

MCP Server 刚才监听的是 8000 端口，cpolar 对 HTTP 隧道要映射的就是这个端口：

cpolar http 8000

命令执行后终端会停留在前台，输出类似：

Forwarding https://abc123.cpolar.cn -> http://localhost:8000 Forwarding http://abc123.cpolar.cn -> http://localhost:8000 Web Interface http://127.0.0.1:9200

看到这一行，说明隧道已经建成了。https://abc123.cpolar.cn就是你 MCP Server 的临时公网地址。

注意：这个地址是 cpolar 免费套餐生成的随机地址，24 小时内会变化。这篇文章只做临时调试用，用完之后关掉即可。如果后续需要长期固定地址，考虑基础套餐的固定二级子域名。

3.4 验证公网地址能访问 MCP Server

用公网地址替换掉本机地址，再跑一遍 curl：

curl -N https://abc123.cpolar.cn/sse

如果能看到和之前一样的 SSE 事件输出，恭喜，公网链路已经打通了。如果返回 404 或者连接超时，先检查：

• MCP Server 是否还在运行
• 隧道是否显示online
• 防火墙是否放行了 8000 端口

检查隧道状态最方便的方式是打开http://127.0.0.1:9200，在 Web UI 里看隧道是否在线。

4 让 AI 客户端通过公网地址连接并验证 Resource

公网地址到手了，现在让 AI 客户端用这个地址去连 MCP Server。

4.1 配置客户端连接地址

不同的 MCP 客户端配置方式不一样，这里列两个最常见的场景：

Claude Desktop（或同类本地客户端）：

在claude_desktop_config.json中，把 MCP Server 的配置改为：

{ "mcpServers": { "demo-server": { "command": "npx", "args": [ "-y", "@modelcontextprotocol/inspector", "--connect", "https://abc123.cpolar.cn/sse" ] } } }

自定义 MCP Client（Python）：

from mcp import ClientSession from mcp.client.sse import sse_client async def test_resources(): async with sse_client("https://abc123.cpolar.cn/sse") as streams: async with ClientSession(streams[0], streams[1]) as session: await session.initialize() resources = await session.list_resources() for r in resources: print(f" {r.name}: {r.uri}")

4.2 验证 Resource 列表

连接成功后，在客户端里请求 Resource 列表。如果能看到你注册的那两个 Resource，说明问题不在代码，在网络——之前本地看不到纯粹是客户端连不回来。

如果公网地址连上去之后 Resource 列表仍然为空，那问题就出在服务器端的 Resource 注册逻辑上了。这个时候需要回来检查：

4.3 Resource 不可见的常见原因

原因 1：capabilities 声明缺失

MCP 协议要求服务器在 initialize 阶段声明自己支持 Resource。检查你的服务器初始化代码是否正确声明了resourcescapability。如果用 FastMCP，通常 SDK 会自动做这件事；但如果你自己实现底层协议，很容易漏掉。

原因 2：Resource URI 格式不对

Resource 的 URI 必须符合 RFC 3986 规范。一个常见的踩坑是用了config://这样的 scheme。MCP 协议本身没有强制限定 scheme，但客户端通常只会稳定渲染自己支持的 URI 形态。实际排查下来，大部分"看不到"的问题出在客户端不支持非标准 scheme 的渲染，而不是 Resource 注册失败。

原因 3：list_resources handler 没返回

如果用低层 SDK，需要手动实现list_resources回调：

# 低层写法，容易忘记返回完整的 resource 列表 @server.list_resources() async def handle_list_resources(): return [ Resource( uri="config://app/settings", name="App Settings", description="应用配置参数", mimeType="text/plain" ), Resource( uri="docs://help/about", name="About Page", description="关于页面内容", mimeType="text/markdown" ) ]

检查确认你确实返回了Resource对象列表，而不只是打印了日志。

原因 4：SSE 长连接断开了

MCP 的 SSE 传输层依赖持久化长连接。如果网络不稳定、客户端重连太频繁、或者 cpolar 隧道因为闲置超时而被回收，SSE 连接就会断开。遇到这种情况，重启隧道后重新连接即可。

5 通过 cpolar 4040 检查回调链路

如果连着公网地址但 Resource 还是看不到，还有一个排查手段：cpolar 提供的 4040 请求检查面板。

启动隧道时，cpolar 同时在本地启动了http://127.0.0.1:4040作为 HTTP 检查界面。打开这个地址，你能看到 cpolar 接收到的每一次 HTTP 请求的详情，包括：

• 请求路径和方法
• 请求头（包括Mcp-Session-Id）
• 请求体（JSON-RPC 消息内容）

这个面板在排查"客户端到底有没有发resources/list请求过来"这个问题时特别好用。

具体来说：让 AI 客户端发起一次 Resource 列表请求，然后切到 4040 页面看看有没有对应的POST /message请求到达。如果有，说明网络链路没问题；如果没有，说明客户端根本没成功建立连接。

# 直接在浏览器打开 open http://127.0.0.1:4040

在请求列表里搜索resources/list的关键字，如果能找到，就把响应体里的result和本地 MCP Inspector 测出来的结果对比一下。

6 验证完成后关闭隧道

MCP Resource 排查结束之后，第一件事就是关掉 cpolar 隧道。临时调试隧道不需要长期运行，关掉的方式很简单：

在 cpolar 前台窗口按Ctrl + C，终端会提示隧道已关闭。

确认隧道已经离线的办法：刷新http://127.0.0.1:9200，在线隧道列表如果空了，说明已经全部关停。

安全提醒：这篇文章全程操作的都是测试 Resource，不包含任何敏感数据（没有 API Key、没有数据库密码、没有用户信息）。如果是排查生产环境的 MCP Server，不要在公网上暴露管理端口，不要传入真实凭证，确认完成后立刻断网。

cpolar 生成的是随机临时地址，非长期固定地址，而且隧道关了地址立刻失效，安全风险可控。但也正是这个原因，它特别适合做 MCP 调试场景——用完即弃。

7 总结

折腾了大半天，说回最核心的结论：MCP Resource 在客户端看不到，90% 是因为客户端回连不到你的本地服务器，不是 Resource 注册代码写错了。

排查链路其实很简单：

• 先用 MCP Inspector 在本地验证一遍 Resource 列表是否正常
• 再用 cpolar 开一个 HTTP 隧道，把本地 MCP Server 的 SSE 端点暴露成公网地址
• 让 AI 客户端通过这个公网地址重新连接，看 Resource 列表是否出现
• 如果还看不到，用 cpolar 的 4040 请求检查面板确认回调链路是否真的走到了服务器端
• 排查完毕关闭隧道，不要让临时地址长期开放

这个流程不需要改一行 MCP Server 代码，不需要重写 Resource，也不需要给 AI 客户端开网络白名单。一条 cpolar 隧道配上 4040 面板，就能把"网络链路不通"和"Resource 注册有问题"这两类原因快速拆开。

如果你也在写 MCP Server 并且卡在"Resource 客户端看不到"这一步，不妨试试这个办法——先排除网络链路，再回头查代码。