已有 MCP 服务，接入产品助手还要决定什么？

已有 MCP 服务，意味着有一条可以复用的工具协议接入路径；它不代表产品已经完成工具许可、用户授权或连接管理。把 MCP 放进产品内的助手，至少还要决定暴露哪些工具、谁能执行，以及由谁持有连接。

在 Node.js 或 Electron 主进程中，Tansr 的 @tansr/sdk 可以把 MCP 工具接入会话运行链。createMcpHost 用于持有服务器连接，工具调用进入已有的权限判断过程。这样可以复用现成协议服务，同时继续由产品处理界面、身份和业务约束。官方 MCP 接入说明

先决定工具目录，不把整个服务直接当成权限

一个 MCP 服务可能同时提供查询、修改和删除。产品当前只需搜索知识条目时，没有必要因为服务已经存在，就把所有操作都暴露给助手。

Tansr 的服务器配置支持 toolAllowlist，限制进入工具目录和发现流程的工具。它回答“助手可见哪些工具”，不回答“某次调用可以执行吗”，更不回答“这个用户可以读取哪些条目”。

因此，工具目录、运行权限和服务端业务授权应分别检查。即使工具名叫 search，实际服务也可能访问敏感资料；名称与协议本身不能证明数据访问范围合理。

再决定调用许可与用户交互

Tansr 的 MCP 桥接工具进入运行权限机制，对第三方操作按保守的效应判断处理。需要明确配置相应权限，或接入产品自己的询问交互；工具白名单不能替代这一层。

permission.askUser 是 SDK 交给宿主实现的确认接点。对于已经判为 ask 的调用，缺少询问回调会降为拒绝，而不是默认放行。实际是否出现询问还取决于权限配置，不能把“注册了 MCP”理解为每次必弹确认或每次自动执行。

对业务产品而言，用户确认应尽量对应明确的对象和影响。高权限服务端凭据也不能因为用户点过确认，就无条件代表所有用户执行任意操作。公开 API 与权限入口

连接归会话，还是归应用

Tansr 提供两种 MCP 连接持有方式：会话配置可以创建会话持有的连接；应用也可以通过 createMcpHost 建立 host，让多个会话使用同一组连接。应用持有的共享 host 需要由应用安排释放。

两种方式对应的是资源所有权，不是业务身份隔离。共享连接适合什么范围，应看服务使用何种凭据、能否区分请求用户、是否缓存用户数据，以及并发请求会不会混用状态。不能从“会话工具目录分开”推导出外部服务的租户数据已经隔离。

Tansr 支持 stdio 与 HTTP 类型的 MCP 连接配置，但某个具体服务能否满足产品的鉴权和行为要求，仍需针对该服务验证；支持协议不等于任意服务都已经兼容验收。

没有 MCP 服务时，是否需要先造一个

如果只有产品内部的一个业务函数，直接通过 defineTool 注册为自定义工具可能更直接。MCP 适合复用已有协议服务，或有明确的跨应用协议接入需求；不必为了给助手调用一个函数而额外建设服务。

Skills 又是不同的材料：它提供任务指引，不替代 MCP 的可执行工具。把操作流程写进手册，也不会自动让模型获得查询或修改业务系统的能力。

需要把外部工具接入自有界面、多轮会话和权限流程的团队，可以从平台装配文档评估 Tansr。先确定工具目录与身份范围，再选连接持有方式，才能判断协议复用到底减少了哪部分接入工作、又留下了哪些责任。