WhenLabs/When
The WhenLabs/When server provides a developer toolkit via MCP with six integrated tools:
🕐 Velocity — Task Timing & Performance
Start/stop timing coding tasks with metadata (category, tags, project, model)
Estimate multi-step plan durations based on historical data
Query performance statistics grouped by category, tag, project, or time period
View task history and generate HTML dashboards with performance charts
📄 Stale — Documentation Drift Detection
Scan for discrepancies between documentation and code
Auto-fix issues (wrong file paths, dead links, outdated scripts)
Generate
.stale.ymlconfig for custom detection rules
🔐 Envalid — Environment Variable Validation
Validate
.envfiles against schemasDetect undocumented env vars and scan for leaked secrets
Generate
.env.schemafrom existing files or code analysisCompare
.envfiles, sync multiple env files, and generate safe.env.exampletemplatesCheck/install git hooks for pre-commit validation
🔌 Berth — Port Conflict Management
Show active ports and diagnose conflicts before starting dev servers
Kill processes on specific ports or free all ports for a project
Register projects with port requirements and list their statuses
Reassign ports in config files and auto-resolve conflicts via kill/reassign strategies
🧠 Aware — AI Context File Generation
Auto-detect project stack and generate AI context files (CLAUDE.md, .cursorrules, etc.)
Regenerate context files from
.aware.jsonand show changes since last syncValidate configuration, diagnose project health, and auto-sync stale context files
Add rules, conventions, or structure entries to configuration
⚖️ Vow — License Compliance
Scan and summarize dependency licenses; validate against policy files
Generate license policy templates and display dependency trees with license annotations
Suggest alternative packages for violations and export reports (JSON, CSV, Markdown)
Install git hooks for pre-commit license checks and generate
THIRD_PARTY_LICENSES.md
All tools are accessible through a single MCP server for Claude Code, with per-tool CLI access and unified commands for project onboarding (when init) and health reporting (when doctor).
Validates .env files against schemas, detects undocumented environment variables in codebases, and generates .env.schema files from code analysis.
Provides CI/CD integration with GitHub Actions for running stale, envalid, and vow checks with annotations and machine-readable JSON output.
Installs pre-commit hooks for license validation checks to ensure compliance before commits are made.
Uses SQLite as the embedded database backend for the velocity tool to persistently track coding task timing and performance metrics.
Manages unified project configuration through .whenlabs.yml files that consolidate settings for all six tools in a single YAML configuration.
@whenlabs/when
Six tools. One install.
A single installable toolkit that brings six WhenLabs developer tools into your Claude Code workflow. After install, the tools are exposed over a single MCP server and Claude calls them automatically when relevant.
Install
npx @whenlabs/when installOne-time setup. The installer:
Registers a single MCP server (
whenlabs) in your Claude Code configurationInjects a CLAUDE.md block so Claude knows when to use each tool
Cleans up any legacy
velocity-mcpregistration (velocity is now bundled)
Related MCP server: DevNarrate
The six tools
Tool | Purpose |
aware | Auto-detect stack and generate AI context files (CLAUDE.md, |
berth | Detect port conflicts before starting dev servers |
envalid | Validate |
stale | Detect documentation drift between docs and code |
vow | Scan dependency licenses and validate against policy |
velocity | Time coding tasks and learn from historical data |
MCP tools
Eight endpoints across the six tools:
Endpoint | What it does |
| Detect stack and regenerate AI context files |
| Scan project for port conflicts |
| Validate |
| Detect documentation drift |
| Scan licenses and validate against policy |
| Start timing a coding task |
| End timing and record results |
| Unified rollup across all five scanners in one call |
All eight are served by the single whenlabs MCP server (stdio, Node 20+). Fix/init/auxiliary commands remain available via each tool's CLI (npx @whenlabs/<tool> --help).
CLI
when init # Onboard a project — detect stack, bootstrap configs, run all checks
when doctor # Run all six tools and show a unified health report
when install # Register MCP server in Claude Code
when uninstall # Remove MCP serverFor per-tool operations, use the tool directly:
npx @whenlabs/stale scan
npx @whenlabs/envalid validate
npx @whenlabs/berth check
npx @whenlabs/aware sync
npx @whenlabs/vow scanManual MCP configuration
If you're not using the install command, add this to your Claude Code MCP config:
{
"mcpServers": {
"whenlabs": {
"command": "npx",
"args": ["@whenlabs/when", "when-mcp"]
}
}
}License
MIT — see LICENSE
Available Tools
7 toolsaware_syncA
Detect the project's tech stack and regenerate AI context files (CLAUDE.md, .cursorrules, .windsurfrules, AGENT.md) from the project's .aware.json config.
When to use: after adding or removing a framework/language, when AI context files fall out of date, or when onboarding a new agent to the repo. Do not call on every turn — run once per session or after stack changes.
Side effects: reads package.json, requirements.txt, pyproject.toml, go.mod, Cargo.toml, and similar manifest files to detect the stack. Writes or overwrites CLAUDE.md, .cursorrules, .windsurfrules, and AGENT.md in the project root based on .aware.json templates. Never modifies source code.
Returns: plain-text summary listing the detected stack, the files written (or that would be written, in dry-run mode), and any errors. Exit 0 on success, non-zero on failure.
Inputs: path, dryRun.
berth_checkA
Scan a project for port conflicts between ports declared in common dev-server config sources (.env files, package.json scripts, docker-compose.yml, devcontainer.json, Procfile, Makefile, framework defaults, and a project-local .berthrc) and ports currently listening on the host.
When to use: before running npm run dev, docker compose up, or any other dev-server command — especially after switching branches in a monorepo where multiple services may want the same port. Safe to call repeatedly; read-only and side-effect free.
Side effects: enumerates listening TCP ports on the host via platform-appropriate commands (lsof on macOS/Linux, netstat on Windows) and inspects running Docker containers for published ports. Reads only the config files listed above; never opens, closes, or binds any ports. No network I/O beyond local loopback checks.
Returns: plain-text (or JSON) report listing each configured port, whether it is free or in use, and — for occupied ports — the PID and process name of the holder. Exit 1 when a conflict is detected, 0 otherwise.
Inputs: path, format.
envalid_validateA
Validate a project's .env files against its envalid schema — catch missing required variables, type mismatches, and values outside allowed ranges.
When to use: before booting the app locally, during CI, after a teammate adds a new required env var, or when switching between development and production configs. Pass environment to validate a specific .env.{env} file.
Side effects: reads .env, .env.local, and .env.{environment} from the project root, and reads the envalid schema (typically src/env.ts or a similar file exporting cleanEnv(...)). Does not write or transmit env values anywhere — validation is local-only.
Returns: plain-text, JSON, or markdown report listing each declared variable, whether it is present, whether its value matches the expected type, and any schema-level validation errors with file:line references. Exit 1 on any validation failure.
Inputs: path, format, environment.
stale_scanA
Detect documentation drift — find places in README.md, CHANGELOG.md, and other project markdown where the docs reference commands, flags, APIs, or files that the code no longer matches.
When to use: before tagging a release, after large refactors or renames, when onboarding a new contributor, or as a periodic health check. Set git: true to additionally flag docs that have not been touched since a closely related source file changed significantly.
Side effects: reads all markdown files and source files reachable from the project root (respecting .gitignore). Never writes, auto-fixes, or moves files — this is a pure reporting tool.
Returns: plain-text, JSON, or markdown report listing each drifted section with file:line references and a one-line explanation of the mismatch (e.g. "README references --deep flag removed in src/cli.ts:42"). Exit 1 if any drift is found.
Inputs: path, format, git.
velocity_end_taskA
Stop a task timer started with velocity_start_task, record the outcome, and return the actual duration alongside a comparison to the historical median for similar tasks.
When to use: immediately after finishing — or abandoning — any task started with velocity_start_task. Always call, even on failed or abandoned outcomes; skipping leaves orphaned active rows that pollute future predictions and stats.
Side effects: updates the task row in ~/.velocity-mcp/tasks.db with end timestamp, duration, status, optional file/line counts, and any telemetry passed in. Shells out to git diff --stat HEAD~1 and git log --since (5s timeout each) to capture diff stats; safely no-ops outside a git repo. On completed status: computes a semantic embedding for similarity matching, records a calibration residual, and — if the task belonged to a plan — seals the plan when its last active task ends.
Returns: JSON with task_id, duration_seconds (numeric), duration_human (formatted), category, tags, and a message that compares this run's duration to the historical median for the category+tags combination ("you were 23% faster", "right on pace", etc.). Includes a git_diff block with lines added/removed, files changed, and commits made during the task when a git repo is detected.
Inputs: task_id (required), status (required), actual_files, notes, +7 more.
velocity_start_taskA
Start a timer for a discrete coding task and, when historical data is available, return a duration estimate derived from similar past tasks.
When to use: before starting any distinct unit of work — a bug fix, a feature, a refactor, a test-writing pass. Use one task per logical unit; do not batch unrelated changes under a single task. Always pair with velocity_end_task so the task row is closed and the dataset stays clean.
Side effects: inserts a new row into the local SQLite database at ~/.velocity-mcp/tasks.db (override via HOME). Computes a best-effort duration prediction by querying historical rows of the same category/tags; predictions run locally and are cached per-task. Federated upload is disabled unless the user has explicitly opted in via velocity-mcp federation enable.
Returns: JSON with task_id (pass this to velocity_end_task), started_at ISO timestamp, message, and — when enough historical data exists — a prediction block containing point estimate in seconds, p25/p75 range, confidence (low/medium/high), whether the estimate was calibrated, and whether it drew on federated data.
Inputs: category (required), description (required), task_id, tags, +6 more.
vow_scanA
Scan all dependency licenses in a project and — if a policy file is present — validate each package against that policy, flagging disallowed licenses (e.g. GPL in a proprietary codebase) or packages with unknown licenses.
When to use: before shipping a release, when adding a new dependency, during compliance or legal review, or as a CI gate. Set production: true to skip devDependencies and audit only what actually ships.
Side effects: reads supported lockfiles (package-lock.json or npm-shrinkwrap.json for Node; Cargo.lock for Rust; requirements.txt with hashes, uv.lock, or poetry.lock for Python) plus local node_modules / vendor manifests to resolve license strings. Pnpm, yarn, and go are not yet supported — vow exits with a clear error when only those lockfiles are present. Read-only; no network requests.
Returns: plain-text, JSON, or markdown summary of package → license mapping grouped by license family (MIT/Apache/BSD/GPL/unknown), with per-package links. Exit 1 if any dependency violates the policy or has an unknown license, 0 otherwise.
Inputs: path, format, production.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 7 tools
Each tool has a clearly distinct purpose with no overlap: aware_sync handles AI context file generation, berth_check scans for port conflicts, envalid_validate validates environment files, stale_scan detects documentation drift, velocity_start_task/velocity_end_task manage task timing, and vow_scan audits dependency licenses. The descriptions clearly differentiate their domains and use cases.
Most tools follow a consistent verb_adjective or verb_noun pattern (e.g., aware_sync, berth_check, envalid_validate, stale_scan, vow_scan), but the velocity tools use a verb_noun_task pattern which slightly deviates. The naming is generally readable and follows a predictable structure across the set.
With 7 tools, the count is well-scoped for a development productivity server. Each tool addresses a specific, valuable aspect of project maintenance (context generation, port checking, env validation, docs drift, task timing, license scanning), and none feel redundant or out of place.
The tool set provides comprehensive coverage for development workflow automation: it includes tools for setup (aware_sync), pre-execution checks (berth_check, envalid_validate), quality assurance (stale_scan, vow_scan), and productivity tracking (velocity tools). There are no obvious gaps; agents can handle common development tasks end-to-end.
Maintenance
Related MCP Connectors
MCP server for your apps' tools and custom tools, plus hosted AI agents and approval-gated workflows
One shared context your team's AI tools read & write over MCP. No re-explaining. Free.
327 dev tools via REST API and MCP. Generate Dockerfiles, schemas, K8s, APIs, and more.
AI-native git hosting — repos, PRs, issues, CI gates, and AI code review over MCP (60 tools).
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceMCP server that equips AI agents with dev workflow tools including GitHub project management, conventional commits, visual regression testing, Jira/Confluence integration, and a persistent memory knowledge graph.11 npmMIT
- AlicenseAqualityDmaintenanceMCP server for developer workflow automation — smart commits, secret scanning, PR descriptions, and more.5MIT
- AlicenseNot gradedqualityAmaintenanceEnables AI assistants to research, plan, generate requirements, create starter projects, analyze codebases, and execute multi-step software development workflows through MCP tools.69 npmMIT
- AlicenseNot gradedqualityAmaintenanceEnables AI assistants to research, plan, generate requirements, map codebases, create starter projects, manage tasks, and run multi-step software development workflows through MCP tools.69 npmMIT