MCP resource availability follows configured servers
MCP 资源可用性取决于已配置服务器
Sessions without configured MCP servers need neither resource schemas nor MCP guidance. Requiring a separate resource-service entry also makes users configure shared resource access in addition to each connection. A shared tool set owned by the first server can disappear when that server unloads even though another server still needs it.
English
Problem
Sessions without configured MCP servers need neither resource schemas nor MCP guidance. Requiring a separate resource-service entry also makes users configure shared resource access in addition to each connection. A shared tool set owned by the first server can disappear when that server unloads even though another server still needs it.
Decision
Every shipped profile mounts mcp-resources once: base-backed profiles, including Desktop, inherit its row from dsh-base; standalone sdk-minimal owns its row. Users configure only their mcp-client entries. No MCP server is enabled by default.
The resource service uses configured provider registrations in the caller's scope, including MCP clients mounted by another provider. An empty visible registry contributes no resource prompt, native tool schemas, PTC declarations, or PTC bindings. The first provider in a scope enables its shared tools; removal of the last removes those local registrations while preserving inherited providers and tools. The resource service owns the shared tool effects independently of any server plugin.
Connection health does not determine this visibility. An active client remains configured through failed requests and reconnect attempts; its shared resource tools and server-name guidance stay available, and calls report connection failures. Server instructions retain their connection-owned publication rules.
This decision partially supersedes the separate opt-in mount in the resource and instruction decision. That note retains the operation, scope-selection, canonical-result, binary-rendering, and logged-instruction rationale.
Alternatives considered
Keep the separate resource mount. It makes a shared capability a second user configuration task and permits different defaults across shipped profiles.
Keep resource tools visible without servers. It adds unusable operations and prompt tokens to ordinary sessions, including the minimal SDK's single-shell default.
Filter providers by negotiated resource capability. This omits resource guidance for servers that declare no resources, but visibility then requires a successful capability exchange. The configured-client policy uses one criterion for direct and provider-mounted clients, including before the first successful connection and during recovery.
Own shared tools under the first server plugin. Disposing that server can remove tools still needed by another configured server. The service owns their lifetime instead.
Verification
Resource tests cover empty native and PTC views, scoped inheritance, first/last-provider transitions, disposal, and failing configured providers. Real SDK tests pin empty discovery and unsupported read errors for a tools-only server. Profile composition tests resolve every shipped CLI template; Desktop composition tests include its profile and Host overlay. The empty native and PTC recorded Sessions exercise the shipped headless composition without adding a resource entry.
Consequences
An empty MCP configuration adds no MCP prompt or tool tokens. A configured server without resource capability still contributes its name and shared resource schemas. The SDK returns empty discovery lists; unsupported reads fail. Adding the first visible server or removing the last changes subsequent prompt and tool assembly. The minimal SDK advertises its single shell until the user adds MCP servers. Resource reads remain on demand, and no connection or durable Session format changes are required.
中文
问题
未配置 MCP 服务器的会话不需要资源 schema 或 MCP 指引。要求单独的资源服务条目，也让用户在配置每个连接之外还要配置共享资源访问。由首台服务器拥有的共享工具集可能随该服务器卸载而消失，即使其他服务器仍需要它。
决策
每个随附 profile 统一挂载 mcp-resources 一次：包括 Desktop 在内的基于 base 的 profile 从 dsh-base 继承该行；独立的 sdk-minimal 拥有自己的行。用户只需配置 mcp-client 条目。默认不启用任何 MCP 服务器。
资源服务使用调用方作用域中的已配置提供方注册，包括由其他提供方挂载的 MCP 客户端。可见注册表为空时，不贡献资源提示词、native 工具 schema、PTC 声明或 PTC 绑定。作用域中的首个提供方启用共享工具；移除最后一个提供方时移除这些本地注册，同时保留继承的提供方与工具。资源服务独立于任何服务器插件拥有共享工具 effect。
连接健康状态不决定这些内容的可见性。激活的客户端在请求失败或重连尝试期间仍属于已配置状态；共享资源工具与服务器名称指引保持可用，调用会报告连接失败。服务器指令保留由连接拥有的发布规则。
本决策部分取代资源与指令决策中单独启用资源服务的挂载方式。该笔记保留操作、作用域选择、规范结果、二进制渲染及已记录指令的设计依据。
考虑过的替代方案
保留单独的资源挂载。 这会让共享能力成为第二项用户配置任务，并允许随附 profile 使用不同默认值。
没有服务器时仍显示资源工具。 这会向普通会话增加不可用操作与提示词 token，包括默认仅有一个 shell 的极简 SDK。
按协商出的资源能力过滤提供方。 这能省略未声明资源的服务器对应的资源指引，但会让可见性取决于成功的能力交换。已配置客户端策略对直接配置和由提供方挂载的客户端使用同一标准，包括首次成功连接前与恢复期间。
由首台服务器插件拥有共享工具。 释放该服务器可能移除其他已配置服务器仍需要的工具，因此由服务拥有这些工具的生命周期。
验证
资源测试覆盖空 native 与 PTC 视图、作用域继承、首个与最后一个提供方的变化、释放，以及已配置提供方调用失败。真实 SDK 测试固定了只提供工具的服务器返回空发现结果，以及不受支持的读取报错。Profile 组合测试解析每个随附 CLI 模板；Desktop 组合测试包含其 profile 与 Host overlay。空 native 与 PTC 录制会话使用随附 headless 组合，不添加资源条目。
后果
空 MCP 配置不增加 MCP 提示词或工具 token。不具备资源能力的已配置服务器仍贡献名称与共享资源 schema。SDK 返回空的发现列表；不受支持的读取会失败。添加首个可见服务器或移除最后一个服务器，会改变后续提示词与工具组装。极简 SDK 在用户添加 MCP 服务器前只公布一个 shell。资源读取仍按需进行，无需更改连接或持久 Session 格式。