Skip to main content
Glama
vertliba

jira-minimal-mcp

by vertliba
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

jira-minimal-mcp

Minimal MCP server for Jira. Only ~150-1500 tokens vs ~25,000 for official Atlassian MCP.

Installation

Docker (recommended)

docker pull vertliba/jira-minimal-mcp

uv (local)

uv tool install git+https://github.com/vertliba/jira-minimal-mcp

Related MCP server: jira-mcp

Usage

Basic (only get_issue, ~150 tokens)

docker run -i --rm \
  -e JIRA_URL=https://xxx.atlassian.net \
  -e JIRA_USERNAME=user@example.com \
  -e JIRA_API_TOKEN=xxx \
  vertliba/jira-minimal-mcp

With additional features

docker run -i --rm \
  -e JIRA_URL=https://xxx.atlassian.net \
  -e JIRA_USERNAME=user@example.com \
  -e JIRA_API_TOKEN=xxx \
  vertliba/jira-minimal-mcp \
  --enable-search --enable-comments

All features (~1500 tokens)

docker run -i --rm \
  -e JIRA_URL=https://xxx.atlassian.net \
  -e JIRA_USERNAME=user@example.com \
  -e JIRA_API_TOKEN=xxx \
  vertliba/jira-minimal-mcp \
  --enable-all

CLI Arguments

Argument

Description

Tools

(none)

Base functionality

jira_get_issue

--enable-search

JQL queries

jira_search

--enable-create

Create issues

jira_create_issue

--enable-update

Update issues

jira_update_issue, jira_assign_issue

--enable-comments

Comments

jira_add_comment, jira_get_comments

--enable-all

All tools

All of the above

Environment Variables

Variable

Required

Description

JIRA_URL

Yes

Jira instance URL (e.g., https://xxx.atlassian.net)

JIRA_USERNAME

Yes

Jira username/email

JIRA_API_TOKEN

Yes

Jira API token (create here)

MCP Client Configuration

Claude Code (.mcp.json)

{
  "mcpServers": {
    "jira": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "--network", "host",
        "-e", "JIRA_URL", "-e", "JIRA_USERNAME", "-e", "JIRA_API_TOKEN",
        "vertliba/jira-minimal-mcp", "--enable-search"],
      "env": {
        "JIRA_URL": "https://xxx.atlassian.net",
        "JIRA_USERNAME": "user@example.com",
        "JIRA_API_TOKEN": "YOUR_TOKEN"
      }
    }
  }
}

Codex (config.toml)

[mcp_servers.jira]
command = "docker"
args = ["run", "-i", "--rm", "--network", "host",
  "-e", "JIRA_URL", "-e", "JIRA_USERNAME", "-e", "JIRA_API_TOKEN",
  "vertliba/jira-minimal-mcp", "--enable-search"]
env = { JIRA_URL = "https://xxx.atlassian.net", JIRA_USERNAME = "user@example.com", JIRA_API_TOKEN = "YOUR_TOKEN" }

Local (uv)

{
  "mcpServers": {
    "jira": {
      "command": "uv",
      "args": ["run", "jira-minimal-mcp", "--enable-search"],
      "env": {
        "JIRA_URL": "https://xxx.atlassian.net",
        "JIRA_USERNAME": "user@example.com",
        "JIRA_API_TOKEN": "YOUR_TOKEN"
      }
    }
  }
}

Why?

The official Atlassian MCP server includes 28 tools and consumes ~25,000 tokens of context on every request. This is wasteful if you only need to read issues.

jira-minimal-mcp starts with just 1 tool (~150 tokens) and lets you add only what you need.

License

MIT

Available Tools

1 tool
jira_get_issueA

Get Jira issue by key (e.g., PROJ-123). Returns summary, status, type, assignee, and description.

ParametersJSON Schema
NameRequiredDescriptionDefault
issue_keyYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It discloses that the tool returns specific fields (summary, status, type, assignee, description) but does not mention permissions, side effects, rate limits, or other behavioral traits. For a simple read operation, this is acceptable but not thorough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is one sentence, front-loaded with action and resource. Every word adds value: verb, resource, key format, returned fields. No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (1 parameter, no annotations, output schema exists but not shown), the description is largely complete. It lists returned fields. However, it omits details like whether the issue key is case-sensitive or if authentication is required, but for a basic get tool, this is sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter 'issue_key' is explained with an example (e.g., PROJ-123), clarifying the expected format. Schema had 0% description coverage, so the description fully compensates by adding meaningful context beyond the parameter name and type.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states verb 'Get', resource 'Jira issue', and specifies the expected key format (e.g., PROJ-123). It also lists the returned fields: summary, status, type, assignee, description. No siblings exist to differentiate, so purpose is crystal clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. However, with no siblings listed and the tool being a straightforward retrieval, the description adequately implies its use. Lacks prerequisites or context about when not to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev0.1.0
    • First observedjira_get_issue
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.9/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is no possibility of confusion or ambiguity between tools.

Naming Consistency5/5

The single tool follows a consistent verb_noun pattern (jira_get_issue), so naming is perfectly consistent.

Tool Count2/5

A single tool for a Jira server is too few; typical usage requires multiple operations like create, update, or search, making this feel incomplete despite the 'minimal' label.

Completeness1/5

Only a read operation is provided; missing essential operations like create, update, delete, and search, leaving the surface severely incomplete for any meaningful workflow.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • jira-mcp

    jack-oval-traits
    A
    license
    Not graded
    quality
    C
    maintenance
    A token-lean MCP server for Jira Cloud that enables natural language interaction with issues, comments, transitions, and more through a set of seven normalized tools, reducing token usage via field allowlists and ADF-to-Markdown conversion.
    2
    MIT

  • jira-mcp-ai

    IvanBBaev
    A
    license
    A
    quality
    B
    maintenance
    MCP server for Jira Cloud that lets AI agents search, read, and write Jira issues using your own Atlassian account and API token, with write operations gated behind explicit opt-in.
    52
    5 npm
    MIT