Skip to main content
Glama
cmeans

mcp-synology

edit_photo

Destructive

Modify Synology Photos items by updating rating, description, taken time, rotation, or favorite status for specified IDs; pass only the fields you want to change.

Instructions

Edit Synology Photos items: rating, description, taken time (set or shift), rotation and favorite (Photos 1.9.1+). Pass only the fields to change; they apply to every id given. Photos writes these into the original files, so file dates and sizes change. Location can't be edited; for tags use tag_photos.

Input Schema

NameRequiredDescriptionDefault
idsYesItem IDs from list_photos, at most 1,000 per call.
spaceNo`personal` (default) or `shared` (Shared Space). IDs belong to one space.personal
ratingNo0-5; `0` clears the rating.
rotateNo`left` or `right`; a repeat rotates again.
favoriteNo`true` marks favorite, `false` unmarks (Photos 1.9.1+).
taken_timeNoLocal date-time such as `2024-07-04T19:30:00`; an offset is dropped, not converted. Not with `shift_hours`.
descriptionNoNew description; `""` clears it, and one of only spaces shows as `—`, like none.
shift_hoursNoShifts the taken time by hours (`-6`, `1.5`); a repeat shifts again.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.9.2

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already flag destructiveHint=true and readOnlyHint=false, but the description adds context the annotations cannot: edits are written into the original files, so file dates and sizes change, and favorite requires Photos 1.9.1+. It also documents repeat-behavior for rotate and shift_hours. That is substantive added value 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.

Conciseness5/5

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

Three tight sentences with zero filler. The editable-field list, the mutation warning, and the routing to tag_photos are front-loaded in that order, so the most decision-relevant information comes first.

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?

For a destructive, multi-parameter mutation tool with no output schema, the description covers what changes, what is irreversible (original files modified), what is out of scope, and where to go for tags. Nothing an agent needs before calling 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 coverage is 100%, so the baseline is 3; the description earns an extra point by stating cross-parameter semantics the schema can only partially convey: fields apply uniformly to every id, and taken_time vs shift_hours are mutually exclusive alternatives. It stops short of explaining the space/id coupling, which the schema handles alone.

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 ('Edit Synology Photos items') and enumerates exactly which attributes are editable (rating, description, taken time, rotation, favorite). It also names the sibling tag_photos and explicitly excludes location, so an agent can distinguish it from neighboring photo tools without opening any schema.

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?

Gives concrete invocation guidance: 'Pass only the fields to change; they apply to every id given,' plus explicit exclusions — location can't be edited and tags must go through tag_photos. That is when-to-use, how-to-use, and when-to-use-something-else in one short block.

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