Skip to main content
Glama
deenesjakoruzh
gkrauchunas-arlo

Confluence MCP Server

by gkrauchunas-arlo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Confluence MCP Server

Сервер Model Context Protocol (MCP) для интеграции Atlassian Confluence с Claude Code.

Возможности

  • 🔍 Поиск по страницам Confluence с использованием CQL (Confluence Query Language)

  • 📄 Чтение страниц по ID или заголовку

  • ✏️ Создание и обновление страниц

  • 🏷️ Управление метками и метаданными

  • 📁 Список пространств и вложений

  • 🔐 Безопасная базовая аутентификация с помощью API-токенов

Related MCP server: mcp-confluence

Установка

Предварительные требования

  • Node.js 18+ и npm

  • Учетная запись Atlassian Confluence Cloud

  • API-токен (см. раздел «Конфигурация» ниже)

Настройка

git clone https://github.com/gkrauchunas-arlo/confluence-mcp.git
cd confluence-mcp
npm install

Конфигурация

  1. Скопируйте .env.example в .env:

    cp .env.example .env

  2. Введите свои учетные данные Atlassian в .env:

    ATLASSIAN_SITE=your-domain.atlassian.net
ATLASSIAN_EMAIL=your-email@example.com
ATLASSIAN_API_TOKEN=your-token

Получение API-токена:

  1. Перейдите на https://id.atlassian.com/manage-profile/security/api-tokens

  2. Нажмите "Create API token"

  3. Дайте ему имя (например, "Claude Code MCP") и скопируйте токен в .env

Тестирование

# Test Confluence API connectivity
node test-confluence.js

# Test MCP protocol (via stdio)
echo '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"0.1.0","capabilities":{},"clientInfo":{"name":"test","version":"1.0.0"}}}' | node index.js

Подключение к Claude Code

Вариант 1: CLI (рекомендуется)

claude mcp add --transport stdio confluence \
  --env ATLASSIAN_SITE="your-domain.atlassian.net" \
  --env ATLASSIAN_EMAIL="your-email@example.com" \
  --env ATLASSIAN_API_TOKEN="your-token" \
  -- node /absolute/path/to/confluence-mcp/index.js

Замените /absolute/path/to/ на ваш фактический путь установки (например, /home/username/confluence-mcp).

Вариант 2: Файл конфигурации

Добавьте в файл конфигурации MCP для Claude Code:

{
  "mcpServers": {
    "confluence": {
      "command": "node",
      "args": ["/absolute/path/to/confluence-mcp/index.js"],
      "env": {
        "ATLASSIAN_SITE": "your-domain.atlassian.net",
        "ATLASSIAN_EMAIL": "your-email@example.com",
        "ATLASSIAN_API_TOKEN": "your-token"
      }
    }
  }
}

Расположение файлов конфигурации:

  • Linux: ~/.config/claude-code/mcp_servers.json или ~/.claude/config/mcp_servers.json

  • macOS: ~/Library/Application Support/claude-code/mcp_servers.json

  • Windows: %APPDATA%\claude-code\mcp_servers.json

После настройки перезапустите Claude Code, чтобы активировать MCP-сервер.

Доступные инструменты

Поиск и навигация

  • confluence_search - Поиск CQL по всему контенту

    • Параметры: query (строка), limit (число, необязательно), spaceKey (строка, необязательно)

    • Пример: Поиск страниц с "API" в заголовке внутри определенного пространства

  • confluence_list_spaces - Список всех пространств

    • Параметры: limit (число, необязательно, по умолчанию: 25)

    • Возвращает: Список всех пространств Confluence, доступных вашей учетной записи

Чтение контента

  • confluence_get_page - Получение страницы по ID

    • Параметры: pageId (строка)

    • Возвращает: Полные данные страницы, включая контент, версию и метаданные

  • confluence_get_page_by_title - Поиск страницы по заголовку и пространству

    • Параметры: title (строка), spaceKey (строка)

    • Возвращает: Страницу, соответствующую точному заголовку в указанном пространстве

  • confluence_get_space - Получение информации о пространстве

    • Параметры: spaceKey (строка)

    • Возвращает: Метаданные и конфигурацию пространства

  • confluence_get_attachments - Список вложений страницы

    • Параметры: pageId (строка)

    • Возвращает: Список всех вложений на странице

Создание и редактирование

  • confluence_create_page - Создание новой страницы

    • Параметры: title (строка), spaceKey (строка), content (HTML-строка), parentId (строка, необязательно)

    • Создает новую страницу в указанном пространстве, опционально как дочернюю для другой страницы

  • confluence_update_page - Обновление существующей страницы

    • Параметры: pageId (строка), title (строка), content (HTML-строка), version (число)

    • Обновляет страницу новым контентом. Номер версии должен совпадать с текущей версией страницы.

Метаданные

  • confluence_add_labels - Добавление меток к странице

    • Параметры: pageId (строка), labels (массив строк)

    • Добавляет одну или несколько меток/тегов к странице для классификации

Примеры использования

После подключения к Claude Code вы можете использовать естественный язык для взаимодействия с Confluence:

Поиск страниц

Find all pages about "API documentation" in Confluence

Чтение страницы

Read the contents of Confluence page with ID 12345

Создание новой страницы

Create a new page in the DEV space titled "API Guidelines" with this content:
<h1>API Guidelines</h1>
<p>This document describes our API design principles.</p>

Обновление страницы

Update Confluence page 12345 to add a new section about authentication

Добавление меток

Add labels "documentation" and "api" to Confluence page 12345

Примеры CQL-запросов

Инструмент confluence_search поддерживает Confluence Query Language (CQL):

type=page AND title~"API"
type=page AND space=DEV
type=page ORDER BY lastmodified DESC
type=page AND label=documentation
type=page AND creator=currentUser()

Справочник API

Этот MCP-сервер использует Confluence REST API:

  • Базовый URL: https://{site}.atlassian.net/wiki/rest/api

  • Аутентификация: Basic Auth с email + API-токен

  • Версия API: Cloud REST API (стабильная)

  • Полная документация API

Устранение неполадок

"Authentication failed"

  • Проверьте ваш email и API-токен в .env

  • Убедитесь, что токен не истек (API-токены не имеют срока действия, но могут быть отозваны)

  • Убедитесь, что вы используете API-токен, а не пароль от учетной записи Atlassian

"MCP tools not showing up"

  • Полностью перезапустите Claude Code (закройте и откройте снова)

  • Проверьте логи сервера на наличие ошибок, запустив node index.js напрямую

  • Проверьте конфигурацию с помощью claude mcp list

  • Убедитесь, что в конфигурации используется полный абсолютный путь

Ошибки "Permission denied"

  • Убедитесь, что ваша учетная запись Atlassian имеет доступ к запрашиваемым пространствам/страницам

  • Некоторые операции требуют специальных разрешений (например, права администратора пространства для создания страниц)

  • Проверьте разрешения пространства в веб-интерфейсе Confluence

"Page version conflict"

  • При обновлении страницы необходимо указать текущий номер версии

  • Сначала получите текущую версию с помощью confluence_get_page

  • Сервер автоматически увеличит версию на 1

Формат контента

Страницы Confluence используют Storage Format (HTML с макросами Confluence). Для простых страниц подходит стандартный HTML:

<h1>Heading</h1>
<p>Paragraph with <strong>bold</strong> and <em>italic</em> text.</p>
<ul>
  <li>Bullet point 1</li>
  <li>Bullet point 2</li>
</ul>
<pre><code>Code block</code></pre>

Для расширенных функций см. документацию по формату хранения Confluence.

Архитектура

Построено на:

Сервер работает как stdio-based MCP-сервер, взаимодействуя с Claude Code через JSON-RPC 2.0 по стандартному вводу/выводу.

Разработка

Структура проекта

confluence-mcp/
├── index.js              # Main MCP server implementation
├── package.json          # Dependencies and scripts
├── test-confluence.js    # Confluence API connectivity tests
├── test-mcp.js           # MCP protocol tests (WIP)
├── .env.example          # Example configuration
├── .env                  # Your configuration (gitignored)
└── README.md             # This file

Запуск тестов

# Test Confluence API directly
node test-confluence.js

# Test MCP server via stdio
echo '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"0.1.0","capabilities":{},"clientInfo":{"name":"test","version":"1.0.0"}}}' | node index.js

Вклад в проект

Вклады приветствуются! Пожалуйста:

  1. Сделайте форк репозитория

  2. Создайте ветку для функции (git checkout -b feature/amazing-feature)

  3. Внесите изменения с тестами

  4. Закоммитьте изменения (git commit -m 'feat: add amazing feature')

  5. Отправьте изменения в ветку (git push origin feature/amazing-feature)

  6. Откройте Pull Request

Известные ограничения

  1. Загрузка вложений - еще не реализована (требует кодирования multipart/form-data)

  2. Форматирование текста - поддерживается только базовый HTML, макросы Confluence могут быть сложными

  3. Пагинация - большие наборы результатов ограничены параметром limit

  4. Разрешения - API возвращает только контент, доступный аутентифицированному пользователю

Лицензия

ISC

Благодарности

Поддержка

Создано: gkrauchunas-arlo Статус: Стабильная версия v1.0.0 - Все основные функции реализованы и протестированы

Available Tools

9 tools
confluence_add_labelsB

Add labels (tags) to a Confluence page

NameRequiredDescriptionDefault
pageIdYesThe ID of the page
labelsYesArray of label names to add

TDQS

B3.2/5.0
Behavior2/5

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

No annotations provided, so description must disclose behavior. Only states 'add labels' without clarifying whether labels are appended or replaced, or any side effects.

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 is concise, but lacks structure and front-loading of critical details.

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?

Simple tool with two straightforward parameters. Missing details on return value or success indication, but adequate for basic understanding.

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 basic descriptions. Tool description adds no additional meaning beyond schema, so baseline 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?

Clear verb ('Add labels') and resource ('Confluence page'), distinct from sibling tools which focus on page creation, retrieval, and search.

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, limitations, 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.

confluence_create_pageB

Create a new Confluence page in a specific space

NameRequiredDescriptionDefault
titleYesThe title of the new page
spaceKeyYesThe key of the space where the page will be created
contentYesThe page content in Confluence storage format (HTML)
parentIdNoOptional ID of the parent page (creates a child page)

TDQS

B3.1/5.0
Behavior2/5

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

No annotations provided, so the description must carry the burden. It only says 'Create', implying mutation, but does not disclose permissions, side effects, or return values.

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?

Very concise, one sentence with clear purpose. Front-loaded but could be slightly more descriptive 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?

No output schema, but description does not explain what the tool returns (e.g., page ID). Missing context about behavior after creation.

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 3. The description adds no extra meaning beyond what the schema already provides for parameters.

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 'Create', the resource 'a new Confluence page', and the scope 'in a specific space', which distinguishes it from siblings like update_page or get_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 or when not to use this tool. Does not mention alternatives or prerequisites, such as needing an existing space or parent page.

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

confluence_get_attachmentsB

Get list of attachments for a Confluence page

NameRequiredDescriptionDefault
pageIdYesThe ID of the page

TDQS

B3.1/5.0
Behavior2/5

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

No annotations provided; description is minimal and does not disclose behavioral traits like pagination, limits, or authentication requirements.

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, but could include more detail without harming 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; description does not explain return value structure or pagination, leaving gaps for a list operation.

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 pageId described; tool description adds no extra meaning beyond the schema, meeting baseline.

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

Purpose5/5

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

Description clearly states verb 'Get list' and resource 'attachments for a Confluence page', distinguishing it from siblings like confluence_add_labels or confluence_create_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; lacks context about prerequisites or constraints.

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

confluence_get_pageA

Get a Confluence page by ID including its content, version, and metadata

NameRequiredDescriptionDefault
pageIdYesThe ID of the page to retrieve

TDQS

A3.6/5.0
Behavior2/5

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

No annotations provided, so description carries full burden. It indicates a read operation but omits behavioral details such as required permissions, whether the operation is destructive, rate limits, or error handling.

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?

Single sentence that is concise and front-loaded with the key action and resource. No extraneous information.

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

Completeness4/5

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

Given no output schema, description usefully lists returned fields (content, version, metadata). However, it lacks details on response structure, potential errors, or pagination behavior. For a simple get by ID, it is mostly adequate but could be more comprehensive.

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% for the single parameter 'pageId', which already has a clear description. The tool description adds no additional semantic value beyond what is 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?

Description clearly states verb 'get', resource 'Confluence page by ID', and lists returned fields 'content, version, and metadata'. Distinguishes from sibling 'confluence_get_page_by_title' which retrieves by title.

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 use when page ID is known, but does not explicitly state when to use this tool over alternatives like 'confluence_get_page_by_title' or provide context on prerequisites or exclusions.

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

confluence_get_page_by_titleB

Find a Confluence page by its title and space key

NameRequiredDescriptionDefault
titleYesThe exact title of the page
spaceKeyYesThe key of the space containing the page

TDQS

B3.2/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 full burden. It only says 'find', but does not disclose behavior on missing pages, return format (content vs metadata), or side effects. Highly insufficient for a retrieval tool.

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?

