Notion MCP 不是工具列表：先验证页面权限与工作区边界

把 Notion 接给 coding host 之后，最危险的误判不是“工具列表少了一个”，而是模型看到了一个工具名，就默认它能读写整个工作区。makenotion/notion-mcp-server 的官方入口是 npx @notionhq/notion-mcp-server，但 Doramagic 的独立能力包把第一步放在 page access checks、workspace boundaries 和 tool verification 上，这个顺序是对的。

我会先把它当成一个权限路由问题，而不是一个“连接成功就完成”的插件。第一轮只准备临时 workspace 或测试页面：确认 host 使用的 MCP 配置指向正确的 server；确认 Notion integration 对目标页面确实有 access；再用一个只读操作证明页面能被看到。页面标题能在 Notion UI 里看到，不等于 integration token 可以读取它。

这个项目的代码证据也值得看。src/init-server.ts 和 scripts/start-server.ts 是启动路径；src/openapi-mcp-server/mcp/proxy.ts 负责把 OpenAPI 描述映射成 MCP 工具；src/openapi-mcp-server/openapi/parser.ts 处理工具解析；src/openapi-mcp-server/auth/ 和 client/http-client.ts 则决定认证与请求边界。也就是说，排查“工具出现但调用失败”时，不能只盯着 host 的 tool list，还要区分 auth、OpenAPI 解析和 Notion API 返回的权限错误。

一个实用的首次验证顺序是：先运行 npx @notionhq/notion-mcp-server 的官方入口；在临时页面上验证 list/search 或页面读取；检查返回对象是否对应预期 page id；再尝试一次最小范围的更新操作。每一步都记录实际输出和页面权限。不要直接把团队知识库、私人页面或生产 integration token 作为第一批测试数据。

边界也很明确。这个能力包不证明本机已经安装、运行或成功调用 Notion API；它的 quick start、Human Manual 和 eval 文件是阅读与验证路线，不是运行结果。项目包还列出了配置、安装、运行时和权限风险，要求在隔离环境复现官方 quickstart。拿到“server 启动了”只能证明进程入口可执行，不能证明目标页面可读，更不能证明 Agent 可以安全写入。

我的操作判断是：先让 Agent 只能看到一页测试内容，再逐步扩大授权范围；把 page id、workspace、integration 权限和实际返回错误写进验收记录。只有读取、最小写入、撤销权限后的失败行为都可观察，才值得接入日常工作区。

这是独立的 Doramagic 能力包，不是 Notion 官方文档或背书。项目页：https://doramagic.ai/zh/projects/notion-mcp-server/；上游：https://github.com/makenotion/notion-mcp-server。