Skip to main content
Glama

export_pdf

Build a PDF from an Immich album or selected photos/videos, embedding dates, places, camera details, people, and tags. Add captions with your analysis; video frames are included directly in the PDF.

Instructions

Build a PDF (cover, index, places, one section per asset) from an album or a list of assets, on the machine running this server. Immich metadata (date, place, camera, people, tags) is always included; pass captions {asset_id: text} with what you saw to add your analysis. Video frames go straight into the PDF and cost no tokens (up to 120 per video). The PDF never enters the conversation unless return_base64=True. If the user asked for a PDF without saying how they want it, call get_export_preview first and ask them about the choices it lists.

Keep the selection coherent: one story per PDF. Never mix unrelated assets
(two videos about different things, photos from different events) just to
show more; if the user's material spans several stories, offer one PDF per
story instead.

Args:
    album_id: Album UUID, or asset_ids: explicit asset UUIDs (exactly one of the two).
    output_path: Where to write (default ~/Desktop/<title>.pdf). Existing files are never overwritten.
    title: Cover title (default: album name or "Immich export <date>").
    captions: {asset_id: text} written after looking at the images.
    layout: 'detail' (one asset per page with its data, default), 'grid' (six per page)
        or 'photobook' (one asset per page, image as large as it fits, caption under
        it; a video with several chosen frames unfolds into one full page per frame).
    frames_per_video: Frames per video, evenly spaced (0-120, default 4; 0 = poster only).
    frame_interval: One frame every N seconds instead of frames_per_video (same 120 cap).
    frame_times: {asset_id: [seconds, ...]} exact moments for specific videos, chosen
        after looking at their frames ("the representative frame"). Wins over
        frames_per_video/frame_interval for the listed videos; others keep the spread.
    frame_captions: {asset_id: [text, ...]} one caption per extracted frame, in frame
        order (photobook prints each on its frame's page; other layouts ignore them).
    image_size: 'original' (default): photos go in at the stored file's quality,
        re-encoded to at most 3000px (a format the server cannot decode, like
        some HEIC, falls back to preview with a note); 'preview' (1440px) or
        'thumbnail' for smaller files.
    frame_size: video frame size in the PDF: 'auto' (default, same as 'preview':
        quality is free inside the PDF) or 'thumbnail' for a smaller file.
    language: 'en' (default) or 'es' for the fixed labels on the pages (Index,
        Places, Camera, page numbers); captions stay in whatever language you wrote.
    map: Draw an OpenStreetMap map on the Places page when assets carry GPS
        (default True; tiles come from tile.openstreetmap.org, the only
        third-party call this server makes — pass map=False to skip it).
    cover, index, places: Include each front-matter page (all default True;
        turn them off for a print-ready photobook of bare pages).
    footer: 'full' (plugin name, server and page number, default), 'pages'
        (just the page number) or 'none'.
    header: Repeat the title at the top of every page except the cover
        (default False).
    videos_position: Where the video pages (frame strips or frame pages) go:
        'mixed' with the photos in the general order (default), 'first' or 'last'.
    order: 'auto' (albums read oldest to newest, like the frames inside a video;
        asset_ids keep the order you passed), 'oldest', 'newest' or 'given'.
    confirm: Only asked for when explicit asset_ids mix videos more than 90 days
        apart (different stories). Pass True only when the user themselves asked
        to mix them; exporting a whole album never needs it.
    limit: Max assets (1-500, default 100).
    return_base64: Also return the PDF bytes (skipped above 2 MB; every MB is
        roughly 350k tokens in the conversation).

Returns: JSON {path, pages, bytes, assets_included, assets_skipped:[{id, reason}], warnings:[...]}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
mapNo
coverNo
indexNo
limitNo
orderNoauto
titleNo
footerNofull
headerNo
layoutNodetail
placesNo
confirmNo
album_idNo
captionsNo
languageNoen
asset_idsNo
frame_sizeNoauto
image_sizeNooriginal
frame_timesNo
output_pathNo
return_base64No
frame_captionsNo
frame_intervalNo
videos_positionNomixed
frames_per_videoNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Install Server

TDQS

A5/5.0
Behavior5/5

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

With no annotations, the description carries the full burden, and it does: PDFs are written to disk, existing files are never overwritten, the PDF never enters the conversation unless return_base64=True, video frames cost no tokens, the map uses a third-party OSM tile server, and undeciable formats fall back to preview. Side effects, costs, and failure/fallback behavior are all disclosed.

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?

Though long, the structure is efficient: purpose first, then key behavioral notes, then usage guidance, then a well-grouped argument list. Every sentence adds information an agent needs; nothing is redundant with the schema since the schema has no descriptions. The length is justified by the tool's 24-parameter complexity.

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

Completeness5/5

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

The description covers the two mutually exclusive selectors, all defaults, the return JSON shape, edge cases (HEIC fallback, video frame cap, 2 MB base64 limit, third-party map call), language options, and the one-story-per-PDF rule. Combined with the schema defaults and the described output object, an agent has everything needed to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must fully explain the 24 parameters, and it does in detail. It clarifies defaults, mutual exclusivity (album_id vs asset_ids), parameter interactions (frame_times wins over frames_per_video/frame_interval; frame_captions only matter in photobook layout), numeric bounds (0-120, 1-500), and the meaning of each enum-like string (layout, order, footer, etc.).

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 exactly what the tool does: 'Build a PDF (cover, index, places, one section per asset) from an album or a list of assets' with the location ('on the machine running this server'). It also names the sibling get_export_preview and explicitly says to call it first when the user hasn't specified choices, so the agent can distinguish this tool from that one.

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?

The description gives explicit guidance: call get_export_preview first if the user asked for a PDF without specifying how; keep one story per PDF; offer one PDF per story rather than mixing unrelated assets; and when confirm is required (explicit assets mixing videos more than 90 days apart), only pass True if the user explicitly asked. This is direct, actionable usage guidance with clear alternatives and exclusions.

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

Other Tools

Latest Blog Posts

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/drolosoft/immich-photo-manager'

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