Skip to main content
hc
Submit
mcpSource-backed

Spec Workflow MCP Server

MCP server for spec-driven development workflows, requirements, design docs, task breakdowns, approvals, implementation logs, and a real-time dashboard.

by Pimzino · submitted by oktofeesh1·added 2026-06-05·
Claude CodeCodexCursorClaude Desktop
HarnessClaude CodeCodexCursorClaude Desktop
Review first — review before installing

Open the source and read safety notes before installing.

Citation facts

Source-backed facts for citing this resource, derived directly from the registry — also available as plain text for AI assistants.

Canonical URL
https://heyclau.de/entry/mcp/spec-workflow-mcp-server
Source URLs
https://github.com/Pimzino/spec-workflow-mcp/blob/main/README.md, https://github.com/Pimzino/spec-workflow-mcp
Brand
Spec Workflow MCP
Brand domain
github.com
Safety notes
Spec Workflow MCP writes requirements, design, task, steering, approval, archive, and implementation-log files under `.spec-workflow`., The dashboard uses a local web server and WebSocket updates; keep it bound to localhost unless you add external authentication, TLS, and network restrictions., The README documents rate limiting, audit logging, security headers, default localhost binding, and CORS restrictions, but also notes that built-in HTTPS/TLS and user authentication are not yet implemented., Task and approval tools can make an agent appear to advance project state; require human review before accepting specs, completing tasks, or using generated implementation prompts., Docker deployment should be reviewed for volume mounts, writable directories, and dashboard exposure before using it in shared environments.
Privacy notes
Requirements, designs, task lists, steering documents, approval comments, implementation logs, filenames, project paths, prompts, and task progress may be visible to the MCP client and model provider., Persistent global state may be stored under `SPEC_WORKFLOW_HOME`, including active project registry, dashboard session data, settings, job history, and migration logs., The `.spec-workflow` directory can contain unreleased product plans, architecture decisions, customer requirements, and implementation details., Review generated specs, logs, approval files, and dashboard screenshots before committing, sharing, or uploading them.
Author
Pimzino
Submitted by
oktofeesh1
Claim status
unclaimed
Last verified
2026-06-05

Decision playbook

Review trust signals before you adopt

Signals are present but mixed. Use the checklist below to confirm the source and operational safety for your environment.

Compare context
Selected

0

Current score

63

Baseline

—

Delta

No baseline selected

No major trust-signal divergence detected in the current selection.

Source and provenance checks

Needs review

Confirm ownership and provenance before trusting install instructions.

  • Source link availableRequired

    Open the canonical repository and verify ownership.

    Done

  • Source provenance statusRequired

    Marked as source-backed.

    Done

  • Metadata reviewed

    No reviewed flag detected in metadata.

    Pending

Safety and privacy checks

Complete

Validate risk disclosures before installation or API wiring.

  • Safety notes presentRequired

    Review the listed safety guidance before running commands.

    Done

  • Privacy notes presentRequired

    Review data handling notes before connecting accounts or secrets.

    Done

  • Trust level risk gateRequired

    Trust level does not block evaluation.

    Done

Package and install checks

Needs review

Check package metadata and artifact integrity signals.

  • Install payload available

    Install or copy payload is available for review.

    Done

  • Package verification flag

    No package verification flag provided.

    Pending

  • Checksum metadata

    No checksum provided for downloaded artifact.

    Pending

Compare-driven decision checks

Needs review

Use compare context to validate trade-offs before adoption.

  • Compare tray has multiple entries

    Add at least one more entry to compare trust differences.

    Pending

  • Baseline comparison available

    No baseline peer selected yet.

    Pending

  • Diverging trust signals identified

    No major trust-signal divergence found.

    Pending

Setup at a glance

CLI install

Copy-ready — paste the snippet to get started.

10 minutes

Install command

Provided

Config snippet

Provided

Copy snippet

Provided

Prerequisites

5 to clear

Platforms

4 listed

Install type

CLI install

Adoption plan

