Skip to main content
Glama
Sign In
immich-photo-manager

immich-photo-manager

by drolosoft
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Download archive

download_archive

Download an album or selected assets as one zip of original files to a local path, streamed to disk for large albums, with existing files never overwritten.

Instructions

Download an album or a selection as one zip of the original files, written to a local path. Use get_download_info first when the size matters. The file is streamed to disk (safe for big albums) and an existing file is never overwritten. Side effect: writes a file on the machine running the server.

Args:
    output_path: Where to write the zip (an existing file is refused).
    album_id: Download the whole album.
    asset_ids: Or download just these assets.

Returns: JSON with path, bytes written and how many assets went in, or an error.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "output_path": "<output_path>"
    },
    "name": "download_archive"
  }
}

Input Schema

NameRequiredDescriptionDefault
album_idNo
asset_idsNo
output_pathYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.0.2

TDQS

A4.5/5.0
Behavior5/5

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

Adds substantial behavior beyond the annotations: the file is streamed to disk so large albums are safe, an existing file is never overwritten, and the side effect of writing on the server machine is called out explicitly. The annotations (readOnlyHint=false, destructiveHint=false) are consistent with, and enriched by, these statements.

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?

Front-loaded with purpose and the key constraint (streaming, no overwrite) before the parameter and return details. The docstring-style 'Args:' block is slightly formulaic but earns its place given the empty schema descriptions; no filler sentences.

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 the write side effect, streaming safety, overwrite policy, and parameter roles for a tool that writes files to the server's disk. An output schema exists, so the one-line return summary is a bonus rather than a necessity; only the album_id/asset_ids interaction remains underspecified.

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?

With 0% schema description coverage the description must carry the parameters, and it documents all three: output_path with the refusal rule for existing files, album_id for a whole album, asset_ids for a selection. The gap is that mutual exclusivity of album_id vs. asset_ids, and what happens when neither is supplied (album_id defaults to empty string), is left unstated.

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?

States a specific verb and resource ('Download an album or a selection as one zip of the original files, written to a local path'), including the output form and destination. This clearly distinguishes it from sibling export tools like export_pdf and get_export_preview, which produce different artifacts.

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 an explicit precondition ('Use get_download_info first when the size matters') and clarifies the two operating modes, whole album via album_id vs. a subset via asset_ids. It stops short of comparing against the other export siblings (export_pdf, get_export_preview) that could plausibly be chosen 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