collections-management

Collections Management

Ideogram lets you group images into named collections via create_collection, list_collections, add_images_to_collection, remove_images_from_collection, rename_collection, delete_collection, and get_images_by_collection_id. This skill orchestrates those calls in sequence to keep a project's images organized instead of scattered across loose generations that have to be re-found later by scrolling get_recent_generations.

This is an orchestration workflow across sequential MCP calls, not a prompt-composition skill — there's no composition-spec-format.md/panel-anatomy.md-style reference here. Flat collections are the only supported structure in v1: create_collection and list_collections both support nesting via parent_collection_id, but this skill never sets or reads that field.

Before you start

Read references/collection-patterns.md before creating or deleting anything. It covers the find-or-create pattern (why you must check list_collections for a name match before calling create_collection) and the destructive-confirmation rule (when delete=True and delete_assets=True are safe to pass). Both apply before you touch step 1 or step 5 below.

Workflow

1. Resolve the collection

Call list_collections (root-level only, since v1 is flat) and check for a name match before creating anything new. Exactly one match → use that collection. Multiple ambiguous matches (same name or close variants) → ask the user which one they mean, don't guess. No match → call create_collection(name). See references/collection-patterns.md for why this check has to happen before create — create_collection doesn't enforce unique names, so skipping this step produces duplicate collections across sessions.

2. Add images

Call add_images_to_collection(collection_id, image_response_ids=[...]) for images generated earlier this session (from generate_image's structured_content.response_ids), or image_upload_ids=[...] for previously uploaded images. Batch every image from the current task into one call — don't loop one call per image. Read the response's added_count, failed_count, and any per-asset failure reasons, and report real failures instead of claiming the add fully succeeded.