MCP SDD Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LOG_LEVEL | No | Log level: debug, info, warn, error | info |
| PLUGIN_DIR | No | Path to plugins directory | |
| MAX_PLUGINS | No | Maximum number of plugins (default 50) | |
| DEFAULT_LANG | No | Default language: en, es, fr, de, it, pt, ru, ja, zh, ko | en |
| HOOK_TIMEOUT | No | Hook timeout in milliseconds (default 10000) | |
| TEMPLATE_DIR | No | Path to templates directory | |
| SDD_ALLOW_TEMPLATE_FALLBACK | No | Set to true to allow fallback templates when module loading fails | false |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": true
} |
| resources | {
"subscribe": true,
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| sdd-initC | Initialize a governed SDD feature |
| sdd-requirementsC | Submit requirements artifact |
| sdd-designC | Submit design artifact |
| sdd-tasksC | Submit implementation tasks artifact |
| sdd-implementC | Begin implementation of approved tasks |
| sdd-statusA | Get one feature status or list all features |
| sdd-approveC | Approve an exact validated phase revision |
| sdd-review-test-casesC | Record review for an exact tasks revision |
| sdd-quality-checkC | Perform code quality analysis |
| sdd-context-loadC | Load phase-aware governed context |
| sdd-template-renderD | Render an optional SDD scaffold |
| sdd-steeringC | Create or update project steering documents |
| sdd-steering-customC | Create a custom steering document |
| sdd-validate-designD | Validate design artifact |
| sdd-validate-gapD | Analyze the implementation gap |
| sdd-spec-implC | Record governed implementation task progress |
| sdd-jev-checkD | Run an opt-in advisory JEV check |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| sdd-requirements-review | Generate comprehensive requirements review using EARS format |
| sdd-design-review | Perform technical design review with architecture analysis |
| sdd-linus-review | Apply Linus-style code review criteria with taste scoring |
| sdd-task-breakdown | Generate detailed task breakdown from design specifications |
| sdd-quality-gates | Evaluate project readiness for phase progression |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| SDD Project Specification Template | Template for project spec.json files |
| SDD Requirements Template | Template for requirements documents |
| Linus-style Code Review Guidelines | Code quality and review guidelines |
TDQS
Scored across 17 tools
Most tools map to distinct SDD workflow phases, but boundaries blur between artifact submission (sdd-design, sdd-tasks, sdd-requirements), validation (sdd-validate-design, sdd-validate-gap, sdd-quality-check), and governance actions (sdd-approve, sdd-review-test-cases, sdd-spec-impl). Descriptions help, but an agent could plausibly misselect among the validate/check/review tools.
The sdd- prefix is consistent, but the remainder mixes verb-first, noun-first, and bare-noun conventions: sdd-validate-design vs sdd-context-load vs sdd-design. This makes the set feel inconsistent even though each name is individually readable.
17 tools is borderline heavy for an SDD workflow server. The surface is large enough that governance, validation, artifact submission, and progress tracking each contribute multiple tools, risking cognitive load for agents selecting the right operation.
The lifecycle is broadly covered from init through requirements, design, tasks, implementation, quality checks, approval, and status. Minor gaps remain around reading or updating existing artifacts beyond submission and approval, plus no clear reset/delete path for features.