Provides tools for accessing and managing the Apache Incubator Confluence wiki space, including listing, searching, and fetching pages and metadata within the Apache Incubator project.
Provides tools for interacting with Confluence wiki pages, including listing, searching, fetching page content, and retrieving child pages and space metadata.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@CwikiMCP list all pages in the Incubator space"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for the Apache Incubator Confluence space:
https://cwiki.apache.org/confluence/display/INCUBATOR
The server is read-only and works against public wiki pages.
GET responses are cached locally by default for 30 days. Use force_refresh=true on read tools to bypass the cache for a single call.
python3 -m venv .venv
. .venv/bin/activate
pip install -e .Related MCP server: Atlassian MCP Server
incubator-cwiki-mcpFor local development:
python -m incubator_cwiki_mcp.serverpip install -e ".[dev]"
make checkUse the Python module entrypoint:
{
"mcpServers": {
"incubator-cwiki": {
"command": "<Path to CwikiMCP>/.venv/bin/python",
"args": ["-m", "incubator_cwiki_mcp.server"],
"env": {
"CWIKI_BASE_URL": "https://cwiki.apache.org/confluence",
"CWIKI_SPACE_KEY": "INCUBATOR"
}
}
}
}cwiki_space_info: return metadata for the configured Confluence space.
cwiki_list_pages: list pages in the Incubator space.
cwiki_search_pages: search pages with Confluence CQL. Use title_only=true to match page titles only (faster and more precise for finding a specific page by name).
cwiki_get_page: fetch a page by title or page_id.
cwiki_get_children: list child pages for a page_id.
cwiki_cache_info: show local cache settings and size.
cwiki_clear_cache: clear the local cache.
CWIKI_BASE_URL: defaults to https://cwiki.apache.org/confluence.
CWIKI_SPACE_KEY: defaults to INCUBATOR.
CWIKI_CACHE_DIR: defaults to .cache/cwiki.
CWIKI_CACHE_TTL_SECONDS: defaults to 2592000 seconds (30 days). Set to 0 to disable caching.
Show local Confluence response cache settings and current size.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It implies read-only behavior via 'Show', but does not explicitly confirm no side effects or detail additional traits like permission requirements or performance impact.
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?
Single, front-loaded sentence with no filler. Every word contributes to meaning.
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?
For a zero-parameter tool with an output schema, the description is sufficient. It clearly states what the tool returns (cache settings and size), and the output schema handles details.
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% (no parameters). Baseline is 3; the description adds no param info, but none is needed. It does not detract from understanding.
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 shows cache settings and size. It uses a specific verb ('Show') and resource ('local Confluence response cache'), distinguishing it from siblings like cwiki_clear_cache.
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 guidance on when to use this tool vs alternatives like cwiki_clear_cache. The description does not specify context, prerequisites, or scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clear the local Confluence response cache.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description labels the action as destructive ('clear') without explaining side effects (e.g., performance impact, data loss, or duration). With no annotations, the burden falls entirely on the description, which falls short.
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 a single, concise sentence that directly states the tool's function without redundancy. It is appropriately front-loaded.
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 the tool has no parameters and an output schema exists, the description is structurally complete. However, the lack of behavioral context (e.g., impact of clearing cache) reduces its overall completeness for an agent.
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?
There are no parameters, so the schema coverage is 100%. The description adds no parameter details, but this is acceptable as there is nothing to explain 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 uses a clear verb 'Clear' with a specific resource 'local Confluence response cache'. It successfully distinguishes from siblings like cwiki_cache_info, which implies inspection rather than mutation.
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 guidance is provided on when to clear the cache, when not to, or how this compares to inspecting cache via cwiki_cache_info. The agent lacks context to decide if this action is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List child pages for a page by page id.
| Name | Required | Description | Default |
|---|---|---|---|
| page_id | Yes | ||
| limit | No | ||
| start | No | ||
| force_refresh | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states 'List child pages' without specifying that it is a read-only operation, describing pagination behavior (limit/start), or clarifying side effects like caching force_refresh. This lack of transparency leaves important behavioral traits undocumented.
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 concise at one sentence, but conciseness must balance with informativeness. It omits crucial details about parameters and usage, so it is under-specified rather than efficiently packed.
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 the absence of annotations, output schema content is not shown but exists, yet the description does not mention return values. Sibling tools are listed but not differentiated. This incompleteness forces the agent to guess at nuances.
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 description coverage is 0%, yet the description adds no meaning to any of the four parameters (page_id, limit, start, force_refresh). With no parameter explanations, the agent cannot correctly construct queries or interpret defaults, making the tool difficult to use correctly.
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 action 'List' and the resource 'child pages' with the key parameter 'by page id'. It is specific and well-defined, but does not explicitly distinguish from sibling tools like cwiki_get_page or cwiki_list_pages, which could cause ambiguity for an AI agent.
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 guidance is provided on when to use this tool versus alternatives such as cwiki_search_pages or cwiki_list_pages. There is no mention of prerequisites or context, leaving the agent without directional cues for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a wiki page by page title or page id.
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | ||
| page_id | No | ||
| format | No | plain | |
| force_refresh | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It does not disclose behavior like caching, error handling, or what happens if both title and page_id are provided. The force_refresh parameter is not explained.
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 a single sentence, which is concise, but at the cost of omitting important details. It could include more information without being overly 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?
Given the tool has 4 parameters and an output schema, the description is too minimal. It does not explain the format parameter, force_refresh, or how the identifiers relate, leaving the agent with insufficient context for correct invocation.
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 description coverage is 0%, yet the description adds no meaning beyond the parameter names. It does not explain the format enum, the force_refresh boolean, or the mutual exclusivity of title and page_id.
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 verb 'Fetch' and the resource 'wiki page', and specifies the two identifiers (title or page id). This distinguishes it from sibling tools like cwiki_get_children (gets children) and cwiki_search_pages (searches).
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 guidelines on when to use this tool vs alternatives. There is no mention of prerequisites, when to prefer this over other page-related tools, or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List pages in the configured Apache Incubator Confluence space.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| start | No | ||
| force_refresh | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states only 'List pages' and omits pagination behavior (despite start/limit parameters), whether archived or restricted pages are included, cache refresh effects, or any side effects. This is insufficient for an agent to understand the tool's behavior.
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 very short (one sentence) but lacks necessary context. While conciseness is positive, the brevity results in incompleteness. It could be improved by adding a second sentence on usage or behavior.
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 the presence of an output schema and three parameters with no descriptions, the description should at least mention the output format (list of page objects) and pagination semantics. It does not, and the tool's complete behavior (e.g., whether it returns all pages or respects limits) is unclear.
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 description coverage is 0%, so the description must explain the parameters. It mentions none of the three parameters (limit, start, force_refresh). The parameter titles are generic and their meanings (pagination control, cache bypass) are not communicated. This adds no value 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 verb 'list' and the resource 'pages in the configured Apache Incubator Confluence space', unambiguously differentiating from siblings like cwiki_search_pages (which searches) and cwiki_get_page (which retrieves a single page).
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 the single configured space but does not explicitly guide when to use this tool versus alternatives like cwiki_search_pages for filtered results or cwiki_get_children for hierarchical nav. No exclusions or conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search pages in the configured Apache Incubator Confluence space.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| limit | No | ||
| start | No | ||
| force_refresh | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, and description provides no behavioral details such as pagination behavior, caching effects of force_refresh, or scope of search (titles only vs full text).
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?
Extremely concise, but this comes at the cost of omitting necessary detail. One sentence with no structure or additional context.
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 the presence of 4 parameters and sibling tools, the description is too sparse. It does not address output format, pagination, or how caching works, leaving the agent underinformed.
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 has 0% description coverage; the description does not explain any parameters. The meaning of 'query', 'limit', 'start', and 'force_refresh' is left to inference from names, which may be insufficient.
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 searches pages in a specific Confluence space. However, it does not differentiate from sibling tools like cwiki_list_pages or cwiki_get_page, which might have overlapping functionality.
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 guidance on when to use this tool vs alternatives (e.g., search vs list). Lacks context about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get metadata for the configured Apache Confluence space.
| Name | Required | Description | Default |
|---|---|---|---|
| force_refresh | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only says 'Get metadata' (implying a read operation) but does not disclose caching behavior, side effects, or authentication needs.
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 a single sentence, making it concise and front-loaded. However, it sacrifices necessary detail for brevity.
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 the low parameter count and presence of an output schema, the description is minimally adequate but lacks explanation of the parameter and clear differentiation from siblings.
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?
The sole parameter force_refresh has no description in either the input schema (0% coverage) or the tool description, leaving its purpose and effect entirely unclear.
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 gets metadata for the configured Apache Confluence space, using a verb+resource structure. However, it does not differentiate from sibling tools like cwiki_cache_info or cwiki_list_pages, which might also return metadata aspects.
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 guidance is provided on when to use this tool versus alternatives, nor any explanation of the force_refresh parameter or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0cwiki_cache_infocwiki_clear_cachecwiki_get_childrencwiki_get_pagecwiki_list_pagescwiki_search_pagescwiki_space_infoEach tool has a clearly distinct purpose: cache management (info/clear), page retrieval (by ID/title), children listing, page listing, page search, and space info. No overlap in functionality.
All tools follow a consistent 'cwiki_verb_noun' pattern (e.g., cwiki_list_pages, cwiki_clear_cache). The naming convention is uniform and predictable.
Seven tools is a reasonable number for a focused Confluence wiki server. The set covers essential read operations and cache management, though it lacks create/update/delete operations, which might be justified if the server is read-only.
The tool set covers page retrieval, listing, search, and space metadata, but notably missing are create, update, and delete operations for pages. This is a significant gap for a full wiki management surface, though the server may be intentionally read-only.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Read-only MCP for the Eco game wiki: search, Markdown pages, and wiki_* lookups. No keys, no writes.
Agent-native MCP server over the public saagarpatel.dev corpus. Read-only, stateless.
MCP server for querying Forkast documentation
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/justinmclean/CwikiMCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
