Sprint MCP Server
The Sprint MCP Server enables AI agents to manage structured sprint-based development workflows, enforcing the Sprint Protocol for iterative, collaborative development.
Start Sprint: Use the
start-sprinttool to initialize a new sprint with title, goal, and owner. It enforces the single-active-sprint rule, creates a unique sprint ID, generates a sprint manifest and request log in a planning directory, and sets up an isolated git worktree and feature branch for parallel development without affecting the main branch.Check Sprint Status: Use
check-sprint-statusto verify current sprint states, list active sprints with details, count completed sprints, detect protocol violations (multiple active sprints), and confirm readiness to start a new sprint.Update Sprint Status: Atomically update sprint status in both manifest and index, including completion details like completion mode and pull request URL.
Regenerate Sprint Index: Rebuild the centralized sprint index from manifests if corrupted or out of sync, providing statistics and validation results.
Git Worktree Management: Each sprint gets its own isolated worktree, allowing parallel development and clean cleanup after completion.
Protocol Enforcement: Ensures adherence to Sprint Protocol rules, such as the single active sprint rule, and maintains detailed request logs for traceability.
Claude Desktop Integration: Can be configured as an MCP server to expose its tools to LLM agents within Claude Desktop.
Click on "Deploy 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., "@Sprint MCP ServerStart a sprint titled 'User Profile API' for owner @johndoe"
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.
sprint-mcp
MCP server providing Sprint Protocol tooling for LLM-driven development workflows
Overview
sprint-mcp is a Model Context Protocol (MCP) server that implements the Sprint Protocol, enabling structured, traceable development workflows for LLM-powered coding assistants like Claude.
What is Sprint Protocol?
Sprint Protocol is a structured methodology for LLM-driven development that provides:
Phased execution (Plan → Approve → Implement → Validate → Verify → Publish → Retro → Learn)
Git worktree isolation for each sprint
Comprehensive artifacts (implementation plans, verification reports, retrospectives)
Full traceability through request logs
Quality gates ensuring code quality and testing
What is MCP?
Model Context Protocol enables Claude Desktop to interact with external tools and services. sprint-mcp exposes Sprint Protocol tools as MCP endpoints.
Related MCP server: Project Manager MCP
Features
Sprint Lifecycle Management - Start, update, complete, and track sprints
Git Worktree Integration - Isolated development environments per sprint
Artifact Generation - Automated creation of plans, reports, retrospectives
Sprint Index Management - Track all sprints across your projects
Archive System - Organize completed sprints by year, free up active workspace
Knowledge Extraction - Automatically extract lessons, patterns, and metrics from completed sprints
Auto-Archive - Intelligent archival based on age, count, or hybrid criteria
Cleanup Tools - Remove completed sprint worktrees safely
Validation & Verification - Quality gates and artifact validation
Installation
Method 1: Global Installation (Recommended)
npm install -g sprint-mcpPros: Simple configuration, faster startup, works offline
Method 2: npx (No Installation)
No installation needed - use directly with npx.
Pros: Always latest version, no global packages, easy to try
Method 3: Project-Local
npm install --save-dev sprint-mcpPros: Project-specific version, locked in package.json
Configuration
For Claude Desktop
Add to your Claude Desktop configuration file:
Config Location:
macOS:
~/Library/Application Support/Claude/claude_desktop_config.jsonWindows:
%APPDATA%\Claude\claude_desktop_config.jsonLinux:
~/.config/Claude/claude_desktop_config.json
Global Installation
{
"mcpServers": {
"sprint-mcp": {
"command": "sprint-mcp"
}
}
}With npx
{
"mcpServers": {
"sprint-mcp": {
"command": "npx",
"args": ["-y", "sprint-mcp"]
}
}
}With Environment Variables
{
"mcpServers": {
"sprint-mcp": {
"command": "sprint-mcp",
"env": {
"SPRINT_ROOT": "/path/to/your/project"
}
}
}
}After configuration:
Restart Claude Desktop completely (Cmd+Q / File → Exit)
Wait 5-10 seconds for MCP servers to initialize
Verify tools appear in Claude
Available Tools
sprint-mcp provides the following MCP tools:
Sprint Lifecycle
start-sprint- Initialize a new sprint with manifest and directory structureCreates sprint directory in
planning/Sets up git worktree for isolated development
Generates sprint manifest with metadata
check-sprint-status- Verify current sprint stateReturns active sprint information
Checks for conflicts (multiple active sprints)
Validates sprint index integrity
update-sprint-status- Update sprint status and metadataStatus transitions: planning → in-progress → validating → verifying → published → complete
Updates both manifest and sprint index
Atomic operations for consistency
complete-sprint- Complete sprint with validationValidates required artifacts (verification-report.md, retro.md, key-learnings.md)
Supports normal and forced completion modes
Updates status and timestamps
Sprint Index Management
regenerate-sprint-index- Rebuild sprint index from manifestsScans all sprint manifests in
planning/Rebuilds
planning/sprint-index.yamlValidates index integrity
Recovers from index corruption
Archive & Knowledge
archive-sprint- Archive completed sprints to organized storageMoves sprints from
planning/active/toplanning/archive/{year}/Updates sprint index with new location
Triggers knowledge extraction (if enabled)
Dry-run mode for preview
auto-archive-sprints- Automatically archive eligible sprintsAge criteria: Archive sprints older than N days
Count criteria: Keep only N most recent sprints
Hybrid criteria: Must meet both age AND count thresholds
Batch processing with error handling
Configurable via
planning/archive-config.yaml
Cleanup
cleanup-sprint- Clean up completed sprint worktreesPreview mode: Shows what will be deleted
Execution mode: Removes git worktrees
Safety checks: Only cleans completed sprints
Force option: Override uncommitted changes check
Usage Examples
Starting a Sprint
In Claude Desktop:
Start a new sprint to implement user authenticationClaude will use the start-sprint tool to:
Check no active sprints exist
Generate sprint ID (e.g.,
sprint-12-abc123)Create
planning/sprint-12-abc123/directoryCreate git worktree in
.worktrees/sprint-12-abc123/Generate sprint manifest
Update sprint index
Checking Sprint Status
Check the current sprint statusReturns information about active sprints and index health.
Completing a Sprint
Complete the current sprintClaude validates artifacts and marks sprint as complete.
Cleaning Up Worktrees
Clean up completed sprint worktreesRemoves git worktrees for completed sprints, freeing disk space.
Sprint Protocol Overview
sprint-mcp implements the Sprint Protocol defined in AGENTS.md. Key concepts:
Sprint Phases
Plan - Create implementation plan, get user approval
Implement - Execute planned work, log all changes
Validate - Run validation script, verify deliverables
Verify - Create verification report, document gaps
Publish - Create GitHub PR, publish deliverables
Retro - Reflect on what went well / what didn't
Learn - Extract transferable learnings
Sprint Artifacts
Every sprint creates:
sprint-manifest.yaml- Sprint metadata and statusimplementation-plan.md- Detailed execution planrequest-log.md- All prompts and changesvalidate_deliverable.sh- Executable validation scriptverification-report.md- Completed/partial/deferred itemsretro.md- What worked, what didn'tkey-learnings.md- Lessons for future sprints
Note: publication.yaml was deprecated in Protocol v2.5. PR URL and publication metadata are now tracked in sprint-manifest.yaml.
Git Worktrees
Each sprint uses an isolated git worktree:
Main worktree stays on main branch
Sprint worktree on feature branch
Independent working directories
Separate git operations
Easy cleanup after completion
Archive System
Completed sprints are organized in an archive hierarchy:
Active sprints:
planning/active/{sprint-id}/Archived sprints:
planning/archive/{year}/{sprint-id}/Auto-archival: Configurable age/count/hybrid criteria
Knowledge extraction: Automatic extraction of lessons and patterns
Index tracking: All sprints remain in
planning/sprint-index.yaml
Knowledge Base
The system automatically builds a knowledge base from sprint artifacts:
Lessons learned: Extracted from
key-learnings.md, retrospectivesPatterns: Successful approaches from "what went well" sections
Anti-patterns: Things to avoid from "what to improve" sections
Metrics: Sprint duration, effort, velocity tracking
Deduplication: Similar knowledge merged with frequency tracking
Storage:
planning/knowledge/knowledge-base.yaml
Requirements
Node.js: v18.0.0 or higher
npm: v8.0.0 or higher
Git: v2.20 or higher (for worktree support)
Claude Desktop: Latest version
Troubleshooting
Tools not appearing in Claude Desktop
Verify configuration file exists and is valid JSON
Check Claude Desktop logs for errors
Ensure sprint-mcp is installed (
which sprint-mcpornpx -y sprint-mcp)Restart Claude Desktop completely
"command not found: sprint-mcp"
Global installation:
npm install -g sprint-mcp
which sprint-mcpnpx usage:
npx -y sprint-mcp # Test it worksPermission denied errors
Fix npm permissions:
mkdir ~/.npm-global
npm config set prefix '~/.npm-global'
echo 'export PATH=~/.npm-global/bin:$PATH' >> ~/.bashrc
source ~/.bashrc
npm install -g sprint-mcpMCP server crashes
Check Node.js version:
node --version # Must be v18+Run manually to see errors:
sprint-mcpUpdating
Global Installation
npm update -g sprint-mcpnpx
No action needed - npx always uses latest version.
To pin version:
{
"args": ["-y", "sprint-mcp@0.1.0"]
}Project-Local
npm update sprint-mcpDocumentation
Sprint Protocol: See
AGENTS.mdin package or GitHubInstallation Guide: Full installation guide
Examples: GitHub examples directory
Development
Running from Source
git clone https://github.com/cnavta/sprint-mcp.git
cd sprint-mcp
npm install
npm run build
npm link # Use locallyRunning Tests
npm test # Run all tests
npm run test:coverage # With coverage reportCurrent test coverage: 310 tests passing across 18 test suites
Contributing
Contributions welcome! Please:
Fork the repository
Create a feature branch
Follow Sprint Protocol (see AGENTS.md)
Include tests for new functionality
Submit pull request
See CLAUDE.md for development guidelines.
License
MIT License - see LICENSE file for details
Links
npm Package: https://www.npmjs.com/package/sprint-mcp
GitHub Repository: https://github.com/cnavta/sprint-mcp
MCP Specification: https://modelcontextprotocol.io/
Acknowledgments
Built with Model Context Protocol SDK
Designed for use with Claude Desktop
Inspired by structured development methodologies
Support
Documentation: See installation guide
Issues: GitHub Issues
Discussions: GitHub Discussions
Available Tools
2 toolscheck-sprint-statusA
Verify current sprint state and check for active sprints. Returns active sprint info or confirms no active sprints.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the return behavior (active sprint info or no active sprints), and the read-only nature is strongly implied by 'verify' and 'check', but it does not explicitly state that no sprint is started or modified.
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?
Two short sentences, no redundant information, and front-loaded with the core purpose. Highly efficient and easy to parse.
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?
Given the tool's simplicity, no parameters, and no output schema, the description adequately covers what it does and what it returns. It could be slightly more explicit about the exact shape of 'active sprint info' and that it does not mutate state, but the current description is sufficient.
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?
The tool has zero parameters, so the schema is empty. The description adds no parameter-specific meaning, but none is needed; baseline is 4 for a no-parameter 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?
Clearly states the tool verifies current sprint state and checks for active sprints. Distinguishes itself from the sibling 'start-sprint' by focusing on inspection rather than creation.
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?
Implies usage as a status-checking tool before or alongside starting sprints, but does not explicitly state when to use it versus 'start-sprint'. No direct alternatives or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
start-sprintA
Initialize a new sprint with manifest and directory structure. Checks for active sprints first.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | Yes | Clear sprint objective | |
| owner | Yes | GitHub handle or name of sprint owner | |
| title | Yes | Concise sprint title |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does add value by revealing the pre-check for active sprints, but it lacks details on potential failure modes, side effects beyond manifest/directory creation, or whether it is idempotent. The description is informative but not comprehensive.
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 two sentences and highly efficient. It front-loads the primary action and adds a single essential behavioral note, with zero wasted words.
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?
For a simple creation tool with three fully described parameters and no annotations, the description covers the core functionality and a key guardrail. However, it lacks explicit usage guidance (when to choose this tool over check-sprint-status) and does not mention expected outcomes or error cases, leaving some gaps for a complete understanding.
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?
The input schema provides full descriptions for all three parameters (title, goal, owner), so the description need not add further detail. The description does not go beyond the schema in explaining parameter meaning or relationships.
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 clearly states the tool's function with a specific verb and resource: 'Initialize a new sprint with manifest and directory structure.' This distinctly separates it from the sibling tool 'check-sprint-status,' which is about checking rather than creating.
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 description mentions a precondition ('Checks for active sprints first') implying it should be used when no active sprint exists, but it does not explicitly contrast with the sibling tool or state when to use one over the other. This is a clear but unspoken usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
v0.1.0- First observed
check-sprint-status - First observed
start-sprint
TDQS
Scored across 2 tools
check-sprint-status and start-sprint have clearly distinct purposes: one queries current state, the other initiates a new sprint. There is no functional overlap between them.
Both tool names follow a consistent verb-noun pattern with hyphens (check-sprint-status, start-sprint), making the naming predictable and readable.
With only 2 tools, the server feels thin. While the scope appears focused on sprint lifecycle basics, the count is borderline and would benefit from additional tools to be considered well-scoped.
The tool set only covers starting and checking sprints. Missing operations like ending a sprint, updating sprint details, or listing historical sprints leave significant gaps in the sprint management lifecycle.
Maintenance
Related MCP Connectors
The project brain for AI coding agents — memory, decisions, sprints, knowledge base via MCP.
AI-native project management + agent memory: tasks, sprints, risk, burnout, knowledge search.
Git-backed platform for skills, tools, and context for AI agents
Project management for AI agents: tasks, docs, decisions and time in one shared team context.
Related MCP Servers
- -licenseNot gradedqualityNot gradedmaintenanceEnables AI agents to track and manage product development projects through structured 7-phase lifecycles with sprint tracking, role-based collaboration, and multi-project support. Provides phase management, progress tracking, and team coordination tools for complete product development workflows.-
- AlicenseNot gradedqualityDmaintenanceEnables AI agents to manage projects, epics, and tasks with atomic locking, real-time dashboard, and multi-agent coordination.MIT
- FlicenseNot gradedqualityDmaintenanceEnables LLM agents to manage projects, track issues, log work, and integrate with Git. Provides 23 MCP tools for full project management capabilities.16-
- AlicenseCqualityAmaintenanceA disciplined-sprint MCP server for AI coding agents, providing structured sprint management with immutable append-only ledger, programmatic close-gates, and live dashboard.2935 npmApache 2.0