dsh-skills-mcp-panel
English | 中文
This project was generated by DeepSeek Flash. Every file here — both plugin
halves, the tests, and this documentation — was written by the model running in
DeepSeek Harness, from requirements and review by the project owner.
Skills & MCP panel for the DeepSeek Harness Web GUI. One Settings page under
Agent presets that lists every skill and every MCP server this deployment
composed, with a search box, a per-row status light, a state selector, and a
details toggle.
Both kinds change without restarting the process:
| What the selector writes | When it lands |
|---|
| Skill | disable-model-invocation and user-invocable in the skill's SKILL.md frontmatter — the four states those two bits spell out | the skill provider watches the roots, so the next agent/pre-step republishes the catalog — same session |
| MCP server | an id-targeted disabled: true row in the profile's own cordis.patch.yml | a patchReload: live profile re-applies the patch through config HMR, which reloads that server's connection in place — same session |
Nothing else is touched: the panel never deletes a skill, never edits a server's
configuration, and never reformats your patch file — see
What it writes.
Install
The package ships ready to run: lib/ is the source of truth, there is no build
step, and a git install needs no allowBuilds permission.
# from npm
dsh plugin --profile web add dsh-skills-mcp-panel
# from GitHub, if you would rather track the repository
dsh plugin --profile web add github:KyattoCat/dsh-skills-mcp-panel
# from a local checkout while developing
dsh plugin --profile web add link:/absolute/path/to/dsh-skills-mcp-panel
Whichever route you take, the installed package carries lib/, the two READMEs,
cordis.patch.yml, and the license — and nothing else. tests/ and
CONTRIBUTING.md stay in the repository.
Then restart the dsh web process once — installing a new bundle layer is
the one operation the live patch reload cannot cover, because
dsh.profile.bundles is read at boot. Every change after that is hot.
Remove it with:
dsh plugin --profile web remove dsh-skills-mcp-panel
Use it
Open Settings → Agent presets → Skills/MCP (the entry sits directly under the
preset page). The page has:
- a search box filtering by name, description, and path;
- two tabs with live counts — skills and MCP servers;
- groups, one per place a row comes from (see below), each with its own
header, path, and count — a header is a toggle that collapses and expands its
group;
- one card per row: title, source, a colored status light, a state
selector, and a details toggle (
+ / −) styled like the selector beside it;
- a details panel per card, showing description / when-to-use /
root / path / body lines / model-invocable / user-invocable for a skill, and
entry id / transport / command-or-URL / connection phase / tool count / tool
names for an MCP server;
- no standing footer: the page adds a message only when a change lands on a
profile that will not act on it until the next
dsh start.
Groups
Rows are grouped by the directory they belong to, so a skill you wrote for one
project never looks like one you installed for every project.
The current project leads. The group of the project the GUI's current session
runs in is pinned to the top of the list, starts expanded, and carries a
Current project badge. Every other group starts collapsed. Clicking a header
collapses or expands that one group, and a choice you make sticks until the page
is reopened — a reload from a toggle does not undo it. A GUI with no session open
falls back to the project the dsh web process itself runs in, and a session in
a workspace this deployment never registered falls back the same way, so exactly
one project group always leads rather than none. A pinned project that has no
skills or servers of its own has no group to render, and the first group that
does have rows opens instead.
Skills. Every scanned root maps to a group:
| Group | Roots |
|---|
| Global | $DSH_HOME/skills and $DSH_AGENTS_HOME/skills — the skills you own regardless of project |
| One per project | <project>/.dsh/skills and <project>/.agents/skills, for every project the deployment knows: each workspace the Web GUI has opened, plus the harness process's own working directory |
| One per configured root | each entry of skillRoots, named after its directory |
A group header carries the group's name, its full path, and its row count.
MCP servers. A server has no directory of its own, so the panel takes the
directory it runs in: a stdio server whose cwd sits inside one of those
projects is grouped under that project, and every other server — HTTP servers,
and stdio servers that inherit the harness process's directory — is Global.
Skill states
A skill's two frontmatter keys are independent, so it has four states and the
selector offers all four:
| Selection | disable-model-invocation | user-invocable | Who can load it |
|---|
| Enabled | absent (the default) | absent (the default) | the model routes to it on its own, and you can type /name |
| Manual only | true | absent | you only — the model never sees it in the catalog and cannot load it with the skill tool |
| Model only | absent | false | the model only — it is not offered in the / menu or to /name |
| Disabled | true | false | neither surface; only trusted ctx.skills.get() callers |
MCP states
An MCP row is a single enablement, so its selector offers Enabled and
Disabled (localized to the interface language). A settled, active server
carries no second label; a tag appears beside the selector only while the
connection is unsettled — loading or failed — because that is a live fact
rather than a setting. The same holds for a long tool list in the details
panel: one name per line, and the box scrolls once it outgrows the card.
Status lights: green = the model can reach it (skill) or the server is
connected (MCP), amber = manual-only (skill) or still connecting (MCP), red = a
parse error (skill) or a failed connection (MCP), grey = disabled.
What it writes
Skills. Only the two invocation keys move. true is the provider's own
default, so a state that needs it REMOVES the key instead of writing a
redundant value: Enabled writes neither key, Manual only writes
disable-model-invocation: true, Model only writes user-invocable: false,
and Disabled writes both. A skill taken away from its default state and put
back therefore returns to its original bytes, and an unrelated key never moves.
MCP servers. The panel owns one marked block at the end of the profile's
cordis.patch.yml:
# >>> dsh-skills-mcp-panel (managed — edit these rows from the panel)
- id: "mcp-playwright"
disabled: true
# <<< dsh-skills-mcp-panel
Everything outside those two fences is preserved byte for byte — comments,
formatting, and your own rows included. The block is rewritten wholesale on
every change, so it always lists exactly the servers currently disabled by the
panel; re-enabling the last one removes the block and the file returns to its
original bytes. The write goes through a temp file and a rename, so the patch
watcher never sees a half-written document.
Configuration
All fields are optional; the defaults are what a stock dsh web needs.
| Field | Default | Meaning |
|---|
patchPath | auto-detected | The patch file MCP selections are written to. Detection picks the profile under $DSH_HOME/profiles whose dsh.profile.bundles lists this plugin, preferring one with patchReload: live. Set it explicitly if you keep several profiles. |
dshHome | $DSH_HOME or ~/.dsh | Harness home; its skills subdirectory is scanned and its profiles directory is searched. |
agentsHome | $DSH_AGENTS_HOME or ~/.agents | Shared agent root; its skills subdirectory is scanned. |
projectRoot | process.cwd() | The harness process's own project; its .dsh/skills and .agents/skills are scanned alongside every workspace the deployment knows. |
skillRoots | [] | Extra skill roots, each forming its own group. |
maxSkillProjects | 64 | Ceiling on how many workspaces one scan covers; project roots are sorted before the cap applies. |
- id: skills-mcp-panel
name: dsh-skills-mcp-panel
config:
projectRoot: /home/me/work
skillRoots:
- /home/me/team-skills
How it works
Two halves in one package, both plain JavaScript, no dependencies:
- Host half (
lib/index.js) registers two exact routes on ctx.webServer
and answers them behind the composition's connection trust fence (the
browser session cookie plus the Host/Origin check). GET /skills-mcp/state
scans the skill roots and walks the Loader for @deepseek-ai/dsh-mcp-client
rows; the browser sends the directory of its current session as ?cwd=, which
is what decides the pinned group. POST /skills-mcp/toggle performs the write
described above and answers with the same full snapshot, cwd included in the
body, so a change never re-orders the page under the cursor.
- Browser half (
lib/client.js) is written directly in the client module
system's lazy-CJS factory form
(window.__ModuleLoader__.load({ id, factory })), so it needs no bundler and
no shared build preset. It registers one settings.section contribution and
takes only react from the module table.
Known limitations
- A panel change is not a preset edit. A skill or MCP row that a preset's
agent.cordis.yml provides is still composed at session creation; the panel's
MCP selections target the profile patch layer, which applies to every session.
Hiding a whole preset-provided row remains a preset edit, and a new session is
what picks it up.
- Startup-frozen profiles.
headless, sdk, and acp default to
patchReload: startup; the panel's MCP writes land there but apply at the next
launch, and the page says so right after such a change. Skills stay hot
everywhere, because the skill provider watches files rather than configuration.
- Skills are read from disk, not from the registry. The panel mirrors the
filesystem provider's discovery (top-level
SKILL.md bundles and flat
<name>.md files, dot-directories skipped) so it can rewrite the file that
actually controls visibility. A skill supplied by a different provider appears
in the model's catalog but has no file for this panel to change.
- No import, create, or delete. The page changes what already exists; it
never adds or removes a skill or a server.
- MCP has no project-level source. DSH composes MCP servers from the profile,
the harness home, and bundles — there is no per-project MCP file to read — so a
server lands in a project group only when its own
cwd points into that
project. Everything else is Global, which is the truth rather than a gap.
Development
node tests/smoke.mjs # drives both routes through a stub Cordis context in a temp dir
The smoke test asserts the two properties that matter most: disabling and
re-enabling a skill restores the original bytes, and the same is true of the
patch file around the managed block.
Packaging rules and the release steps live in CONTRIBUTING.md,
because they are maintainer tasks rather than user instructions.
License
MIT
