How do I use DPS-Superskills-MCP?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@DPS-Superskills-MCP list all skills" 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.

DPS-Superskills-MCP

by Eilodon

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Hybrid

The DPS-Superskills-MCP server exposes the DPS SuperSkills v5.2.1 framework as MCP tools, giving AI agents structured access to 31 software engineering skills, workflows, and knowledge management across 16 tools and 31 read-only resources.

Skill Tools

skill_list — Discover all 31 skills with descriptions and registers (DISCIPLINE, TECHNIQUE, KNOWLEDGE LAYER, REFERENCE); filter by register category
skill_read — Retrieve full SKILL.md content for any skill, with optional compressed nano version
skill_run — Invoke a skill with your task context to receive a structured workflow: ANNOUNCE, GOAL, CONSTRAINTS, CHECKLIST, OUTPUT TEMPLATE, active GOTCHAS, and NANO REFERENCE
Dispatch templates — Generate role-specific prompt templates (implementer, reviewer, specialist) for spawning focused subagents

Knowledge Base Persist, update, query, and monitor cross-session knowledge entries (gotchas, decisions, patterns, bug-patterns, domain terms) with health reporting on entry counts, stale items, and coverage gaps.

Code Retrieval Perform semantic code searches within your repository, build/refresh a local code index, and check index status.

DPS Spec Tools Initialize or validate the four core DPS living-spec files (README, CONTRACTS, BLUEPRINT, ADR) in your workspace. Validation via Python script is disabled under MCP_SAFE_MODE=true.

System Tools

super_mcp_ping — Health check confirming server and middleware status
super_mcp_pattern_debt — View the pattern-debt registry (implementation gates, runtime guards), with optional filtering

MCP Resources 31 read-only skill resources available for auto-injection by compatible MCP clients, with DISCIPLINE skills prioritized.

Skill Categories

DISCIPLINE (Iron Laws): complexity-gate, tdd-verified, verification-before-completion, context-reanchor, epistemic-health-check, privacy-secrets-gate
TECHNIQUE: brainstorming, systematic-debugging, specialist-review, session-handoff, dispatching-parallel-agents, and more
KNOWLEDGE LAYER: domain-alignment, knowledge-compound, audit-distill, adr-commit
REFERENCE: kb-query, skill-init, using-super-skills, framework-doctor, writing-super-skills

DPS SuperSkills MCP Server

DPS SuperSkills v5.2.1 deployed as an MCP server — exposes 16 MCP tools plus 31 read-only skill resources for any MCP-compatible client (Claude Desktop, Cursor, VS Code, Windsurf, Antigravity, or any IDE/chatbot supporting MCP).

Package: dps-superskills-mcp Default transport: stdio Skills content: docs/DPS-superskills-v5.2.1/ (31 skills, 31 nano references) Runtime entrypoint: dist/index.js Base layer: SUPER-MCP Framework (TypeScript / ESM)

DPS SuperSkills — MCP Tools & Resources

This server exposes both MCP Tools (for on-demand invocation) and MCP Resources (for context auto-injection) to give any AI agent structured access to the full DPS SuperSkills v5.2.1 framework.

MCP Resources

All 31 skills are exposed as read-only MCP Resources at skill://<name> (for example, skill://using-super-skills or skill://complexity-gate). Resource annotations prioritize DISCIPLINE skills so clients that support resource ranking can inject the Iron Laws first. Compatible MCP clients can discover the skill://{skill_name} template, call resources/list, and read individual skills with resources/read. When resources are enabled, the server advertises standard MCP resources capability during initialize.

Note: Resources inherit the SUPER-MCP governance pipeline scaled by endpoint: resources/read enforces rate-limiting, quota, and Output Firewall (like Tools); resources/list enforces rate-limiting and quota; resources/templates/list is lightweight discovery. Enabled by default; can be disabled via MCP_ENABLE_SKILL_RESOURCES=false.

MCP Tools

Skills (skills.tool.js — 5 tools)

