Skip to main content
Glama
Sign In

Editmamei Connect

by io.github.editmamei
OverviewDiscussionsAdmin

open_photo

Open a photo and get its image id, which every other tool uses. source is an upload handle "upload:" (from request_upload), the name of one of your uploads, or a public https:// image URL the server downloads itself (a photo share link works). It never opens a file path. Accepts JPEG, PNG, TIFF, WebP and HEIC, and RAW camera files on the larger workspace (the optional raw object sets white balance, exposure and highlights for a RAW file). A source can also be one of the built-in sample photos, listed by inspect what=uploads (sample:<name>, or its file name when none of your uploads has it). precision promotes bit depth before grading (16-bit only only up to a size limit that overview lists). At most 2 photos may be open at once. Uploads and open photos belong to this server; a photo opened through another Editmamei connector stays with that connector.

Input Schema

NameRequiredDescriptionDefault
rawNoOnly for a RAW camera file (an error for any other source): how it is developed. White balance, exposure and highlight recovery; each is optional.
sourceYes"upload:<upload_id>" as returned by the upload (the name of one of your uploads also works), or an https:// image URL.
precisionNoPromote bit depth on open. 'keep' leaves the file's own precision; '16' converts to 16-bit BEFORE any grading, which avoids banding from an aggressive tone move on an 8-bit source. On this server '16' is refused above a size limit (memory); overview lists it.keep

Output Schema

NameRequiredDescriptionDefault
imageNo
widthNo
heightNo
layersNo
base_typeNo
precisionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / raw
      Added value: +{
+  "description": "Only for a RAW camera file (an error for any other source): how it is developed. White balance, exposure and highlight recovery; each is optional.",
+  "properties": {
+    "exposure": {
+      "default": 0,
+      "description": "Exposure change in stops, -2 to +3.",
+      "maximum": 3,
+      "minimum": -2,
+      "type": "number"
+    },
+    "highlights": {
+      "default": "blend",
+      "description": "'clip' cuts blown highlights, 'blend' softens them into the surroundings, 'rebuild' tries to reconstruct them.",
+      "enum": [
+        "clip",
+        "blend",
+        "rebuild"
+      ],
+      "type": "string"
+    },
+    "white_balance": {
+      "default": "camera",
+      "description": "'camera' uses the white balance the camera recorded, 'auto' averages the whole picture.",
+      "enum": [
+        "camera",
+        "auto"
+      ],
+      "type": "string"
+    }
+  },
+  "type": "object"
+}
  2. Changed1 schema field changed
    • changedInput schema / properties / precision / description
      Previous value: -"Promote bit depth on open. 'keep' leaves the file's own precision; '16' converts to 16-bit BEFORE any grading, which avoids banding from an aggressive tone move on an 8-bit source. On this server '16' is refused above 12.2 MP (memory)."New value: +"Promote bit depth on open. 'keep' leaves the file's own precision; '16' converts to 16-bit BEFORE any grading, which avoids banding from an aggressive tone move on an 8-bit source. On this server '16' is refused above a size limit (memory); overview lists it."
  3. Changed1 schema field changed
    • changedInput schema / properties / precision / description
      Previous value: -"Promote bit depth on open. 'keep' leaves the file's own precision; '16' converts to 16-bit BEFORE any grading, which avoids banding from an aggressive tone move on an 8-bit source. On this server '16' is refused above 12 MP (memory)."New value: +"Promote bit depth on open. 'keep' leaves the file's own precision; '16' converts to 16-bit BEFORE any grading, which avoids banding from an aggressive tone move on an 8-bit source. On this server '16' is refused above 12.2 MP (memory)."
  4. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already flag this as a non-read-only, non-idempotent, open-world operation, so the bar is lower. The description adds real behavioral context beyond them: the two-photos-open-at-once limit, cross-connector scoping ('a photo opened through another Editmamei connector stays with that connector'), supported format list, and that RAW is restricted to the larger workspace.

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?

The essential purpose is front-loaded in the first sentence, and the remaining sentences each carry functional detail (formats, limits, scoping). It is dense but not padded, though a couple of clauses are run-on and could be tightened.

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?

With an output schema present, return values need not be explained, and the description covers the full operational surface for a 3-param tool with a nested object: sources, formats, RAW development, precision, concurrency cap, and server scoping. Nothing an agent needs to call it correctly 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 still adds meaning: the accepted `source` forms (upload handle, upload name, public https URL, `sample:<name>`), that `raw` errors for non-RAW sources, and that `precision` promotes bit depth before grading. These go beyond the schema text.

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 ('Open a photo') plus its key output ('get its image id, which every other tool uses'), which immediately distinguishes it from siblings like close_photo, request_upload, and inspect. The role in the workflow is unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives strong context on what qualifies as a `source`, routes the agent to `request_upload` for upload handles and to `inspect what=uploads` for sample photos, and states an exclusion ('It never opens a file path'). It stops short of an explicit 'use this before adjusting/exporting' sequencing statement, but the routing guidance is clear.

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

All Editmamei Connect toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources