Atlassian Confluence MCP Server
Atlassian Confluence MCP 서버
Atlassian Confluence Cloud용 Node.js/TypeScript 모델 컨텍스트 프로토콜(MCP) 서버입니다. AI 시스템(예: Claude 또는 Cursor AI와 같은 LLM)이 Confluence 공간, 페이지 및 콘텐츠와 실시간으로 안전하게 상호 작용할 수 있도록 지원합니다.
왜 이 서버를 사용해야 하나요?
최소 입력, 최대 출력 : 간단한 식별자는 추가 플래그가 필요하지 않고 포괄적인 세부 정보를 제공합니다.
지식 기반에 대한 완벽한 접근 : AI 도우미에게 문서, 위키, 지식 기반 콘텐츠에 대한 가시성을 제공합니다.
풍부한 콘텐츠 형식 : Atlassian 문서 형식을 읽을 수 있는 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 편집하거나 생성합니다.
지엑스피1
<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-spaces4단계: AI Assistant에 연결
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 요청). 용도: 공간 콘텐츠 및 메타데이터에 액세스합니다.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: 문자열 필요). 사용: 전체 페이지 콘텐츠를 마크다운으로 표시합니다.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.검색 : 콘텐츠를 검색합니다(
--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 5CQL 검색:
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를 참조하세요.
특허
Available Tools
5 toolsconf_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/
| Name | Required | Description | Default |
|---|---|---|---|
| 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
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.
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.
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.
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.
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.
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
jqparam to filter response fields. Unfiltered responses are very expensive!Use
limitquery 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 fieldsThen 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 (usespace-idquery 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 (cqlquery param)
JQ examples: results[*].id, results[0], results[*].{id: id, title: title}
API reference: https://developer.atlassian.com/cloud/confluence/rest/v2/
| Name | Required | Description | Default |
|---|---|---|---|
| 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
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.
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.
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.
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.
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.
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/
| Name | Required | Description | Default |
|---|---|---|---|
| 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
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.
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.
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.
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.
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.
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
jqparam 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/pagesbody:{"spaceId": "123456", "status": "current", "title": "Page Title", "parentId": "789", "body": {"representation": "storage", "value": "<p>Content</p>"}}Create blog post:
/wiki/api/v2/blogpostsbody:{"spaceId": "123456", "status": "current", "title": "Blog Title", "body": {"representation": "storage", "value": "<p>Content</p>"}}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/
| Name | Required | Description | Default |
|---|---|---|---|
| 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
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.
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.
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.
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.
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.
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
jqparam to extract only needed fields from responseExample:
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": "<p>Content</p>"}, "version": {"number": 2}}Note: version.number must be incrementedUpdate 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/
| Name | Required | Description | Default |
|---|---|---|---|
| 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
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.
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.
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.
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.
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.
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.
TDQS
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.
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.
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.
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
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol server for Wix AI tools
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
Related MCP Servers
- AlicenseAqualityFmaintenanceA Model Context Protocol server that enables AI assistants to interact with Confluence content, supporting operations like retrieving, searching, creating, and updating pages and spaces.91912MIT
- AlicenseNot gradedqualityCmaintenanceA 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.3753MIT
- AlicenseNot gradedqualityDmaintenanceModel 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.1MIT
- AlicenseBqualityCmaintenanceA 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.131MIT
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 .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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