Skip to main content
Glama
hangboss1761

Spec-Driven MCP Server

by hangboss1761

create_spec

Manage spec-driven development from requirements to tasks, converting user input into structured specifications while intelligently routing workflow stages based on complexity.

Instructions

⚠️ 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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
stageNoJump 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_stageYesSpecify 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_promptNoUser 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'
Install Server

TDQS

A4.3/5.0
Behavior5/5

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.

Conciseness3/5

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.

Completeness4/5

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.

Parameters5/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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.

Other Tools

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