Skip to main content
Glama
enesjakozh
zereight

confluence-mcp

by zereight
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Remote

Better Confluence Communication Server

Overview

This server implements the Model Context Protocol (MCP) for Confluence integration. This version addresses and fixes bugs found in the existing Confluence server, providing a more stable and reliable experience. It provides functionalities to execute CQL queries and retrieve page content from Confluence.

This server follows the MCP client-server architecture:

  • Acts as an MCP server providing Confluence functionalities

  • Connects to Confluence as a data source

  • Communicates with MCP clients through a standardized protocol

How to use

Related MCP server: mcp-jira

Using with Claude App, Cline, Roo Code

When using with the Claude App, you need to set up your API key and URLs directly.

{
  "mcpServers": {
    "Confluence communication server": {
      "command": "npx",
      "args": ["-y", "@zereight/mcp-confluence"],
      "env": {
        "CONFLUENCE_URL": "https://XXXXXXXX.atlassian.net",
        "JIRA_URL": "https://XXXXXXXX.atlassian.net",
        "CONFLUENCE_API_MAIL": "Your email",
        "CONFLUENCE_API_KEY": "KEY_FROM: https://id.atlassian.com/manage-profile/security/api-tokens",
        "CONFLUENCE_IS_CLOUD": "true" // Set to "false" for Server/Data Center
      }
    }
  }
}

Using with Cursor

Installing via Smithery

To install Confluence communication server for Claude Desktop automatically via Smithery:

npx -y @smithery/cli install @zereight/confluence-mcp --client claude

When using with Cursor, you can set up environment variables and run the server as follows:

env CONFLUENCE_API_MAIL=your@email.com CONFLUENCE_API_KEY=your-key CONFLUENCE_URL=your-confluence-url JIRA_URL=your-jira-url CONFLUENCE_IS_CLOUD=true npx -y @zereight/mcp-confluence

  • CONFLUENCE_API_MAIL: Your email address for the Confluence API.

  • CONFLUENCE_API_KEY: Your Confluence API key.

  • CONFLUENCE_URL: Your Confluence URL.

  • JIRA_URL: Your JIRA URL.

  • CONFLUENCE_IS_CLOUD: Determines Confluence version (Cloud or Server)

    • Default: true (Cloud version)

    • Set to 'false' explicitly for Server/Data Center version

    • Affects API endpoint paths:

      • Cloud: /wiki/rest/api

      • Server: /rest/api

Confluence Tools

  • execute_cql_search: Executes a CQL query on Confluence to search pages.

    • Description: Executes a CQL query on the Confluence instance to search for pages.

    • Input Schema:

      {
  "type": "object",
  "properties": {
    "cql": {
      "type": "string",
      "description": "CQL query string"
    },
    "limit": {
      "type": "integer",
      "description": "Number of results to return",
      "default": 10
    }
  },
  "required": ["cql"]
}

  • get_page_content: Retrieves the content of a specific Confluence page.

    • Description: Gets the content of a Confluence page using the page ID.

    • Input Schema:

      {
  "type": "object",
  "properties": {
    "pageId": {
      "type": "string",
      "description": "Confluence Page ID"
    }
  },
  "required": ["pageId"]
}

  • create_page: Creates a new Confluence page.

    • Description: Creates a new page in the specified Confluence space.

    • Input Schema:

      {
  "type": "object",
  "properties": {
    "spaceKey": {
      "type": "string",
      "description": "Space key where the page will be created"
    },
    "title": {
      "type": "string",
      "description": "Page title"
    },
    "content": {
      "type": "string",
      "description": "Page content in storage format"
    },
    "parentId": {
      "type": "string",
      "description": "Parent page ID (optional)"
    }
  },
  "required": ["spaceKey", "title", "content"]
}

  • update_page: Updates an existing Confluence page.

    • Description: Updates the content of an existing Confluence page.

    • Input Schema:

      {
  "type": "object",
  "properties": {
    "pageId": {
      "type": "string",
      "description": "ID of the page to update"
    },
    "content": {
      "type": "string",
      "description": "New page content in storage format"
    },
    "title": {
      "type": "string",
      "description": "New page title (optional)"
    }
  },
  "required": ["pageId", "content"]
}

Jira Tools

  • execute_jql_search: Executes a JQL query on Jira to search issues.

    • Description: Executes a JQL query on the Jira instance to search for issues.

    • Input Schema:

      {
  "type": "object",
  "properties": {
    "jql": {
      "type": "string",
      "description": "JQL query string"
    },
    "limit": {
      "type": "integer",
      "description": "Number of results to return",
      "default": 10
    }
  },
  "required": ["jql"]
}

  • create_jira_issue: Creates a new Jira issue.

    • Description: Creates a new issue in the specified Jira project.

    • Input Schema:

      {
  "type": "object",
  "properties": {
    "project": {
      "type": "string",
      "description": "Project key"
    },
    "summary": {
      "type": "string",
      "description": "Issue summary"
    },
    "description": {
      "type": "string",
      "description": "Issue description"
    },
    "issuetype": {
      "type": "string",
      "description": "Issue type name"
    },
    "assignee": {
      "type": "string",
      "description": "Assignee account ID"
    },
    "priority": {
      "type": "string",
      "description": "Priority ID"
    }
  },
  "required": ["project", "summary", "issuetype"]
}

  • update_jira_issue: Updates an existing Jira issue.

    • Description: Updates fields of an existing Jira issue.

    • Input Schema:

      {
  "type": "object",
  "properties": {
    "issueKey": {
      "type": "string",
      "description": "Issue key (e.g., PROJ-123)"
    },
    "summary": {
      "type": "string",
      "description": "New issue summary"
    },
    "description": {
      "type": "string",
      "description": "New issue description"
    },
    "assignee": {
      "type": "string",
      "description": "New assignee account ID"
    },
    "priority": {
      "type": "string",
      "description": "New priority ID"
    }
  },
  "required": ["issueKey"]
}

  • transition_jira_issue: Changes the status of a Jira issue.

    • Description: Changes the status of a Jira issue using transition ID.

    • Input Schema:

      {
  "type": "object",
  "properties": {
    "issueKey": {
      "type": "string",
      "description": "Issue key (e.g. PROJ-123)"
    },
    "transitionId": {
      "type": "string",
      "description": "Transition ID to change the issue status"
    }
  },
  "required": ["issueKey", "transitionId"]
}

  • get_board_sprints: Get all sprints from a Jira board.

    • Description: Retrieves all sprints from a specified Jira board.

    • Input Schema:

      {
  "type": "object",
  "properties": {
    "boardId": {
      "type": "string",
      "description": "Jira board ID"
    },
    "state": {
      "type": "string",
      "description": "Filter sprints by state (active, future, closed)",
      "enum": ["active", "future", "closed"]
    }
  },
  "required": ["boardId"]
}

  • get_sprint_issues: Get all issues from a sprint.

    • Description: Retrieves all issues from a specified sprint.

    • Input Schema:

      {
  "type": "object",
  "properties": {
    "sprintId": {
      "type": "string",
      "description": "Sprint ID"
    },
    "fields": {
      "type": "array",
      "items": {
        "type": "string"
      },
      "description": "List of fields to return for each issue"
    }
  },
  "required": ["sprintId"]
}

  • get_current_sprint: Get current active sprint from a board with its issues.

    • Description: Retrieves the current active sprint and its issues from a specified board.

    • Input Schema:

      {
  "type": "object",
  "properties": {
    "boardId": {
      "type": "string",
      "description": "Jira board ID"
    },
    "includeIssues": {
      "type": "boolean",
      "description": "Whether to include sprint issues in the response",
      "default": true
    }
  },
  "required": ["boardId"]
}

  • get_epic_issues: Get all issues belonging to an epic.

    • Description: Retrieves all issues that belong to a specified epic.

    • Input Schema:

      {
  "type": "object",
  "properties": {
    "epicKey": {
      "type": "string",
      "description": "Epic issue key (e.g. CONNECT-1234)"
    },
    "fields": {
      "type": "array",
      "items": {
        "type": "string"
      },
      "description": "List of fields to return for each issue"
    }
  },
  "required": ["epicKey"]
}

  • get_user_issues: Get all issues assigned to or reported by a specific user in a board.

    • Description: Retrieves all issues associated with a specific user in a board.

    • Input Schema:

      {
  "type": "object",
  "properties": {
    "boardId": {
      "type": "string",
      "description": "Jira board ID"
    },
    "username": {
      "type": "string",
      "description": "Username to search issues for"
    },
    "type": {
      "type": "string",
      "description": "Type of user association with issues",
      "enum": ["assignee", "reporter"],
      "default": "assignee"
    },
    "status": {
      "type": "string",
      "description": "Filter by issue status",
      "enum": ["open", "in_progress", "done", "all"],
      "default": "all"
    }
  },
  "required": ["boardId", "username"]
}

Available Tools

13 tools
create_jira_issueC

Create a new Jira issue

ParametersJSON Schema
NameRequiredDescriptionDefault
projectYesProject key
summaryYesIssue summary
assigneeNoAssignee account ID
priorityNoPriority ID
issuetypeYesIssue type name
descriptionNoIssue description

TDQS

C2.1/5.0
Behavior1/5

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

No annotations are provided, so the description must disclose behavioral traits. It does not mention permissions, side effects, rate limits, or error handling, leaving the agent with no useful behavioral information.

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 sentence that is under-specified. While concise, it does not earn its place as it adds no value over the tool name, failing to provide necessary context.

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?

Despite having 6 parameters and no output schema or annotations, the description provides no information about return values, error conditions, or prerequisites like Jira access. This is inadequate for a tool of this complexity.

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?

The schema provides 100% coverage with descriptions for all 6 parameters. The description adds no extra meaning beyond the schema, so baseline score of 3 is appropriate.

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

Purpose3/5

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

The description 'Create a new Jira issue' clearly states the action and resource, but it is essentially a restatement of the tool name without additional context or differentiation from sibling tools like update_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 is given on when to use this tool vs alternatives such as update_jira_issue. The description lacks context for appropriate usage scenarios.

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

create_pageB

Create a new Confluence page

ParametersJSON Schema
NameRequiredDescriptionDefault
titleYesPage title
contentYesPage content in storage format
parentIdNoParent page ID (optional)
spaceKeyYesSpace key where the page will be created

TDQS

B3.1/5.0
Behavior2/5

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

No annotations provided. The description only says 'create', lacking details on permissions, duplicate handling, or what the response contains. Fully behavioral burden falls on description, which is insufficient.

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?

The description is a single sentence, concise and to the point. While it could benefit from more detail, it is not verbose or unnecessary.

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 no output schema and 4 parameters, the description should at least mention return values (e.g., page ID) or constraints. It is incomplete for effective usage.

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 description coverage is 100% (all 4 parameters described). The description adds no additional meaning beyond what the schema already provides, so baseline score of 3 is appropriate.

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 'Create a new Confluence page' clearly states the action (create) and resource (Confluence page), and distinguishes it from sibling tools like update_page or get_page_content.

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 update_page or get_page_content. Missing context on prerequisites or typical scenarios.

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

get_board_sprintsB

Get all sprints from a Jira board

ParametersJSON Schema
NameRequiredDescriptionDefault
stateNoFilter sprints by state (active, future, closed)
boardIdYesJira board ID

TDQS

B3.4/5.0
Behavior3/5

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

No annotations are provided, so the description bears full burden. It correctly implies a read-only operation via 'Get', but does not disclose potential pagination, rate limits, or whether 'all' sprints implies any constraints. The behavior is straightforward but lacks explicit safety or scope details.

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?

The description is a single clear sentence with no wasted words. It is concise, though could slightly benefit from mentioning the optional state filter.

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?

With two parameters, no output schema, and moderate complexity, the description is adequate but incomplete. It does not mention the return format, ordering, or if results are paginated, leaving gaps for an AI agent.

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% with both parameters described. The description adds no extra meaning beyond the schema definitions, meeting the baseline for full 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 'Get all sprints from a Jira board' uses a specific verb and resource, clearly stating the tool's function. It distinguishes itself from sibling tools like 'get_current_sprint' and 'get_sprint_issues'.

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?

The description provides no guidance on when to use this tool versus alternatives such as 'get_current_sprint' or 'get_sprint_issues'. It lacks any 'when-to-use' or 'when-not-to-use' context.

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

get_current_sprintA

Get current active sprint from a board with its issues

ParametersJSON Schema
NameRequiredDescriptionDefault
boardIdYesJira board ID
includeIssuesNoWhether to include sprint issues in the response

TDQS

A3.7/5.0
Behavior3/5

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

No annotations, so description carries full burden. It identifies the tool as a read operation ('Get') but does not disclose specifics like permissions, side effects, or response structure. Adequate for a simple read, but minimal.

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 with no wasted words. Could be slightly improved by structuring key operations upfront, but very concise.

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?

For a simple tool with 2 parameters and no output schema, the description is sufficient. It covers core functionality. Missing details like return format, but not critical given tool simplicity.

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 does not add meaning beyond the schema; 'with its issues' hints at includeIssues but is not explicit.

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 action ('Get current active sprint') and resource ('from a board with its issues'). Distinguishes from sibling tools like get_board_sprints (lists all sprints) and get_sprint_issues (issues for a specific sprint).

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?

