sdd-mcp-server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_specsB | Lista specs legadas e features do pipeline SDD. |
| list_skillsB | Lista skills legadas e Agent Skills no formato SKILL.md. |
| get_skillC | Retorna o conteúdo de uma skill pelo nome do domínio. |
| validate_specC | Valida as seções obrigatórias de uma spec legada. |
| prepare_generation_contextC | Combina uma spec legada e uma skill em contexto para o agente. |
| steeringC | Lê ou inicializa a constituição em .kiro/steering/constitution.md. |
| spec-initC | Inicializa uma feature e cria o rascunho de requirements.md. |
| spec-requirementsC | Lê ou salva requirements.md. Salvar novamente remove aprovações downstream. |
| spec-designB | Lê ou salva design.md depois da aprovação dos requisitos. |
| spec-tasksC | Lê ou salva tasks.md depois da aprovação do design. |
| spec-approveC | Registra aprovação humana explícita para requisitos, design ou tarefas. |
| spec-implC | Prepara contexto TDD das tarefas aprovadas; o agente implementa no repositório. |
| spec-statusC | Mostra aprovações e progresso das tarefas de uma feature. |
| spec-feedbackC | Gera relatório de status ou análise de lacunas do workflow. |
| validate-designC | Valida as seções necessárias do design técnico. |
| validate-gapC | Compara aprovações e tarefas com um resumo fornecido da implementação. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 16 tools
Most tools target a clearly distinct stage or artifact (spec-init, spec-requirements, spec-design, spec-tasks, spec-approve, spec-impl). The main overlap is spec-status vs spec-feedback, both of which surface progress/status information, and the three validate_* tools differ only by target. Descriptions largely resolve these ambiguities.
The set mixes two conventions: snake_case (list_specs, get_skill, validate_spec, prepare_generation_context) and kebab-case (spec-init, spec-requirements, validate-design, validate-gap), plus a bare noun 'steering'. While the spec-* family is internally consistent, the overall pattern is unpredictable.
16 tools is borderline-heavy for a spec-driven-development server. Many serve a genuine lifecycle stage, but the validate_* trio and the status/feedback pair feel partially redundant, suggesting some tools could be consolidated.
The surface covers the full spec lifecycle: init, requirements, design, tasks, approval, implementation prep, status, feedback, plus skills/steering and validation. Minor gaps around editing/versioning of specs exist, but core CRUD-style workflows are covered without dead ends.