使用现有上下文和 ToolHandler 工作流来支持每台服务器的工具扩展

您的特性请求与问题有关吗 ? 请说明。

我在浏览器-工具集成中嵌入了“chrome-devtools-mcp”并想扩展所选工具,同时保留服务器现有浏览器上下文和“ToolHandler”管道。

由#1038 / #1043所添加的程式厂使嵌入成为可能. 下一个限制是定制:在1.8.0中, " CreateMcpServer " 返回SDK服务器,但其上下文存取器、工具注册和mutex是内部的。 目前主要(a918b7b4086bbb14105b80abab1deb882535f15e'),McpServer.from'存在,但McpServer Optimers'仍然只有logFile',这些设施仍然是私人设施。

两个具体的用途是增加一个单独的快照-导出工具,使用已存在的页面上下文,并报告当前有效的文件根而无需创建浏览器连接. 将导出的工具定义或上下文方法在全球与嵌入器对等,使独立的服务器实例难以分离。

描述你想要的解决方案

支持的,选入的,每服务器扩展表面. 准确的API应该遵循维护者的偏好;所需要的能力是:

1. 在 " ToolHandler " 构建之前添加或替换工具定义。 自定义仍应通过正常的注册/验证管道、页码路由、申报的文件检查和现有的工具mutex。 改变逐个定义是一种可能的设计;全球出口绝不能改变。
2. 被动地通过有限的观点/设计或回调来检查当前环境的生命周期和有效的根基信息。 在创建上下文之前和处置之后,应报告不存在。 观测不能启动/连接到浏览器;重新连接和根更改必须更新视图. 这一诊断使用案例不需要广泛的公众可变环境。 自定义工具处理器可以使用由"工具汉德勒"已经传递的上下文.

建议接受检查:默认工具目录/结果不变;两个配置的服务器实例互不影响;自定义工具保留路由,root/file拒绝和mutex行为;被动诊断不会产生上下文;再连接,root刷新和处理不会暴露 stale状态.

描述你考虑过的其他选择

• 调用返回的SDK服务器的登记工具':今天可以使用,但不能单独提供现有的上下文/ToolHandler'管道。
• 启动前修改导出的定义和上下文方法:为被绑定的版本工作,但依赖于共享可变内部.
• 复制注册/文本管理或打开另一个浏览器连接:重复生命周期、权限和同步逻辑。

小型支持的API比一般插件框架或下游服务器叉更好. 此请求不需要更改 CLI 工具默认或削弱已存在的检查.

其他背景

伴侣请求 : . . . . . . .