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 |
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 16 tools
Most tools map to distinct SDD phases, but sdd-implement and sdd-spec-impl could be confused as both relate to implementation, and sdd-steering vs sdd-steering-custom have overlapping purposes. The descriptions help but boundaries are not always crisp.
All tools share the 'sdd-' prefix, but the structure is mixed: some are verb-led (sdd-approve, sdd-validate-design), some are noun-led (sdd-requirements, sdd-status), and sdd-spec-impl uses an abbreviation, so the pattern is readable but inconsistent.
16 tools is slightly above the ideal 3-15 range, and several are highly specialized (sdd-context-load, sdd-template-render) that may not be used in every workflow, making the set feel a bit heavy for the domain.
The surface covers the full SDD lifecycle from init to implementation, including requirements, design, tasks, validation, quality, and steering. Minor gaps exist such as no general artifact update/review tool beyond test cases, but core workflows are well supported.