confluence-dc-advops-mcp

by iljasorokin

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.3.0
Disambiguation5/5
Every tool targets a distinct action and resource: storage file operations, page moving (single/multiple), and space template lifecycle (list, get, create, update, sync, delete). The destructive delete tools further differentiate with explicit approval requirements. No two tools cause confusion.
Naming Consistency5/5
All tool names follow a consistent 'confluence_verbNoun' pattern with camelCase after the underscore (e.g., confluence_updateStorageFromFile, confluence_movePages). The pattern is uniform and predictable, aiding agent selection.
Tool Count5/5
With 11 tools, the set is well-scoped for the domain of Confluence Data Center advanced operations, particularly around storage XML and space templates. Each tool serves a clear purpose without unnecessary overlap, making the count appropriate.
Completeness4/5
The tool surface covers the core workflows for managing storage XML files and space templates (CRUD, sync, move, delete). Minor gap: no tool to create a page from a template, but that aligns with the server's focus on template management rather than page creation. Overall, it's nearly complete for its stated purpose.
Average 3.9/5 across 11 of 11 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 17 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavior. It states the tool downloads XML to a local file and returns version/title/path, but it does not mention whether the file will be overwritten, what permissions are needed, or any side effects. For a download tool, these are basic behavioral details that are missing.
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?
The description is extremely concise with three short sentences: first states the action, second lists return values, third provides usage guidance. No redundant words; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description provides core information (purpose, return values, one use case) but lacks details on error handling, file overwrite behavior, and prerequisites. For a simple download tool, it is minimally complete but could be more thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters (contentId and filePath). The description adds no additional meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool downloads Confluence page body.storage XML to a local file for surgical edits. The verb 'Download' and resource 'page body.storage XML' are specific, and the mention of 'surgical edits (large templates)' adds context. However, it does not explicitly differentiate from related read tools like confluence_getSpaceTemplateToFile, though the sibling list includes that tool.
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?
Provides implicit guidance: 'Prefer this over stuffing huge storage into chat' suggests when to use this tool (for large templates) but does not explicitly state when not to use or list alternatives. The sibling tools are named but not mentioned in the description, so an agent must infer context based on tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It mentions copying body.storage but does not clarify whether it creates or updates a template, what happens to other fields, or if the operation is destructive. The term 'Create from template snapshot' is ambiguous.
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 one sentence plus an example, front-loading the key action. It is efficient, though it uses domain-specific acronyms (BSA, TempStream) that may reduce clarity for some users.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description should hint at return values or error conditions. It does not. The tool has 6 parameters but only 2 are required; the purpose of optional parameters like name, description, descriptionSuffix is not explained.
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 documented. The description adds a helpful example but does not elaborate on parameter meaning beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'copy' and the resource 'body.storage from a BSA/page contentId into a TempStream space template'. It provides a concrete example with specific IDs, making the purpose unambiguous and distinct from sibling tools like create/update from file or list templates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a 'fast path' use case but does not explicitly state when to use this tool versus alternatives like createSpaceTemplateFromFile or updateSpaceTemplateFromFile. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the tool fails if a template with the same name exists, which is a useful behavioral trait. However, it does not mention authorization requirements, rate limits, or the fact it uses an experimental API endpoint. No annotations are provided to supplement these gaps.
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?
Two sentences: first defines the core action, second provides usage context and a failure condition. Front-loaded and efficient with no wasted words.
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 information about the success response format (e.g., return of template ID). For a creation tool with no output schema, the description should at least indicate what the agent can expect on success. The failure case is covered, but success context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter described. The description adds limited value beyond the schema, such as an example for 'name' and the source for 'filePath'. Baseline is 3 since schema already documents all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (create a new space page template from a local XML file) and the API endpoint. The phrase 'BSA заготовка' introduces jargon that may reduce clarity for general agents, but the overall purpose is distinct from sibling tools.
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?
Provides a specific use case ('Use after a new BSA заготовка exists...') but does not explicitly state when to avoid this tool or mention alternatives. Sibling tools like update/delete/list are present but not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description mentions sequential execution and per-item success/error, but lacks details on rollback behavior, error handling, authentication needs, or destructive consequences.
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?
Two efficient sentences with no redundant information. Front-loaded with purpose and key behavioral trait.
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?
Adequate for a simple batch move with full schema coverage, but lacks details on error handling, atomicity, and prerequisites. Without output schema, more behavioral context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage for both parameters. Description adds no param-specific meaning beyond what schema already provides; baseline 3.
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 the verb 'move', resource 'Confluence pages', and scope 'several' and 'sequentially'. Distinguishes from sibling tool 'confluence_movePage' which moves 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage for batch moves, but no explicit when-to-use vs alternatives like 'confluence_movePage', nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full disclosure burden. It mentions the API endpoint and that body is unchanged, but omits authorization needs, versioning behavior, or side effects on children pages.
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?
Two sentences with no filler, but could add a bit more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 3 parameters (2 required), no output schema, and no annotations, the description is minimal. It would benefit from mentioning response structure or prerequisites.
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 the description adds no new parameter-level details beyond naming the API. The baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Move (reparent)'), the resource ('a Confluence Data Center page'), and the target ('under a new parent'). It distinctly separates from siblings like 'confluence_movePages' (plural) and other storage-related tools.
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 explicitly mentions the API method and that the page body is unchanged, implying a structural move. However, it does not contrast with 'confluence_movePages' or provide explicit when-to-use/when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses auto-incrementing version behavior, the constraint that version must be current+1, the requirement to not re-escape entities, and optional reparenting. However, it omits failure modes or response details.
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?
Three sentences, each with value: purpose and auth, version behavior, content handling and optional parentId. No redundant words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing output schema and no mention of return values or success/error behavior. For a tool with 6 parameters and no annotations, the description should at least hint at what the response contains (e.g., updated page, version number). This gap reduces 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 meaningful behavioral context for version (auto-bump rule) and parentId (reparenting). It also warns about not re-escaping file content. This adds value beyond the schema descriptions.
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 publishes page body from a local storage XML file via the Confluence proxy, using specific verbs and resources. It distinguishes from sibling tools like movePage and getStorageToFile, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for updating page body from storage XML but does not explicitly guide when to use this tool versus alternatives like getStorageToFile or template tools. No exclusion criteria or when-not advice is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It mentions the 404 issue and identification methods but does not discuss file overwrite behavior, authentication needs, or rate limits. Adequate but not comprehensive.
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?
Two sentences: first defines the action, second adds usage constraints. No redundant words. Front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main action, required parameters, identification, and a known issue. No output schema but output is a file. Missing details like whether file overwrites or appends. Nearly complete for a straightforward download 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?
Schema has 100% coverage with descriptions. The description adds context that templateId and name can be used together and that name supports substring matching. Also clarifies filePath as absolute path. Adds value 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 verb 'download', resource 'space page template body.storage', and output 'local XML file'. Distinguishes from siblings by being the only template download to file tool. Also provides identification methods and a specific constraint (GET by id alone 404s on DC).
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?
Description explains required spaceKey and identification via templateId/exact/partial name, and warns about a 404 issue. However, it does not explicitly compare with alternative tools like confluence_getStorageToFile or specify when to use this over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that body is not expanded by default for speed, and that expandBody option makes it slow. No annotations exist, so description carries full burden; this is adequate but could mention authorization or rate limits.
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?
Three sentences, efficiently conveying purpose, usage hint, and key behavioral note. No unnecessary words.
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 description of return format, pagination, or error conditions. For a list tool with no output schema, more detail on what is returned would improve 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% and description adds context: example for spaceKey, nature of nameContains filter, and behavioral effect of expandBody. Adds value 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 'List space page templates' with specific verb and resource, and includes API endpoint for precision. Distinct from sibling tools which focus on update, move, delete, etc.
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 specific use case (spaceKey=TempStream for ДРП Create from template) and mentions optional nameContains filter. Does not explicitly exclude alternative tools, but sibling list provides context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behaviors: preserves labels by default, BSA page remains source of truth, and renaming works via templateId and name. It does not mention error states or prerequisites, but covers the most relevant behavioral aspects.
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?
The description is three sentences, each serving a purpose: action/endpoint, default behavior and source-of-truth note, and renaming tip. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters and no output schema, the description covers the essential behavioral and usage points but omits details about the description parameter and potential error conditions. It is adequate for most use cases but not exhaustive.
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?
Input schema has 100% description coverage, so the schema already documents each parameter. The description adds value by clarifying the renaming pattern (templateId + name) and confirming default for keepLabels. This extra guidance goes 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 verb 'Update', the resource 'space page template body', and the source 'local storage XML file'. It also distinguishes itself by noting that the BSA page remains the source of truth, which differentiates it from other template operations.
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 gives context on when to use this tool (publishing a snapshot for Create from template) and mentions a specific usage for renaming. However, it does not explicitly compare to sibling tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set destructiveHint=true, but description adds critical context: the need for human approval, the confirm parameter constraint, and the lack of trash restore. Does not contradict annotations.
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?
Description is concise (3 sentences) and front-loads the key point (DESTRUCTIVE, human approval). Some redundancy in repeating the confirm requirement across sentences, 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?
Given 5 params, no output schema, and annotations, the description covers essential behavioral traits and usage constraints. Lacks detail on return value or error cases, but sufficient for agent decision-making.
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 description adds meaning to 'confirm' (must be literal 'DELETE', not just boolean) and 'confirmName' (exact template name from listSpaceTemplates). Enhances understanding beyond schema descriptions.
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 deletes one space template, using a specific API endpoint, and distinguishes itself from sibling tools like 'confluence_deleteSpaceTemplates' (plural). The verb 'delete' and resource 'space template' are explicit.
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 explicit guidance: always stop and get human approval, never invent confirm, requires confirm='DELETE' and confirmName=exact template name. Also warns about no trash restore and advises archiving first. Clearly states when and how to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include destructiveHint:true, idempotentHint:true. The description adds crucial behavioral details not in annotations: it starts with 'DESTRUCTIVE', requires human approval, details the confirmation mechanism, notes continuation on errors, and recommends an archive dump. No contradictions.
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?
The description is very concise (five sentences) with no wasted words. It is front-loaded with 'DESTRUCTIVE' to immediately signal danger. Each sentence conveys essential information: action, approval requirement, confirmation mechanics, error behavior, and precaution.
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 covers the key aspects: destructive nature, human approval, parameter specifics, error handling, and a precaution (archive dump). It lacks return value description but that is not expected without output schema. Adequate for safe invocation.
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%, so baseline is 3. The description adds value beyond schema by explaining that confirm must be the exact string 'DELETE' (not true/yes), and confirmNames must match templateIds in order and be exact names. This clarifies parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete), the resource (space Create templates), and the scope (several by id). It effectively distinguishes from siblings like 'deleteSpaceTemplate' (singular) and other space template operations.
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 provides explicit guidance: it requires human approval, specifies confirmation parameters (confirm='DELETE', confirmNames), and mentions error handling (continues on per-item errors). However, it does not explicitly compare to alternatives like the singular delete tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![confluence-dc-advops-mcp MCP server](https://glama.ai/mcp/servers/iljasorokin/confluence-dc-advops-mcp/badges/card.svg)](https://glama.ai/mcp/servers/iljasorokin/confluence-dc-advops-mcp)

Score Badge

Copy to your README.md:

[![confluence-dc-advops-mcp MCP server](https://glama.ai/mcp/servers/iljasorokin/confluence-dc-advops-mcp/badges/score.svg)](https://glama.ai/mcp/servers/iljasorokin/confluence-dc-advops-mcp)

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/iljasorokin/confluence-dc-advops-mcp'

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