-
dsh-cert-mcp
by PerryLink
It is a read-only MCP server for querying the dsh-plugin-certification registry for DeepSeek Harness plugins.
get_certification(owner, repo)— return one plugin’s full certification record: grade, snapshot date, five-dimension evidence, veto, notes, or a not-found message.list_certified()— list all registry entries with repo, grade, snapshot, spec version, generation timestamp, count, and coverage caveat.certification_spec()— explain spec v1: the five dimensions, A–F grade scale, and veto rule.All tools are read-only, idempotent, need no credentials, and may use an optionally refreshed bundled registry snapshot.
Provides read-only certification records (grades, snapshot dates, and five-dimension evidence) for DeepSeek Harness plugins hosted on GitHub, enabling lookup of plugin certification before recommending or installing them.
dsh-cert-mcp
Non-official companion tool. Part of the DSH standards family; not a certification, accreditation, security audit, or official endorsement. Standard: https://github.com/PerryLink/dsh-standards. The
dsh.standardsblock is anot-runplaceholder, not a pass.
🧊 FROZEN — 2026-10-31. Reference only. No new certification features; the registry remains in
dsh-plugin-certification.
Maintenance status: 🧊 FROZEN
Frozen on 2026-10-31. This read-only MCP endpoint stays available as a reference integration; certification data is owned by dsh-plugin-certification.
English · 简体中文 · Español · Português · हिन्दी
dsh plugin --profile <name> add dsh-cert-mcpRead-only MCP server that exposes the dsh-plugin-certification registry: certification grades, snapshot dates and five-dimension evidence for DeepSeek Harness (DSH) plugins. Zero runtime dependencies, stdio transport.
Related MCP server: feedback-loop-mcp
Install
dsh plugin --profile web add github:PerryLink/dsh-cert-mcpgit clone https://github.com/PerryLink/dsh-cert-mcp
cd dsh-cert-mcp
node src/index.js # stdio serverRun it directly from the published npm package: npx dsh-cert-mcp.
Register in an MCP client
Claude Code:
claude mcp add dsh-cert -- node <path-to-repo>/src/index.jsClaude Desktop (claude_desktop_config.json):
{
"mcpServers": {
"dsh-cert": {
"command": "node",
"args": ["<path-to-repo>/src/index.js"]
}
}
}DSH: add it through dsh-mcp-panel as a stdio server, or any MCP client that supports stdio.
Install as a DSH bundle
The package declares dsh.bundle.patch → cordis.patch.yml, so it also installs as a DeepSeek Harness bundle:
# git channel (latest main)
dsh plugin --profile web add github:PerryLink/dsh-cert-mcp
# npm channel (published releases)
dsh plugin --profile web add dsh-cert-mcpThe inserted row loads the package through the standard Cordis plugin contract: the host half is a plain ESM module exporting name, inject and apply(ctx). This package ships no browser UI, so there is no dsh.client declaration.
// bundle entry (host half) — the contract the patch row loads
export const name = 'dsh-cert-mcp'
export const inject = ['tools'] // the host tool surface, provided by dsh-tools
export function apply(ctx) {
// registers the read-only certification lookup surface
// (get_certification / list_certified / certification_spec)
}The host half needs the tools service (shipped by @deepseek-ai/dsh-tools). A profile without it does not lose the tools silently: Cordis holds this row in PENDING until tools exists, which is visible in the profile's plugin list. Nothing else is required — no config keys, no credentials, and no network access at load time.
Two halves, one data path. The bundle row and the stdio server are separate entry points over the same handleRequest core. The server half is an independent process any MCP client can spawn (node src/index.js), and it is not part of the plugin path: installing this bundle never starts it, and removing the bundle never touches it. Conversely npx dsh-cert-mcp registers nothing on the DSH tool surface.
Remove the bundle with dsh plugin --profile web remove dsh-cert-mcp (or delete the row from the profile patch). The standalone stdio MCP server above keeps working for any MCP client.
What is dsh-cert-mcp?
Read-only MCP server that exposes the dsh-plugin-certification registry: certification grades, snapshot dates and five-dimension evidence for DeepSeek Harness (DSH) plugins. Zero runtime dependencies, stdio transport.
Workflow overview: install → open panel → act. The examples below use the real command surface.
Tools
Tool | Input | Returns |
|
| Full certification record (grade, snapshot, five dimensions, veto, notes) or "no record" |
| — | Every entry in the public registry: repo / grade / snapshot |
| — | Spec v1 summary: five dimensions, grade scale, veto rule |
The embedded snapshot lives in data/attestations.json (synced from the certification repo) and the server refreshes it from the public registry at most once per five minutes. No writes, no secrets, no code execution.
Why this exists
The DeepSeek Harness repository does not run a plugin registry and does not accept external PRs; discovery happens through the dsh-plugin GitHub topic and community lists, none of which certify anything. dsh-plugin-certification turns "can I install this plugin" into a reproducible five-dimension check (manifest, build hygiene, supply-chain Scorecard, release provenance, sandboxed install smoke test) with a public registry and README badges. This MCP server is the same data with an agent-facing interface: agents can look up a plugin's certification before recommending or installing it.
Registry
Data source: PerryLink/dsh-plugin-certification — data/attestations.json, spec v1.
What the registry is, and what a short answer from this server means. The
registry is an opt-in subset: a repository appears in it only after it has
been evaluated, so the absence of a record is not evidence that a plugin is
uncertified, and list_certified returning few rows is not evidence that few
plugins were assessed. The bundled snapshot held one entry (grade A, snapshot
2026-09-07) when this was written; a single-entry list carries no statistical
meaning — a grade describes that one repository, and rankable comparison across
plugins only becomes possible once the registry holds many. Every
list_certified reply carries a coverage object stating exactly this, so an
agent reading only the tool output cannot mistake the count for ecosystem
coverage. The snapshot's date is the certification repo's fact, not a
freshness promise from this server: it is synced byte-for-byte from
dsh-plugin-certification, which owns the schedule and the check.
Compatibility
Surface | Status |
Harness | DeepSeek Harness |
Node |
|
Declared host range |
|
Peer |
|
Development
pnpm install
pnpm run typecheck # the one type ruler: checkJs over the published host face
pnpm test # JSON-RPC smoke + the real-Cordis runtime suite
pnpm pack # the published tarballThe runtime suite mounts the REAL SystemPrompt/ToolRuntime registries and asserts that mounting this package puts all three certification tools into ctx.tools.schemas(), that disposing the fiber removes them again, and that a context without the tools service parks the plugin in PENDING. dsh --dump-config is deliberately not used as acceptance: a mounted row and a pending fiber look the same there.
There is deliberately one type ruler. @deepseek-ai/* resolves through this repo's own node_modules (the pinned devDependencies — the published line) and the package declares no DSH peer, so a second tsc configuration would be the same command over the same type universe. The typecheck:ci script is kept as the historical no-op duplicate (its only extra key is an empty paths: {}) for compatibility with existing references, not as a second face. The independent second piece of evidence is the runtime mount gate above.
PerryLink DSH Plugin Family
This project is part of the DeepSeek Harness plugin family from PerryLink. The roster stays collapsed below so every README keeps a short first screen; expand it to see every row and its status.
Plugin | Status |
🧊 FROZEN — see the repo README | |
🧊 FROZEN — see the repo README | |
🧊 FROZEN — see the repo README | |
🧊 FROZEN — see the repo README | |
🧊 FROZEN — see the repo README | |
🧊 FROZEN — see the repo README | |
🧊 FROZEN — see the repo README | |
🚫 RETIRED — see the repo README | |
🚫 RETIRED — see the repo README | |
🚫 RETIRED — see the repo README |
License
Apache-2.0. A listing or grade is an evidence record, not a security guarantee: plugins run inside your DSH process with your permissions.
Examples
These are the plugin's real entry points; install once, then call one.
Detailed example
Command
get_certificationInput
{
"owner": "PerryLink",
"repo": "dsh-auto-review"
}Output
{
"repo": "PerryLink/dsh-auto-review",
"grade": "A",
"snapshot": "2026-09-07",
"dimensions": {
"manifest": { "result": "pass" },
"buildHygiene": { "result": "pass" },
"supplyChain": { "result": "pass", "score": 5.4 },
"releaseIntegrity": { "result": "pass" },
"installSmoke": { "result": "ok" }
},
"veto": null
}Observed from plugins/dsh-cert-mcp/src/server.js:192-199; data in plugins/dsh-cert-mcp/data/attestations.json:1-30; smoke test at plugins/dsh-cert-mcp/test/smoke.mjs:29-39
Failure branch
Input
{"owner":"nobody","repo":"nothing"}Output
No certification record for nobody/nothing in registry snapshot 2026-09-07.Observed from plugins/dsh-cert-mcp/src/server.js:191-199; plugins/dsh-cert-mcp/test/smoke.mjs:41-47; plugins/dsh-cert-mcp/data/attestations.json
Brief examples
list_certifiedcertification_spec
Available Tools
3 toolscertification_specExplain the certification specARead-onlyIdempotent
Return the dsh-plugin-certification specification document, version 1: the five graded dimensions, the grade scale from A to F, and the veto rule that can override a grade. Use this to interpret a grade you have already read - for example to learn why a record was vetoed, or what a dimension actually measures. Use list_certified or get_certification instead when you want a specific plugin's data rather than the rules behind it. Read-only: the document is compiled into the server, takes no parameters, performs no writes and needs no credentials. The same document is returned on every call.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds genuinely new context beyond them: the document is compiled into the server, takes no parameters, needs no credentials, and returns the identical document on every call (version 1 is pinned). Only the "performs no writes / read-only" clause is redundant with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with what the document contains, then usage guidance, then behavioral facts, then the static-return note. Every sentence carries information, though the read-only/no-writes clause slightly overlaps the annotation hints and could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by summarizing what the returned document contains (dimensions, grade scale, veto rule) and notes that the content is static and version-pinned. An agent has everything needed to call and consume it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, so the baseline of 4 applies. The description correctly states the tool "takes no parameters," which matches the empty schema and removes any doubt about supplying input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ("Return the dsh-plugin-certification specification document, version 1") and enumerates the document's contents (five graded dimensions, A–F grade scale, veto rule). It explicitly distinguishes itself from both siblings, so an agent can route without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit use case ("interpret a grade you have already read - for example to learn why a record was vetoed") and an explicit counter-case with named alternatives ("Use list_certified or get_certification instead when you want a specific plugin's data rather than the rules"). When-to-use, when-not-to-use, and the alternatives are all present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_certificationGet one plugin certification recordARead-onlyIdempotent
Return the certification record for ONE DeepSeek Harness plugin repository, identified by its GitHub owner and repository name: the letter grade, the snapshot date the grade was measured, and the five-dimension evidence behind it. Use this when you already know which plugin you are asking about and need its grade, or the reasoning that produced it. Use list_certified instead to enumerate every certified plugin, and certification_spec instead to learn what the five dimensions, the grade scale and the veto rule mean. Read-only: it reads a registry snapshot bundled with this server. When the public registry is reachable the snapshot may be refreshed opportunistically; otherwise the embedded snapshot is used. It performs no writes, contacts no service other than that optional refresh, and requires no credentials. Two calls with the same arguments return the same record. If the registry holds no entry for that owner/repo, the result is a plain not-found sentence naming the key it looked up and the snapshot date - it never invents, interpolates or approximates a grade.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | Yes | GitHub repository name of the plugin, for example "dsh-auto-review". This is the repository name, not the npm package name. Matched case-insensitively. | |
| owner | Yes | GitHub owner (user or organisation) of the plugin repository, for example "PerryLink". Matched case-insensitively. |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, yet the description adds genuinely new context: reads a bundled registry snapshot, may opportunistically refresh when the registry is reachable, needs no credentials, is deterministic for identical arguments, and returns a plain not-found sentence rather than an invented grade. The one external-contact caveat is disclosed rather than hidden, which is the opposite of an annotation contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose in the first sentence, then routing, then behavioral caveats. Every sentence carries information, though the refresh/credentials/determinism block is dense enough that the definition runs longer than strictly needed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 return-value burden and does it: it names the letter grade, snapshot date and five-dimension evidence, and specifies the not-found response format. For a two-parameter lookup tool this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters, including case-insensitive matching and the repo-vs-npm-name distinction. The description restates that identification is by GitHub owner and repository name but adds no syntax or format detail beyond the schema; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Return the certification record for ONE ... plugin repository') and enumerates the returned content (letter grade, snapshot date, five-dimension evidence). It explicitly distinguishes itself from list_certified and certification_spec, so an agent can route without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit when-to-use condition ('when you already know which plugin you are asking about and need its grade, or the reasoning that produced it') and names both alternatives with the conditions that select them ('list_certified to enumerate', 'certification_spec to learn the dimensions/grade scale/veto rule'). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_certifiedList every certified pluginARead-onlyIdempotent
List every plugin in the public dsh-plugin-certification registry, each with its repository, letter grade and snapshot date, plus the registry spec version, its generation timestamp and the total count. The returned coverage object states what that count is and is not: the registry is an opt-in subset of the ecosystem (a plugin appears only after it was evaluated), so a short list — the bundled snapshot holds one entry — is not evidence that the ecosystem is uncertified, and a single-entry list supports no comparison across plugins. Read coverage before drawing any conclusion from count. Use this to discover what is in the registry, or to compare grades across plugins. Use get_certification instead when you already know the plugin and want its full five-dimension evidence; this tool returns the summary row only. Read-only: it reads the embedded registry snapshot (optionally refreshed from the public registry when reachable), takes no parameters, performs no writes and needs no credentials. Repeated calls are identical until the snapshot is refreshed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only/idempotent/non-destructive, and the description still adds substantive context beyond them: it reads an embedded snapshot optionally refreshed from the network when reachable, requires no credentials, performs no writes, and repeated calls are identical until refresh. It also discloses the crucial caveat that the registry is an opt-in subset, so a short list is not evidence of ecosystem non-certification.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the scope and returned fields before the caveat, which is good structure, but the coverage warning is somewhat belabored — the 'short list is not evidence' point is restated with a concrete example that occupies several clauses. Efficient overall but not maximally tight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 full burden and does so: it names every returned field (repository, letter grade, snapshot date, spec version, generation timestamp, total count, coverage object) and warns how to interpret count. An agent has everything needed to call it and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so per the baseline this dimension is inherently satisfied. The description correctly confirms there is nothing to pass ('takes no parameters'), though there is no additional parameter meaning to add.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List every plugin in the public dsh-plugin-certification registry') and enumerates the returned fields. It explicitly distinguishes itself from get_certification, noting this returns the summary row only, so an agent can separate the two siblings without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit positive cases ('discover what is in the registry, or compare grades across plugins') and an explicit exclusion with the alternative name ('Use get_certification instead when you already know the plugin and want its full five-dimension evidence'). Nothing about tool selection is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v0.2.9- Changed
get_certification2 fields changed- changed
Input schema / properties / owner / descriptionPrevious value: -"GitHub owner, e.g. PerryLink"New value: +"GitHub owner (user or organisation) of the plugin repository, for example \"PerryLink\". Matched case-insensitively." - changed
Input schema / properties / repo / descriptionPrevious value: -"GitHub repository name, e.g. dsh-auto-review"New value: +"GitHub repository name of the plugin, for example \"dsh-auto-review\". This is the repository name, not the npm package name. Matched case-insensitively."
3 tool updates
v0.1.0- First observed
certification_spec - First observed
get_certification - First observed
list_certified
TDQS
A4.6/5.0
Scored across 3 tools
Disambiguation5/5
Each tool targets a clearly distinct need: get_certification returns one plugin's record, list_certified enumerates the registry, and certification_spec returns the rules document. The descriptions explicitly cross-reference each other ('use list_certified instead when...'), leaving essentially no room for misselection.
Naming Consistency4/5
All names use snake_case, and two of three share the verb_ prefix pattern (get_certification, list_certified). Minor deviation: the noun forms differ (certification vs certified) and certification_spec drops the verb entirely, though it reads naturally as a document lookup.
Tool Count4/5
Three tools is on the lean side but proportionate for a read-only registry lookups service: single-record fetch, enumeration, and spec. Nothing feels padded or redundant, though it sits near the thin end of the 3-15 range.
Completeness4/5
The read-only surface covers the natural lifecycle: discover the registry, fetch a specific record with full evidence, and interpret the grading rules. Minor gap in that there is no filtering/search by grade or dimension, but agents can work around this by listing and reading records.
Maintenance
ActivityActive
ResponsivenessSyncing
Related MCP Connectors
Official MCP server for Certifier to issue, manage, and track certificates and badges.
SAM.gov MCP — Federal contract opportunities and entity registration data
Related MCP Servers
- MIT
- -
- AlicenseAqualityAmaintenanceMCP server for HUD housing data, enabling Fair Market Rent lookups, Section 8 income limits, and ZIP-to-county crosswalk mapping for affordable housing assessments.66 npmMIT