Skip to content

adarsh-devappsys/devctl-mcp

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

7 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

devctl-mcp

An MCP (Model Context Protocol) server that lets Claude manage long-running dev processes seamlessly — across Flutter, Next.js, Spring Boot, Vite, and any custom stack.

The problem it solves: When Claude spawns flutter run, next dev, or gradle bootRun via bash, it immediately loses control. No hot reload, no log access, no restart. This server runs as a persistent daemon that owns all dev processes and exposes simple tools Claude can call.


Features

  • Flutter — auto-detect FVM, target specific devices, hot reload & hot restart via Dart VM service
  • Next.js — auto-detect package manager (npm / pnpm / yarn / bun) from lockfiles
  • Spring Boot — auto-detect Maven or Gradle, use mvnw/gradlew wrappers when present
  • Vite / React — detect vite.config.* or react-scripts in package.json
  • Generic — run any custom command with full log capture
  • Log streaming — circular buffer (1000 lines), filter by string, timestamps on demand
  • Full process lifecycle — start, stop, restart with status tracking (starting → running → stopped/crashed)

Installation

Prerequisites

  • Node.js 20+
  • Claude Code CLI

Setup

git clone git@github.com:adarsh-devappsys/devctl-mcp.git
cd devctl-mcp
npm install
npm run build

Register globally with Claude Code

claude mcp add -s user devctl -- node /absolute/path/to/devctl-mcp/dist/index.js

Verify it's connected:

claude mcp list
# devctl: node .../dist/index.js - ✓ Connected

The server will be available in all your Claude Code sessions globally.

Project-level (alternative)

The repo ships with a .mcp.json — if you open this repo in Claude Code, it's auto-loaded without any extra setup.


Available Tools

Core — works for all frameworks

Tool Description
list_processes List all managed processes with status, uptime, PID
start_process Start a dev server — auto-detects the framework
stop_process Gracefully stop a process (SIGTERM → SIGKILL after 5s)
restart_process Stop + restart with original configuration
get_logs Get recent log output, with optional line count and filter
clear_logs Clear the log buffer for a process
send_input Send raw text to process stdin (escape hatch)

Flutter-specific

Tool Description
flutter_hot_reload Hot reload via Dart VM service, falls back to stdin r
flutter_hot_restart Hot restart via Dart VM service, falls back to stdin R
list_devices List connected Flutter devices and emulators

Usage Examples

Flutter

List my connected Flutter devices
Start my Flutter app at /Users/me/projects/myapp, name it "myapp", on my Pixel device
Hot reload myapp
Hot restart myapp
Get the last 100 logs from myapp, filter by "error"

With FVM (auto-detected):

If your project has .fvm/flutter_sdk or fvm_config.json, FVM is used automatically. You can also force it:

Start myapp at /path/to/project with use_fvm true, device id "32211JEHN06807"

Next.js

Start the Next.js project at /Users/me/projects/website, name it "web"

Package manager is auto-detected from lockfiles (bun.lockb → bun, pnpm-lock.yaml → pnpm, yarn.lock → yarn, else npm). Override with package_manager: "pnpm".

Spring Boot

Start /Users/me/projects/api, name it "api"

Maven vs Gradle auto-detected from pom.xml / build.gradle. Uses ./mvnw or ./gradlew wrappers when present.

Any other stack

Start /Users/me/projects/backend, name it "django", command "python manage.py runserver"

Checking logs

Show me the logs for myapp
Get last 50 lines from api, filter by "Exception"
Get logs from web with timestamps

Framework Auto-Detection

The adapter is chosen automatically based on what's in your project directory:

Framework Detection
Flutter pubspec.yaml exists
Spring Boot pom.xml or build.gradle / build.gradle.kts
Next.js package.json with next in dependencies
Vite vite.config.* file, or vite/react-scripts in package.json
Generic Fallback — requires command option

Priority: Flutter → Spring Boot → Next.js → Vite → Generic

FVM Auto-Detection (Flutter)

FVM is auto-enabled when both are true:

  1. fvm binary is in PATH
  2. Project has .fvm/flutter_sdk, fvm_config.json, or .fvmrc

Override: pass use_fvm: true or use_fvm: false explicitly.

Package Manager Auto-Detection (JS projects)

Detected from lockfiles in priority order:

  1. bun.lockb → bun
  2. pnpm-lock.yaml → pnpm
  3. yarn.lock → yarn
  4. Fallback → npm

How Flutter Hot Reload Works

The server uses a two-tier system for maximum reliability:

Tier 1 — Dart VM service (preferred)

When flutter run starts, it prints a line like:

A Dart VM Service on Pixel 7a is available at: http://127.0.0.1:56789/TOKEN=/

The server captures this URL and derives a WebSocket endpoint. Hot reload/restart is sent as JSON-RPC over WebSocket — the same protocol Flutter DevTools uses.

Hot reload sequence: getVMreloadSourcescallServiceExtension('ext.flutter.reassemble')

Hot restart sequence: getVMcallService('hotRestart')

Tier 2 — stdin fallback

If the VM service URL isn't available yet (app still starting up), the server sends r or R to the process stdin — Flutter's interactive keyboard commands.


Development

# Run without building (tsx watches for changes)
npm run dev

# Build
npm run build

# Type-check only
npm run typecheck

Project Structure

src/
  index.ts              ← MCP server entry, stdio transport
  types.ts              ← Shared TypeScript interfaces
  process-manager.ts    ← Process registry, spawn, lifecycle, VM service URL parsing
  log-store.ts          ← Circular buffer (1000 lines, stdout + stderr + timestamps)
  adapters/
    flutter.ts          ← Flutter + FVM detection
    nextjs.ts           ← Next.js + package manager detection
    spring-boot.ts      ← Maven/Gradle + wrapper detection
    vite.ts             ← Vite/React-scripts detection
    generic.ts          ← Fallback for custom commands
    registry.ts         ← Ordered detection chain
  tools/
    process-tools.ts    ← 7 core MCP tools
    flutter-tools.ts    ← Flutter hot reload/restart + list_devices

Important Notes

  • Session persistence: Managed processes live as long as the Claude Code session is open. If you close the session, running processes are stopped. This is a fundamental constraint of the stdio MCP transport.
  • stdout is reserved: The MCP protocol uses process.stdout for JSON-RPC messages. All internal server logs go to stderr.
  • PATH inheritance: The server inherits your shell PATH, so fvm, flutter, mvn, gradle, etc. must be on your PATH as they would be in a terminal.

About

An MCP (Model Context Protocol) server that lets Claude manage long-running dev processes seamlessly — across Flutter, Next.js, Spring Boot, Vite, and any custom stack.

Topics

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

 
 
 

Contributors