MCP Tool	Purpose
`skill_list`	List all 31 skills with descriptions, register (DISCIPLINE / TECHNIQUE / KNOWLEDGE LAYER / REFERENCE), and curated `suggested next:` routing hints. Optionally filter by register.
`skill_read`	Return the full SKILL.md content for a specific skill. Optionally include nano (compressed) version.
`skill_run`	Invoke a skill with caller context. Returns the structured workflow (ANNOUNCE, GOAL, CONSTRAINTS, CHECKLIST, OUTPUT TEMPLATE, active GOTCHAS, NANO REFERENCE) scaled by `depth` (`nano` / `checklist` / `full`). Set `format="json"` to also receive a `structuredContent` payload for agent-to-agent dispatch.
`skill_dispatch`	Generate a role-specific prompt template (implementer / reviewer / specialist) for spawning a focused subagent, pre-loaded with tier-appropriate skills and nano references. C0 tasks return a simplified "implement directly" prompt.
`skill_search`	Search skills by keyword across names, descriptions, and registers. Use when unsure which skill applies — faster than reading `skill_list` manually.

Knowledge base (knowledge.tool.js — 4 tools, persistent cross-session memory)

MCP Tool	Purpose
`kb_write`	Record a single knowledge entry (`gotcha` / `pattern-debt` / `domain-term` / `decision` / `bug-pattern`) to `docs/superskills/<category>.md` by default, or `MCP_KB_PATH/<category>.md` when overridden. Slug is validated as kebab-case. Active gotchas auto-inject into future `skill_run` responses.
`kb_update`	Update an existing KB entry in-place by slug. Use when a gotcha or decision is no longer accurate and needs replacing.
`kb_query`	Search the KB. Default returns a compact `id + 1-line summary` per match (token-efficient); pass `detail=true` for full entry bodies. Supports `category` filter and `limit`.
`kb_health`	Report entry counts per category, flag stale entries (>90 days), and surface coverage gaps.

