MCP server devflow
✓ VerificadoConecta o Jira ao GitHub e GitLab para automatizar o gerenciamento de issues, criação de branches, pull requests e fluxos de trabalho de desenvolvedores via assistente de IA.
Também conhecido como cocaxcode/devflow-mcp, @cocaxcode/devflow-mcp
- Stars
- 1
- Ferramentas
- 32
- Downloads, 30 dias
- 311
- Versão mais recente
- 0.1.8
- Último commit
- 29 de mar. de 2026
- Licença
- MIT
O que é o MCP devflow?
devflow é um MCP server. Conecta o Jira ao GitHub e GitLab para automatizar o gerenciamento de issues, criação de branches, pull requests e fluxos de trabalho de desenvolvedores via assistente de IA. Ele expõe 32 ferramentas, como df_project_setup, df_project_update, df_project_list.
Resumo gerado a partir do README do projeto
Sobre o MCP server de devflow
Automatizar a conexão entre o Jira e provedores Git como GitHub ou GitLab é o que o devflow-mcp permite para desenvolvedores que utilizam assistentes de IA. Este MCP server fornece 32 ferramentas que permitem que uma IA gerencie todo o ciclo de vida de uma tarefa, desde a leitura de detalhes de issues e transição de status até a criação de branches, push de código e abertura de pull requests. Ele suporta tanto Jira Cloud quanto Server, bem como ambientes Git em nuvem ou self-hosted.
Os usuários configuram projetos definindo escopos específicos, que são diretórios locais que acionam automaticamente as credenciais e configurações corretas. Isso garante que, ao alternar entre diferentes repositórios de código, o assistente utilize a instância do Jira e os tokens Git apropriados sem necessidade de troca manual. Todas as credenciais sensíveis permanecem armazenadas localmente no seu diretório home para garantir a privacidade. O sistema também suporta playbooks YAML personalizados chamados flows, permitindo que você defina sequências repetíveis de chamadas de ferramentas para fluxos de trabalho complexos.
O que você pode fazer com ele
- 1Otimizar fluxos de pull requestFinalize uma tarefa de codificação fazendo o push das alterações, criando um pull request e adicionando um comentário na issue do Jira com o link.
- 2Gerenciar múltiplos ambientes de projetoAlterne automaticamente entre diferentes repositórios de backend e frontend que utilizam diferentes instâncias do Jira e provedores Git.
Escrito a partir do README do projeto. Cada caso de uso é verificado com uma citação dele.
Como instalar o MCP devflow
Formatos verificados em 10 nov 2026Adicionar ao CursorAdicionar ao GooseInstalar o MCP devflow no Claude Code
$ claude mcp add devflow-mcp -- npx -y @cocaxcode/devflow-mcpInstalar o MCP devflow no Cursor
~/.cursor/mcp.json
{
"mcpServers": {
"devflow-mcp": {
"command": "npx",
"args": [
"-y",
"@cocaxcode/devflow-mcp"
]
}
}
}Instalar o MCP devflow no VS Code
.vscode/mcp.json
{
"servers": {
"devflow-mcp": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"@cocaxcode/devflow-mcp"
]
}
}
}Instalar o MCP devflow no VS Code CLI
$ code --add-mcp '{"name":"devflow-mcp","type":"stdio","command":"npx","args":["-y","@cocaxcode/devflow-mcp"]}'Instalar o MCP devflow no Claude Desktop
claude_desktop_config.json
{
"mcpServers": {
"devflow-mcp": {
"command": "npx",
"args": [
"-y",
"@cocaxcode/devflow-mcp"
]
}
}
}Instalar o MCP devflow no Codex
$ codex mcp add devflow-mcp -- npx -y @cocaxcode/devflow-mcpInstalar o MCP devflow no Codex config.toml
~/.codex/config.toml
[mcp_servers.devflow-mcp] command = "npx" args = ["-y", "@cocaxcode/devflow-mcp"]
Instalar o MCP devflow no Gemini CLI
$ gemini mcp add -s user devflow-mcp npx -- -y @cocaxcode/devflow-mcpInstalar o MCP devflow no Gemini settings.json
~/.gemini/settings.json
{
"mcpServers": {
"devflow-mcp": {
"command": "npx",
"args": [
"-y",
"@cocaxcode/devflow-mcp"
]
}
}
}Ferramentas do MCP devflow 32
Detectadas a partir do 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 | — |
Mostrar todas as 32 ferramentasMostrar menos ferramentas
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 | — |
Verificações automatizadas
Executado em 15 de nov. de 2026Relatório completo →Passou em nossas verificações automatizadas. Isso não é uma auditoria de segurança: leia o código e dê ao servidor o acesso mais restrito de que ele precisa. Como as verificações funcionam
- Repositório de origem vinculado e acessívelcocaxcode/devflow-mcp is public and reachablegithub.com/cocaxcode/devflow-mcp ↗Passou
- O pacote indica este repositório como sua origem@cocaxcode/devflow-mcp names cocaxcode/devflow-mcp as sourcenpmjs.com/package/@cocaxcode/devflow-mcp ↗Passou
- Proveniência da build (atestação Sigstore)No build attestation published for this releaseNão verificado
- Licença de código aberto (OSI)MITspdx.org/licenses/MIT.html ↗Passou
- Commit ou release no último anoLast commit or release 2026-03-29github.com/cocaxcode/devflow-mcp ↗Passou
- OpenSSF ScorecardNão verificado
- Nome do pacote não é próximo a um pacote popularNo popular package one edit away from @cocaxcode/devflow-mcpPassou
- Nenhum aviso crítico no pacote ou em suas dependências100 resolved dependencies checked; no critical advisoryosv.dev ↗Passou
- Sem instruções ocultas para o modelo32 tool descriptions and the README read; no override phrases, credential paths or hidden charactersPassou
- Ferramentas destrutivas estão rotuladasNo tool named like delete, drop or execPassou
- O endpoint remoto responde ao handshake do MCPNão verificado
README
Ver no GitHubOverview
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)
Perguntas sobre o MCP devflow
Como adiciono o MCP devflow ao Claude Code?
Execute claude mcp add devflow-mcp -- npx -y @cocaxcode/devflow-mcp no seu terminal. Adicione --scope user para torná-lo disponível em todos os projetos.
Como adiciono o MCP devflow ao Cursor?
Abra ~/.cursor/mcp.json e adicione o servidor em mcpServers, usando a configuração do Cursor mostrada na seção de instalação acima.
Quais ferramentas o MCP devflow oferece?
Ele expõe 32 ferramentas, incluindo df_project_setup, df_project_update, df_project_list, df_project_switch, df_project_delete.
Como o servidor lida com minhas credenciais?
Todas as credenciais são mantidas localmente no seu diretório home e nunca são sincronizadas ou rastreadas externamente.
Posso usar isso tanto com o Jira Cloud quanto com o Jira Server?
Sim, o servidor suporta tanto Jira Cloud quanto Jira Server, e detecta automaticamente a sua versão do Jira.
Posso criar fluxos de trabalho automatizados personalizados?
Sim, você pode definir playbooks de fluxo YAML personalizados para criar sequências repetíveis de ferramentas.