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

immich-photo-manager

by drolosoft
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Review assets

review_assets

Record a keep, delete, duplicate, or check verdict and its reason on Immich assets so later cleanup or duplicate passes reuse the decision instead of repeating analysis.

Instructions

Remember a review verdict on assets, with the reason, so a later session does not redo the analysis and the why survives. Use this after deciding what to do with a photo in a cleanup or duplicate pass — together with a tag when the user must see the state in Immich (tags are visible there, notes are not). Side effect: writes the plugin's metadata key on each asset; other apps' keys are untouched.

Args:
    asset_ids: The assets the verdict applies to.
    verdict: One of 'keep', 'delete_candidate', 'duplicate_of', 'needs_check'.
    reason: Free text explaining the verdict (e.g. 'near-identical to IMG_6367,
        keep that one'). Short and concrete beats long.

Returns: JSON with success, the number of assets reviewed, the verdict, and a
failed array of {asset_id, error} for any asset that could not be written.
Success is true only when nothing failed.

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": {
      "asset_ids": "<asset_ids>",
      "verdict": "<verdict>"
    },
    "name": "review_assets"
  }
}

Input Schema

NameRequiredDescriptionDefault
reasonNo
verdictYes
asset_idsYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.0.2

TDQS

A4.1/5.0
Behavior5/5

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

The annotations only say readOnlyHint=false and destructiveHint=false, which does not tell an agent that this writes scoped plugin metadata while leaving other apps' keys intact. The description discloses that side effect plus partial-failure semantics: success is true only when nothing failed, and per-asset errors come back in a failed array. That is meaningful behavior beyond the structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The intent sentence is front-loaded and useful, but the closing 'Returns:' block largely restates what the output schema already provides, and the rationale clause about later sessions is longer than needed. Formatting into Args/Returns sections is readable but adds bulk for a three-parameter tool.

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 metadata-writing tool this covers what matters: the scoped write side effect, the verdict vocabulary, the reason guidance, and failure reporting. The restatement of return values is redundant given the output schema, but nothing an agent needs to call it correctly is missing.

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 description coverage is 0%, so the description carries the parameter burden and mostly does: it enumerates the four verdict values (not available as an enum in the schema), explains that reason is free text with a worked example and a preference for short concrete wording, and says asset_ids are the assets the verdict applies to. The asset_ids explanation is thin about format or batching expectations, but the enum disclosure alone is a substantial add.

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?

States a specific verb and resource: 'Remember a review verdict on assets, with the reason'. The description also implicitly separates it from tag_assets by explaining that tags are the visible counterpart to this plugin-side note. It never names a sibling tool outright, so an agent must infer the boundary rather than read it.

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?

'Use this after deciding what to do with a photo in a cleanup or duplicate pass' gives a concrete triggering situation, and the tag pairing clause explains the alternative (tag_assets) and the condition that selects it. There is no explicit statement of when not to use it, such as an already-recorded verdict or assets outside a review pass.

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