Spec-Driven MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SPEC_ROOT_DIR | Yes | The root directory for the specification project. This is where the .spec folder will be created. |
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| init_spec_projectA | Initialize spec-driven project structure and templates. This tool focuses on workflow setup, not content generation. Core Function:
Responsibility Separation:
When to use this tool:
Key Features:
Output:
Note: This tool is a prerequisite for create_spec and must be run first to establish the project structure. |
| create_specA | ⚠️ MANDATORY USER CONFIRMATION: After each stage completion, MUST pause and wait for explicit user approval before proceeding to next stage. Do NOT automatically continue workflow without user's explicit "satisfied" or "approved" response. CRITICAL: LLM must intelligently infer next_stage based on requirements complexity. This is the tool's core value. Intelligent workflow manager for spec-driven development that delegates all content generation to LLM while managing workflow orchestration through requirements → design → tasks stages. User Confirmation Protocol:
When to use this tool:
Key features:
Requirements Complexity Analysis (LLM MUST perform this):
Parameters explained:
Usage Examples & Workflow Paths:
LLM Responsibilities:
User Responsibilities:
Tool Responsibilities:
|
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 2 tools
The two tools are clearly separated: init_spec_project handles project structure and template setup, while create_spec handles the entire specification generation workflow. There is no functional overlap between them, so an agent should never confuse which tool to invoke for a given task.
Both tool names use a consistent snake_case verb_noun pattern (init_, create_). The minor inconsistency is that one uses 'spec_project' and the other just 'spec', but the pattern is still predictable and readable.
With only two tools, the server feels thin at first glance, but the tools are well-scoped for a narrow workflow: setup and generation. The count is borderline because create_spec carries a very large orchestration responsibility that could arguably be split into separate stage-specific tools.
The core lifecycle of a spec-driven project is covered: initialization and requirements/design/tasks generation, including regeneration and workflow recovery. The main gap is the lack of dedicated tools to list, read, or delete generated spec documents, though create_spec's stage auto-detection partially compensates for this.