Balanced adoption plan

Current risk score 24/100. Use staged verification before broader rollout.

Risk 24

Pre-adoption checks

Validate source and review signals before any execution.

  • Confirm source provenanceRequired

    Source URL/provenance metadata is present.

    Done

  • Confirm metadata review state

    No review metadata found; increase manual validation.

    Pending

  • Verify install payload

    Install/config payload exists and can be inspected.

    Done

Security checks

Confirm safety, privacy, and package integrity signals.

  • Review safety notesRequired

    Safety notes are present.

    Done

  • Review privacy notesRequired

    Privacy notes are present.

    Done

  • Verify package integrity metadata

    No package verification/checksum metadata.

    Pending

Rollout

Adopt in controlled steps based on the selected plan.

  • Run in isolated sandbox firstRequired

    Use a constrained sandbox and observe behavior across multiple tasks.

    Pending

  • Roll out graduallyRequired

    Roll out to a small cohort before wider usage.

    Pending

  • Set monitoring and fallback

    Define rollback path and monitor errors after adoption.

    Pending

Evidence readiness

Evidence readiness matrix · balanced

Missing required evidence: Metadata review. Risk score 31.

Risk 31

Source provenance

Present

Source repository/provenance is listed.

Required in this preset

Metadata review

Missing

Review metadata is missing.

Required in this preset

Safety notes

Present

Safety notes are present.

Required in this preset

Privacy notes

Present

Privacy notes are present.

Optional in this preset

Package integrity

Missing

Package integrity metadata is missing.

Optional in this preset

Install payload

Present

Install payload is available.

Required in this preset

Required gaps: Metadata review

Decision timeline

Decision timeline · balanced

Blocking gaps: Check metadata review status. Risk 28.

Risk 28

triage

Confirm source provenanceRequired

Source/provenance metadata is available.

Done

triage

Check metadata review statusRequired

Review metadata is missing.

Pending

verify

Review safety notesRequired

Safety notes are available.

Done

verify

Review privacy notes

Privacy notes are available.

Done

verify

Validate package integrity metadata

Package integrity metadata is missing.

Pending

rollout

Verify install payload and commandsRequired

Install payload is available.

Done

Blockers: Check metadata review status

Prerequisite readiness

Prerequisite readiness

5 prerequisites to line up before setup. Have accounts and credentials ready first. Includes a review or approval gate.

0/5 ready
Account & credentials1Install & runtime2Review & approval210 minutes

Safety & privacy surface

Safety & privacy surface

5 safety and 4 privacy notes across 5 risk areas. Review closely: credentials & tokens, network access, third-party handling.

5 areas
  • SafetyLocal filesSpec Workflow MCP writes requirements, design, task, steering, approval, archive, and implementation-log files under `.spec-workflow`.
  • SafetyNetwork accessThe dashboard uses a local web server and WebSocket updates; keep it bound to localhost unless you add external authentication, TLS, and network restrictions.
  • SafetyNetwork accessThe README documents rate limiting, audit logging, security headers, default localhost binding, and CORS restrictions, but also notes that built-in HTTPS/TLS and user authentication are not yet implemented.
  • SafetyGeneralTask and approval tools can make an agent appear to advance project state; require human review before accepting specs, completing tasks, or using generated implementation prompts.
  • SafetyGeneralDocker deployment should be reviewed for volume mounts, writable directories, and dashboard exposure before using it in shared environments.
  • PrivacyThird-party handlingRequirements, designs, task lists, steering documents, approval comments, implementation logs, filenames, project paths, prompts, and task progress may be visible to the MCP client and model provider.
  • PrivacyCredentials & tokensPersistent global state may be stored under `SPEC_WORKFLOW_HOME`, including active project registry, dashboard session data, settings, job history, and migration logs.
  • PrivacyLocal filesThe `.spec-workflow` directory can contain unreleased product plans, architecture decisions, customer requirements, and implementation details.
  • PrivacyNetwork accessReview generated specs, logs, approval files, and dashboard screenshots before committing, sharing, or uploading them.

