de en es ja ko ru zh

Atlassian Confluence MCP Server

Name: Atlassian Confluence MCP Server
Author: aashari

by aashari

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

アトラシアン Confluence MCP サーバー

Atlassian Confluence Cloud 用の Node.js/TypeScript Model Context Protocol (MCP) サーバー。AI システム（Claude や Cursor AI などの LLM など）が Confluence のスペース、ページ、コンテンツと安全にリアルタイムでやり取りできるようにします。

NPMバージョンビルドステータス

このサーバーを使用する理由

最小限の入力、最大限の出力: シンプルな識別子により、追加のフラグを必要とせずに包括的な詳細が提供されます。
完全なナレッジベースアクセス: AI アシスタントにドキュメント、Wiki、ナレッジベースコンテンツの可視性を提供します。
リッチコンテンツのフォーマット: Atlassian ドキュメント形式を読み取り可能な Markdown に自動変換します。
安全なローカル認証: 資格情報を使用してローカルで実行し、トークンをリモートサーバーに保存することはありません。
直感的な Markdown 応答: すべての出力に対して、適切に構造化された一貫した Markdown 形式が採用されています。

Related MCP server: MCP Atlassian Server

MCPとは何ですか?

モデルコンテキストプロトコル（MCP）は、AIシステムを外部ツールやデータソースに安全に接続するためのオープンスタンダードです。このサーバーはConfluence Cloud向けにMCPを実装しており、AIアシスタントがConfluenceコンテンツをプログラム的に操作できるようにします。

前提条件

Node.js (>=18.x):ダウンロード
Confluence Cloud にアクセスできるAtlassian アカウント

設定

ステップ1: Atlassian APIトークンを取得する

Atlassian API トークン管理ページに移動します: https://id.atlassian.com/manage-profile/security/api-tokens
「API トークンの作成」をクリックします。
説明的なラベル(例: mcp-confluence-access ) を付けます。
[作成]をクリックします。
生成されたAPIトークンはすぐにコピーしてください。再度表示することはできません。

ステップ2: 資格情報を構成する

オプション A: MCP 構成ファイル (推奨)

~/.mcp/configs.jsonを編集または作成します。

{
	"confluence": {
		"environments": {
			"ATLASSIAN_SITE_NAME": "<YOUR_SITE_NAME>",
			"ATLASSIAN_USER_EMAIL": "<YOUR_ATLASSIAN_EMAIL>",
			"ATLASSIAN_API_TOKEN": "<YOUR_COPIED_API_TOKEN>"
		}
	}
}

<YOUR_SITE_NAME> : Confluence サイト名 (例: mycompany.atlassian.netの場合はmycompany )。
<YOUR_ATLASSIAN_EMAIL> : Atlassian アカウントのメールアドレス。
<YOUR_COPIED_API_TOKEN> : ステップ 1 の API トークン。

オプションB: 環境変数

export ATLASSIAN_SITE_NAME="<YOUR_SITE_NAME>"
export ATLASSIAN_USER_EMAIL="<YOUR_EMAIL>"
export ATLASSIAN_API_TOKEN="<YOUR_API_TOKEN>"

ステップ3: インストールと実行

`npx`のクイックスタート

npx -y @aashari/mcp-server-atlassian-confluence ls-spaces

グローバルインストール

npm install -g @aashari/mcp-server-atlassian-confluence
mcp-atlassian-confluence ls-spaces

ステップ4：AIアシスタントに接続する

MCP 互換クライアント (例: Claude、Cursor AI) を構成します。

{
	"mcpServers": {
		"confluence": {
			"command": "npx",
			"args": ["-y", "@aashari/mcp-server-atlassian-confluence"]
		}
	}
}

MCPツール

MCP ツールは、 snake_case名、 camelCaseパラメータを使用し、Markdown 形式の応答を返します。

