Skip to main content
Glama
sweetrb

apple-photos-mcp

by sweetrb

create-album

Create a new album to file photos into, optionally nested under a folder path. Reuses an existing album with the same name instead of creating a duplicate.

Instructions

Use when: you need an album to file photos into — a new album by name, optionally nested inside a folder path (e.g. for a quarantine album before a dedupe review, or a per-trip album). Returns: album {uuid, name, path} and created — false means an album of that name already existed and was returned instead of creating a duplicate (idempotent: safe to re-run; without folder the name is matched anywhere in the library, with folder only inside that folder). Do not use when: you want to list existing albums — use list-albums; or you want to put photos into the album — follow up with add-to-album. Safety: WRITE tool — disabled unless APPLE_PHOTOS_MCP_ENABLE_WRITES=1 (run doctor to check). Only creates albums/folders; never deletes, moves, or modifies photos. Drives Photos.app via AppleScript: Photos is launched if not running, and macOS Automation permission is required (one-time system prompt on first write). Writes always target the library currently open in Photos.app — there is no library parameter.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesAlbum name
folderNoFolder path to nest the album under, "/"-separated for nesting (e.g. "Trips/2026"); folders are created as needed

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
albumNo
createdNo
Behavior5/5

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

With no annotations provided, the description fully discloses key behavioral traits: it is a WRITE tool requiring an environment variable, it only creates albums/folders, it never destroys or modifies other data, it drives Photos.app via AppleScript, may launch Photos, requires macOS Automation permission, and targets the currently open library. It also explains idempotent behavior and return semantics, providing substantial transparency beyond the schema.

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?

The description is well-structured into labeled sections (Use when, Returns, Do not use when, Safety) with no wasted words. Each sentence serves a distinct purpose, and the front-loaded use case makes it easy to scan.

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 use cases, exclusions, return values, safety, side effects, and environmental requirements. Despite having an output schema, it still explains the 'created' flag and idempotent behavior. It is complete for a write tool with this complexity.

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, but the description adds meaningful context for the 'name' parameter (matching behavior without folder vs with folder) and clarifies the 'folder' parameter with an example path structure. This goes beyond the schema's brief descriptions, enriching the semantics.

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 description clearly states the tool's purpose: creating a new album by name, optionally nested in a folder. It distinguishes itself from siblings by explicitly naming list-albums and add-to-album as alternatives for different needs.

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 provides explicit 'Use when' and 'Do not use when' guidance, including concrete examples (quarantine album, per-trip album) and direct references to alternative tools (list-albums, add-to-album). This leaves no ambiguity about when to select this tool.

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

Install Server

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/sweetrb/apple-photos-mcp'

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