Safety notes

  • Spec Workflow MCP writes requirements, design, task, steering, approval, archive, and implementation-log files under `.spec-workflow`.
  • The dashboard uses a local web server and WebSocket updates; keep it bound to localhost unless you add external authentication, TLS, and network restrictions.
  • The README documents rate limiting, audit logging, security headers, default localhost binding, and CORS restrictions, but also notes that built-in HTTPS/TLS and user authentication are not yet implemented.
  • Task and approval tools can make an agent appear to advance project state; require human review before accepting specs, completing tasks, or using generated implementation prompts.
  • Docker deployment should be reviewed for volume mounts, writable directories, and dashboard exposure before using it in shared environments.

Privacy notes

  • Requirements, designs, task lists, steering documents, approval comments, implementation logs, filenames, project paths, prompts, and task progress may be visible to the MCP client and model provider.
  • Persistent global state may be stored under `SPEC_WORKFLOW_HOME`, including active project registry, dashboard session data, settings, job history, and migration logs.
  • The `.spec-workflow` directory can contain unreleased product plans, architecture decisions, customer requirements, and implementation details.
  • Review generated specs, logs, approval files, and dashboard screenshots before committing, sharing, or uploading them.

Prerequisites

  • Node.js and npx available to the MCP client runtime.
  • A project workspace you are authorized to organize with generated specs and steering documents.
  • A writable `.spec-workflow` project directory and, for sandboxed runtimes, a writable `SPEC_WORKFLOW_HOME`.
  • Optional dashboard process started separately before using visual approvals or project tracking.
  • Approval workflow expectations agreed with the team before letting an agent mark tasks complete.

Schema details

Install type
cli
Troubleshooting
No
Source repository stats
Scope
Source repo
Collection metadata
Estimated setup
10 minutes
Difficulty
intermediate
Full copyable content
{
  "mcpServers": {
    "spec-workflow": {
      "command": "npx",
      "args": ["-y", "@pimzino/spec-workflow-mcp@latest", "PROJECT_PATH"]
    }
  }
}

About this resource

Content

Spec Workflow MCP is an MCP server for structured, spec-driven development. It helps Claude create and manage requirements, design documents, task breakdowns, approval states, steering documents, and implementation logs inside a project workspace.

The upstream README documents client setup for Claude Code, Claude Desktop, Codex, Cursor, Windsurf, OpenCode, Continue, Cline, and Augment. It also provides a separate dashboard mode and a VS Code extension for reviewing specs, task progress, approvals, comments, and implementation activity.

Source Review

These sources were reviewed on 2026-06-05. Prefer the live repository, README, package metadata, docs, NPM registry metadata, and VS Code Marketplace listing for current install commands, dashboard behavior, supported clients, tool names, extension status, package versions, and security notes.

Features

  • Create requirements, design, and task documents for named specs.
  • Track task status, completion, notes, and overall spec progress.
  • Request, approve, reject, and revise documents through an approval workflow.
  • Maintain product, technical, and structure steering documents.
  • View project progress through a real-time dashboard with WebSocket updates.
  • Use a VS Code extension sidebar for spec review and approval actions.
  • Store implementation logs and code statistics for completed tasks.
  • Configure workspace-local or shared git-worktree spec storage.
  • Localize the dashboard interface across multiple supported languages.

Installation

Start the dashboard separately when you want the visual approval and tracking interface:

npx -y @pimzino/spec-workflow-mcp@latest --dashboard

For MCP clients that launch stdio servers, configure the server with the project path it should manage:

{
  "mcpServers": {
    "spec-workflow": {
      "command": "npx",
      "args": ["-y", "@pimzino/spec-workflow-mcp@latest", "PROJECT_PATH"]
    }
  }
}

For sandboxed runtimes with a read-only home directory, set SPEC_WORKFLOW_HOME to a writable workspace location before launching the server or dashboard.

