auto-photos5.86 KB
View saved version →
---
name: auto-photos
description: Search and display photos from the user's photo library / camera roll through the Auto MCP plugin. Use when the user explicitly asks to find, browse, show, or view "my photos," "my pictures," or otherwise clearly refers to their own photo library, including searches by subject, visible detail, scene, activity, mood, date or date range, location, or a combination of these. Also use when Auto or this skill is explicitly invoked, and for follow-ups referring to a photo or photo set previously returned by Auto. Do not use for generic requests such as "show me pictures of New York" that do not indicate the user's own photos; those should use ordinary image search instead.
---
# Auto photos
Use the connected Auto MCP tools for the user's photo request. Tool names below are the server's logical names; use the matching tools exposed by the host. Follow the user's requested scope and the live tool schemas.
## Identify the library and provide setup help
- Call `get_info` when the user asks what Auto can do, when a search or list returns no pictures, or when a tool reports `not_enrolled` or `no_photos`.
- Use `get_info.result.app` or the search/list `source` to distinguish `auto_photos` (the synced camera roll in Auto Photos) from `auto` (pictures captured in Auto). Auto captures have no albums or screenshots, and their search matches descriptions only: `words` join the query and a `place` searches the area it covers.
- If the library is empty or syncing is off, explain the returned `help` and use the returned `installUrl` and `installChannel` for installation guidance. An Auto user can still search and view existing captures with `syncEnabled: false`; explain that syncing and albums require Auto Photos when relevant.
- If photos exist but the filters find nothing, explain that no matching photos were found. Do not describe the entire library as empty or silently discard the user's filters.
## Find and show pictures
- Use `search_images` for anything about what the pictures show, text written in them, where or when they were taken, or any combination. Use `list_images` only to browse the most recent pictures, or a known album, with no other criteria.
- `search_images` takes a structured query. Put each part of the request in its own parameter, and combine them as the request does:
- `query`: what the pictures show, in plain words ("dog on the beach", "receipts", "whiteboard notes"). Leave dates, places and exact text out of it. It is matched against what the picture itself looks like, and only close matches come back, so a search can return nothing.
- `words`: text that must be visible in the picture itself, read from it exactly: a name on a sign, a store on a receipt, a code on a screen. Every word must appear, so use it only when the user asks for that text; descriptive words belong in `query`.
- `startDate` and `endDate`: UTC ISO 8601 timestamps. Convert the user's dates using their known time zone, and make `endDate` the end of the last day.
- `place`: where the pictures were taken, as a place name: a country, region, city, neighborhood or landmark ("Japan", "California", "Lisbon", "Brooklyn", "Golden Gate Park"). The server resolves it, so do not convert it to coordinates. Use `latitude`, `longitude` and `radiusMeters` only for a spot with no name or for coordinates the user gives.
- `albumId` to search one album (resolve an album name with `list_albums`; ask if several fit) and `screenshot: true` to keep only screenshots. Search cannot leave screenshots out, so never send `screenshot: false`.
- Leave `channels` unset.
- A search without `query` returns the matching pictures newest first, so "photos from Lisbon last July" needs only `place` and the dates. Filters apply before ranking.
- Read `notes` in the result for anything that could not be applied, such as a place that was not found; each result's `placeLabel` shows where it was taken. When a search comes back empty or weak, adjust it once or twice (a broader `query`, another name for the place, wider dates, no `words`) before saying nothing matched. Clarify missing dates or places when they materially change the results.
- `matchedTerms` lists the `words` each picture contains.
- Search and list results contain metadata. When the user wants to see photos, pass returned IDs to `display_image` for one, `display_images_grid` for several, or `display_images_carousel` for a small set to swipe through. Preserve any requested ordering.
- Use `get_image` when metadata is needed. Use `get_image_bytes` sparingly when the model must inspect pixels; displaying a photo alone does not provide its pixels to the model. Ground visual claims in inspected pixels or identify them as based on returned descriptions.
- Respect each tool's limits. Results are the best matches up to `limit` (at most 100); describe a limited result set as such, and do not claim it covers every matching photo. Use only IDs returned by the tools or explicitly supplied by the user.
## Organize pictures into albums
- Make album changes when requested. For a new or named destination, `create_album` with a title and selected `imageIds` creates the album or reuses an existing album with that title. Use `add_images_to_album` for a known destination album ID.
- Use `rename_album`, `set_album_cover`, `remove_images_from_album`, or `delete_album` for the requested operation. A cover picture must already belong to the album. Resolve ambiguous targets before changing them; deleting an explicitly identified album needs no additional conversational confirmation.
- Batch IDs within the live schema limits. Inspect `added`, `removed`, and `missing` before reporting completion; explain partial results. Removing pictures from an album or deleting an album leaves the pictures in the library.
- If the library source is `auto`, explain that album organization requires Auto Photos and provide relevant setup help. Do not claim the operation succeeded.
