Click on "Install 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.
A Model Context Protocol (MCP) server that provides structured project specification management capabilities for AI editors through a specification-driven development workflow.
Specification-Driven Development: Kiro Spec-driven development for any AI tool that supports MCP
Related MCP server: Foundry MCP
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.
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/ directories
Copies 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
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 → tasks
Simple features: requirements → tasks (skip design)
Documentation only: requirements → complete
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 |
It is not recommended to install this as a global MCP tool. Please install it in your workspace.
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"
}
}
}
}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"
}
}
}
}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 criteria
design.md: Architecture design including component relationships
tasks.md: Implementation checklist with specific actionable tasks
pnpm watch # Development mode with auto-reload
pnpm build # Production buildMIT License
⚠️ 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
| Name | Required | Description | Default |
|---|---|---|---|
| stage | No | Jump directly to specified stage. Auto-detects current stage if not specified. 'requirements' requires requirements_prompt; 'design' requires requirements.md to exist; 'tasks' requires requirements.md to exist (design.md is optional); 'complete' returns completion message | |
| next_stage | Yes | Specify the next stage after current stage completion. 'design' means enter design stage, 'tasks' means enter tasks stage, 'complete' means workflow ends, 'null' is used when stage is 'complete'. Let LLM intelligently choose workflow path based on requirements complexity | |
| requirements_prompt | No | User requirements description. Required only for requirements stage. Used to convert user needs into structured specifications. Example: 'Implement user login functionality with email and phone number support' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so thoroughly. It discloses mandatory user-confirmation pauses, automatic stage detection, dependency validation, idempotent execution, error handling, and the fact that content generation is delegated to the LLM rather than performed by the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with markdown headings and a front-loaded critical warning, but it is heavily redundant. The user-confirmation protocol appears multiple times, and sections like 'Key Features' and 'User Responsibilities' add length without introducing operationally necessary information for invoking the tool correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is unusually complete for a complex orchestration tool: it covers workflow paths, stage dependencies, recovery, confirmation requirements, idempotence, and error guidance. It still leaves some gaps, such as not explaining the relationship or sequencing with the sibling init_spec_project, and not describing the return value above what the schema hints at.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already high, but the description adds substantial semantic value beyond the schema. It explains the complexity-analysis rules for next_stage, gives concrete examples for simple vs. complex vs. documentation requirements, and clarifies that requirements_prompt should capture the essence of the user's intent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening line clearly identifies the tool as an 'Intelligent workflow manager' that routes work through requirements → design → tasks and delegates content generation to the LLM. It does not explicitly distinguish itself from the sibling tool init_spec_project, but the workflow-scoped description is specific enough to convey what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'When to use this tool' section lists concrete scenarios such as starting spec-driven development, continuing interrupted workflows, jumping stages, and regenerating documentation. It also provides complete workflow-path examples. However, it never explicitly says when NOT to use it or how it relates to init_spec_project, so it lacks explicit exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden and handles it well: it discloses that the tool creates directories, copies templates, is idempotent, and does not generate content. It does not fully specify what happens to existing files on a reset, but the main side effects and safety profile are clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized and front-loaded, but it is longer than necessary for a zero-parameter tool: 'prepares the foundation' and 'prepares workspace' are near-duplicates, and the no-content-generation point is repeated three times. Structure helps, but the prose could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, sequencing relative to create_spec, side effects, idempotency, output, and next-step guidance. For a simple parameterless setup tool with no output schema, nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema leaves no gaps to explain. The description still supplies useful setup context, which is the baseline expectation for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-object statement: 'Initialize spec-driven project structure and templates.' It explicitly contrasts with content generation and names the sibling workflow by saying it prepares the workspace before create_spec, so an agent can distinguish it from create_spec.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
A dedicated 'When to use this tool' section lists concrete triggers: new project, user asks about setup, before first create_spec use, or resetting structure. The 'not content generation' and 'LLM Responsibility: None' statements clarify when not to rely on it for content work.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Project registry, behavioral specs, and engineering threads for AI coding agent workflows.
Design spec + milestones AI coding agents read before building; drift flagged, changes reviewed.
Turn PRDs and product ideas into structured specs so coding agents build your intent, not theirs.
AI-powered spec-to-task decomposition and execution orchestration for coding agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/hangboss1761/spec-driven-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