Use Cases

  • Turn a feature request into requirements, design, and task documents.
  • Keep an implementation plan reviewable before Claude starts coding.
  • Track which tasks are pending, in progress, completed, or waiting for approval.
  • Add steering documents so future specs follow project conventions.
  • Review generated requirements and design proposals in a dashboard.
  • Keep implementation logs for later project review.
  • Share spec state across git worktrees when a team works from multiple branches.

Safety and Privacy

Spec Workflow MCP deliberately writes durable planning state. Treat .spec-workflow as project data, not disposable chat history, because it can contain product requirements, design decisions, implementation prompts, approval comments, and task logs.

Keep the dashboard on localhost unless you add a reverse proxy with authentication, TLS, and firewall restrictions. The upstream README documents localhost binding, rate limiting, audit logging, security headers, CORS restrictions, and Docker hardening, but it also states that built-in HTTPS/TLS and user authentication are not yet implemented.

Duplicate Check

No Pimzino/spec-workflow-mcp entry, @pimzino/spec-workflow-mcp package entry, or matching source URL was found in content/mcp.

#planning#workflow#approvals#project-management#developer-tools

Source citations

Add this badge to your README

Show that Spec Workflow MCP Server is listed on HeyClaude. Paste this Markdown into your README — it renders the badge and links back to this page.

