Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-dsh-plugins search the DSH plugin marketplace for SBOM compliance plugins"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
已发布到官方 MCP Registry：
io.github.feely0208/mcp-dsh-plugins（active）· npm@deepwhale-cn/mcp-dsh-plugins
English · 简体中文
An MCP server for the DeepWhale DSH plugin marketplace — search, inspect and check compatibility of 51 open-source DeepSeek Harness plugins from Claude, Cursor or any MCP client.
深鲸 DSH 插件市场的 MCP（Model Context Protocol）服务器。通过 stdio 把 deepwhale.org.cn 插件市场 的 50 个插件暴露给 Claude Desktop、Cursor、Cline 等任意 MCP 客户端，用于插件发现、检索与运行时兼容性检查。
包名：@deepwhale-cn/mcp-dsh-plugins（version 0.1.0）
传输方式：MCP stdio
运行时：Node.js >= 20（无网络也能跑，内置市场快照）
工具 | 说明 |
| 按关键词模糊搜索（包名 / 中英文标题 / 描述），可按分类过滤、限制返回条数 |
| 按包名查看详情：全部版本、最新版本、DSH 兼容范围、homepage、安装命令 |
| 列出插件分类（合规 / 治理 / 数据 / 供应链 / 能力 / 行业）及分类下的插件 |
| 传入当前 DSH 版本，按 |
Related MCP server: cc-plugin-mcp
无需安装，直接用 npx 启动（stdio 服务器，通常由 MCP 客户端托管）：
npx -y @deepwhale-cn/mcp-dsh-plugins也可以全局安装：
npm install -g @deepwhale-cn/mcp-dsh-plugins
mcp-dsh-plugins编辑 claude_desktop_config.json（macOS 位于 ~/Library/Application Support/Claude/）：
{
"mcpServers": {
"dsh-plugins": {
"command": "npx",
"args": ["-y", "@deepwhale-cn/mcp-dsh-plugins"]
}
}
}在项目根目录创建 .cursor/mcp.json（或编辑全局 ~/.cursor/mcp.json）：
{
"mcpServers": {
"dsh-plugins": {
"command": "npx",
"args": ["-y", "@deepwhale-cn/mcp-dsh-plugins"]
}
}
}其他支持 MCP 的客户端同理：把命令设为 npx、参数设为 ["-y", "@deepwhale-cn/mcp-dsh-plugins"] 即可。
{ "query": "sbom", "limit": 5 }{ "category": "合规", "limit": 10 }参数：
query（可选）：搜索关键词，支持中文/英文，空格分隔多个词时按 AND 匹配。
category（可选）：分类 id 或中文名，如 compliance / 合规、data / 数据、supply-chain / 供应链。
limit（可选）：1–50，默认 10。
返回结果包含 name、title（中英文）、description、category、latestVersion、dshRange、homepage、installCommand，以及 dataSource（当前数据来自线上还是随包快照）。
{ "name": "dsh-sbom" }包名可省略 @deepwhale-cn/ 前缀。返回插件详情、全部版本、最新版本、engines.dsh、homepage 和安装命令：
{
"plugin": {
"name": "@deepwhale-cn/dsh-sbom",
"latestVersion": "0.1.0",
"installCommand": "dsh plugin add @deepwhale-cn/dsh-sbom",
"homepage": "https://deepwhale.org.cn/plugins.html"
}
}找不到插件时返回 isError: true，并附带相似插件建议。
{}{ "include_plugins": false }返回分类列表及每个分类的插件数量；include_plugins 为空时只返回分类元信息。
{ "dsh_version": "0.2.1-rc.2" }返回 compatible / incompatible / unknown 三组插件，以及 compatibleCount 等计数。版本范围按 SemVer 2.0.0 顺序比较，包含预发布版本：例如 0.2.1-rc.2 满足 >=0.1.0-rc.6 <0.3.0，0.1.0-rc.5 不满足，0.3.0 不满足。
变量 | 默认值 | 说明 |
|
| 覆盖市场索引地址；支持 http(s) URL 或本地 JSON 文件路径 |
| 未设置 | 设为 |
|
| 远程索引请求超时（毫秒） |
启动时先请求线上索引；请求失败、超时或数据不合法时自动回退到随包快照 data/plugin-market.json，因此断网环境也能完整使用。工具返回中的 dataSource.kind 会标明本次数据来自 remote、local 还是 snapshot。
npm install
npm test # node:test，全部测试（含真实 stdio 握手）
npm start # 直接启动 stdio 服务器（等待 MCP 客户端连接）目录结构：
cli.mjs # bin 入口（stdio）
src/server.mjs # MCP server 与 4 个工具
src/catalog.mjs # 插件目录：搜索 / 详情 / 分类 / 运行时检查
src/categories.mjs # 分类规则
src/index-loader.mjs # 索引加载：远程 → 本地 → 快照
src/semver.mjs # 轻量 SemVer 范围判断（含预发布）
data/plugin-market.json # 随包市场快照（50 个插件）
tests/ # node:test 测试MIT © 温州深鲸智能科技有限公司
@deepwhale-cn/mcp-dsh-plugins is a local stdio MCP server that exposes the DeepWhale (深鲸) DSH plugin marketplace.
npx -y @deepwhale-cn/mcp-dsh-pluginsClaude Desktop / Cursor configuration:
{
"mcpServers": {
"deepwhale-plugins": {
"command": "npx",
"args": ["-y", "@deepwhale-cn/mcp-dsh-plugins"]
}
}
}Tools:
search_plugins — search by name, description or category
get_plugin — version, engines.dsh compatibility, install command
list_categories — compliance / governance / data / supply chain / capability / industry
check_runtime — which plugins are compatible with a given DSH version
Data: fetched from https://www.deepwhale.org.cn/plugin-market.json with an offline snapshot fallback (DSH_PLUGIN_INDEX_URL overrides). Read-only, no accounts, no telemetry.
Published to the official MCP Registry as io.github.feely0208/mcp-dsh-plugins.
MIT © 温州深鲸智能科技有限公司
传入当前 DSH 版本号（支持预发布版本，例如 0.2.1-rc.2），按每个插件最新版本的 engines.dsh 范围判断兼容性，返回兼容 / 不兼容 / 无法判断的插件列表及安装命令。
| Name | Required | Description | Default |
|---|---|---|---|
| dsh_version | Yes | 当前 DSH 版本号，例如 0.2.1-rc.2 或 0.1.0 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: the judgment is made against each plugin's *latest* version's engines.dsh range, and the output is three explicit buckets (compatible / incompatible / undeterminable) plus install commands. It does not mention whether any registry/network lookup occurs or how staleness of 'latest' is handled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence with no filler, and the return shape is stated up front at the end. It opens with the input parameter rather than the purpose verb, which slightly weakens front-loading of the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of describing returns, and it does so (three verdict categories plus install commands) while also explaining the comparison logic. For a one-parameter, read-only check, nothing an agent needs in order to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds semantics the schema does not: prerelease versions are explicitly supported and a concrete example (0.2.1-rc.2) is given, which matters because prerelease range matching is a common source of ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (judge compatibility) and resource (DSH runtime vs. each plugin's latest engines.dsh range), and its input/output contract makes it unmistakably distinct from the sibling search_plugins / get_plugin / list_categories tools. An agent knows exactly what it gets: three categorized plugin lists plus install commands.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the mention of install commands and compatibility verdicts suggests a pre-install/pre-upgrade check, but the description never says when to call it, when not to, or what the alternatives are. Adequate but with a clear gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
按包名获取单个深鲸 DSH 插件的详情：中英文标题与描述、作者、主页、全部版本、最新版本、DSH 兼容范围，以及安装命令（dsh plugin add ）。包名可省略 @deepwhale-cn/ 前缀，例如 dsh-sbom。
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | 插件包名，例如 @deepwhale-cn/dsh-sbom 或 dsh-sbom |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds no auth, error, or rate-limit context, but it does spell out the response payload, which is meaningful given there is no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense sentence with the lookup key and returned fields front-loaded; the parenthetical install command is useful rather than filler. The long field list is justified because no output schema exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must convey what comes back, and it does so thoroughly (titles, author, homepage, versions, compatibility range, install command). Only missing element is any failure/not-found or auth behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter is fully documented there, including the same '@deepwhale-cn/' prefix example. The description's restatement of the prefix rule adds no meaning beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('按包名获取单个...插件的详情') and scopes it to a single plugin looked up by package name, which cleanly separates it from search_plugins/list_categories. It even enumerates the returned fields, so an agent knows exactly what it gets back.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: use this when you already have a package name rather than a query. No explicit when-to-use/when-not or named alternative (search_plugins) is given, though the prefix-omission note does hint at input expectations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
列出深鲸 DSH 插件市场的分类（合规 / 治理 / 数据 / 供应链 / 能力 / 行业）及每个分类下的插件包名与数量，可用于后续按分类检索。
| Name | Required | Description | Default |
|---|---|---|---|
| include_plugins | No | 是否在响应中包含每个分类下的插件包名列表（默认 true） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds useful behavior beyond that: it discloses the shape of the return payload (categories plus plugin package names and counts), which matters since there is no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no wasted framing; the parenthetical category enumeration is informative rather than filler. Slightly dense, but nothing should be cut.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-required-parameter, single-boolean read tool with annotations and full schema coverage, the description covers purpose, return content, and follow-up usage. Only the explicit relationship to search_plugins is left implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and there is only one parameter, so the schema already documents include_plugins fully. The description's mention of '插件包名与数量' loosely maps to that toggle but adds no format or default detail beyond the schema, so the baseline 3 holds.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (列出) and resource (DSH 插件市场的分类), and even enumerates the six category values, so the agent knows exactly what comes back. It only implicitly distinguishes itself from search_plugins via '可用于后续按分类检索' rather than naming the sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for use: this is a discovery step that precedes category-based retrieval. It does not state when NOT to use it or name search_plugins directly as the alternative, so it stops short of the explicit routing a 5 requires.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
按关键词模糊搜索深鲸 DSH 插件市场（匹配包名、中英文标题、描述），可按分类过滤。不传 query 时按分类/默认顺序列出插件。返回插件名、简介、最新版本、DSH 兼容范围与安装命令。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 最多返回条数（1-50，默认 10） | |
| query | No | 搜索关键词，例如 "sbom"、"隐私"、"供应链" | |
| category | No | 分类 id 或中文名，例如 compliance / 合规、data / 数据、supply-chain / 供应链 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real behavioral context beyond that: which fields the fuzzy match spans, what happens when query is omitted, and what each result contains (名称、简介、最新版本、DSH 兼容范围、安装命令). Pagination/limit behavior is left entirely to the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: match scope first, fallback behavior second, return shape third. No filler and the most decision-relevant information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description correctly takes on the burden of enumerating returned fields, and it covers matching scope and the no-query fallback. Only minor gaps remain (no mention of ordering guarantees beyond '默认顺序' or how limit interacts with paging).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds semantics the schema does not carry: query performs a fuzzy match across package name, Chinese/English title and description (the schema only gives example keywords), and category acts as a filter over those results. limit semantics are left to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (按关键词模糊搜索 DSH 插件市场) and even names the fields matched (包名、中英文标题、描述), so an agent knows exactly what this returns. It does not, however, explicitly distinguish itself from siblings like get_plugin or list_categories, leaving that differentiation to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a useful conditional: 不传 query 时按分类/默认顺序列出插件, which implicitly covers the list-vs-search use case. But it never names get_plugin (single plugin lookup) or list_categories as alternatives, nor states when keyword search is inappropriate, so routing guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.2check_runtimeget_pluginlist_categoriessearch_pluginsScored across 4 tools
search_plugins, get_plugin, and check_runtime each target a clearly different operation (fuzzy search, single-package detail, compatibility check). list_categories partially overlaps with search_plugins since search supports category filtering, but it still adds distinct category enumeration and counts.
All four tools follow a consistent snake_case verb_noun pattern: search_plugins, get_plugin, list_categories, check_runtime. The convention is predictable and readable across the whole set.
Four tools is modest but well-matched to a read-only plugin catalog: discovery, detail, taxonomy, and compatibility. Nothing feels redundant, though the surface is somewhat thin for a marketplace.
The set covers search, single-plugin detail, category listing, and DSH version compatibility, which is most of the read-only lifecycle for a plugin registry. Minor gaps like explicit pagination or listing all plugins (partially covered by search with no query) are workable.
Search and get install details on MCP servers, right from your agent -- a unified marketplace index.
Search and inspect source-pinned agent skills, plugins and tools through a free public MCP.
Search your AI chat history (ChatGPT, Claude, Codex) from any MCP client. Remote, private, read-only
Search and install 4,000+ security-scanned MCP servers from inside any MCP-aware AI client.
