全部插件

DSH / BUNDLE / BUNDLES

dsh-mcp-loader

v0.5.0MikotoMyWife / dsh-mcp-loader9a9f2de25f

可安装组合包组合包与其他模块社区 · Topic 自动分析

概览

dsh-mcp-loader

Lazy-loading MCP tools for DeepSeek Harness (DSH): one loader tool per multi-tool MCP server, per-agent tool masking and description presets

README / ZH

插件文档

目录摘要

Lazy-loading MCP tools for DeepSeek Harness (DSH): one loader tool per multi-tool MCP server, per-agent tool masking and description presets

dsh.pub 核对固定版本的组合包契约、运行时事实与分发语义;完整 README 请查看源仓库。

在 GitHub 阅读完整 README

LIMITATIONS

已知限制

- Granularity is per server, not per tool (one loader per server). - Tool rules are expanded when a generation loads and re-expanded when it re-syncs, so a glob sees the tool set of the moment. A mask is applied to an agent once per server (the per-agent `restrict` is not replayed on re-sync), so a tool that first appears in a later re-sync is masked for agents created after that re-sync, not for agents that were already masked under the earlier expansion. - Startup probing is a snapshot: a server that later grows past the threshold stays revealed until restart (pin it with `mode: lazy`). - Only one bridge may serve a given server name: each configured name is claimed at mount time, and a second instance (another mount of this plugin, or the official `dsh-mcp-client` on the same name) is refused with a named error instead of silently failing to register — registration is global, so the public tool names would collide. - Images/audio become `[image image/png]` text placeholders and only tools are bridged: MCP resources are bridged only through the optional resource service described above, while prompts, progress and task-typed tools are out of scope. Images are a deliberate divergence — the official `dsh-mcp-client` 0.1.6 projects them through attachment blocks. - A server that never declares the `tools` capability loads as an empty catalogue (logged once, loader kept) and is never asked for a tool list, so a resources-only server does not fail every load. - Reconnection is bounded and lazy: one user-visible operation (a loader load, a tool call, a startup probe) draws from a single budget of `reconnectAttempts + 1` connect+discovery tries (`reconnectAttempts`/`reconnectBackoffMs`); a failed `tools/call` is surfaced immediately and never replayed. There is no eager background keep-alive/reconnect — an idle server with `idleDisconnectMs: 0` (the default) stays warm indefinitely, and one with `idleDisconnectMs > 0` is disconnected only while it has no loaded tools, reconnecting on the next load. - Known lifecycle edges (accepted for now; a connection "generation" scheme for these is a later slice): - Disconnecting while another caller is connecting can, in a narrow window, leave two spawned children and orphan the losing one. - An idle disconnect waits for a connect attempt already in flight (up to `connectTimeoutMs`) before closing; retries that were only scheduled are cancelled instead of delaying the disconnect. - With the default `reconnectAttempts: 1`, deterministic discovery errors (e.g. a duplicated tool name) are retried once before surfacing. Discovery hard caps are the exception: a `DiscoveryLimitError` (page/tool limit or deadline) is deterministic and surfaces immediately, never retried.