PilotDeck 已有原生 Streamable HTTP、Header 和 ${env:NAME} 配置展开，以及 MCP 工具到宿主的执行桥。想基于这些能力贡献一个小型使用实例：在独立 WorkSpace 中，显式连接远端 MCP，完成一次公开资料研究并生成带来源链接的摘要。
拟议范围是一份 docs/mcp-research-example.md 和必要的合成验证样例，具体落点可以按维护者建议调整：
- 演示向现有
mcpServers 合并一个用户选择的服务，说明全局/项目同名覆盖规则，保留已有配置；Key 使用现有 Header 环境展开机制，并说明缺失环境值的行为。
- 区分连接、工具发现和实际工具执行，示例只使用少量已发现工具（最多三种），展示返回内容、可核对的来源及失败情况，不将“连接成功”写成研究任务已完成。
- 以单次、有限调用的研究任务为例，说明费用、退出和移除配置的步骤。复用当前 MCP 实现，不新增默认服务、传输层或行业研究方法论。
这与 #335 的中文平台 Skills、#336 的行业研究方法论侧重点不同；本提案聚焦远端 MCP 的配置到执行流程，也不重复已合入的 #407 环境展开修复。
验证计划：用合成凭据和本地 Streamable HTTP 服务，经过真实配置加载、MCP Runtime、工具注册及宿主调度入口，分别验证 list/call、错误 Key、超时/取消和清理。完整模型、GUI、平台及真实服务验证会单独标明；目前只有源码核对，没有运行验收或生产调用。
关联说明：我参与百智云 Agent Toolkit的生态接入与推广，希望将其作为用户可选的托管实例。用户需自备 Key，请求及所选内容会发送给服务，可能产生服务和模型费用；示例开源不代表托管后端开源。不会要求维护者提供凭据或承担费用。
若欢迎这个方向，我可以准备教程与验证材料，并跟进本次贡献的评审修订；维护范围是接入示例，托管服务由其提供方负责。请问这一增量是否适合纳入，以及应放在主仓文档还是其他官方位置？
PilotDeck 已有原生 Streamable HTTP、Header 和
${env:NAME}配置展开，以及 MCP 工具到宿主的执行桥。想基于这些能力贡献一个小型使用实例：在独立 WorkSpace 中，显式连接远端 MCP，完成一次公开资料研究并生成带来源链接的摘要。拟议范围是一份
docs/mcp-research-example.md和必要的合成验证样例，具体落点可以按维护者建议调整：mcpServers合并一个用户选择的服务，说明全局/项目同名覆盖规则，保留已有配置；Key 使用现有 Header 环境展开机制，并说明缺失环境值的行为。这与 #335 的中文平台 Skills、#336 的行业研究方法论侧重点不同；本提案聚焦远端 MCP 的配置到执行流程，也不重复已合入的 #407 环境展开修复。
验证计划：用合成凭据和本地 Streamable HTTP 服务，经过真实配置加载、MCP Runtime、工具注册及宿主调度入口，分别验证 list/call、错误 Key、超时/取消和清理。完整模型、GUI、平台及真实服务验证会单独标明；目前只有源码核对，没有运行验收或生产调用。
关联说明：我参与百智云 Agent Toolkit的生态接入与推广，希望将其作为用户可选的托管实例。用户需自备 Key，请求及所选内容会发送给服务，可能产生服务和模型费用；示例开源不代表托管后端开源。不会要求维护者提供凭据或承担费用。
若欢迎这个方向，我可以准备教程与验证材料，并跟进本次贡献的评审修订；维护范围是接入示例，托管服务由其提供方负责。请问这一增量是否适合纳入，以及应放在主仓文档还是其他官方位置？