Skip to main content
Glama

Upload Attachment

confluence_upload_attachment
Destructive

Upload files or base64-encoded content to Confluence pages or blog posts; existing attachments with the same filename are updated as a new version.

Instructions

Upload an attachment to Confluence content (page or blog post).

Provide the file either as a server-readable path ('file_path') or as base64-encoded content ('content_base64' together with 'filename'). The base64 form is intended for remote or containerized servers that cannot read host file paths. Exactly one of the two must be supplied.

If the attachment already exists (same filename), a new version is created. This is useful for:

  • Attaching documents, images, or files to a page

  • Updating existing attachments with new versions

  • Adding supporting materials to documentation

Input Schema

NameRequiredDescriptionDefault
commentNo(Optional) A comment describing this attachment or version. Visible in the attachment history. Example: 'Updated Q4 2024 figures'
filenameNo(Optional) Attachment filename, including extension (e.g. 'report.pdf'). Required when using 'content_base64'; it determines the attachment title and file type. Ignored when 'file_path' is used.
file_pathNoFull path to the file to upload. Can be absolute (e.g., '/home/user/document.pdf' or 'C:\Users\name\file.docx') or relative to the current working directory (e.g., './uploads/document.pdf'). If a file with the same name already exists, a new version will be created. Requires the server to be able to read the path; for remote or containerized servers use 'content_base64' instead. Provide either 'file_path' or 'content_base64', not both.
content_idYesThe ID of the Confluence content (page or blog post) to attach the file to. Page IDs can be found in the page URL or by using the search/get_page tools. Example: '123456789'
minor_editNo(Optional) Whether this is a minor edit. If true, watchers are not notified. Default is false.
content_base64No(Optional) Base64-encoded file content to upload directly, without the server reading from disk. Use this when the server cannot access host file paths (e.g. a remote or containerized MCP server). Requires 'filename'. Provide either 'file_path' or 'content_base64', not both.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.4.1
    • addedInput schema / additionalProperties
      Added value: +false
    • removedOutput schema / description
      Removed value: -"Generic wrapper for non-object return types."
  2. Changed5 schema fields changedv1.2.1
    • addedInput schema / properties / content_base64
      Added value: +{
      +  "default": null,
      +  "description": "(Optional) Base64-encoded file content to upload directly, without the server reading from disk. Use this when the server cannot access host file paths (e.g. a remote or containerized MCP server). Requires 'filename'. Provide either 'file_path' or 'content_base64', not both.",
      +  "type": "string"
      +}
    • addedInput schema / properties / file_path / default
      Added value: +null
    • changedInput schema / properties / file_path / description
      Previous value: -"Full path to the file to upload. Can be absolute (e.g., '/home/user/document.pdf' or 'C:\\Users\\name\\file.docx') or relative to the current working directory (e.g., './uploads/document.pdf'). If a file with the same name already exists, a new version will be created."New value: +"Full path to the file to upload. Can be absolute (e.g., '/home/user/document.pdf' or 'C:\\Users\\name\\file.docx') or relative to the current working directory (e.g., './uploads/document.pdf'). If a file with the same name already exists, a new version will be created. Requires the server to be able to read the path; for remote or containerized servers use 'content_base64' instead. Provide either 'file_path' or 'content_base64', not both."
    • addedInput schema / properties / filename
      Added value: +{
      +  "default": null,
      +  "description": "(Optional) Attachment filename, including extension (e.g. 'report.pdf'). Required when using 'content_base64'; it determines the attachment title and file type. Ignored when 'file_path' is used.",
      +  "type": "string"
      +}
    • changedInput schema / required
      Previous value: -[
      -  "content_id",
      -  "file_path"
      -]New value: +[
      +  "content_id"
      +]
  3. Addedv1.0.1

TDQS

A3.9/5.0
Behavior4/5

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

Adds genuine behavioral value beyond annotations: it discloses the upsert/versioning behavior ('if the attachment already exists, a new version is created') and the watcher-notification side effect of 'minor_edit'. These matter given destructiveHint=true and idempotentHint=false, and clarify that re-uploading is non-destructive versioning rather than replacement. It does not mention required Confluence permissions or size limits.

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?

Purpose is front-loaded in the first sentence, followed by the parameter-mode explanation and versioning note in a logical order. The trailing 'This is useful for' bullet list is three near-synonymous items that add little and could be dropped without information loss.

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

Completeness4/5

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

With a full output schema, complete annotation set, and 100%-documented parameters, the description covers what an agent still needs: the dual input mode, the mutual exclusion, and the versioning outcome. The one omission is the relationship to the plural 'confluence_upload_attachments' sibling, which matters for tool selection.

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 every parameter including the file_path vs content_base64 mutual exclusion is already documented in the schema. The description restates the either/or constraint but adds no format, path, or encoding detail beyond what the schema already says. Baseline 3 applies.

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?

Opens with a specific verb and resource: 'Upload an attachment to Confluence content (page or blog post)', which is unambiguous about the operation. However, a very close sibling named 'confluence_upload_attachments' (plural) exists in the toolset and the description never distinguishes this single-file tool from it, so an agent cannot route confidently without guessing.

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?

Gives clear contextual guidance for the key decision: use 'file_path' when the server can read disk, use 'content_base64' for remote/containerized servers, and 'exactly one of the two must be supplied'. The use-case bullets ('attaching documents, images...', 'updating existing attachments') are generic filler rather than real routing guidance. No mention of when to pick the batch sibling instead.

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

Deploy Server

Other Tools