Skip to main content
Glama

Create Media

create_media
Idempotent

Upload photos, scans, or PDFs from server upload folders as media records and attach them to people, families, events, places, sources, or citations, including selected image regions.

Instructions

Upload a photo, document scan or PDF from the server's upload folder as a new media record, and show it on people, families, events, places, sources or citations with attachTo, whole or as a region such as one record on a page scan. Only files inside GRAMPS_MEDIA_UPLOAD_DIRS can be uploaded, and a relative filePath is looked up in each of them in turn; the type (JPEG, PNG, GIF, WebP, TIFF, BMP or PDF) is judged by content. citationHandles cite where the file itself came from, while attachTo shows it on the records it documents, such as a citation with the region of its entry. If the tree already stores an identical file (same MD5 checksum), nothing is uploaded: that record is returned with action existing, its fields stay as they are and only attachTo is applied, so repeating a call is safe. Returns the handle and Gramps ID; an unreadable date or unknown attachTo record is rejected before anything is uploaded. It is the only tool that uploads a file: create_records takes no media, and a transcription of a document belongs in a note (create_note), not here. Change the record later, or swap its file, with update_media; check what a region shows with read_media. Writes run one at a time and need a Gramps Web account allowed to edit the tree; a locked or rate-limited write fails with the delay to wait before retrying it. Formats of every argument: get_reference(topic: "input-guide").

Input Schema

NameRequiredDescriptionDefault
dateNoDate of the photo or document. Date text: 1856-07-20, 1920-05, 1920, 1 Jul 1919, about/before/after 1920, 1800-1850, between … and …; append the calendar for other calendars, e.g. 1856-07-20 (Julian). Unreadable dates are rejected.
attachToNoRecords to show the media on, each getting a link after its existing media: Gramps IDs (I0001, F0001, E0001, P0001, S0001, C0001) or handles of people, families, events, places, sources or citations. JSON array, one value, or a comma-separated string. To show only part of the image, such as one record on a page scan, give an object {"ref":"I0001","region":[left, top, right, bottom]} in place of the ID. A region is [left, top, right, bottom]: its edges in percent of the image width and height, 0 to 100, measured from the top-left corner; [10, 20, 60, 45] runs from 10% to 60% across and from 20% to 45% down. A record already showing the media keeps its link and takes the region; list a record twice to show two regions. Check a region with read_media first.
filePathYesThe file to upload: an absolute path inside an upload folder, ~/…, or a name relative to the folder, e.g. scan.jpg.
isPrivateNoMark the media private (default false).
attributesNoAttributes. Attributes: JSON array of objects {type,value,...}, or strings "Type: Value" (first colon), or one string with lines or | between entries. A type must be a standard Gramps attribute type or a custom one the tree already uses; anything else is rejected with suggestions. Full grammar: gramps://input-guide.
tagHandlesNoTags. Handles, not Gramps IDs: JSON array ["h1","h2"], one handle, or a comma/semicolon/newline-separated string; entries may also be objects {"ref":"…"}.
descriptionNoDescription (caption). Default: the file name without its extension.
noteHandlesNoNotes. Handles, not Gramps IDs: JSON array ["h1","h2"], one handle, or a comma/semicolon/newline-separated string; entries may also be objects {"ref":"…"}.
citationHandlesNoCitations for the media itself. Handles, not Gramps IDs: JSON array ["h1","h2"], one handle, or a comma/semicolon/newline-separated string; entries may also be objects {"ref":"…"}.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations (readOnly=false, idempotent=true, destructive=false) the description discloses the upload directory restriction and lookup order, content-based format detection, MD5 dedup semantics (returns the existing record with action existing and applies only attachTo), pre-upload validation of dates and attachTo, serialized writes, edit permission requirement, and rate-limit retry delay. That is substantially more than the structured fields provide.

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

Conciseness4/5

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

A single dense paragraph, front-loaded with what the tool does and the upload constraint, with each sentence carrying real content. It is long, but the length is justified by the number of non-obvious behaviors; minor tightening would help readability.

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 9-parameter write tool with no output schema, the description covers return values (handle, Gramps ID, action existing), idempotency, failure modes, permissions, and cross-tool routing. Nothing an agent needs to call it correctly appears to be 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 goes further by explaining the relative-filePath lookup across upload dirs, the distinction between citationHandles (provenance of the file) and attachTo (where it is shown), and the duplicate-record region override behavior. Region semantics are also restated, though much of that already lives in the schema.

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?

Opens with a specific verb and resource ("Upload a photo, document scan or PDF ... as a new media record") and names the attach targets (people, families, events, places, sources, citations). An agent can distinguish it immediately from create_records and create_note, which it explicitly rules out.

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?

Explicitly states this is the only tool that uploads a file, that create_records takes no media and a transcription belongs in create_note, and routes follow-up work to update_media and read_media. When-to-use and when-not-to-use are both covered.

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