Implies usage for retrieving the currently active sprint but provides no explicit when-to-use or when-not-to-use guidance. Does not mention alternatives among siblings.

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

get_epic_issuesB

Get all issues belonging to an epic

ParametersJSON Schema
NameRequiredDescriptionDefault
fieldsNoList of fields to return for each issue
epicKeyYesEpic issue key (e.g. CONNECT-1234)

TDQS

B3.4/5.0
Behavior2/5

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

No annotations are provided, and the description only states the basic operation without disclosing behavioral traits like idempotency, error handling, or whether it returns all issues at once or paginated.

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?

The description is a single, clear sentence with no wasted words, but could be slightly more informative without sacrificing conciseness.

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 two parameters and no output schema, the description is minimally viable but lacks context on pagination, required permissions, or the format of the returned issues.

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%, and the description does not add any semantics beyond the schema itself. The description mentions 'all issues' but does not elaborate on the 'fields' parameter or how to control output.

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 'Get' and the resource 'all issues belonging to an epic', which is specific and distinguishable from sibling tools that deal with sprints, users, or pages.

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 needing issues for a given epic, but provides no explicit guidance on when to use this tool over alternatives, such as get_sprint_issues or get_user_issues.

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

get_page_contentB

Get the content of a Confluence page

ParametersJSON Schema
NameRequiredDescriptionDefault
pageIdYesConfluence Page ID

TDQS

B3/5.0
Behavior2/5

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

No annotations exist, so the description must carry the burden of behavioral disclosure. It only says 'Get the content', failing to mention read-only nature, permissions, or return format.

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 omits important context, making it underinformative despite its brevity.

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 lack of output schema, the description should clarify what 'content' entails (e.g., body, metadata, attachments) and whether it is read-only, but it provides no such details.

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%, and the description adds no additional meaning beyond the schema's 'Confluence Page ID' for the pageId parameter, meeting the baseline but not exceeding it.

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 'Get' and the resource 'the content of a Confluence page', distinguishing it from sibling tools that operate on Jira issues or create/update pages.

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?

The description provides no guidance on when to use this tool versus alternatives like create_page or update_page, nor does it mention any prerequisites or context.

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

get_sprint_issuesC

Get all issues from a sprint

ParametersJSON Schema
NameRequiredDescriptionDefault
fieldsNoList of fields to return for each issue
sprintIdYesSprint ID

TDQS

C2.6/5.0
Behavior1/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 fails to mention whether it returns only active issues, includes subtasks, or requires authentication. This is a critical gap for a tool that modifies no state but should clarify scope.

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 very brief (one sentence), which is concise but lacks necessary detail. It is front-loaded but too minimal to be fully informative. Conciseness is good, but it does not earn its place with comprehensive value.

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 tool has no output schema, so the description should explain what the tool returns (e.g., a list of issue objects) but does not. It is incomplete for a developer trying to integrate the tool without additional documentation.

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 description coverage is 100% (both parameters have descriptions). The description adds no extra meaning beyond what the schema already provides, so baseline score of 3 is appropriate.

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?

Clear verb+resource 'Get all issues from a sprint'. It conveys the core function but does not explicitly distinguish from sibling tools like get_epic_issues or execute_jql_search, which could also retrieve sprint issues. A 5 would require explicit differentiation.

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 such as execute_jql_search or get_board_sprints. The description provides no context about prerequisites (e.g., needing a sprint ID) or scenarios where another tool is more appropriate.

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

get_user_issuesB

Get all issues assigned to or reported by a specific user in a board

ParametersJSON Schema
NameRequiredDescriptionDefault
typeNoType of user association with issuesassignee
statusNoFilter by issue statusall
boardIdYesJira board ID
usernameYesUsername to search issues for

TDQS

B3.3/5.0
Behavior2/5

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

No annotations provided. Description only says 'get all issues' without disclosing potential limits, pagination, or read-only guarantee. Lacks behavioral context beyond the obvious get operation.

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 with no fluff. Efficient but could benefit from more structure or additional context.

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?

Tool has 4 parameters, no output schema, no annotations. Description omits return format, pagination, or limitations. Incomplete for an agent to reliably use.

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 description coverage is 100%, so description adds no additional meaning over the schema. Baseline 3 is appropriate.

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 verb 'Get', resource 'issues', and scope 'assigned to or reported by a specific user in a board'. Distinguishes from sibling tools like get_epic_issues or get_sprint_issues.

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?

Description implies usage for user-specific issues but does not explicitly state when to use versus alternatives like execute_jql_search. No exclusions or when-not-to-use guidance provided.

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

transition_jira_issueB

Change the status of a Jira issue

ParametersJSON Schema
NameRequiredDescriptionDefault
issueKeyYesIssue key (e.g. PROJ-123)
transitionIdYesTransition ID to change the issue status

TDQS

B3.2/5.0
Behavior2/5

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

With no annotations and a minimal description, the agent lacks information on side effects, idempotency, permissions, or return values. The description does not go 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?

The description is a single, concise sentence that conveys the core purpose. It is front-loaded with the action, though it could be slightly more structured with additional context.

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?

Given the simplicity (2 required params, no output schema), the description is adequate but minimal. It does not explain how to discover valid transition IDs or what happens upon success/failure, which could be helpful.

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 description coverage is 100% and both parameters have clear descriptions (issueKey format, transitionId purpose). The tool description adds no extra semantic value beyond what the schema already provides.

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 'Change the status of a Jira issue' clearly states the specific action (transition) and resource (Jira issue). It differentiates from sibling tools like 'create_jira_issue' (creation) and 'update_jira_issue' (field edits) by focusing solely on status changes.

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 is provided on when to use this tool versus alternatives (e.g., 'update_jira_issue' for other fields). There is no mention of prerequisites or context for status transitions.

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

update_jira_issueB

Update an existing Jira issue

ParametersJSON Schema
NameRequiredDescriptionDefault
summaryNoNew issue summary
assigneeNoNew assignee account ID
issueKeyYesIssue key (e.g. PROJ-123)
priorityNoNew priority ID
descriptionNoNew issue description

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 behavioral details such as partial update behavior, error handling, or side effects. Only states 'Update an existing Jira issue'.

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 with no waste. Could benefit from slightly more detail, but maintains 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?

No output schema, no annotations, and 5 parameters. Description does not explain return values or behavior when only partial fields provided. Incomplete for effective use.

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 covers 100% of parameters with descriptions. Description adds no extra value beyond schema, so baseline of 3 applies.

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 'Update' and resource 'existing Jira issue', distinguishing it from siblings like create_jira_issue (create) and transition_jira_issue (status change).

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 (e.g., transition_jira_issue). No mention of prerequisites or exclusions.

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

update_pageB

Update an existing Confluence page

ParametersJSON Schema
NameRequiredDescriptionDefault
titleNoNew page title (optional)
pageIdYesID of the page to update
contentYesNew page content in storage format

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations provided, the description fails to disclose behavioral traits such as whether the update replaces or merges content, required permissions, or side effects. It only states 'update', which is insufficient for a mutation tool.

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?

The description is a single concise sentence with no wasted words. However, it could be more informative without sacrificing 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?

The description does not explain the return value or behavior (e.g., whether content is replaced or merged). Given the lack of output schema and annotations, it is incomplete for a mutation tool.

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%, with clear descriptions for all parameters. The tool description does not add extra meaning beyond the schema, so baseline 3 is appropriate.

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 'Update' and the resource 'existing Confluence page', distinguishing it from sibling tools like 'create_page' and 'get_page_content'.

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_page' or 'get_page_content'. The description lacks context for appropriate usage.

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 updatesv1.0.1
    • First observedcreate_jira_issue
    • First observedcreate_page
    • First observedexecute_cql_search
    • First observedexecute_jql_search
    • First observedget_board_sprints
    • First observedget_current_sprint
    • First observedget_epic_issues
    • First observedget_page_content
    • First observedget_sprint_issues
    • First observedget_user_issues
    • First observedtransition_jira_issue
    • First observedupdate_jira_issue
    • First observedupdate_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 a distinct operation and domain, with clear separation between Confluence page management and Jira issue tracking. No two tools appear to do the same thing.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case, with verbs like create, get, update, execute, and transition appropriately paired with nouns like page, jira_issue, cql_search, etc.

Tool Count5/5

With 13 tools covering both Confluence and Jira operations, the count is well-scoped and balanced—each tool serves a distinct purpose without being overwhelming or insufficient.

Completeness4/5

The tool set covers essential CRUD operations for both Confluence pages and Jira issues, along with context-specific searches. Missing delete operations and some Jira board management are minor gaps, but core workflows are supported.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • MCP Jira Server

    edrich13
    A
    license
    A
    quality
    C
    maintenance
    An MCP server for interacting with self-hosted Jira instances using Personal Access Token (PAT) authentication. It enables users to perform CRUD operations on issues, search with JQL, manage comments, and list projects through the Jira REST API.
    12
    489
    11
    MIT

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/zereight/confluence-mcp'

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