Listed on HeyClaude
[![Listed on HeyClaude](https://heyclau.de/badge/mcp/spec-workflow-mcp-server.svg)](https://heyclau.de/entry/mcp/spec-workflow-mcp-server)

How it compares

Spec Workflow MCP Server side by side with 3 alternatives on trust, install, platform support, and disclosed safety notes — all from reviewed registry metadata.

Field
Spec Workflow MCP Server

MCP server for spec-driven development workflows, requirements, design docs, task breakdowns, approvals, implementation logs, and a real-time dashboard.

Open dossier
Shrimp Task Manager MCP Server

MCP server for AI-assisted development task planning, decomposition, dependency tracking, execution workflow state, reflection, and research mode.

Open dossier
Overture MCP

MCP server that turns an AI coding agent's plan into a local interactive flowchart, approval workflow, execution tracker, branch selector, and plan history before code changes proceed.

Open dossier
Agentset logoAgentset MCP Server

Official Agentset MCP server that lets Claude retrieve cited knowledge-base results from an Agentset namespace through the `knowledge-base-retrieve` tool, with optional tenant scoping and custom tool descriptions.

Open dossier
Next steps
Open dossierAPI JSONOpen LLMMCP feedOpen sourceNewsletterClaim listing
Open dossierAPI JSONOpen LLMMCP feedOpen sourceNewsletterClaim listing
Open dossierAPI JSONOpen LLMMCP feedOpen sourceNewsletterClaim listing
Open dossierAPI JSONOpen LLMMCP feedOpen sourceNewsletterClaim listing
Trust
Review statusNot reviewedNot reviewedNot reviewedNot reviewed
Package trustPackage not verifiedPackage not verifiedPackage not verifiedPackage not verified
Source provenanceSource-backedSource-backedSource-backedSource-backed
Submitteroktofeesh1oktofeesh1oktofeesh1oktofeesh1
Install riskReview firstReview firstReview firstReview first
Notes Safety ✓ Privacy ✓ Safety ✓ Privacy ✓ Safety ✓ Privacy ✓ Safety ✓ Privacy ✓
Brand———Agentset logoAgentset
Categorymcpmcpmcpmcp
SourceSource-backedSource-backedSource-backedSource-backed
AuthorPimzinocjo4m06SixthAgentset
Added2026-06-052026-06-052026-06-062026-06-06
Platforms
Claude CodeCodexCursorClaude Desktop
Claude CodeClaude Desktop
Claude CodeClaude Desktop
Claude CodeClaude Desktop
Harness
Claude CodeCodexCursorClaude Desktop
Claude CodeClaude Desktop
Claude CodeClaude Desktop
Claude CodeClaude Desktop
Source repo————
Safety notes✓Spec Workflow MCP writes requirements, design, task, steering, approval, archive, and implementation-log files under `.spec-workflow`. The dashboard uses a local web server and WebSocket updates; keep it bound to localhost unless you add external authentication, TLS, and network restrictions. The README documents rate limiting, audit logging, security headers, default localhost binding, and CORS restrictions, but also notes that built-in HTTPS/TLS and user authentication are not yet implemented. Task and approval tools can make an agent appear to advance project state; require human review before accepting specs, completing tasks, or using generated implementation prompts. Docker deployment should be reviewed for volume mounts, writable directories, and dashboard exposure before using it in shared environments.✓Shrimp Task Manager persists task plans, project rules, research notes, task status, dependencies, and execution history in `DATA_DIR`. Tools such as `execute_task`, `complete_task`, `delete_task`, `clear_all_tasks`, and `update_task` can change workflow state and should be reviewed before treating status as authoritative. Agent-assignment and planning features can make generated work look more complete than it is; require human review before accepting implementation progress. The optional GUI starts a web interface when enabled; keep it local or protect it with appropriate network controls. Avoid launching development agents with broad permission-bypass flags solely because an example command suggests it.✓Overture is an approval and visualization layer; it does not replace code review, tests, access controls, or human judgment. The server starts a local web UI and WebSocket service for plan review and execution tracking. Plan approval, pause, rerun, branch selection, and node-status tools affect what the agent is instructed to do next, but they do not sandbox the agent's other tools. File attachments and node metadata can influence later agent steps, so review attached context and secret fields before approval. If local UI ports are exposed beyond trusted local clients, plan data and attachments could be visible to unintended users.✓The MCP server sends Claude's retrieval queries to the Agentset API using the configured API key and namespace. The `knowledge-base-retrieve` tool can return up to 100 results per call and can rerank results by relevance. Namespace and tenant selection control which indexed documents are searchable; review them before connecting a shared agent. API keys should be scoped, rotated, and stored only in the MCP server environment or a secret manager. Custom tool descriptions can influence when the model calls the retrieval tool, so review them before use in production workflows.
Privacy notes✓Requirements, designs, task lists, steering documents, approval comments, implementation logs, filenames, project paths, prompts, and task progress may be visible to the MCP client and model provider. Persistent global state may be stored under `SPEC_WORKFLOW_HOME`, including active project registry, dashboard session data, settings, job history, and migration logs. The `.spec-workflow` directory can contain unreleased product plans, architecture decisions, customer requirements, and implementation details. Review generated specs, logs, approval files, and dashboard screenshots before committing, sharing, or uploading them.✓Task descriptions, project rules, research notes, dependency graphs, agent assignments, prompts, and execution history may include private implementation details. Persisted task data and backups can reveal roadmap items, security work, customer requests, or internal architecture decisions. Tool arguments and task records may be visible to the MCP client and model provider during planning and execution. Review `DATA_DIR` before committing, sharing, archiving, or uploading generated task state.✓Plans can include workspace paths, task descriptions, risks, expected outputs, user inputs, selected branches, node outputs, and agent execution status. Overture stores project history in a project `.overture.json` file when possible and falls back to local user-level storage. Uploaded attachments are saved under local Overture attachment storage and can include code, documents, images, or secrets if the user provides them. The UI includes file-reading and attachment endpoints for local plan review, so use it only with trusted local clients and approved workspaces. The marketplace panel can fetch remote MCP marketplace data, so network policy should account for that optional UI feature.✓Retrieved chunks can include private documents, product specs, policies, support content, internal procedures, historical project information, or customer-specific data. Retrieval queries, namespace IDs, tenant IDs, document chunks, citations, and tool outputs may be visible to the MCP client, model provider, Agentset logs, and application telemetry. Tenant IDs are useful for data segregation, but incorrect tenant or namespace configuration can expose the wrong knowledge base. Do not paste API keys, namespace IDs, tenant IDs, or retrieved private chunks into shared issue reports, screenshots, or repository files.
Prerequisites
  • Node.js and npx available to the MCP client runtime.
  • A project workspace you are authorized to organize with generated specs and steering documents.
  • A writable `.spec-workflow` project directory and, for sandboxed runtimes, a writable `SPEC_WORKFLOW_HOME`.
  • Optional dashboard process started separately before using visual approvals or project tracking.
  • Node.js 18 or newer and npm available to the MCP client runtime.
  • A cloned, installed, and built checkout of `mcp-shrimp-task-manager`, or an installed package that exposes the built server.
  • A writable `DATA_DIR` for persistent task data and backups.
  • Agreement on how generated plans, task status, agent assignments, and research notes should be reviewed.
  • Node.js 18 or newer and npx available to the MCP client runtime.
  • A coding-agent workflow that will call Overture planning tools before making changes.
  • Review of local browser, file attachment, and plan-history storage behavior before using it with private workspaces.
  • Agentset account or self-hosted Agentset deployment with a populated namespace.
  • Agentset API key with access to the namespace Claude should query.
  • Node.js 18.17 or newer for running the `@agentset/mcp` package.
  • Namespace ID selected with `--ns` or `AGENTSET_NAMESPACE_ID`.
Install
claude mcp add spec-workflow npx @pimzino/spec-workflow-mcp@latest -- PROJECT_PATH
npm install -g mcp-shrimp-task-manager
npx -y overture-mcp
Run `npx @agentset/mcp --ns <namespace-id>` with `AGENTSET_API_KEY` set in the MCP server environment.
Config
{
  "mcpServers": {
    "spec-workflow": {
      "command": "npx",
      "args": ["-y", "@pimzino/spec-workflow-mcp@latest", "PROJECT_PATH"],
      "env": {
        "SPEC_WORKFLOW_HOME": "WRITABLE_SPEC_WORKFLOW_HOME"
      }
    }
  }
}
{
  "mcpServers": {
    "shrimp-task-manager": {
      "command": "node",
      "args": ["PATH_TO_SHRIMP_TASK_MANAGER/dist/index.js"],
      "env": {
        "DATA_DIR": "WRITABLE_SHRIMP_DATA_DIR",
        "TEMPLATES_USE": "en",
        "ENABLE_GUI": "false"
      }
    }
  }
}
{
  "mcpServers": {
    "overture": {
      "command": "npx",
      "args": ["-y", "overture-mcp"],
      "env": {
        "OVERTURE_AUTO_OPEN": "false",
        "OVERTURE_HTTP_PORT": "3031",
        "OVERTURE_WS_PORT": "3030"
      }
    }
  }
}
{
  "mcpServers": {
    "agentset": {
      "command": "npx",
      "args": ["-y", "@agentset/mcp@latest", "--ns", "ns_xxx"],
      "env": {
        "AGENTSET_API_KEY": "agentset_xxx"
      }
    }
  }
}
Citations
ClaimUnclaimedUnclaimedUnclaimedUnclaimed
Open 4 picks in the interactive comparison tool

Related guides

Source-backed guides for putting this to work.

Claude Code On The Web For Repository Planning

Plan repository work with Claude Code on the web before local implementation.

Added 1mo ago
guidesReview firstSource-backedReview first
Safety ✓ Privacy ✓by kiannidev

Slash Commands in Claude Agent SDK Sessions

Read slash_commands from the SDK init message, dispatch a command via the prompt, and ship custom SKILL.md commands with allowed-tools.

Added 1mo ago
guidesReview firstSource-backedReview first
Safety ✓ Privacy ✓by JPette1783

Adding Plugin Install Hints to Developer CLIs

Write a claude-code-hint tag to stderr under CLAUDECODE, and Claude Code prompts users once to install your official-marketplace plugin.

Added 1mo ago
guidesReview firstSource-backedReview first
Safety ✓ Privacy ✓by JPette1783

Signals

Loading live community signals…

More like this, weekly

A short, calm digest of reviewed Claude resources. Unsubscribe any time.