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

immich-photo-manager

by drolosoft
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

List memories

list_memories
Read-only

Fetch Immich 'on this day' memories from past years by date or saved status to build photo stories, albums, or PDFs; read-only.

Instructions

List memories — Immich's "on this day" collections of photos from past years. Use this to build a 'tal día como hoy' story, album or PDF: each memory carries the year it looks back to and the assets Immich picked for it. Read-only.

Args:
    for_date: ISO date — return the memories Immich shows on that day
        (e.g. today for the classic on-this-day feed). Omit for all memories.
    is_saved: If true, only memories the user saved; if false, only unsaved.
    size: Maximum memories to return (default 50).

Returns: JSON with total and a memories array; each has id, type, memory_at,
the year it remembers, is_saved, asset_count and a trimmed assets list
(id, filename, date).

Input Schema

NameRequiredDescriptionDefault
sizeNo
for_dateNo
is_savedNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.0.2

TDQS

A4.1/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description's "Read-only" only restates that. It does add genuine context — that each memory carries the year it looks back to and the assets Immich selected — but the detailed Returns block largely duplicates the output schema, and nothing is said about pagination or permission scope.

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?

Well structured with a purpose line followed by Args and Returns blocks, and the key scoping behavior (omit for_date for all) is stated up front. The Returns block is somewhat redundant given an output schema exists, but it is compact and earns most of its space.

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?

For a three-parameter, zero-required read-only tool with an output schema and read-only annotations, the description covers purpose, per-parameter meaning, and filtering behavior. The remaining gaps (date format specifics, null semantics for is_saved) are minor at this complexity level.

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 0%, so the description must carry the load, and it does: for_date is described as an ISO date with the semantic 'memories Immich shows on that day' plus an example, is_saved distinguishes saved-only from unsaved-only, and size is capped with its default. It could go further by stating the wire format (YYYY-MM-DD) and that omitting is_saved returns both, which is why it is a 4 rather than a 5.

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 and defines the domain concept precisely (Immich's "on this day" collections of photos from past years), which separates it from list_albums, list_assets, and list_stacks in the sibling list. An agent can identify the tool without opening the schema.

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 a concrete usage scenario (build a 'tal día como hoy' story, album or PDF) and states that omitting for_date returns all memories, plus the is_saved true/false filter behavior. It stops short of naming alternatives or stating when not to use it (e.g., versus list_albums or get_timeline_buckets), so it lands at clear context without exclusions.

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