Single short sentence with no unnecessary words. Efficiently conveys the core purpose.

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 no output schema and 2 required params. Description does not specify what is returned (e.g., page content, metadata) or behavior on not found. Missing critical return value information 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 descriptions already cover both parameters (title and spaceKey) with clear explanations. Description adds no extra meaning, but schema coverage is 100%, 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 action (find), resource (Confluence page), and identifiers (title and space key). It distinguishes from siblings like 'confluence_get_page' which likely uses page ID, and 'confluence_search' which is broader.

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 'confluence_get_page' (by ID) or 'confluence_search'. No explicit context or exclusion criteria provided.

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

confluence_get_spaceB

Get information about a specific Confluence space

NameRequiredDescriptionDefault
spaceKeyYesThe key of the space to retrieve

TDQS

B3.3/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden but only says 'Get information', failing to disclose behavioral traits like return format, authentication requirements, rate limits, or potential errors.

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 that efficiently states the purpose. It is not verbose, but could include more detail without being wasteful.

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 and no annotations, yet the description provides no hint about return values, pagination, or related data. This under-specifies the behavior for an 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?

Input schema has 100% coverage for the single parameter 'spaceKey' with a description. The tool description adds no 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 'Get information about a specific Confluence space', which uses a specific verb and resource, and distinguishes from sibling tools like 'list_spaces' (list vs. get specific) and 'get_page' (different resource).

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?

Usage is implied: use when needing info on a specific space. There is no explicit guidance on when to use this vs. alternatives (e.g., 'list_spaces' for all spaces) or prerequisites, which leaves some ambiguity.

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

confluence_list_spacesA

List all Confluence spaces accessible to the user

NameRequiredDescriptionDefault
limitNoMaximum number of spaces to return (default: 25)

TDQS

A3.6/5.0
Behavior3/5

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

No annotations exist, so description carries full burden. It mentions 'accessible to the user' implying personalization, but lacks details on pagination, rate limits, or edge cases.

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?

Single sentence, front-loaded, no redundant words. Perfectly concise for the tool's simplicity.

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 list tool with one optional parameter and no output schema, the description is adequate. Could mention pagination or return format but not necessary.

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 limit parameter already described. Description adds no extra meaning beyond 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 action (list) and resource (spaces), and distinguishes from sibling tools like get_space (specific) and search (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 vs alternatives. No mention of when not to use or prerequisites.

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

confluence_update_pageC

Update an existing Confluence page

NameRequiredDescriptionDefault
pageIdYesThe ID of the page to update
titleYesThe new title for the page
contentYesThe new content in Confluence storage format (HTML)
versionYesCurrent version number of the page (will be incremented)

TDQS

C2.8/5.0
Behavior2/5

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

With no annotations, the description should detail behavioral traits like destructive overwrite, version incrementing, and content format. It only says 'update', omitting key details that are only in the schema (e.g., version requirement, storage 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?

Single sentence is concise, but lacks structure. It does not front-load critical information like required parameters or behavioral notes, making it minimally adequate.

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 four required parameters and no output schema, the description fails to explain versioning implications, content format, or error handling. It is incomplete for an AI agent to use correctly without additional context.

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 baseline is 3. The description adds no extra meaning beyond what the schema already provides, so it neither improves nor harms parameter understanding.

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 uses specific verb 'update' and resource 'existing Confluence page', clearly distinguishing from sibling tools like create_page, get_page, etc. However, it does not specify which fields can be updated, which is partially covered by schema.

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, no prerequisites mentioned, and no context about required version handling or page existence. The description solely states the action without any decision-making support.

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

Tool Schema Changelog

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

  1. 9 tool updatesv1.0.0
    • First observedconfluence_add_labels
    • First observedconfluence_create_page
    • First observedconfluence_get_attachments
    • First observedconfluence_get_page
    • First observedconfluence_get_page_by_title
    • First observedconfluence_get_space
    • First observedconfluence_list_spaces
    • First observedconfluence_search
    • First observedconfluence_update_page
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.6/5.0

Scored across 9 tools

Disambiguation5/5

Each tool targets a distinct resource or action. There is no overlap between getting a page by ID vs title, or between getting a space and listing spaces. All tools have clearly separate purposes.

Naming Consistency5/5

All tool names follow a consistent 'confluence_verb_noun' pattern, using snake_case. Verbs like add, create, get, list, search, and update are applied uniformly, making the set predictable.

Tool Count5/5

With 9 tools, the set is well-scoped for a Confluence MCP server. It covers essential CRUD operations for pages, spaces, attachments, labels, and search without being overly large or sparse.

Completeness4/5

Core workflows are covered: page create/read/update, space retrieval, search, and attachments. Minor gaps like delete operations and label management are absent, but the surface is sufficient for typical use.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers