Skip to main content
Glama
Sign In
atlassian-browser-mcp

atlassian-browser-mcp

by GeiserX
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Get Content Attachments

confluence_get_attachments
Read-onlyIdempotent

Lists all attachments for a Confluence page or blog post and returns IDs, file metadata, download URLs, dates, and version details for discovery or download operations.

Instructions

List all attachments for a Confluence content item (page or blog post).

Returns metadata about attachments including:

  • Attachment ID, title, and file type

  • File size and download URL

  • Creation/modification dates

  • Version information

Important: Confluence API returns 'application/octet-stream' as the media type for most binary files (PNG, JPG, PDF) instead of specific types like 'image/png'. For filtering by file type, using the 'filename' parameter is more reliable (e.g., filename='*.png' pattern matching if supported, or exact filename).

Useful for:

  • Discovering what files are attached to a page

  • Getting attachment IDs for download operations

  • Checking if a specific file exists

  • Listing images/documents for processing

Input Schema

NameRequiredDescriptionDefault
limitNo(Optional) Maximum number of attachments to return per request (1-100). Use pagination (start/limit) for large attachment lists. Default: 50
startNo(Optional) Starting index for pagination. Use 0 for the first page. To get the next page, add the 'limit' value to 'start'. Default: 0
filenameNo(Optional) Filter results to only attachments matching this filename. Exact match only. Example: 'report.pdf'
content_idYesThe ID of the Confluence content (page or blog post) to list attachments for. Example: '123456789'
media_typeNo(Optional) Filter by MIME type. **Note**: Confluence API returns 'application/octet-stream' for most binary files (PNG, JPG, PDF) instead of specific MIME types like 'image/png'. For more reliable filtering, use the 'filename' parameter. Examples: 'application/octet-stream' (binary files), 'application/pdf', 'application/vnd.openxmlformats-officedocument.wordprocessingml.document' (for .docx)

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. Addedv1.0.1

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, open-world, and non-destructive, so the safety profile is covered. The description adds genuinely non-obvious behavioral context: that the API reports 'application/octet-stream' for most binaries, making media_type filtering unreliable, plus pagination expectations for large lists. It does not discuss permissions or rate limits, but the octet-stream caveat is a real value-add.

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 purpose is front-loaded in sentence one, and the caveat is bolded for prominence. The four-bullet metadata list is partly redundant with the existing output schema, and the hedged glob suggestion adds mild noise, but overall the structure is 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?

With an output schema present, the description needn't enumerate return fields, and it is complete enough on filtering and pagination for an agent to call correctly. The only weak spot is the unresolved '*.png pattern matching if supported' claim, which leaves an agent unsure whether wildcard filtering actually works.

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 3 is the baseline, but the description goes further by explaining the practical unreliability of media_type and steering toward filename matching instead. That is semantic guidance beyond the schema's own note, though the example '*.png pattern matching if supported' is hedged and left unresolved.

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 first sentence states a specific verb and resource — 'List all attachments for a Confluence content item (page or blog post)' — and scopes the content type. It is clearly distinguishable from siblings like confluence_download_attachment or confluence_get_page_images, which operate on the returned attachments rather than enumerating them.

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?

A 'Useful for' list gives four concrete scenarios (discovering files, getting IDs for download, existence checks, listing for processing), which covers when to reach for this tool. It stops short of naming explicit alternatives or exclusions — e.g. it does not say to use confluence_download_attachment once IDs are known, or how it differs from confluence_get_page_images.

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