Spec-Driven MCP Server
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Spec-Driven MCP Server Start a new spec project with requirements and tasks for a simple calculator app."
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.
Spec-Driven MCP Server
A Model Context Protocol (MCP) server that provides structured project specification management capabilities for AI editors through a specification-driven development workflow.
Features
Specification-Driven Development: Kiro Spec-driven development for any AI tool that supports MCP
Related MCP server: Foundry MCP
Usage
Build a TODO Web app like Microsoft Todo, using Spec-driven development mode
Build a TODO Web app like Microsoft Todo, using Spec-driven development mode, just want the requirements and tasks stage, and then complete the workflow.
Tools
init_spec_project
Initialize the specification-driven project structure and templates.
Purpose: Create the foundational directory structure and template files required for specification-driven development.
Features:
Creates
.spec/and.spec/template/directoriesCopies default template files for requirements, design, and tasks
Idempotent operation (can be safely run multiple times)
Prepares workspace for subsequent specification generation
Parameters: No parameters required
create_spec
Start a specification-driven development workflow.
Parameters:
requirements_prompt(string, optional): User requirement description. Required for requirements stage. Used to convert user requirements into structured specifications.stage(enum, optional): Jump directly to specified stage ("requirements", "design", "tasks"). If not specified, automatically detects current stage.next_stage(enum, optional): Specify next stage after completion ("design", "tasks", null). Allows LLM to intelligently choose workflow path based on requirement complexity.
Workflow Stages:
Requirements: Analyze and document functional requirements
Design: Create technical architecture and implementation approach
Tasks: Break down implementation into actionable development tasks
Usage Patterns:
Complex features:
requirements → design → tasksSimple features:
requirements → tasks(skip design)Documentation only:
requirements → complete
Responsibility Matrix
Role | Core Position | Primary Responsibilities |
🤖 LLM | Intelligent Analyzer & Decision Maker | • Analyze requirement complexity and infer next_stage values• Generate all .spec/*.md file content• Make technical routing decisions based on complexity assessment• Process user requirements into structured requirements_prompt |
👤 User | Requirement Owner & Quality Controller | • Clearly express desired features and functionality• Review generated documentation to ensure it meets actual requirements• Control workflow progress (continue/restart/modify)• Provide project context that influences implementation decisions |
🔧 Tool | Workflow Orchestrator | • Automatically detect current stage and manage requirements → design → tasks progression• Validate workflow dependencies before stage transitions• Provide structured prompts for LLM content creation• Provide clear guidance when dependencies are missing or parameters are invalid |
Installation & Setup
It is not recommended to install this as a global MCP tool. Please install it in your workspace.
Claude Desktop
Add the following to your claude_desktop_config.json:
{
"mcpServers": {
"spec-driven": {
"command": "npx",
"args": ["-y", "spec-driven-mcp"],
"env": {
"SPEC_ROOT_DIR": "/path/to/workspace"
}
}
}
}VS Code / Cursor
Add the following to your .cursor/mcp.json or VS Code MCP settings:
{
"mcpServers": {
"spec-driven": {
"command": "npx",
"args": ["-y", "spec-driven-mcp"],
"env": {
"SPEC_ROOT_DIR": "/path/to/workspace"
}
}
}
}Template Customization
Edit template files in the .spec/template/ directory to customize the generated specification format. Each call to create_spec uses the latest template version to generate specification prompts.
Template Files:
requirements.md: User story format with acceptance criteriadesign.md: Architecture design including component relationshipstasks.md: Implementation checklist with specific actionable tasks
Development
pnpm watch # Development mode with auto-reload
pnpm build # Production buildLicense
MIT License
Available Tools
2 toolscreate_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:
After generating any .spec/*.md file, STOP and ask user for confirmation
Wait for user to explicitly state satisfaction with the generated document
Only proceed to next stage after receiving clear approval
If user is not satisfied, regenerate the current stage based on feedback
When to use this tool:
Starting spec-driven development process with user requirements
Continuing workflow from any interrupted stage
Jumping to specific development stages when dependencies are met
Regenerating any stage documentation with new insights
Managing complex project specification workflows
Converting user ideas into structured development plans
Orchestrating multi-stage development planning
Recovering from incomplete or partial specification states
Key features:
Mandatory intelligent next_stage inference - LLM must analyze and decide workflow routing
Automatic stage detection based on existing .spec/*.md files
Flexible stage jumping with dependency validation and clear error guidance
Optional design stage support (can skip requirements → tasks for simple features)
Intelligent workflow recovery from any point in the process
Structured LLM prompt generation with customizable templates
Real-time progress tracking and next-step guidance
Idempotent operations safe for multiple executions
Comprehensive error handling with actionable suggestions
Requirements Complexity Analysis (LLM MUST perform this):
Simple Requirements (single function, clear implementation path) → next_stage: "tasks" Examples: Add button, modify text, simple API call, UI tweaks, basic CRUD operations
Complex Requirements (multiple modules, complex logic, architectural design needed) → next_stage: "design" Examples: User authentication system, payment flow, data analysis module, multi-component features, system integrations
Documentation Requirements (pure documentation updates, no code implementation) → next_stage: "complete" Examples: API documentation updates, README modifications, specification documents, process documentation
Parameters explained:
requirements_prompt: Your analysis of user requirements that will be transformed into structured specifications. Required when starting requirements stage or when no existing requirements exist. Should capture the essence of what the user wants to build.
stage: Optional direct stage jump to specific workflow stage. Use when you want to skip auto-detection and go directly to "requirements", "design", or "tasks". Each stage has specific dependencies that will be validated.
next_stage: MANDATORY workflow routing decision that LLM must make based on requirements complexity analysis. Controls what happens after current stage completes. Set to "design" for complex features needing architecture, "tasks" for simple implementations, or "complete" to end workflow.
Usage Examples & Workflow Paths:
Complex feature: create_spec(requirements_prompt: "implement user authentication system", next_stage: "design") → requirements → design → tasks
Simple feature: create_spec(requirements_prompt: "add logout button", next_stage: "tasks") → requirements → tasks (skip design)
Documentation: create_spec(requirements_prompt: "update API documentation", next_stage: "complete") → requirements → complete
Continue workflow: create_spec() (auto-detects current stage and continues)
Jump to design: create_spec(stage: "design", next_stage: "tasks") (requires existing requirements.md)
Jump to tasks: create_spec(stage: "tasks", next_stage: "complete") (requires existing requirements.md)
LLM Responsibilities:
Analyze requirements complexity and intelligently infer appropriate next_stage value ("design"|"tasks"|"complete")
Generate all .spec/*.md file content based on structured prompts from the tool
Make technical routing decisions - choose workflow paths based on complexity assessment, not user preferences
Process user requirements into comprehensive requirements_prompt that captures intent and technical needs
User Responsibilities:
Express requirements clearly - describe what features or functionality they want to build
Confirm specification quality - review generated docs to ensure they match their actual needs
Control workflow progression - decide whether to continue, restart, or modify the development process
Provide project context - share relevant background information that affects implementation decisions
Tool Responsibilities:
Orchestrate workflow stages - automatically detect current stage and manage progression through requirements → design → tasks
Validate workflow dependencies - ensure required files exist before allowing stage transitions
Generate structured prompts - provide LLM with templates and context needed for content creation
Handle errors gracefully - provide clear guidance when dependencies are missing or parameters are invalid
Inputs: next_stage (required), stage, requirements_prompt.
init_spec_projectA
Initialize spec-driven project structure and templates. This tool focuses on workflow setup, not content generation.
Core Function:
Creates .spec/ and .spec/template/ directory structure
Copies default template files for requirements, design, and tasks
Prepares the foundation for LLM-driven content generation
Responsibility Separation:
Tool Responsibility: Directory creation, template file management
LLM Responsibility: None (this is purely setup)
User Responsibility: Project initialization decision
When to use this tool:
Starting a new spec-driven project
When users ask about spec-driven development setup
Before using create_spec tool for the first time
When project structure needs to be reset
Key Features:
Idempotent operation (safe to run multiple times)
Creates editable template files in .spec/template/
Prepares workspace for subsequent spec generation
No content generation, only structure creation
Output:
Clear initialization status feedback
Next step guidance for spec generation
Template customization instructions
Note: This tool is a prerequisite for create_spec and must be run first to establish the project structure.
Inputs: no named parameters.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
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.
Maintenance
Related MCP Connectors
Work management with Spec-Driven Development: tasks, sprints and SDD approvals for coding agents.
Project management shared by people and AI agents, with persistent project state through MCP.
Project memory for coding agents: requirements, decisions, code graph and delivery telemetry.
Design spec + milestones AI coding agents read before building; drift flagged, changes reviewed.
Related MCP Servers
- AlicenseAqualityDmaintenanceProvides structured spec-driven development workflow tools for AI-assisted software development with sequential spec creation (Requirements → Design → Tasks). Features a real-time web dashboard for monitoring project progress and managing development workflows.5637 npm4,307GPL 3.0
- AlicenseNot gradedqualityDmaintenanceEnables spec-driven development workflows with AI assistants, providing tools for managing specification lifecycles, task dependencies, code navigation, testing, and automated reviews through a unified CLI and MCP interface.4MIT
- AlicenseNot gradedqualityDmaintenanceTransforms AI agents into spec-driven product engineers by managing the software project lifecycle through requirements, design, implementation, and archiving phases with state-aware MCP tools.5 npmMIT
- AlicenseAqualityCmaintenanceEnables AI coding tools to follow a structured spec-driven development workflow with three phases: requirements, design, and tasks, ensuring approval before advancing.10MIT