devflow-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| JIRA_PAT | Yes | Your Jira Personal Access Token (Bearer). | |
| GITLAB_URL | No | The base URL of your self-hosted GitLab instance (optional). If omitted, GitLab tools self-disable. | |
| GITLAB_TOKEN | No | Your GitLab personal access token with read_api and read_repository scopes (optional). | |
| JIRA_BASE_URL | Yes | The base URL of your Jira Server/Data Center instance (e.g., https://jira.your-company.com). | |
| JIRA_VERIFY_SSL | No | Set to 'false' to disable SSL verification for internal self-signed certs. | true |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| jira_my_tasksA | List MY tasks: assigned to me, in active statuses (default: To Do, Doing). This is the default local-dev working set — call with no key to see what to work on. Override statuses via env JIRA_ACTIVE_STATUSES. |
| jira_get_issueB | Fetch a single Jira issue (read-only). |
| jira_get_commentsA | Fetch comments on a Jira issue (read-only). Returns the most recent |
| jira_get_subtasksA | List subtasks of a Jira issue (read-only). |
| jira_get_linked_issuesA | List issues linked to a Jira issue (read-only), with relation + direction. |
| jira_searchA | Search Jira issues by JQL (read-only), with offset pagination. |
| jira_get_fieldsA | List Jira field metadata to resolve custom field IDs (read-only). Run once per instance during setup to discover IDs for Sprint, Epic Link, Story Points, etc. (these differ per Jira instance). |
| jira_get_ticket_bundleA | One-call ticket context for analysis (read-only): the PRIMARY tool for /jira-dev. Returns the issue + subtasks + linked issues + recent comments in a single token-efficient payload, avoiding multiple round-trips. |
| jira_get_epicA | Get a Jira epic by key/id (read-only). |
| jira_get_epic_issuesC | List issues belonging to an epic (read-only). |
| jira_get_sprintB | Get a sprint by id (read-only). |
| jira_get_sprint_issuesB | List issues in a sprint (read-only). |
| jira_get_attachmentsA | List attachment metadata on a Jira issue (read-only, no download). Use this to see whether a task has images/mockups worth analyzing. Download a specific one with jira_download_attachment. |
| jira_download_attachmentA | Download one Jira attachment to a LOCAL file and return its path (read-only). The download uses the server's authenticated client (token stays hidden).
Claude can then read the returned |
| gitlab_search_mrsA | Find merge requests referencing a ticket key (read-only, heuristic). Searches MR title + description for the key. Linkage is a HEURISTIC — results are candidates, not guaranteed matches. |
| gitlab_get_mrB | Get a single merge request (read-only). |
| gitlab_get_mr_commitsB | List commits in a merge request (read-only). |
| gitlab_get_commitsB | List recent commits for a project branch/ref (read-only). |
| gitlab_get_commit_diffA | Get a commit's diff (read-only). Truncated for token efficiency. |
| gitlab_get_pipeline_statusA | Get latest pipeline status for a branch/ref or a merge request (read-only). Provide either |
| gitlab_search_codeA | Search code (blobs) across GitLab (read-only). Degrades gracefully. Use this only for repos NOT checked out locally; for local repos prefer Claude's native Grep/Glob. Requires Advanced Search on the instance. |
| gitlab_get_fileA | Read a repo file's content (read-only). Truncated for token efficiency. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 22 tools
Each tool has a unique, well-defined purpose. GitLab and Jira tools are cleanly separated by prefixes, and within each domain, tools target distinct resources (e.g., commits, MRs, pipelines, issues, attachments) with no functional overlap.
All tools follow a consistent `domain_verb_noun` pattern in snake_case. GitLab tools start with `gitlab_` and Jira tools with `jira_`, and verbs like `get_`, `search_`, `download_` are used uniformly.
With 22 tools, the server covers two distinct domains (GitLab and Jira) comprehensively. While slightly above the typical 3-15 range, each tool addresses a specific need for developer workflows, justifying the count.
The tools comprehensively cover read operations for GitLab (commits, files, MRs, pipelines, code search) and Jira (issues, epics, sprints, attachments, comments). However, write operations (creating/updating MRs or issues) are absent, leaving a gap for lifecycle management.