Skip to main content
Glama
hangboss1761

Spec-Driven MCP Server

by hangboss1761

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
SPEC_ROOT_DIRYesThe 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

CapabilityDetails
tools
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
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.

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:

  • 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:

  1. Analyze requirements complexity and intelligently infer appropriate next_stage value ("design"|"tasks"|"complete")

  2. Generate all .spec/*.md file content based on structured prompts from the tool

  3. Make technical routing decisions - choose workflow paths based on complexity assessment, not user preferences

  4. Process user requirements into comprehensive requirements_prompt that captures intent and technical needs

User Responsibilities:

  1. Express requirements clearly - describe what features or functionality they want to build

  2. Confirm specification quality - review generated docs to ensure they match their actual needs

  3. Control workflow progression - decide whether to continue, restart, or modify the development process

  4. Provide project context - share relevant background information that affects implementation decisions

Tool Responsibilities:

  1. Orchestrate workflow stages - automatically detect current stage and manage progression through requirements → design → tasks

  2. Validate workflow dependencies - ensure required files exist before allowing stage transitions

  3. Generate structured prompts - provide LLM with templates and context needed for content creation

  4. Handle errors gracefully - provide clear guidance when dependencies are missing or parameters are invalid

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

Latest Blog Posts

MCP directory API

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