conf_ls_spaces : アクセス可能な Confluence スペースを一覧表示します ( type : str opt、 status : str opt、 limit : num opt、 cursor : str opt)。使用方法: 利用可能なスペースを表示します。
conf_get_space : スペースの詳細情報を取得します（ spaceKey : str req）。用途: スペースのコンテンツとメタデータにアクセスします。
conf_ls_pages : フィルタリングされたページを一覧表示します（ spaceIds : str[] opt、 spaceKeys : str[] opt、 title : str opt、 status : str[] opt、 sort : str opt、 limit : num opt、 cursor : str opt）。使用方法: 条件に一致するページを検索します。
conf_get_page : 包括的なページコンテンツを取得します（ pageId : 文字列が必要です）。使用方法: ページ全体のコンテンツをMarkdown形式で表示します。
conf_ls_page_comments : ページ（ pageId ：文字列必須）のコメントを一覧表示します。用途：ページのディスカッションを読み取ります。
conf_search : Confluenceコンテンツを検索します（ cql : str opt、 query : str opt、 title : str opt、 spaceKey : str opt、 labels : str[] opt、 contentType : str opt、 limit : num opt、 cursor : str opt）。使用方法: 特定のコンテンツを検索します。

`conf_ls_spaces`

グローバルスペースの一覧:

{ "type": "global", "status": "current", "limit": 10 }

`conf_get_space`

スペースの詳細を取得:

{ "spaceKey": "DEV" }

`conf_ls_pages`

スペースとタイトル別にページを一覧表示:

{
	"spaceKeys": ["DEV"],
	"title": "API Documentation",
	"status": ["current"],
	"sort": "-modified-date"
}

複数のスペースからページを一覧表示する:

{
	"spaceKeys": ["DEV", "HR", "MARKETING"],
	"limit": 15,
	"sort": "-modified-date"
}

`conf_get_page`

ページコンテンツを取得:

{ "pageId": "12345678" }

`conf_ls_page_comments`

リストページのコメント:

{ "pageId": "12345678" }

`conf_search`

シンプル検索:

{
	"query": "release notes Q1",
	"spaceKey": "PRODUCT",
	"contentType": "page",
	"limit": 5
}

高度な CQL 検索:

{ "cql": "space = DEV AND label = api AND created >= '2023-01-01'" }

CLIコマンド

CLIコマンドはkebab-caseを使用します。詳細については、 --helpを実行してください（例： mcp-atlassian-confluence ls-spaces --help ）。

ls-spaces : スペースを一覧表示します（ --type 、 --status 、 --limit 、 --cursor ）。例： mcp-atlassian-confluence ls-spaces --type global 。
get-space : スペースの詳細を取得します ( --space-key )。例: mcp-atlassian-confluence get-space --space-key DEV 。
ls-pages : ページを一覧表示します（ --space-keys 、 --title 、 --status 、 --sort 、 --limit 、 --cursor ）。例： mcp-atlassian-confluence ls-pages --space-keys DEV 。
get-page : ページコンテンツを取得します（ --page-id ）。例： mcp-atlassian-confluence get-page --page-id 12345678 。
ls-page-comments : コメントを一覧表示します ( --page-id )。例: mcp-atlassian-confluence ls-page-comments --page-id 12345678 。
search : コンテンツを検索します（ --cql 、 --query 、 --space-key 、 --label 、 --type 、 --limit 、 --cursor ）。例： mcp-atlassian-confluence search --query "security" 。

リストスペース

グローバルスペースの一覧:

mcp-atlassian-confluence ls-spaces --type global --status current --limit 10

スペースを取得する

mcp-atlassian-confluence get-space --space-key DEV

リストページ

複数のスペースキーを使用する場合:

mcp-atlassian-confluence ls-pages --space-keys DEV HR MARKETING --limit 15 --sort "-modified-date"

タイトルフィルター付き:

mcp-atlassian-confluence ls-pages --space-keys DEV --title "API Documentation" --status current

ページを取得

mcp-atlassian-confluence get-page --page-id 12345678

リストページのコメント

mcp-atlassian-confluence ls-page-comments --page-id 12345678

検索

シンプル検索:

mcp-atlassian-confluence search --query "security best practices" --space-key DOCS --type page --limit 5

CQL 検索:

mcp-atlassian-confluence search --cql "label = official-docs AND creator = currentUser()"

応答フォーマット

すべての回答は Markdown 形式です。これには以下が含まれます。

