devflow MCP server
✓ VerifiziertVerbindet Jira mit GitHub und GitLab, um das Issue-Management, das Erstellen von Branches, Pull Requests und Developer-Workflows über einen KI-Assistenten zu automatisieren.
Auch bekannt als cocaxcode/devflow-mcp, @cocaxcode/devflow-mcp
- Stars
- 1
- Tools
- 32
- Downloads, 30 Tage
- 311
- Neueste Version
- 0.1.8
- Letzter Commit
- 29. März 2026
- Lizenz
- MIT
Was ist devflow MCP?
devflow ist ein MCP server. Verbindet Jira mit GitHub und GitLab, um das Issue-Management, das Erstellen von Branches, Pull Requests und Developer-Workflows über einen KI-Assistenten zu automatisieren. Er stellt 32 Tools bereit, etwa df_project_setup, df_project_update, df_project_list.
Zusammenfassung generiert aus dem README des Projekts
Über devflow MCP server
devflow-mcp ermöglicht es Entwicklern, die Verbindung zwischen Jira und Git-Providern wie GitHub oder GitLab mithilfe von KI-Assistenten zu automatisieren. Dieser Server bietet 32 Tools, die es einer KI ermöglichen, den gesamten Lebenszyklus einer Aufgabe zu verwalten – vom Lesen von Issue-Details und dem Ändern von Status bis hin zum Erstellen von Branches, Pushen von Code und Öffnen von Pull Requests. Er unterstützt sowohl Jira Cloud als auch Server sowie Cloud- oder selbst gehostete Git-Umgebungen.
Nutzer richten Projekte durch die Definition spezifischer Scopes ein. Das sind lokale Verzeichnisse, die automatisch die richtigen Credentials und Configs triggern. So stellt der Server sicher, dass der Assistent beim Wechsel zwischen verschiedenen Code-Repositories die passende Jira-Instanz und die korrekten Git-Tokens verwendet, ohne dass du manuell umschalten musst. Alle sensiblen Credentials bleiben lokal in deinem Home-Verzeichnis gespeichert, um die Privatsphäre zu gewährleisten. Das System unterstützt zudem benutzerdefinierte YAML Playbooks namens Flows, mit denen du wiederholbare Sequenzen von Tool-Aufrufen für komplexe Workflows definieren kannst.
Was du damit machen kannst
- 1Pull Request Workflows optimierenSchließe eine Coding-Aufgabe ab, indem du Änderungen pushst, einen Pull Request erstellst und den Link als Kommentar zum Jira-Issue hinzufügst.
- 2Mehrere Projektumgebungen verwaltenWechsle automatisch zwischen verschiedenen Backend- und Frontend-Repositories, die unterschiedliche Jira-Instanzen und Git-Provider nutzen.
Geschrieben aus dem README des Projekts. Jeder Use Case wurde gegen ein Zitat daraus geprüft.
So installierst du devflow MCP
Formate geprüft am 10. Nov. 2026Zu Cursor hinzufügenZu Goose hinzufügendevflow MCP in Claude Code installieren
$ claude mcp add devflow-mcp -- npx -y @cocaxcode/devflow-mcpdevflow MCP in Cursor installieren
~/.cursor/mcp.json
{
"mcpServers": {
"devflow-mcp": {
"command": "npx",
"args": [
"-y",
"@cocaxcode/devflow-mcp"
]
}
}
}devflow MCP in VS Code installieren
.vscode/mcp.json
{
"servers": {
"devflow-mcp": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"@cocaxcode/devflow-mcp"
]
}
}
}devflow MCP in VS Code CLI installieren
$ code --add-mcp '{"name":"devflow-mcp","type":"stdio","command":"npx","args":["-y","@cocaxcode/devflow-mcp"]}'devflow MCP in Claude Desktop installieren
claude_desktop_config.json
{
"mcpServers": {
"devflow-mcp": {
"command": "npx",
"args": [
"-y",
"@cocaxcode/devflow-mcp"
]
}
}
}devflow MCP in Codex installieren
$ codex mcp add devflow-mcp -- npx -y @cocaxcode/devflow-mcpdevflow MCP in Codex config.toml installieren
~/.codex/config.toml
[mcp_servers.devflow-mcp] command = "npx" args = ["-y", "@cocaxcode/devflow-mcp"]
devflow MCP in Gemini CLI installieren
$ gemini mcp add -s user devflow-mcp npx -- -y @cocaxcode/devflow-mcpdevflow MCP in Gemini settings.json installieren
~/.gemini/settings.json
{
"mcpServers": {
"devflow-mcp": {
"command": "npx",
"args": [
"-y",
"@cocaxcode/devflow-mcp"
]
}
}
}devflow MCP tools 32
Erkannt aus dem READMEdf_project_setupdf_project_updatedf_project_listdf_project_switchdf_project_deletedf_issuesdf_issuedf_statusesdf_transitiondf_assigndf_commentdf_branch
| df_project_setup | — | |
| df_project_update | — | |
| df_project_list | — | |
| df_project_switch | — | |
| df_project_delete | — | |
| df_issues | — | |
| df_issue | — | |
| df_statuses | — | |
| df_transition | — | |
| df_assign | — | |
| df_comment | — | |
| df_branch | — |
Alle 32 Tools anzeigenWeniger Tools anzeigen
df_find_branchdf_checkoutdf_pulldf_pushdf_mergedf_prdf_flow_createdf_flow_listdf_flow_getdf_flow_updatedf_flow_deletedf_rule_createdf_rule_listdf_rule_getdf_rule_updatedf_rule_toggledf_rule_deletedf_rule_project_overridedf_rule_project_adddf_rule_project_remove
| df_find_branch | — | |
| df_checkout | — | |
| df_pull | — | |
| df_push | — | |
| df_merge | — | |
| df_pr | — | |
| df_flow_create | — | |
| df_flow_list | — | |
| df_flow_get | — | |
| df_flow_update | — | |
| df_flow_delete | — | |
| df_rule_create | — | |
| df_rule_list | — | |
| df_rule_get | — | |
| df_rule_update | — | |
| df_rule_toggle | — | |
| df_rule_delete | — | |
| df_rule_project_override | — | |
| df_rule_project_add | — | |
| df_rule_project_remove | — |
Automatisierte Checks
Geluften am 15. Nov. 2026Vollständiger Bericht →Unsere automatisierten Checks bestanden. Das ist kein Security-Audit: Lies den Code und gib dem Server nur den minimal notwendigen Zugriff. Wie die Checks funktionieren
- Source Repository verknüpft und erreichbarcocaxcode/devflow-mcp is public and reachablegithub.com/cocaxcode/devflow-mcp ↗Bestanden
- Paket nennt dieses Repository als Quelle@cocaxcode/devflow-mcp names cocaxcode/devflow-mcp as sourcenpmjs.com/package/@cocaxcode/devflow-mcp ↗Bestanden
- Build-Provenienz (Sigstore-Attestierung)No build attestation published for this releaseNicht geprüft
- Open Source Lizenz (OSI)MITspdx.org/licenses/MIT.html ↗Bestanden
- Commit oder Release im letzten JahrLast commit or release 2026-03-29github.com/cocaxcode/devflow-mcp ↗Bestanden
- OpenSSF ScorecardNicht geprüft
- Package-Name ähnelt keinem populären PackageNo popular package one edit away from @cocaxcode/devflow-mcpBestanden
- Keine kritischen Advisories im Paket oder seinen Abhängigkeiten100 resolved dependencies checked; no critical advisoryosv.dev ↗Bestanden
- Keine versteckten Anweisungen an das Modell32 tool descriptions and the README read; no override phrases, credential paths or hidden charactersBestanden
- Destruktive Tools sind markiertNo tool named like delete, drop or execBestanden
- Remote-Endpoint beantwortet den MCP-HandshakeNicht geprüft
README
Auf GitHub ansehenOverview
The most complete MCP server for developer workflow automation. 32 tools that connect Jira (Cloud + Server) with GitHub/GitLab (cloud + self-hosted) — so your AI assistant can manage issues, branches, PRs, and deployments without you ever opening a browser tab.
It auto-detects your Jira version and git provider, enforces configurable safety rules, and lets you define custom YAML flow playbooks for repeatable workflows. Projects are configured once and remembered — each with its own Jira instance, git provider, branch conventions, credentials, and directory scopes. The project that matches your current directory activates automatically (default), or you can switch to another for the session (active). All credentials stay local in ~/.devflow-mcp/ — nothing is synced, nothing is tracked, nothing leaves your machine.
Just Talk to It
You don't memorize tool names. You talk naturally and the assistant picks the right tools.
"Set up a project for my Jira + GitHub"
> df_project_setup with:
name: "my-backend"
jiraUrl: "https://myteam.atlassian.net"
jiraEmail: "dev@myteam.com"
jiraToken: "ATATT3x..."
jiraProjectKey: "PROJ"
gitToken: "ghp_..."
Auto-detects:
- Jira Cloud (API v3)
- GitHub (org/my-backend)
- Base branch: main
- Scope: C:/repos/my-backend (your CWD, auto-added)
"List my projects"
Projects:
my-backend [default] [active] scopes: C:/repos/my-backend
my-frontend scopes: C:/repos/my-frontend
"Switch to my-frontend for this session"
Active project switched to: my-frontend (session only)
Default remains: my-backend (based on your current directory)
"Let's work on PROJ-123"
> Reading PROJ-123...
Title: Add OAuth login
Status: To Do | Priority: High
> Branch feat/PROJ-123 not found. Creating...
branch: feat/PROJ-123-add-oauth-login
base: main
Confirm? (confirm: true to execute)
> Moved PROJ-123 → In Progress
> Assigned to you
"Show me my tasks for the ACME project"
ACME-45 Fix OAuth login In Progress High
ACME-52 Dashboard refactor To Do Medium
ACME-61 Update dependencies To Do Low
"Push my changes"
Preview:
branch: feat/PROJ-123-add-oauth-login
pending commits:
- a1b2c3d feat: add login component
- d4e5f6g feat: add auth service
Confirm? (confirm: true to execute)
"Merge main into my current branch"
Conflict detected:
- src/auth/login.ts
- src/config/routes.ts
Resolve the files and commit to complete the merge.
"Create a PR titled 'feat: add OAuth login'"
PR created:
url: https://github.com/org/repo/pull/42
title: feat: add OAuth login
provider: github
"Comment on PROJ-123 that the PR is ready for review"
Preview:
issue: PROJ-123
comment: "PR ready for review: https://github.com/org/repo/pull/42"
Confirm? (confirm: true to publish)
"Create a fix branch for PROJ-456 with description fix-oauth-redirect"
Preview:
branch: fix/PROJ-456-fix-oauth-redirect
base: main
actions: checkout main → pull → create branch
Confirm? (confirm: true to execute)
Installation
Claude Code (recommended)
# Global — available across all your projects
claude mcp add --scope user devflow -- npx -y @cocaxcode/devflow-mcp@latest
# Per-project
claude mcp add devflow -- npx -y @cocaxcode/devflow-mcp@latest
Claude Desktop
{
"mcpServers": {
"devflow": {
"command": "npx",
"args": ["-y", "@cocaxcode/devflow-mcp@latest"]
}
}
}
{
"mcpServers": {
"devflow": {
"command": "npx",
"args": ["-y", "@cocaxcode/devflow-mcp@latest"]
}
}
}
Cursor / Windsurf
// .cursor/mcp.json or .windsurf/mcp.json
{
"mcpServers": {
"devflow": {
"command": "npx",
"args": ["-y", "@cocaxcode/devflow-mcp@latest"]
}
}
}
VS Code / Codex / Gemini CLI
{
"mcpServers": {
"devflow": {
"command": "npx",
"args": ["-y", "@cocaxcode/devflow-mcp@latest"]
}
}
}
Project Scopes
Each project has paths (scopes) — the directories that belong to it. A directory can only be the scope of one project.
This gives you two concepts:
-
Default project: The project whose scope matches your current working directory. This is automatic and persistent — if you are inside
C:/repos/my-backendand that directory is a scope ofmy-backend, thenmy-backendis the default. No action needed. -
Active project: The project you are currently working with. By default it equals the default project, but you can switch it manually with
df_project_switchfor the current session. This resets to the default when you restart.
df_project_list shows both the default and active indicators so you always know where you stand.
Practical example
"Set up a project called my-backend"
→ CWD (C:/repos/my-backend) is auto-added as scope
"Set up another called my-frontend"
→ Run from C:/repos/my-frontend, that directory becomes its scope
"List projects"
→ my-backend [default] [active] scopes: C:/repos/my-backend
my-frontend scopes: C:/repos/my-frontend
"Switch to my-frontend"
→ Session switches. Now my-frontend is active for checking issues, etc.
"List projects"
→ my-backend [default] scopes: C:/repos/my-backend
my-frontend [active] scopes: C:/repos/my-frontend
Close and reopen → my-backend is active again (matches CWD = default)
This means you can work across multiple projects with different Jira instances and git providers — the right credentials are always selected based on where you are, and you can always override for the session when needed.
Tools
32 tools organized in 5 categories.
Projects (5)
| Tool | Description |
|---|---|
df_project_setup |
Configure a new project (Jira + Git, auto-detects everything) |
df_project_update |
Modify project configuration |
df_project_list |
List all configured projects (shows default + active) |
df_project_switch |
Switch the active project for the current session |
df_project_delete |
Delete a project |
df_project_setup with:
name: "my-project"
jiraUrl: "https://myteam.atlassian.net"
jiraEmail: "dev@myteam.com"
jiraToken: "ATATT3x..."
jiraProjectKey: "PROJ"
gitToken: "ghp_..."
Auto-detects:
- Jira Cloud (API v3)
- GitHub (org/my-project)
- Base branch: main
- Scope: your CWD (auto-added)
Jira (6)
| Tool | Description | Confirmation |
|---|---|---|
df_issues |
List my assigned issues (filters by project) | -- |
df_issue |
Full issue detail | -- |
df_statuses |
Available transitions for an issue | -- |
df_transition |
Move issue to another status | Yes |
df_assign |
Assign issue to current user | -- |
df_comment |
Comment on an issue | Yes |
Git (7)
| Tool | Description | Confirmation |
|---|---|---|
df_branch |
Create branch (feat/ or fix/) from base |
Yes |
df_find_branch |
Search branch by issue key | -- |
df_checkout |
Switch branch (with safety guard) | -- |
df_pull |
Pull current branch from remote | -- |
df_push |
Push current branch to remote | Yes |
df_merge |
Merge a branch into the current one | Yes |
df_pr |
Create PR (GitHub) or MR (GitLab) | -- |
Important:
df_branch,df_checkout, anddf_pushverify the working directory before executing. They block if there are uncommitted files or unpushed commits, listing exactly what needs attention. This prevents accidental work loss.
Flows (5)
| Tool | Description |
|---|---|
df_flow_create |
Create a custom flow |
df_flow_list |
List all flows |
df_flow_get |
View flow details |
df_flow_update |
Modify an existing flow |
df_flow_delete |
Delete a flow (protects start-task) |
Rules (9)
| Tool | Description | Level |
|---|---|---|
df_rule_create |
Create a global rule | Global |
df_rule_list |
List all rules | Global |
df_rule_get |
View rule details | Global |
df_rule_update |
Modify a rule | Global |
df_rule_toggle |
Enable/disable a rule | Global |
df_rule_delete |
Delete a rule | Global |
df_rule_project_override |
Enable/disable a global rule for a project | Project |
df_rule_project_add |
Create a project-only rule | Project |
df_rule_project_remove |
Remove a project rule or override | Project |
Flows
Flows are YAML playbooks that define step sequences. They don't run automatically -- you tell the assistant when to use them.
Default: start-task
Triggered when you say something like "let's work on PROJ-123":
name: start-task
trigger: "when the user says 'let's work on', 'start task', 'new task' + issue ID"
steps:
- tool: df_issue
note: "Read issue detail and summarize the task"
- tool: df_find_branch
note: "Check if a branch already exists for this issue"
- tool: df_branch
confirm: true
note: "Only if no existing branch was found"
- tool: df_statuses
note: "Get transitions to find the 'In Progress' transition ID"
- tool: df_transition
target: "In Progress"
confirm: true
- tool: df_assign
note: "Assign the issue if it has no assignee"
Custom flows
Create your own by asking naturally:
"Create a flow called 'finish-task' that pushes, creates a PR, and comments on Jira"
name: finish-task
trigger: "when the user says 'finish task', 'wrap up' + issue ID"
steps:
- tool: df_push
confirm: true
note: "Push pending commits"
- tool: df_pr
note: "Create PR/MR to base branch"
- tool: df_comment
confirm: true
note: "Comment on the issue with the PR link"
The start-task flow can be modified but not deleted. Use df_flow_update to change any flow's steps, trigger, or name.
Rules
Rules are configurable guards that block or warn about actions. Two levels: global and per-project.
Default rules
| Rule | Scope | Action | What it does |
|---|---|---|---|
no-merge-to-base |
git | block | Prevent direct push/merge to main/master |
no-merge-from-dev |
git | block | Prevent merging dev/develop/int branches out |
no-close-issues |
jira | block | Prevent closing issues (Done, Closed, Resolved...) |
only-own-issues |
jira | block | Prevent modifying issues assigned to others |
Project overrides
Each project can override global rules or define its own:
# Disable a global rule for one project
df_rule_project_override: name="no-close-issues", enabled=false
# Add a project-only rule
df_rule_project_add: name="no-push-friday", scope="git", action="warn"
# Remove an override or project rule
df_rule_project_remove: name="no-close-issues"
Custom rules
df_rule_create:
name: "no-push-friday"
description: "Warn when pushing on Fridays"
scope: "git" # git | jira | all
action: "warn" # block | warn
Note: Rule resolution order: Global rules load first, then project overrides are applied (project wins), then project-specific rules are added. Rules are filtered by scope and enabled state before evaluation.
Storage
Everything lives in ~/.devflow-mcp/ — your home directory, never inside any git repository. Jira tokens, GitHub PATs, GitLab tokens — all stored locally with 600 permissions (owner-only read/write). Nothing gets committed, nothing gets pushed, nothing leaves your machine.
~/.devflow-mcp/
├── projects/ # Project configs (.json) — credentials included
│ ├── my-project.json # Jira URL, token, GitHub PAT, branch rules, scopes
│ └── other-project.json
├── flows/ # Flow definitions (.yaml)
│ └── start-task.yaml
├── rules/ # Global rules (.json)
│ ├── no-merge-to-base.json
│ ├── no-merge-from-dev.json
│ ├── no-close-issues.json
│ └── only-own-issues.json
├── active-project # Current active project (plain text)
└── config.json # Server configuration
Project resolution works automatically: devflow-mcp matches your current working directory against each project's paths (scopes). The matching project becomes the default. You can override it for the session with df_project_switch, which sets the active project. On restart, the active project resets to whatever the default is for your CWD. If no match is found and no active project is set, it prompts you to configure with df_project_setup.
Compatibility
Jira
| Type | API | Authentication |
|---|---|---|
| Jira Cloud | REST API v3 | Email + API Token (Basic) |
| Jira Server / Data Center | REST API v2 | Personal Access Token (Bearer) |
Auto-detection via /rest/api/2/serverInfo -- no manual configuration needed.
Git providers
| Provider | API |
|---|---|
| GitHub (cloud) | REST API v3 |
| GitHub Enterprise | REST API v3 (custom URL) |
| GitLab (cloud) | REST API v4 |
| GitLab self-hosted | REST API v4 (custom URL) |
Auto-detection by parsing the repository's remote URL.
Architecture
src/
├── index.ts # Entry point (stdio transport)
├── server.ts # Factory: createServer() + instructions
├── lib/
│ ├── types.ts # Interfaces, defaults, valid tool names
│ ├── storage.ts # CRUD: projects, flows, rules, config
│ ├── git-exec.ts # Git CLI wrapper (execFile)
│ ├── jira/
│ │ ├── client.ts # JiraClient (Cloud v3 + Server v2)
│ │ └── types.ts # Raw Jira API response shapes
│ └── git/
│ ├── detect.ts # parseRemoteUrl (SSH/HTTPS, GitHub/GitLab)
│ ├── github.ts # GitHubClient (REST API v3)
│ ├── gitlab.ts # GitLabClient (REST API v4)
│ ├── factory.ts # createGitProviderClient()
│ └── types.ts # Git provider interfaces
└── tools/
├── project.ts # 5 tools: setup, update, list, switch, delete
├── jira.ts # 6 tools: issues, issue, statuses, transition, assign, comment
├── git.ts # 7 tools: branch, find_branch, checkout, pull, push, merge, pr
├── flow.ts # 5 tools: create, list, get, update, delete
└── rule.ts # 9 tools: CRUD global + 3 project-level
Stack: TypeScript · MCP SDK · Zod · YAML · tsup
Tests: 4 suites · 51 tests (Vitest + InMemoryTransport)
devflow MCP Fragen
Wie füge ich devflow MCP zu Claude Code hinzu?
Führe claude mcp add devflow-mcp -- npx -y @cocaxcode/devflow-mcp in deinem Terminal aus. Füge --scope user hinzu, damit der Server in jedem Projekt verfügbar ist.
Wie füge ich devflow MCP zu Cursor hinzu?
Öffne ~/.cursor/mcp.json und füge den Server unter mcpServers hinzu, mit der Cursor-Config aus dem Installationsabschnitt oben.
Welche Tools bietet devflow MCP?
Er stellt 32 Tools bereit, darunter df_project_setup, df_project_update, df_project_list, df_project_switch, df_project_delete.
Wie geht der Server mit meinen Credentials um?
Alle Credentials werden lokal in deinem Home-Verzeichnis gespeichert und niemals extern synchronisiert oder getrackt.
Kann ich das sowohl mit Jira Cloud als auch mit Jira Server nutzen?
Ja, der Server unterstützt sowohl Jira Cloud als auch Jira Server und erkennt deine Jira-Version automatisch.
Kann ich eigene automatisierte Workflows erstellen?
Ja, du kannst eigene YAML Flow Playbooks definieren, um wiederholbare Sequenzen von Tools zu erstellen.