Code retrieval (code_index.tool.js — 3 tools, local data-plane over the user's repo)

MCP Tool	Purpose
`code_search`	Semantic-ish local code search (native zero-dependency BM25 + symbol/path/proximity rerank). Use instead of grep+read to locate where something is implemented — returns the most relevant chunks as `path:line` + a match-centred preview, typically ~80–97% fewer tokens. Auto-builds the index on first use (gitignored cache in `<workspace>/.dps/index/`; disable with `MCP_INDEX_AUTO=false`). Fuses DPS spec files (`source=spec`) when present.
`code_index`	Build / incrementally refresh the local index. Only changed files (size+mtime) are re-read; a no-op refresh short-circuits in ~25ms.
`code_index_status`	Report whether the index exists, its manifest, and how stale it is (added/modified/removed files).

DPS living-spec (dps.tool.js — 2 tools)

MCP Tool	Purpose
`dps_init`	Initialize/inject the 4 DPS living-spec files (README/CONTRACTS/BLUEPRINT/ADR) into `<workspace>/.dps/spec/` from the bootstrap templates. Detects an existing spec and asks for consent (MCP elicitation, or explicit `confirm=true`). Pure filesystem → runs under safe mode.
`dps_check`	Validate the DPS spec via `dps.py` (every `Ref<X>` resolves to CONTRACTS, single-definition rule, version sync). Requires `python3` (degrades to a manual checklist). Spawns a process → disabled under `MCP_SAFE_MODE=true`.

System (system.tool.js — 2 tools)

MCP Tool	Purpose
`super_mcp_ping`	Health check — confirm the server is alive and responding.
`super_mcp_pattern_debt`	View the active pattern-debt registry.

31 Skills Available

DISCIPLINE (Iron Laws — non-negotiable): complexity-gate · tdd-verified · verification-before-completion · context-reanchor · epistemic-health-check · privacy-secrets-gate

TECHNIQUE (Goal + constraints — adapt approach): brainstorming · dps-init · audit-design · dps-promote · writing-plans · task-risk-score systematic-debugging · pattern-globalize · specialist-review · release-readiness subagent-driven-development · executing-plans · dispatching-parallel-agents receiving-code-review · using-git-worktrees · session-handoff

KNOWLEDGE LAYER (Cross-cycle compounding): domain-alignment · knowledge-compound · audit-distill · adr-commit

REFERENCE (Lookup only): kb-query · skill-init · writing-super-skills · framework-doctor · using-super-skills

Related MCP server: mcp-ai-agent-guidelines

Client Configuration

To automatically generate the correct configuration with absolute paths for your environment, run:

./install.sh

Manual Configuration (Claude Desktop / Claude Code / Cursor / Antigravity / Codex)

Replace <absolute-path-to> with your actual full path, or run ./install.sh to get it pre-filled.

MCP_SAFE_MODE=false is required for dps_check (it spawns python3 — process.spawn is blocked in safe mode). Everything else runs under safe mode: kb_write / kb_update use the local kb.write capability, and code_search / code_index / dps_init only write into the workspace (fs.write.workspace). Use false when you want the full tool set including dps_check; use true for the smallest local permission profile when you do not need DPS linting.
MCP_WORKSPACE_ROOT — the code retrieval + DPS tools operate on the user's project. Under stdio they default to the server's working directory (process.cwd()); if your IDE does not launch the server with the project as cwd, set MCP_WORKSPACE_ROOT to the absolute project path. Under http (remote/control-plane) the indexer disables itself.

{
  "mcpServers": {
    "dps-superskills": {
      "command": "node",
      "args": ["<absolute-path-to>/DPS-Superskills/dist/index.js"],
      "env": {
        "TRANSPORT_DRIVER": "stdio",
        "STORAGE_DRIVER": "fs",
        "MCP_SAFE_MODE": "false",
        "MCP_PLUGIN_ALLOWLIST": "system.tool.js,skills.tool.js,knowledge.tool.js,code_index.tool.js,dps.tool.js",
        "MCP_PLUGIN_ISOLATION_MODE": "policy",
        "MCP_ENABLE_SKILL_RESOURCES": "true",
        "MCP_PROJECT_ID": "dps-superskills",
        "MCP_TENANT_ID": "tenant_local"
      }
    }
  }
}

VS Code / Windsurf (stdio)

{
  "mcp": {
    "servers": {
      "dps-superskills": {
        "command": "node",
        "args": ["<absolute-path-to>/DPS-Superskills/dist/index.js"],
        "env": {
          "TRANSPORT_DRIVER": "stdio",
          "STORAGE_DRIVER": "fs",
          "MCP_SAFE_MODE": "false",
          "MCP_PLUGIN_ALLOWLIST": "system.tool.js,skills.tool.js,knowledge.tool.js,code_index.tool.js,dps.tool.js",
          "MCP_PLUGIN_ISOLATION_MODE": "policy",
          "MCP_ENABLE_SKILL_RESOURCES": "true",
          "MCP_PROJECT_ID": "dps-superskills",
          "MCP_TENANT_ID": "tenant_local"
        }
      }
    }
  }
}

Cursor (`~/.cursor/mcp.json` or `.cursor/mcp.json`)

{
  "dps-superskills": {
    "command": "node",
    "args": ["<absolute-path-to>/DPS-Superskills/dist/index.js"],
    "env": {
      "TRANSPORT_DRIVER": "stdio",
      "STORAGE_DRIVER": "fs",
      "MCP_SAFE_MODE": "false",
      "MCP_PLUGIN_ALLOWLIST": "system.tool.js,skills.tool.js,knowledge.tool.js,code_index.tool.js,dps.tool.js",
      "MCP_PLUGIN_ISOLATION_MODE": "policy",
      "MCP_ENABLE_SKILL_RESOURCES": "true",
      "MCP_PROJECT_ID": "dps-superskills",
      "MCP_TENANT_ID": "tenant_local"
    }
  }
}

Quick Start

# Option A — auto build + print IDE configs with your absolute paths:
./install.sh

# Option B — manual:
pnpm install --frozen-lockfile
pnpm build
# Then copy a config block from docs/MCP-CONNECT.md into your IDE

Project Structure

.
├── docs/DPS-superskills-v5.2.1/         <- 31 skills content (SKILL.md + nano.md)
│   ├── <skill-name>/SKILL.md
│   ├── <skill-name>/<skill-name>.nano.md
│   ├── shared/                          <- gotcha-schema, claim-grammar, etc.
│   ├── bootstrap-templates/
│   ├── quickstarts/
│   ├── tools/
│   └── README.md
├── docs/MCP-CONNECT.md                  <- IDE connection guide (all configs)
├── install.sh                           <- build + print IDE configs with abs paths
└── src/
    ├── index.ts
    ├── skills/                          <- DPS SuperSkills MCP bridge layer
    │   ├── skill_loader.ts              <- SKILL.md / nano.md parser + cache
    │   ├── skill_registry.ts            <- 31-skill static registry
    │   └── skill_executor.ts            <- structured workflow formatter
    ├── plugins/
    │   ├── skills.tool.ts               <- skill_list, skill_read, skill_run, skill_dispatch, skill_search
    │   ├── knowledge.tool.ts            <- kb_write, kb_update, kb_query, kb_health
    │   ├── code_index.tool.ts           <- code_search, code_index, code_index_status
    │   ├── dps.tool.ts                  <- dps_init, dps_check
    │   └── system.tool.ts               <- super_mcp_ping, super_mcp_pattern_debt
    ├── core/indexer/                    <- zero-dep BM25 code retrieval (walker, chunker, bm25, store)
    ├── core/dps/                        <- DPS spec scaffold + dps.py wrapper (init.ts)
    └── ...                              <- Layer 0 (SUPER-MCP runtime)

At runtime, the code-retrieval + DPS tools materialize a folder inside the user's own project (never this repo):

<user-project>/.dps/
├── spec/        <- DPS living-spec: README/CONTRACTS/BLUEPRINT/ADR.md (tracked)
├── agent/       <- generated projection sidecars (tracked)
├── index/       <- local code index cache (gitignored)
└── DPS_INDEX.yml, DPS_LOCK.yml

By default the server reads skills from <project_root>/docs/DPS-superskills-v5.2.1. Override with:

MCP_SKILLS_PATH=/custom/path/to/skills

The persistent knowledge base defaults to <project_root>/docs/superskills. Override it when you want project-local or test-isolated KB files:

MCP_KB_PATH=/abs/path/to/docs/superskills

Code-retrieval / DPS tools:

# Project root the indexer + DPS tools operate on (defaults to cwd under stdio).
MCP_WORKSPACE_ROOT=/abs/path/to/your/project
# Set false to stop code_search from auto-building the index on first use.
MCP_INDEX_AUTO=true

Layer 0: SUPER-MCP Runtime

This MCP server is built on top of the hardened SUPER-MCP Boilerplate (Layer 0).

While the primary focus of this project is the DPS SuperSkills implementation, the underlying architecture provides:

Dual transports: Native support for both stdio and http.
Durable Storage: Extensible storage (fs, Redis) for task and state persistence.
Output Firewall: Redaction of sensitive data before returning to the LLM.
Security Primitives: Capability-based safety policies (MCP_SAFE_MODE), plugin allowlisting, and native tasks support.

(Note: Advanced configuration options for Redis, KMS encryption, OAuth, and HTTP deployments inherited from SUPER-MCP are supported but omitted from this README for brevity, as the standard local stdio usage is recommended for IDEs and Chatbots).

Available Tools

5 tools

skill_listA

Read-onlyIdempotent

List all available DPS SuperSkills v5.2.1 skills with their descriptions and register (DISCIPLINE / TECHNIQUE / KNOWLEDGE LAYER / REFERENCE). Use this first to discover which skill to invoke.

ParametersJSON Schema

Name	Required	Description	Default
`register`	No	Filter by register. Omit to list all skills.

TDQS

A4.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, fully covering safety and idempotency. The description adds context about the data returned (descriptions and register) but no further behavioral traits, so the bar is met with modest additional value.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no waste: first defines functionality, second provides usage directive. Perfectly front-loaded and efficient.

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?

For a simple list tool with one optional parameter and no output schema, the description is complete. It covers what the tool returns, how to use it, and is supported by annotations. An agent has all needed information to invoke it correctly.

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 schema already describes the 'register' parameter with enum values, but the description adds the crucial behavior 'Omit to list all skills', which is not in the schema. This provides meaningful guidance beyond what the schema offers.

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 clearly states the tool lists available skills with descriptions and register, and it distinguishes itself from siblings like 'skill_read' and 'skill_run' by indicating it is a discovery tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Use this first to discover which skill to invoke', providing clear context for when to use. It does not mention when not to use or alternatives, but the guidance is sufficient and unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

skill_readA

Read-onlyIdempotent

Return the full SKILL.md content for a specific DPS SuperSkill. Use when you need the raw, complete skill definition including all examples and pressure tests. For a structured executable workflow, use skill_run instead.

ParametersJSON Schema

Name	Required	Description	Default
`skill_name`	Yes	The skill slug to read (e.g. 'brainstorming', 'complexity-gate').
`include_nano`	No	Also include the nano (compressed) version. Default: false.

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=true and idempotentHint=true. Description adds context that it returns full content including examples and pressure tests. Could mention that it returns raw markdown to be more explicit, but overall sufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no fluff. The first sentence states the purpose, the second provides usage guidance. Front-loaded and efficient.

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?

For a simple read tool with 2 parameters and no output schema, the description covers all essential aspects: purpose, when to use, behavioral note about content, and sibling differentiation.

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 coverage is 100%, so baseline 3 applies. Description doesn't add additional semantics beyond the schema's parameter descriptions: skill_name accepts an enum of slugs, include_nano is a boolean for including a compressed version.

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 clearly states the action ('Return the full SKILL.md content') and the resource ('specific DPS SuperSkill'). It distinguishes from the sibling skill_run by noting the alternative use case.

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?

Explicitly says when to use ('when you need the raw, complete skill definition') and when not to, providing a direct alternative: 'For a structured executable workflow, use skill_run instead.'

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

skill_runA

Read-onlyIdempotent

Invoke a DPS SuperSkill v5.2.1 with your task context. Returns a structured workflow response: ANNOUNCE statement, GOAL, CONSTRAINTS, CHECKLIST (ready to execute), OUTPUT TEMPLATE (pre-labeled), active GOTCHAS with do-instead guidance, and NANO REFERENCE.

Tip: Run skill_list first if unsure which skill to use. Run complexity-gate before other skills for software tasks.

ParametersJSON Schema

Name	Required	Description
`skill_name`	Yes	The skill to invoke. Examples: 'complexity-gate', 'brainstorming', 'systematic-debugging', 'verification-before-completion'.
`task_description`	No	What you are working on. Be specific: include the feature name, file, component, or error message relevant to this skill invocation.
`context`	No	Additional project context: tech stack, team size, existing constraints, or relevant file paths.
`error_message`	No	For debugging skills: the exact error text, stack trace excerpt, or unexpected behavior description.
`query`	No	For kb-query: the search term (topic, decision, module name) to look up.
`mode`	No	Optional mode hint passed to the skill (e.g. 'C3' for complexity-gate, 'STRIDE' for specialist-review, 'SOLO' for session-handoff).

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, destructiveHint, and idempotentHint. The description adds context by listing the structured response elements (ANNOUNCE, GOAL, etc.), but does not detail side effects or auth needs, which is acceptable given the annotations cover safety.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences plus a tip, all front-loaded with the main purpose. Every sentence adds value with no redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 6 parameters (1 required) and no output schema, the description covers the output structure in detail, provides usage tips, and states the tool's purpose. It is nearly complete, though a brief note on return format (already partially given) could further enhance completeness.

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 baseline is 3. The description does not elaborate on individual parameters beyond what the schema provides, but the overall context 'with your task context' is minimally additive.

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 clearly states it invokes a DPS SuperSkill v5.2.1 with task context, providing a specific verb and resource. It distinguishes from siblings by including a tip to use skill_list first if unsure, contrasting with listing or reading skills.

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?

Explicit tips are provided: 'Run skill_list first if unsure which skill to use' and 'Run complexity-gate before other skills for software tasks,' offering clear guidance on when to use this tool versus alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

super_mcp_pattern_debtA

Read-onlyIdempotent

Read-only report of documented pattern-debt items, implementation gates, and runtime guards.

ParametersJSON Schema

Name	Required	Description	Default
`debt_id`	No	Optional pattern-debt id to inspect.
`include_implemented`	No	Include implemented/closed debt items in the report.

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readonlyHint=true and idempotentHint=true, so the description's 'Read-only' aligns but adds context about the content of the report (pattern-debt items, gates, guards), providing value beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence with no wasted words. Efficiently conveys purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only report with 2 optional parameters and complete annotations, the description covers the key aspects. It could explain what 'implementation gates' and 'runtime guards' are, but these may be domain terms.

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 description does not need to add parameter details. It adds no additional meaning beyond the schema.

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 clearly states it is a read-only report, identifies the specific resources (pattern-debt items, implementation gates, runtime guards), and distinguishes from sibling tools that deal with skills or ping.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for inspection due to 'Read-only report', but does not explicitly mention when to use or when to avoid this tool, nor does it contrast with sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

super_mcp_pingA

Read-onlyIdempotent

Ping server để kiểm tra trạng thái và pipeline middlewares.

ParametersJSON Schema

Name	Required	Description	Default
`message`	No	Tin nhắn ping

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that it checks status and middlewares, but does not contradict annotations. It provides minimal extra behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, focused sentence with no unnecessary words. It is front-loaded and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool is a simple ping with one optional parameter and rich annotations, the description covers the core purpose. It lacks detail on the return value, but for a ping tool this is acceptable.

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 has one parameter with description 'Tin nhắn ping' (ping message). Schema coverage is 100%, so baseline is 3. Description does not add meaning beyond the schema.

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 clearly states the tool pings a server to check status and pipeline middlewares. The verb 'Ping' and resource 'server' are specific, and the tool is distinct from its siblings (skill_list, skill_read, etc.).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when or when not to use this tool, nor any alternatives mentioned. The description only states what it does, not the context of use.

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. Dates show when Glama detected each change.

5 tool updatesv1.0.0Jun 23, 2026
- First observedskill_list
- First observedskill_read
- First observedskill_run
- First observedsuper_mcp_pattern_debt
- First observedsuper_mcp_ping

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.3/5.0

Scored 2026-06-23 16:55 across 5 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: listing skills, reading full definitions, running skills with workflow, checking pattern debt, and pinging server status. No overlap in functionality.

Naming Consistency5/5

All tool names follow snake_case with a consistent prefix per group: 'skill_' for core skill operations and 'super_mcp_' for server utilities. The pattern is predictable and uniform.

Tool Count5/5

With 5 tools, the server is well-scoped for its purpose of managing and invoking DPS SuperSkills. Each tool covers an essential operation without bloat or deficiency.

Completeness5/5

The tool surface covers the full lifecycle expected for a skills server: discovery (list), full definition retrieval (read), execution (run), plus supporting utilities for debt management and health check. No obvious gaps.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

SkillRepoOAuth
dev.skillrepo
Governed AI agent skills — one library, distributed to devs and exposed to remote agents over MCP.
Agent Orchestration Autonomous Agents Developer Tools
2
weavzOAuth
io.weavz
Governed app access for AI agents: 1,000+ apps & 12,000+ tools via Code Mode MCP.
Agent Orchestration Developer Tools
2
mcp-knowledge C
io.github.getgapup
100+ MCP tools for AI agents: content metadata, trade intelligence, business-expertise analysis.
Knowledge & Memory Research & Data RAG Systems
2792
SkillDBOAuth
io.github.devchad-cmd
A registry of 5,900+ peer-authored skills any MCP agent can search and load on demand.
Agent Orchestration Search
2

Related MCP Servers

Claude Rules MCP Server
Documentation Access Knowledge & Memory
jeremykenedy
A
license
A
quality
C
maintenance
Serves 484 Claude Code skills and 17 global rules as MCP tools, enabling skill and rule retrieval, keyword search, and project-level rule discovery for any Claude client.
Updated a month ago (2026-08-09 07:22 UTC)
11
13
2
MIT
mcp-ai-agent-guidelines
Developer Tools Agent Orchestration Code Analysis
Anselmoo
A
license
Not graded
quality
B
maintenance
A TypeScript ESM MCP server exposing 20 public instruction tools and 7 utility tools, backed by 102 internal skills across 18 domain families — from requirements discovery and code quality through governance, resilience, and physics-inspired analysis.
Updated 4 days ago (2026-09-05 09:23 UTC)
196
6
MIT
skillsmcp
Coding Agents Autonomous Agents
aviddiviner
A
license
A
quality
D
maintenance
Exposes Agent Skills to AI agents as MCP tools, enabling discovery and activation of skill instructions for coding agents.
Updated 5 months ago (2026-04-08 23:46 UTC)
3
27
MIT
Skill7
Developer Tools AI & Machine Learning Knowledge & Memory
Abderraouf-yt
A
license
A
quality
D
maintenance
Provides 634+ curated production-ready AI skills for any MCP-compatible client, covering areas like security, frontend, backend, infrastructure, AI/ML, and architecture. Enables AI agents to access best practices, patterns, and solutions across multiple domains.
Updated 7 months ago (2026-02-07 10:40 UTC)
6
12
1
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Eilodon/DPS-Superskills-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

DPS SuperSkills MCP Server

DPS SuperSkills — MCP Tools & Resources

MCP Resources

MCP Tools

31 Skills Available

Client Configuration

Manual Configuration (Claude Desktop / Claude Code / Cursor / Antigravity / Codex)

VS Code / Windsurf (stdio)

Cursor (~/.cursor/mcp.json or .cursor/mcp.json)

Quick Start

Project Structure

Layer 0: SUPER-MCP Runtime

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Cursor (`~/.cursor/mcp.json` or `.cursor/mcp.json`)