タイトル: コンテンツの種類と名前。
コンテンツ: ページ全体のコンテンツ、検索結果、またはアイテムのリスト。
メタデータ: 作成者、日付、ラベル、その他の関連情報。
ページ区切り: ページ区切りされた結果のナビゲーション情報。
リンク: 該当する場合の関連リソースへの参照。

スペースリスト応答

# Confluence Spaces

Showing **5** global spaces (current)

| Key | Name | Description |
|---|---|---|
| [DEV](#) | Development | Engineering and development documentation |
| [HR](#) | Human Resources | Employee policies and procedures |
| [MARKETING](#) | Marketing | Brand guidelines and campaign materials |
| [PRODUCT](#) | Product | Product specifications and roadmaps |
| [SALES](#) | Sales | Sales processes and resources |

*Retrieved from mycompany.atlassian.net on 2025-05-19 14:22 UTC*

Use `cursor: "next-page-token-123"` to see more spaces.

ページコンテンツレスポンス

# API Authentication Guide

**Space:** [DEV](#) (Development)
**Created by:** Jane Smith on 2025-04-01
**Last updated:** John Doe on 2025-05-15
**Labels:** api, security, authentication

## Overview

This document outlines the authentication approaches supported by our API platform.

## Authentication Methods

### OAuth 2.0

We support the following OAuth 2.0 flows:

1. **Authorization Code Flow** - For web applications
2. **Client Credentials Flow** - For server-to-server
3. **Implicit Flow** - For legacy clients only

### API Keys

Static API keys are supported but discouraged for production use due to security limitations:

| Key Type | Use Case | Expiration |
|---|---|---|
| Development | Testing | 30 days |
| Production | Live systems | 90 days |

## Implementation Examples

  import requests

  def get_oauth_token():
      return requests.post(
          'https://api.example.com/oauth/token',
          data={
              'client_id': 'YOUR_CLIENT_ID',
              'client_secret': 'YOUR_CLIENT_SECRET',
              'grant_type': 'client_credentials'
          }
      ).json()['access_token']

*Retrieved from mycompany.atlassian.net on 2025-05-19 14:25 UTC*

発達

# Clone repository
git clone https://github.com/aashari/mcp-server-atlassian-confluence.git
cd mcp-server-atlassian-confluence

# Install dependencies
npm install

# Run in development mode
npm run dev:server

# Run tests
npm test

貢献

貢献を歓迎します！ご協力をお願いします:

リポジトリをフォークします。
機能ブランチを作成します ( git checkout -b feature/xyz )。
変更をコミットします ( git commit -m "Add xyz feature" )。
ブランチにプッシュします ( git push origin feature/xyz )。
プルリクエストを開きます。

詳細については、 CONTRIBUTING.md を参照してください。

ライセンス

ISCライセンス

Available Tools

5 tools

conf_deleteConfluence DELETE RequestA

Delete Confluence resources. Returns TOON format by default.

Output format: TOON (default) or JSON (outputFormat: "json")

Common operations:

/wiki/api/v2/pages/{id} - Delete page
/wiki/api/v2/blogposts/{id} - Delete blog post
/wiki/api/v2/pages/{id}/labels/{label-id} - Remove label
/wiki/api/v2/footer-comments/{id} - Delete comment
/wiki/api/v2/attachments/{id} - Delete attachment

Note: Most DELETE endpoints return 204 No Content on success.

API reference: https://developer.atlassian.com/cloud/confluence/rest/v2/

ParametersJSON Schema

Name	Required	Description
`path`	Yes	The Confluence API endpoint path (without base URL). Must start with "/". Examples: "/wiki/api/v2/spaces", "/wiki/api/v2/pages", "/wiki/api/v2/pages/{id}"
`queryParams`	No	Optional query parameters as key-value pairs. Examples: {"limit": "25", "cursor": "...", "space-id": "123", "body-format": "storage"}
`jq`	No	JMESPath expression to filter/transform the response. IMPORTANT: Always use this to extract only needed fields and reduce token costs. Examples: "results[].{id: id, title: title}" (extract specific fields), "results[0]" (first result), "results[].id" (IDs only). See https://jmespath.org
`outputFormat`	No	Output format: "toon" (default, 30-60% fewer tokens) or "json". TOON is optimized for LLMs with tabular arrays and minimal syntax.

TDQS

A3.6/5.0

Behavior3/5

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

Annotations absent, so description carries full burden. It describes the action, output format (TOON), and typical response (204), but omits authorization, error handling, and irreversible nature beyond 'Delete'.

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?

Well-structured with clear sections and bullet points. Front-loaded with core action. The list of endpoints is slightly lengthy but overall concise.

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?

Lacks output schema, so description should explain return values. Mentions TOON format and 204 response but not error handling or response structure. Missing guidance on authentication and pagination.

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 parameters are already documented. Description adds concrete endpoint examples for the 'path' parameter but does not significantly enhance understanding of other parameters beyond 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?

Clearly states it deletes Confluence resources via DELETE HTTP method, with specific endpoint examples, differentiating from siblings (get, patch, post, put).

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. Usage is implied by the action 'Delete' but not clarified with respect to other methods.

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

conf_getConfluence GET RequestA

Read any Confluence data. Returns TOON format by default (30-60% fewer tokens than JSON).

IMPORTANT - Cost Optimization:

ALWAYS use jq param to filter response fields. Unfiltered responses are very expensive!
Use limit query param to restrict result count (e.g., limit: "5")
If unsure about available fields, first fetch ONE item with limit: "1" and NO jq filter to explore the schema, then use jq in subsequent calls

Schema Discovery Pattern:

First call: path: "/wiki/api/v2/spaces", queryParams: {"limit": "1"} (no jq) - explore available fields
Then use: jq: "results[*].{id: id, key: key, name: name}" - extract only what you need

Output format: TOON (default, token-efficient) or JSON (outputFormat: "json")

Common paths:

/wiki/api/v2/spaces - list spaces
/wiki/api/v2/pages - list pages (use space-id query param)
/wiki/api/v2/pages/{id} - get page details
/wiki/api/v2/pages/{id}/body - get page body (body-format: storage, atlas_doc_format, view)
/wiki/rest/api/search - search content (cql query param)

JQ examples: results[*].id, results[0], results[*].{id: id, title: title}

API reference: https://developer.atlassian.com/cloud/confluence/rest/v2/

ParametersJSON Schema

Name	Required	Description
`path`	Yes	The Confluence API endpoint path (without base URL). Must start with "/". Examples: "/wiki/api/v2/spaces", "/wiki/api/v2/pages", "/wiki/api/v2/pages/{id}"
`queryParams`	No	Optional query parameters as key-value pairs. Examples: {"limit": "25", "cursor": "...", "space-id": "123", "body-format": "storage"}
`jq`	No	JMESPath expression to filter/transform the response. IMPORTANT: Always use this to extract only needed fields and reduce token costs. Examples: "results[].{id: id, title: title}" (extract specific fields), "results[0]" (first result), "results[].id" (IDs only). See https://jmespath.org
`outputFormat`	No	Output format: "toon" (default, 30-60% fewer tokens) or "json". TOON is optimized for LLMs with tabular arrays and minimal syntax.

TDQS

A4.8/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. It fully discloses behavior: returns TOON format by default (30-60% fewer tokens), explains cost implications, and provides a schema discovery pattern. However, it does not mention error handling, authentication requirements, or rate limiting. Could be slightly more transparent on edge cases but sufficient for a read 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?

Well-structured with clear sections (IMPORTANT - Cost Optimization, Schema Discovery Pattern, Output format, Common paths, JQ examples). Front-loaded with core purpose and crucial cost advice. Every sentence adds value; no fluff. Appropriately detailed for a complex tool without being verbose.

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

Completeness5/5

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

Comprehensive given no output schema: explains output format, how to control it, provides common paths, discovery pattern, and jq examples. With 4 parameters and no output schema, the description fully equips an agent to use the tool effectively, including cost optimization. Sibling tools are all write, reinforcing the read-only nature.

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

Parameters5/5

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

Schema coverage is 100% but description adds significant value beyond schema: explains `jq` with cost-saving context, contrasts `outputFormat` options, gives concrete examples for `path` and `queryParams`. Each parameter is well-contextualized in the tool's usage, making it easier for the agent to choose correct values.

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?

Starts with 'Read any Confluence data', clearly describing the tool as a read-only GET request. Differentiates from sibling tools (conf_delete, conf_patch, conf_post, conf_put) which are all write operations. Also specifies output format (TOON by default) and token efficiency.

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

Usage Guidelines5/5

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

Provides extensive usage guidelines: strongly recommends using `jq` and `limit` to reduce costs, outlines a discovery pattern for exploring schemas, lists common paths with examples, and gives jq examples. Explicitly advises on when to use this tool for reading and implies not for writing by nature of being a GET tool.

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

conf_patchConfluence PATCH RequestA

Partially update Confluence resources. Returns TOON format by default.

IMPORTANT - Cost Optimization: Use jq param to filter response fields.

Output format: TOON (default) or JSON (outputFormat: "json")

Common operations:

Update space: /wiki/api/v2/spaces/{id} body: {"name": "New Name", "description": {"plain": {"value": "Desc", "representation": "plain"}}}
Update comment: /wiki/api/v2/footer-comments/{id}

Note: Confluence v2 API primarily uses PUT for updates.

API reference: https://developer.atlassian.com/cloud/confluence/rest/v2/

ParametersJSON Schema

Name	Required	Description
`path`	Yes	The Confluence API endpoint path (without base URL). Must start with "/". Examples: "/wiki/api/v2/spaces", "/wiki/api/v2/pages", "/wiki/api/v2/pages/{id}"
`queryParams`	No	Optional query parameters as key-value pairs. Examples: {"limit": "25", "cursor": "...", "space-id": "123", "body-format": "storage"}
`jq`	No	JMESPath expression to filter/transform the response. IMPORTANT: Always use this to extract only needed fields and reduce token costs. Examples: "results[].{id: id, title: title}" (extract specific fields), "results[0]" (first result), "results[].id" (IDs only). See https://jmespath.org
`outputFormat`	No	Output format: "toon" (default, 30-60% fewer tokens) or "json". TOON is optimized for LLMs with tabular arrays and minimal syntax.
`body`	Yes	Request body as a JSON object. Structure depends on the endpoint. Example for page: {"spaceId": "123", "title": "Page Title", "body": {"representation": "storage", "value": "<p>Content</p>"}}

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 must cover behavioral traits. It discloses default output format (TOON) and cost optimization via 'jq' parameter. However, it does not discuss error handling, idempotency, authentication requirements, or side effects beyond the PATCH verb.

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 well-structured with sections and bolded notes, making key information scannable. It is somewhat verbose with examples, but each part earns its place by providing actionable guidance. Could be slightly trimmed without loss.

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, the description explains the return format (TOON or JSON) and common endpoint patterns. It covers the main use case (partial updates) and provides API reference URL. Missing details on response structure beyond format, but overall complete for a patch tool.

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?

All 5 parameters have schema descriptions (100% coverage). The description adds value by providing concrete examples for 'path' and 'body', common operations, and cost optimization context for 'jq' and 'outputFormat'. This goes beyond the schema fields.

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 explicitly states 'Partially update Confluence resources' and provides specific examples for updating a space and comment. The name 'conf_patch' and sibling tools ('conf_delete', 'conf_get', 'conf_post', 'conf_put') clearly differentiate it as the partial update operation.

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 mentions that Confluence v2 API primarily uses PUT for updates, which hints at when to use PATCH vs PUT, but does not explicitly state when to use this tool over alternatives. No guidance on when not to use or prerequisites beyond this subtle note.

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

conf_postConfluence POST RequestA

Create Confluence resources. Returns TOON format by default (token-efficient).

IMPORTANT - Cost Optimization:

Use jq param to extract only needed fields from response (e.g., jq: "{id: id, title: title}")
Unfiltered responses include all metadata and are expensive!

Output format: TOON (default) or JSON (outputFormat: "json")

Common operations:

Create page: /wiki/api/v2/pages body: {"spaceId": "123456", "status": "current", "title": "Page Title", "parentId": "789", "body": {"representation": "storage", "value": "Content"}}
Create blog post: /wiki/api/v2/blogposts body: {"spaceId": "123456", "status": "current", "title": "Blog Title", "body": {"representation": "storage", "value": "Content"}}
Add label: /wiki/api/v2/pages/{id}/labels - body: {"name": "label-name"}
Add comment: /wiki/api/v2/pages/{id}/footer-comments

API reference: https://developer.atlassian.com/cloud/confluence/rest/v2/

ParametersJSON Schema

Name	Required	Description
`path`	Yes	The Confluence API endpoint path (without base URL). Must start with "/". Examples: "/wiki/api/v2/spaces", "/wiki/api/v2/pages", "/wiki/api/v2/pages/{id}"
`queryParams`	No	Optional query parameters as key-value pairs. Examples: {"limit": "25", "cursor": "...", "space-id": "123", "body-format": "storage"}
`jq`	No	JMESPath expression to filter/transform the response. IMPORTANT: Always use this to extract only needed fields and reduce token costs. Examples: "results[].{id: id, title: title}" (extract specific fields), "results[0]" (first result), "results[].id" (IDs only). See https://jmespath.org
`outputFormat`	No	Output format: "toon" (default, 30-60% fewer tokens) or "json". TOON is optimized for LLMs with tabular arrays and minimal syntax.
`body`	Yes	Request body as a JSON object. Structure depends on the endpoint. Example for page: {"spaceId": "123", "title": "Page Title", "body": {"representation": "storage", "value": "<p>Content</p>"}}

TDQS

A4.2/5.0

Behavior3/5

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

No annotations; description covers output format and cost implications but lacks details on authentication requirements, potential side effects, or behavior for existing resources.

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?

Well-structured with sections and front-loaded important info, but slightly verbose with repeated examples.

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?

Covers usage, cost optimization, output format, and common operations; missing auth and error handling, but references external documentation.

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

Parameters5/5

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

Schema coverage is 100% with descriptions. The description adds significant value with endpoint examples, body structures, and jq usage guidance 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 tool creates Confluence resources, with specific examples like creating pages, blog posts, labels, and comments. This distinguishes it from sibling tools (get, delete, patch, put).

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

Usage Guidelines4/5

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

Provides cost optimization tips and common operation examples, but does not explicitly state when not to use the tool or compare with siblings beyond implied HTTP methods.

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

conf_putConfluence PUT RequestA

Replace Confluence resources (full update). Returns TOON format by default.

IMPORTANT - Cost Optimization:

Use jq param to extract only needed fields from response
Example: jq: "{id: id, version: version.number}"

Output format: TOON (default) or JSON (outputFormat: "json")

Common operations:

Update page: /wiki/api/v2/pages/{id} body: {"id": "123", "status": "current", "title": "Updated Title", "spaceId": "456", "body": {"representation": "storage", "value": "Content"}, "version": {"number": 2}} Note: version.number must be incremented
Update blog post: /wiki/api/v2/blogposts/{id}

Note: PUT replaces entire resource. Version number must be incremented.

API reference: https://developer.atlassian.com/cloud/confluence/rest/v2/

ParametersJSON Schema

Name	Required	Description
`path`	Yes	The Confluence API endpoint path (without base URL). Must start with "/". Examples: "/wiki/api/v2/spaces", "/wiki/api/v2/pages", "/wiki/api/v2/pages/{id}"
`queryParams`	No	Optional query parameters as key-value pairs. Examples: {"limit": "25", "cursor": "...", "space-id": "123", "body-format": "storage"}
`jq`	No	JMESPath expression to filter/transform the response. IMPORTANT: Always use this to extract only needed fields and reduce token costs. Examples: "results[].{id: id, title: title}" (extract specific fields), "results[0]" (first result), "results[].id" (IDs only). See https://jmespath.org
`outputFormat`	No	Output format: "toon" (default, 30-60% fewer tokens) or "json". TOON is optimized for LLMs with tabular arrays and minimal syntax.
`body`	Yes	Request body as a JSON object. Structure depends on the endpoint. Example for page: {"spaceId": "123", "title": "Page Title", "body": {"representation": "storage", "value": "<p>Content</p>"}}

TDQS

A4.3/5.0

Behavior4/5

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

Despite no annotations, the description discloses key behaviors: full replacement, version increment requirement, default TOON output, and jq cost optimization. It adequately informs about operational 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?

Well-structured with sections, bold headings, and bullet points. Front-loaded with purpose, then organized by cost, output, and examples. Some redundancy (version increment mentioned twice), but overall efficient.

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?

Covers main aspects for a PUT tool: purpose, parameters, common operations, output format, and token optimization. Lacks error handling or status codes, but sufficient given schema completeness.

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?

Schema coverage is 100%, but the description adds value through examples (e.g., page update body) and explanations of jq and outputFormat, enriching understanding 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 states 'Replace Confluence resources (full update)' with specific examples for pages and blog posts, clearly distinguishing it from partial update (patch) siblings.

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

Usage Guidelines4/5

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

The description implies usage for full replacements via 'full update' and 'PUT replaces entire resource', but lacks explicit comparison to conf_patch 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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

No tool schema history has been recorded yet.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.3/5.0

Disambiguation5/5

Each tool corresponds to a distinct HTTP method (DELETE, GET, PATCH, POST, PUT), clearly differentiating their purpose. There is no overlap in functionality between tools.

Naming Consistency5/5

All tools follow the consistent pattern 'conf_' followed by the HTTP method verb in lowercase (e.g., conf_delete, conf_get). This pattern is uniform and predictable.

Tool Count5/5

With 5 tools covering the essential CRUD operations plus partial update, the count is well-scoped for a Confluence API server. It is not too few or too many.

Completeness5/5

The tools provide full coverage of basic resource lifecycle operations (create, read, update, partial update, delete). The descriptions include common API paths for pages, spaces, blog posts, etc., and the GET tool supports search via query parameters, leaving no obvious gaps.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
mcp COAuth
com.wix
A Model Context Protocol server for Wix AI tools
Developer Tools Content Management Systems App Automation
216
Artificial Wit AIOAuth
com.artificialwit
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
ERP Systems CRM Knowledge & Memory
2
driflyte-mcp-server
com.driflyte
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
Search Web Scraping Knowledge & Memory
211

Related MCP Servers

Confluence MCP
Content Management Systems Documentation Access App Automation
cosmix
A
license
A
quality
F
maintenance
A Model Context Protocol server that enables AI assistants to interact with Confluence content, supporting operations like retrieving, searching, creating, and updating pages and spaces.
Updated a year ago (2025-07-29 11:46 UTC)
9
19
12
MIT
MCP Atlassian Server
Project Management App Automation
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.
Updated a year ago (2025-08-10 00:39 UTC)
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.
Updated a year ago (2025-07-11 01:45 UTC)
1
MIT
MCP Jira & Confluence Server
Project Management Developer Tools
akhilthomas236
A
license
B
quality
C
maintenance
A Model Context Protocol server that integrates with Atlassian's Jira and Confluence, enabling AI assistants to interact with these tools directly through features like issue management, page creation, and content search.
Updated a year ago (2025-07-30 02:34 UTC)
13
1
MIT

Appeared in Searches

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/aashari/mcp-server-atlassian-confluence'

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

アトラシアン Confluence MCP サーバー

このサーバーを使用する理由

MCPとは何ですか?

前提条件

設定

ステップ1: Atlassian APIトークンを取得する

ステップ2: 資格情報を構成する

オプション A: MCP 構成ファイル (推奨)

オプションB: 環境変数

ステップ3: インストールと実行

npxのクイックスタート

グローバルインストール

ステップ4：AIアシスタントに接続する

MCPツール

conf_ls_spaces

conf_get_space

conf_ls_pages

conf_get_page

conf_ls_page_comments

conf_search

CLIコマンド

リストスペース

スペースを取得する

リストページ

ページを取得

リストページのコメント

検索

応答フォーマット

スペースリスト応答

ページコンテンツレスポンス

発達

貢献

ライセンス

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

MCP directory API

`npx`のクイックスタート

`conf_ls_spaces`

`conf_get_space`

`conf_ls_pages`

`conf_get_page`

`conf_ls_page_comments`

`conf_search`