Skip to main content
Glama
akhilthomas236

MCP Jira & Confluence Server

by akhilthomas236
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

MCP Server for Jira and Confluence

A Model Context Protocol (MCP) server that integrates with Atlassian's Jira and Confluence, enabling AI assistants to interact with these tools directly.

Features

  • Jira Integration

    • List recent issues

    • View issue details including comments

    • Create new issues

    • Add comments to issues

    • Transition issues between statuses

    • Get assigned issues - Retrieve your assigned tickets ordered by priority and date

    • Summarize issues - Get comprehensive issue summaries with comments and history

    • Extract Confluence and Git links - Find all Confluence page references and Git repository URLs in issues

  • Confluence Integration

    • List recent pages

    • View page content

    • Create new pages

    • Update existing pages

    • Add comments to pages

    • Search pages using CQL (Confluence Query Language)

    • Get specific pages by ID or title

    • Ask questions about page content

  • AI-Powered Prompts

    • Summarize Jira issues

    • Create structured Jira issue descriptions

    • Summarize Confluence pages

    • Generate structured Confluence content

Related MCP server: MCP Atlassian

Installation

  1. Clone the repository

  2. Install dependencies using uv:

pip install uv
uv pip install -e .

Configuration

Environment Variables

Set the following environment variables to configure the server:

Jira Configuration

  • JIRA_URL: Base URL of your Jira instance (e.g., https://yourcompany.atlassian.net)

  • JIRA_USERNAME: Your Jira username/email

  • JIRA_API_TOKEN: Your Jira API token or password

  • JIRA_PERSONAL_TOKEN: Personal access token (alternative to username/API token)

Confluence Configuration

  • CONFLUENCE_URL: Base URL of your Confluence instance (e.g., https://yourcompany.atlassian.net/wiki)

  • CONFLUENCE_USERNAME: Your Confluence username/email

  • CONFLUENCE_API_TOKEN: Your Confluence API token or password

  • CONFLUENCE_PERSONAL_TOKEN: Personal access token (alternative to username/API token)

Quick Setup

  1. Create API tokens from your Atlassian account settings

  2. Set environment variables in your shell:

export JIRA_URL="https://yourcompany.atlassian.net"
export JIRA_USERNAME="your-email@company.com"
export JIRA_API_TOKEN="your-jira-api-token"

export CONFLUENCE_URL="https://yourcompany.atlassian.net/wiki"
export CONFLUENCE_USERNAME="your-email@company.com"
export CONFLUENCE_API_TOKEN="your-confluence-api-token"

  1. Or use the provided run.sh script with environment variables

Usage

Starting the Server

Run the server directly:

python -m mcp_jira_confluence.server

VSCode MCP Extension

If using with the VSCode MCP extension, the server is automatically configured via .vscode/mcp.json.

Claude Desktop

To use with Claude Desktop, add the following configuration:

On MacOS: ~/Library/Application\ Support/Claude/claude_desktop_config.json On Windows: %APPDATA%/Claude/claude_desktop_config.json

"mcpServers": {
  "mcp-jira-confluence": {
    "command": "uv",
    "args": [
      "--directory",
      "/Users/annmariyajoshy/vibecoding/mcp-jira-confluence",
      "run",
      "mcp-jira-confluence"
    ]
    }
  }
"mcpServers": {
  "mcp-jira-confluence": {
    "command": "uvx",
    "args": [
      "mcp-jira-confluence"
    ]
  }
}

Resources

The server exposes the following types of resources:

  • jira://issue/{ISSUE_KEY} - Jira issues

  • confluence://page/{PAGE_ID} - Confluence pages

  • confluence://space/{SPACE_KEY}/page/{PAGE_ID} - Confluence pages with space key

Usage

Available Tools

Jira Tools

  • create-jira-issue: Create a new Jira issue

  • comment-jira-issue: Add a comment to an issue

  • transition-jira-issue: Change an issue's status

  • get-jira-issue: Get detailed information about a specific Jira issue

  • get-my-assigned-issues: Get issues assigned to you, ordered by priority and date

  • summarize-jira-issue: Get comprehensive issue summary with comments and history

  • extract-confluence-links: Find all Confluence and Git repository links in an issue

Confluence Tools

  • create-confluence-page: Create a new Confluence page

  • update-confluence-page: Update an existing page (version auto-fetched if not provided)

  • comment-confluence-page: Add a comment to a page

  • get-confluence-page: Get a specific page with optional comments/history

  • search-confluence: Search pages using CQL queries

  • ask-confluence-page: Ask questions about page content

Usage Examples

Getting Your Assigned Issues

Get issues assigned to you ordered by priority (highest first) and creation date (newest first):

Default (25 issues, exclude completed):
- No parameters needed

Custom parameters:
- max_results: 50 (max: 100)
- include_done: true (includes closed/resolved issues)

The tool returns issues with:
- Issue key, summary, status, priority
- Issue type, creation date, due date
- Formatted for easy reading

Getting a Specific Jira Issue

Get detailed information about any Jira issue by its key:

Basic issue info:
- issue_key: "PROJ-123" (required)
- include_comments: false (default)

With comments:
- issue_key: "PROJ-123"
- include_comments: true (includes last 3 comments)

Returns:
- Complete issue details (status, priority, assignee, dates)
- Full description
- Optional recent comments
- Formatted for easy reading

Summarizing a Jira Issue

Get comprehensive issue information including:
- Basic details (status, priority, assignee, dates)
- Full description
- Recent comments (last 5)
- Confluence page references
- Status history

Parameters:
- issue_key: "PROJ-123" (required)

Returns formatted markdown summary perfect for AI analysis.

Extracting Links from Issues

Find all Confluence and Git repository links in a Jira issue from:
- Issue description text
- Comments from all users  
- Remote links attached to the issue

Parameters:
- issue_key: "PROJ-123" (required)
- include_git_urls: true (default, set to false to exclude Git links)

Supported Git platforms:
- GitHub, GitLab, Bitbucket (cloud and self-hosted)
- Azure DevOps / Visual Studio Team Services
- Generic Git hosting platforms
- SSH Git URLs (git@server:org/repo.git)

Returns:
- Confluence page links with titles and context
- Git repository URLs with source location
- Organized by category (Confluence vs Git)
- Source information (description, comment, remote link)

Getting a Confluence Page

You can retrieve a page using either its ID or title + space key:

By ID:
- page_id: "123456789"
- include_comments: true
- include_history: false

By title and space:
- title: "API Documentation"
- space_key: "DEV"
- include_comments: false

Searching Confluence Pages

Search using CQL (Confluence Query Language):

Simple text search:
- query: "API Documentation"
- max_results: 10

Search by title:
- query: "title ~ 'API Documentation'"
- max_results: 10

Search in specific space:
- query: "space.key = 'DEV'"
- space_key: "DEV"
- max_results: 5

Recent pages:
- query: "lastmodified >= now('-7d')"

Note: The system automatically adds "type = page" to queries that don't specify a content type.

Asking Questions About Pages

Ask specific questions about page content:

- page_id: "123456789"
- question: "What are the main features described?"
- context_type: "summary" | "details" | "specific"

Or using title + space:
- title: "User Guide"
- space_key: "DOCS"
- question: "How do I configure authentication?"
- context_type: "details"

Common CQL Query Examples

  • Simple text search: "API Documentation" (searches in content and title)

  • Search by title: title ~ "API Documentation"

  • Search in space: space.key = "DEV"

  • Recent pages: lastmodified >= now("-7d")

  • By author: creator = "john.doe"

  • Combined: title ~ "API" AND space.key = "DEV" AND lastmodified >= now("-30d")

  • Text in content: text ~ "authentication method"

Note: All queries automatically include type = page unless explicitly specified otherwise.

Available Prompts

AI-Powered Analysis

  • summarize-jira-issue: Create a summary of a Jira issue

  • create-jira-description: Generate a structured issue description

  • summarize-confluence-page: Create a summary of a Confluence page

  • create-confluence-content: Generate structured Confluence content

  • answer-confluence-question: Answer questions about specific page content

Context Types for Question Answering

  • summary: Quick answers using first 1000-1500 characters

  • details: Comprehensive answers using full page content

  • specific: Full content with enhanced filtering (future feature)

For detailed Confluence tool documentation and advanced CQL examples, see CONFLUENCE_TOOLS.md.

Practical Examples

Workflow: Research and Documentation

  1. Search for relevant pages: Use search-confluence to find pages related to your topic

  2. Get page details: Use get-confluence-page to retrieve full content with comments

  3. Ask specific questions: Use ask-confluence-page to extract specific information

  4. Create summaries: Use summarize-confluence-page prompt for quick overviews

Common Use Cases

Finding Documentation

"Search for all API documentation in the DEV space that was updated in the last month"
→ Use search-confluence with query: "type = page AND space.key = 'DEV' AND title ~ 'API' AND lastmodified >= now('-30d')"

Getting Page Information

"Get the User Guide page from DOCS space with all comments"
→ Use get-confluence-page with title: "User Guide", space_key: "DOCS", include_comments: true

Content Analysis

"What authentication methods are supported according to the API documentation?"
→ Use ask-confluence-page with the API doc page ID and your specific question

Knowledge Extraction

"Summarize the key points from the deployment guide"
→ Use summarize-confluence-page prompt with the deployment guide page ID

Development

Building and Publishing

To prepare the package for distribution:

  1. Sync dependencies and update lockfile:

uv sync

  1. Build package distributions:

uv build

This will create source and wheel distributions in the dist/ directory.

  1. Publish to PyPI:

uv publish

Note: You'll need to set PyPI credentials via environment variables or command flags:

  • Token: --token or UV_PUBLISH_TOKEN

  • Or username/password: --username/UV_PUBLISH_USERNAME and --password/UV_PUBLISH_PASSWORD

Debugging

Since MCP servers run over stdio, debugging can be challenging. For the best debugging experience, we strongly recommend using the MCP Inspector.

You can launch the MCP Inspector via npm with this command:

npx @modelcontextprotocol/inspector uv --directory /Users/annmariyajoshy/vibecoding/mcp-jira-confluence run mcp-jira-confluence

Upon launching, the Inspector will display a URL that you can access in your browser to begin debugging.

Changelog

Version 0.2.4 (2025-07-27)

Enhanced Confluence Search:

  • Smart CQL Query Builder - Automatically enhances simple search queries with proper CQL syntax:

    • Simple text queries - "API docs" becomes (title ~ "API docs" OR text ~ "API docs")

    • Phrase detection - Longer queries become text ~ "your search phrase"

    • Advanced CQL preservation - Complex queries with operators (AND, OR, ~, =) are used as-is

    • Space integration - Automatically adds space constraints when specified

    • Query transparency - Shows the enhanced CQL query in search results

Technical Improvements:

  • Added build_smart_cql_query() function for intelligent query enhancement

  • Enhanced search-confluence tool description to explain automatic query enhancement

  • Better user experience with query transformation visibility

  • Improved search accuracy for both novice and advanced users

Version 0.2.3 (2025-07-27)

Enhanced Link Extraction:

  • Enhanced extract-confluence-links - Now extracts both Confluence pages AND Git repository URLs:

    • Git Repository Support - Detects URLs from GitHub, GitLab, Bitbucket, Azure DevOps, and other Git platforms

    • Smart Pattern Matching - Uses regex patterns to identify repository URLs in issue descriptions, comments, and remote links

    • Comprehensive Coverage - Scans all issue text fields for both Confluence and Git references

    • Rich Output - Returns organized lists of both Confluence pages and Git repositories with context

Technical Improvements:

  • Added _extract_git_urls_from_text() method with support for major Git platforms

  • Enhanced URL extraction patterns for better accuracy

  • Improved tool description and documentation

  • Better organization of extracted links by type (Confluence vs Git)

Version 0.2.2 (2025-07-27)

New Jira Tools:

  • get-my-assigned-issues - Get issues assigned to you ordered by priority (highest first) and creation date (newest first)

    • Configurable max results (default: 25, max: 100)

    • Option to include completed/closed issues

    • Rich formatting with status, priority, type, dates

  • summarize-jira-issue - Comprehensive issue analysis including:

    • Complete issue details (status, priority, assignee, dates)

    • Full description and recent comments (last 5)

    • Confluence page references from remote links

    • Formatted as markdown for easy AI processing

  • extract-confluence-links - Find all Confluence page references in issues:

    • Scans issue description, all comments, and remote links

    • Supports multiple Confluence URL patterns (atlassian.net, custom domains)

    • Returns link titles, URLs, and source context

Technical Enhancements:

  • Added get_current_user() API method for user context

  • Enhanced JQL queries with proper field selection and ordering

  • Robust URL extraction with regex pattern matching

  • Improved error handling for missing or invalid issues

  • Better date formatting for human readability

Version 0.2.1 (2025-07-27)

Formatting Fixes:

  • Fixed 400 Bad Request errors with complex markdown formatting in Confluence pages

  • Implemented intelligent complexity detection - automatically chooses conversion strategy

  • Added robust error handling with graceful fallbacks for conversion failures

  • Enhanced list processing with proper HTML grouping and nesting

Version 0.2.0 (2025-07-27)

Major Improvements:

  • Fixed EmbeddedResource validation errors - All tools now use the correct MCP structure with type: "resource" and proper TextResourceContents format

  • Enhanced Confluence formatting - Dramatically improved markdown to Confluence conversion:

    • Proper list handling (grouped <ul>/<ol> tags instead of individual ones)

    • Better code block formatting with language support

    • Improved inline formatting (bold, italic, code, links)

    • Smarter paragraph handling

    • More robust markdown detection patterns

  • Fixed HTTP 409 conflicts - Made version parameter optional in update-confluence-page with automatic version fetching

  • Added missing Confluence tools - Implemented get-confluence-page and search-confluence-pages with proper CQL support

  • Improved error handling - Better error messages and validation throughout

Technical Changes:

  • Rewrote ConfluenceFormatter.markdown_to_confluence() with line-by-line processing

  • Added regex-based markdown detection with multiple pattern matching

  • Enhanced _process_inline_formatting() helper for consistent formatting

  • Improved version conflict resolution in page updates

  • Added comprehensive logging for format detection and conversion

Version 0.1.9 (2025-07-26)

  • Initial PyPI release with basic Jira and Confluence functionality

  • Fixed basic EmbeddedResource structure issues

  • Added core tool implementations

Available Tools

13 tools
ask-confluence-pageB

Ask a question about a specific Confluence page content

ParametersJSON Schema
NameRequiredDescriptionDefault
page_idNoThe ID of the Confluence page
titleNoThe title of the Confluence page
space_keyNoThe key of the Confluence space
questionNoThe question to ask about the page content
context_typeNoType of context needed to answer the questionsummary

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are present, but the description does not disclose any behavioral traits such as read-only nature, authentication, or rate limits. It solely states the function.

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

Conciseness4/5

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

Single sentence, no fluff, but could benefit from a brief note on required parameter combinations.

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

Completeness2/5

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

With 5 parameters and no output schema, the description fails to explain return format, error conditions, or the effect of context_type choices.

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

Parameters3/5

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

Schema coverage is 100%, so description adds little extra meaning beyond the schema. It underscores 'question' and context_type' but doesn't explain how they interact.

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?

The description clearly states the verb 'ask a question' and resource 'specific Confluence page content', distinguishing it from siblings like search-confluence or get-confluence-page.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like get-confluence-page or search-confluence. Does not mention prerequisites or the need for either page_id or title+space_key.

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

comment-confluence-pageC

Add a comment to a Confluence page

ParametersJSON Schema
NameRequiredDescriptionDefault
page_idYes
commentYes

TDQS

C2.4/5.0
Behavior2/5

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

No annotations are provided, so the description must fully disclose behavioral traits. It only states 'Add a comment' without revealing whether it is idempotent, what permissions are needed, or what happens if the page does not exist.

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

Conciseness3/5

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

The description is a single short sentence, making it concise, but it lacks structure such as front-loading key information. It is minimally adequate but under-specified.

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

Completeness2/5

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

With no annotations, no output schema, and sparse parameter info, the description fails to provide a complete picture. The agent lacks context about side effects, return values, and constraints.

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

Parameters1/5

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

Schema description coverage is 0%, and the description does not explain the purpose or format of the parameters (page_id, comment). It adds no meaning beyond the schema, failing to guide the agent on how to construct valid inputs.

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

Purpose4/5

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

The description clearly states the action (add a comment) and the resource (Confluence page), distinguishing it from siblings like create-confluence-page or ask-confluence-page. However, it lacks nuance such as whether the comment is a top-level reply or any specific scope.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus siblings like update-confluence-page or comment-jira-issue. The description does not mention prerequisites, alternatives, or context for usage.

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

comment-jira-issueC

Add a comment to a Jira issue

ParametersJSON Schema
NameRequiredDescriptionDefault
issue_keyYes
commentYes

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden. It fails to disclose behavioral traits like idempotency, authentication needs, or error handling (e.g., what if issue not found).

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

Conciseness3/5

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

The description is a single concise sentence, but it is too brief; it could include more useful information without becoming verbose.

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

Completeness2/5

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

Given the tool's simplicity (2 params, no output schema), the description should at least note that it requires an existing issue or indicate the result (e.g., comment added). It lacks sufficient context.

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

Parameters2/5

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

The input schema has 0% description coverage; parameter names are self-explanatory ('issue_key', 'comment'), but the description adds no additional meaning (e.g., format, length constraints).

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?

The description 'Add a comment to a Jira issue' uses a specific verb ('Add') and resource ('comment to a Jira issue'), clearly distinguishing it from siblings like 'create-jira-issue' and 'comment-confluence-page'.

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs alternatives or prerequisites (e.g., issue must exist). The description only states what it does, not when or why.

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

create-confluence-pageC

Create a new Confluence page

ParametersJSON Schema
NameRequiredDescriptionDefault
space_keyYes
titleYes
contentYes
parent_idNo

TDQS

C2.3/5.0
Behavior2/5

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

With no annotations, the description carries full burden but only says 'Create a new Confluence page', not disclosing behavioral traits like side effects, authentication needs, or rate limits.

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

Conciseness2/5

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

Single sentence is concise but lacks necessary detail; under-specification outweighs brevity.

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

Completeness1/5

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

No output schema, no annotations, and no guidance on return values, error handling, or relationships to sibling tools. Incomplete for a tool with four parameters.

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

Parameters1/5

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

Schema description coverage is 0% and the description does not explain any parameter meanings or usage. Users must infer from parameter names alone.

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

Purpose4/5

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

Description clearly states it creates a Confluence page, distinguishing it from sibling tools like update-confluence-page and comment-confluence-page. However, it lacks specificity about the creation process.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. Does not mention prerequisites (e.g., needing a space key) or exclusions.

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

create-jira-issueC

Create a new Jira issue

ParametersJSON Schema
NameRequiredDescriptionDefault
project_keyYes
summaryYes
issue_typeYes
descriptionNo
assigneeNo

TDQS

C2.1/5.0
Behavior1/5

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

No annotations exist, so description is the sole source. It does not disclose behavioral traits like permission requirements, side effects, or response shape. The brevity provides no transparency beyond the basic action.

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

Conciseness2/5

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

The description is a single short sentence, but it is under-specified rather than concise. It fails to convey necessary details, so it does not earn its place as a complete description.

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

Completeness1/5

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

Given 5 parameters, no output schema, and no annotations, the description is severely incomplete. It leaves critical gaps about parameter meanings, return values, and usage context.

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

Parameters1/5

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

Schema description coverage is 0%, meaning no parameter descriptions in schema. The description does not add any meaning to parameters like project_key, summary, or issue_type, leaving the agent guessing their purpose.

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

Purpose4/5

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

Description 'Create a new Jira issue' clearly states verb and resource, avoiding tautology. However, it lacks specificity about the type of issue or project context, and does not distinguish from sibling tools like comment-jira-issue or transition-jira-issue.

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

Usage Guidelines2/5

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

No guidance provided on when to use this tool versus alternatives. No mention of prerequisites, required fields, or situations where another tool would be more appropriate.

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

get-confluence-pageA

Get a Confluence page by ID or title. Use this tool to retrieve a specific page's content, optionally including comments and version history.

ParametersJSON Schema
NameRequiredDescriptionDefault
page_idNoThe ID of the Confluence page
titleNoThe title of the Confluence page
space_keyNoThe key of the Confluence space
include_commentsNo
include_historyNo

TDQS

A3.9/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It indicates the tool is a read operation (Get), but does not disclose error behavior, permissions, or side effects. It is adequate but lacks depth.

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?

The description is two concise sentences, 24 words, front-loaded with the action, and contains no redundant information. It is efficient and well-structured.

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

Completeness3/5

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

For a simple retrieval tool with 5 parameters and no output schema, the description covers the core purpose and optional features but omits details about the return format and error handling, leaving some gaps.

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

Parameters4/5

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

The description adds meaning beyond the input schema by explaining the two identification methods (ID or title) and optional inclusion of comments and history. It effectively supplements the schema with a 60% coverage.

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?

The description clearly states the tool retrieves a Confluence page by ID or title, and distinguishes it from sibling tools like create, update, comment, or search. Its purpose is explicit and differentiated.

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?

The description advises using this tool to retrieve a specific page's content, implying when to use it, but does not explicitly mention when not to use it or alternative tools like search-confluence or ask-confluence-page.

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

get-jira-issueB

Get detailed information about a specific Jira issue by its key

ParametersJSON Schema
NameRequiredDescriptionDefault
issue_keyYesThe Jira issue key (e.g., PROJ-123)
include_commentsNoInclude comments in the response (default: false)

TDQS

B3.1/5.0
Behavior2/5

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

No annotations provided; description lacks details on what 'detailed information' includes, error handling, or side effects. Does not disclose behavioral traits beyond the basic action.

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

Conciseness4/5

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

Single sentence, front-loaded with key verb and resource. Efficient but could benefit from slightly more detail without losing conciseness.

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

Completeness2/5

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

Lacks output schema description, no mention of return structure or error behavior. Incomplete for a data retrieval tool compared to siblings like 'summarize-jira-issue'.

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

Parameters3/5

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

Schema coverage is 100%, so baseline is 3. Description adds no extra meaning beyond the schema; it merely restates the purpose without enriching parameter semantics.

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 the action (get), target (detailed information about a specific Jira issue), and method (by its key). It distinguishes from sibling tools like create/comment/transition.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives (e.g., search or summarize). Missing context about prerequisites or 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.

get-my-assigned-issuesA

Get issues assigned to the current user, ordered by priority (highest first) and creation date (newest first)

ParametersJSON Schema
NameRequiredDescriptionDefault
max_resultsNoMaximum number of issues to return (default: 25, max: 100)
include_doneNoInclude completed/closed issues (default: false)

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds ordering behavior (priority then creation date) which is useful, but does not mention that this is a read-only operation, authentication requirements, or pagination behavior beyond max_results.

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?

The description is a single sentence that is front-loaded with the core purpose and ordering details. Every word adds value, with no redundant or unnecessary information.

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

Completeness3/5

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

The description covers purpose and ordering, but lacks information about the return format or content of each issue (e.g., fields returned). Since there is no output schema, the description could have compensated by mentioning what keys/values are returned.

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

Parameters3/5

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

Input schema coverage is 100%, so the baseline is 3. The description does not add any information about the two parameters (max_results, include_done) that is not already in the schema.

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?

The description clearly states the tool retrieves issues assigned to the current user, with specific ordering by priority and creation date. This distinguishes it from sibling tools like get-jira-issue, which retrieves a single issue.

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?

The description implies usage when a user needs their assigned issues, but provides no explicit guidance on when not to use it or alternatives. Since sibling tools include search-confluence and get-jira-issue, the description could mention that this tool is for the current user's assignments only.

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

search-confluenceA

Search Confluence pages using CQL (Confluence Query Language). Simple queries are automatically enhanced with proper CQL syntax (e.g., 'API docs' becomes 'text ~ "API docs" OR title ~ "API docs"'). Advanced CQL is used as-is.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesSearch query. Can be simple text (automatically enhanced) or advanced CQL syntax.
space_keyNoLimit search to a specific space
max_resultsNoMaximum number of results to return

TDQS

A3.9/5.0
Behavior3/5

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

With no annotations, the description carries the burden. It discloses automatic CQL enhancement for simple queries, which is valuable. However, it does not mention authentication needs, rate limits, or behavior on invalid queries.

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?

Two sentences, front-loaded with purpose, no filler. Every sentence adds value.

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

Completeness3/5

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

Adequate for a search tool with 3 parameters, but lacks description of return format or how results are structured. Without an output schema, the description should cover this.

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

Parameters4/5

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

The description adds significant meaning beyond the schema for the 'query' parameter by explaining automatic CQL enhancement. The other parameters are well-documented in the schema. Schema coverage is 100%, so baseline is 3, but the enhancement detail raises it to 4.

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?

The description clearly states the tool's function: 'Search Confluence pages using CQL'. It differentiates from siblings by focusing on search with CQL, while others like get-confluence-page retrieve specific pages or ask-confluence-page likely answer questions based on a page.

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?

The description explains when to use simple text vs. advanced CQL queries, but does not provide guidance on selecting this tool over sibling tools like ask-confluence-page or get-confluence-page.

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

summarize-jira-issueB

Get a comprehensive summary of a Jira issue including comments, status history, and any Confluence page references

ParametersJSON Schema
NameRequiredDescriptionDefault
issue_keyYesThe Jira issue key (e.g., PROJ-123)

TDQS

B3.4/5.0
Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It does not state that the tool is read-only, nor mention permission requirements, rate limits, or performance implications.

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

Conciseness4/5

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

Single sentence that is front-loaded and efficient. No wasted words, though it could benefit from additional structure or clarifications.

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

Completeness3/5

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

For a simple tool with one parameter and no output schema, the description gives an adequate summary of what is returned, but lacks details on output format, error conditions, or limitations.

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

Parameters3/5

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

Schema coverage is 100% for the single parameter. The description repeats the parameter's purpose but adds no new semantic information beyond the schema's own description.

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?

The description clearly specifies the verb 'Get' and the resource 'comprehensive summary of a Jira issue', and differentiates from sibling tools like get-jira-issue by mentioning inclusion of comments, status history, and Confluence references.

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 vs alternatives like get-jira-issue. The description implies it provides a richer output but does not state trade-offs or exclusions.

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

transition-jira-issueC

Transition a Jira issue to a new status

ParametersJSON Schema
NameRequiredDescriptionDefault
issue_keyYes
transition_idYes

TDQS

C2.6/5.0
Behavior2/5

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

Description is minimal and does not disclose side effects, validation rules, idempotency, or error states. Since no annotations are provided, the description fails to compensate with behavioral details.

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

Conciseness3/5

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

The description is a single sentence, but it is too brief and lacks details. Conciseness is good, but structure is minimal and does not earn its place with useful information.

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

Completeness2/5

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

With no output schema and no annotations, the description should provide contextual completeness about return values, error handling, or prerequisite states. It does not, leaving the agent underinformed.

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

Parameters2/5

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

The description does not explain the parameters 'issue_key' and 'transition_id'. It mentions 'new status' but does not connect that to the transition_id parameter. Schema coverage is 0%, and the description adds no parameter meaning.

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

Purpose4/5

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

The description clearly states the action (transition) and resource (a Jira issue) but does not specify that the transition is identified by a transition ID, which is slightly ambiguous. It is distinct from sibling tools like create or comment.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like create-jira-issue or comment-jira-issue. No context about prerequisites or when transitions are applicable.

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

update-confluence-pageB

Update an existing Confluence page. If version is not provided, the current version will be automatically fetched to prevent conflicts.

ParametersJSON Schema
NameRequiredDescriptionDefault
page_idYes
titleYes
contentYes
versionNoVersion number of the page. If not provided, current version will be automatically fetched.

TDQS

B3/5.0
Behavior3/5

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

The description discloses automatic version fetching to prevent conflicts, which is a key behavioral trait. However, it does not mention permissions, return value, or whether updates are partial or full replacements.

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?

Two concise sentences, front-loaded with the main action. No redundant information.

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

Completeness2/5

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

The description covers version handling but omits return value, error conditions, idempotency, and content format. For a mutation tool with 4 parameters and no output schema, this is insufficient for autonomous agent use.

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

Parameters2/5

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

Only the 'version' parameter has additional context about auto-fetching. Other parameters (page_id, title, content) lack any description beyond their names, and the schema provides no descriptions for them. The agent gets no guidance on content format or expected values.

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

Purpose4/5

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

The description clearly states 'Update an existing Confluence page', using a specific verb and resource. It distinguishes from siblings like create-confluence-page, though it doesn't explicitly contrast with them.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives (e.g., create-confluence-page, comment-confluence-page). No prerequisites or exclusions are mentioned.

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. Dates show when Glama detected each change.

  1. 13 tool updatesv0.0.1
    • First observedask-confluence-page
    • First observedcomment-confluence-page
    • First observedcomment-jira-issue
    • First observedcreate-confluence-page
    • First observedcreate-jira-issue
    • First observedextract-confluence-links
    • First observedget-confluence-page
    • First observedget-jira-issue
    • First observedget-my-assigned-issues
    • First observedsearch-confluence
    • First observedsummarize-jira-issue
    • First observedtransition-jira-issue
    • First observedupdate-confluence-page
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.3/5.0
Disambiguation5/5

Each tool targets either Jira or Confluence with distinct actions, making them easily distinguishable. Even similar tools like get-jira-issue and summarize-jira-issue have clear differences in scope.

Naming Consistency5/5

All tools follow a consistent verb-noun pattern with hyphens, e.g., 'create-confluence-page' and 'transition-jira-issue', ensuring predictability.

Tool Count5/5

13 tools provide a balanced coverage for Jira and Confluence operations without being excessive. Each tool serves a clear purpose.

Completeness4/5

Covers core CRUD for Confluence pages and Jira issues, plus commenting, searching, transitions, and extra utilities. Missing delete operations and Jira issue field updates are minor gaps.

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • MCP Atlassian Server

    phuc-nt
    A
    license
    Not graded
    quality
    C
    maintenance
    A Model Context Protocol server that connects AI assistants like Cline to Atlassian Jira and Confluence, enabling them to query data and perform actions through a standardized interface.
    37
    53
    MIT

  • MCP Atlassian

    uchinx
    A
    license
    Not graded
    quality
    D
    maintenance
    Model Context Protocol server that integrates with Atlassian Confluence and Jira, enabling AI assistants to search, create, and update content in these platforms through natural language interactions.
    1
    MIT

  • MCP Atlassian

    saihiteesh
    -
    license
    Not graded
    quality
    Not graded
    maintenance
    A Model Context Protocol server that enables interaction with Atlassian products (Confluence and Jira), supporting both Cloud and Server/Data Center deployments for searching, creating, and managing content through natural language.
    -

Appeared in Searches

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/akhilthomas236/mcp-jira-confluence-sse'

If you have feedback or need assistance with the MCP directory API, please join our Discord server