spec-driver-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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 | {} |
| resources | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| init-specA | Initialize a spec-driven development workspace for the current project. Creates a .spec/ directory that will hold three files:
Call this FIRST when user expresses intent to build, plan, design, analyze, or refactor. |
| write-spec-fileA | Write content to one of the three spec files. Use this to create or update requirements.md, design.md, or tasks.md. |
| read-spec-fileA | Read the content of one of the three spec files. Use this to review requirements, check design decisions, or see task status. |
| list-spec-filesB | List all spec files with their status (exists, size, task count). |
| update-taskA | Mark a task as done or pending in tasks.md. Use this during implementation to track progress. The task is identified by matching its text content (case-insensitive partial match). |
| get-task-summaryA | Get a summary of task completion status from tasks.md. |
| create-hookA | Register an automation hook for the spec workflow. Hooks define actions the AI should automatically perform when specific events occur. Events: on-requirements-confirmed, on-design-confirmed, on-tasks-confirmed, on-task-completed, on-implementation-done, on-spec-phase-change, on-user-request-change, manual Example: when a task is completed (on-task-completed), auto-run update-task to mark it [x]. |
| list-hooksA | List all registered hooks with their event type and description. Use this to review what automations are active. |
| delete-hookB | Remove a hook by name. |
| run-hooksA | Get all hooks matching a specific event type. The AI should call this when an event occurs and execute the matching hooks' instructions. For example, after completing implementation of a task, call run-hooks with event "on-task-completed" to find and execute all relevant hooks. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| requirements.md | requirements.md content |
| design.md | design.md content |
| tasks.md | tasks.md content |
| Spec Hooks | List of all registered hooks |
TDQS
Scored across 10 tools
Each tool has a clearly distinct purpose: hooks management (create/delete/list/run), spec file operations (init/read/write/list), and task tracking (get-task-summary/update-task). No overlap or ambiguity.
All tool names follow a consistent pattern of verb-noun (or verb-object) using lowercase with hyphens, e.g., 'create-hook', 'init-spec', 'update-task'. No mixing of conventions.
With 10 tools, the set is well-scoped for a spec-driven development workflow. It covers every necessary operation without being excessive or insufficient.
The tool surface covers the full lifecycle: initialization, file management, task tracking, and automation hooks. No obvious missing operations for the stated purpose.