This server enables AI agents to manage and non-destructively edit photos through a comprehensive set of tools.
Library Management: Open a photo library from a local folder (set_library), list images with filters like rating, flag, edit status, sorting, and pagination (list_images), retrieve full metadata for an image (get_image), and get the image currently selected in the web UI (get_current_image).
Metadata Editing: Set star ratings (set_rating), flags as pick/reject/unflagged (set_flag), add/edit/list keywords and color labels, and perform batch updates for ratings, flags, labels, and keywords.
Non-Destructive Editing: Work with edit recipes: fetch (get_recipe), merge-patch changes (update_recipe), replace entirely (set_recipe), or reset to original (reset_recipe). Auto-calculate white balance, tone, and vibrance adjustments (auto_adjust). Apply detailed per-image edits including white balance (temperature, tint), tone (exposure, contrast, highlights, shadows, whites, blacks, curves), color (saturation, vibrance, HSL, color grading), detail (sharpening, noise reduction), geometry (rotate, flip, crop, aspect ratio), and effects (vignette, grain). Create and manage local adjustments using linear, radial, luminance, and color range masks. Save, apply, list, and delete named develop presets.
Preview & Export: Render a JPEG preview with all edits applied (render_preview), export the final image as an sRGB JPEG with configurable quality and resizing (export_image), and batch-export multiple images.
Schema Access: Retrieve the complete JSON schema for all recipe parameters and their valid ranges (get_recipe_schema).
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@viberoom open ~/Photos/shoot, reject blurry, rate keepers, warm up by 500K, export picks at 85."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Viberoom is a RAW photo manager and non-destructive editor you can drive by hand or by agent. Edit with the full develop UI in the browser — or tell Claude Code "reject the blurry ones, warm up the sunsets, export the picks" and it happens through MCP, REST, or plain JSON sidecar files.
🧾 Non-destructive, always. Every edit is a readable photo.CR3.vibe.json
next to the original. Delete the sidecar, get your pixels back.
📷 Real RAW. LibRaw decoding (CR2/CR3, NEF, ARW, RAF, DNG, …) plus JPEG/PNG/TIFF/HEIC.
🎛️ The whole develop kit — in the UI and the API. WB, tone, curves, HSL, color grading, LUTs, sharpening/NR, lens & perspective corrections, heal/clone, grain — and local masks: gradients, luminance/color ranges, brushes, AI subject/sky masks. Everything the API can do is reachable from the interface, and vice versa.
🤖 Bring your own agent. The app is a PWA that exposes its tools to
whatever agent your browser provides, via WebMCP — it no longer launches an
agent of its own. Outside the browser, viberoom-mcp drives it from Claude
Code.
🗂️ DAM things. Ratings, flags, labels, keywords, collections (smart too), stacks, dupes, history, snapshots, virtual copies, multi-folder catalogs.
📥 In and out. Card ingest, tethered capture, HDR & pano merge, ML
enhance (viberoom[ml]), XMP interop, batch everything, color-managed
export (sRGB → ProPhoto) with watermarks and soft proofing.
Version | Why | |
Python | 3.12+ |
|
Node | 20.19+ or 22.12+ | what Vite 8 requires |
pnpm | 10+ |
|
any recent | resolves and runs the backend |
Nothing else. LibRaw and the image codecs arrive inside the rawpy and Pillow
wheels, so there's no Homebrew/apt step and no compiler needed for the web app.
git clone https://github.com/RatulMaharaj/viberoom.git
cd viberoom
uv sync # backend deps into .venv (uv installs Python if missing)
pnpm --dir frontend install
pnpm --dir frontend build # typechecks, then writes frontend/dist
uv run viberoom # UI + API → http://127.0.0.1:8423Open it, point it at a folder of photos. That's it — no database to provision, no config file.
Optional extras:
uv sync --extra ml # AI subject/sky masks, face detection, ML enhance
# (onnxruntime + rembg; weights download on first use)Other ways to run:
uv run dev # hacking: backend --reload + Vite (:7666 "ROOM" → :8423 "VIBE")If something's off: pnpm build failing on syntax that looks fine usually
means Node is below the Vite floor (node -v), and a uv sync that resolves
oddly usually means an old uv (uv self update). The frontend must be built at
least once — without frontend/dist the backend serves the API but no UI.
Related MCP server: CoreViz MCP
The frontend is also a standalone progressive web app: it reads your photo folder straight off disk with the File System Access API, decodes RAW with LibRaw compiled to WebAssembly, and develops on the GPU. Nothing is uploaded — there is no server to upload to. Sidecars and thumbnails are written back into your own folder and its browser-local cache.
Chrome or Edge, on desktop. Safari, Firefox and every browser on iOS lack the File System Access API; the app says so up front rather than failing halfway in.
Install it from the address-bar install icon to get a standalone window.
Offline. A service worker precaches the app shell, and the LibRaw wasm is cached the first time a RAW is decoded, so a second visit works with no network at all.
Updates ship by pushing to main: the host rebuilds and deploys the
static site, and open tabs get a "a new version of Viberoom is ready"
prompt instead of silently running last month's build.
Browsing, rating, flagging, EXIF filtering and sorting, RAW decode and thumbnails, the whole develop panel, auto-adjust, crop and straighten, virtual copies (created, viewed and promoted from the filmstrip), copy/paste of develop settings, and export to JPEG or PNG. The GPU renders tone, colour, HSL, grading, blurs, clarity, dehaze, lens corrections, geometry, LUTs and masks — checked against the Python engine at the float32 noise floor across 89 parity cases.
RAW decoding matches the desktop app closely: Apple DNG differs by 1 part in 65535, Canon CR3, Sony ARW and Nikon NEF by around a hundredth of that.
Some of this is a browser limit; most of it is simply unbuilt. The app never guesses — a photo whose edits it cannot draw shows the original with a badge, and export refuses by name and reason rather than writing a file missing your edits.
Why | Could the browser do it? | |
Claude Code sidebar | A page cannot start a process | No. Use WebMCP with a browser agent, or |
Tethered capture | Needs USB and a camera SDK | No |
X3F (Sigma Foveon) | Absent from the WebAssembly LibRaw build | Yes, with a rebuilt binary |
Retouch (heal/clone) | Per-spot work, sequentially dependent | Yes, but it is a real project |
AI subject masks | Needs a segmentation network | Yes, via onnxruntime-web |
Grain, sharpening, defringe | Unported shader work; defringe needs a whole-frame reduction | Yes, defringe least easily |
16-bit PNG, TIFF, ICC profiles | Unbuilt encoders | Yes |
Watermarks, output sharpening | Unbuilt | Yes |
Collections, stacks, duplicates | Catalog features, no browser store yet | Yes |
Face detection, HDR/pano merge | Server-side compute | Yes, with more wasm |
The short version: the only permanent limits are the ones that need a process or a USB device. Everything else is work someone has not done yet.
The build is a static site — no server, no functions, nothing to run.
wrangler.toml points Cloudflare at the built files and turns on SPA routing,
so /edit/<id> survives a reload. Cache headers live in
frontend/public/_headers, beside the app, so they travel with it.
On a host without an SPA setting of its own — Netlify, for instance — add
/* /index.html 200 to frontend/public/_redirects. Do not ship both:
Cloudflare serves the shell and the catch-all rule then matches that too,
which it rejects as an infinite loop.
Leave Root directory empty, so the paths below match wrangler.toml:
Setting | Value |
Build command |
|
Deploy command |
|
Cloudflare treats a repository containing wrangler.toml as a Workers project
and runs wrangler deploy, so the config uses [assets] rather than the older
Pages key — a static site is served the same way either route.
Only a subpath deploy needs VITE_BASE — / is the default and is what a
domain root wants:
VITE_BASE=/viberoom/ pnpm --dir frontend build # e.g. GitHub Pagesclaude mcp add --transport http viberoom http://127.0.0.1:8423/mcpThe MCP server is mounted on the viberoom server itself — just a URL, no paths
to keep in sync. ~45 tools, from list_images to update_recipe (the
workhorse merge-patch) to render_preview — which returns the rendered image,
so the agent can look at its own edits and iterate. Then just talk:
"Open ~/Photos/shoot-42, reject anything blurry, rate the keepers, warm the sunset shots by 500K with +0.3 EV, and export all picks at quality 85."
Prefer HTTP? Everything is REST under /api/v1 (docs at /api/v1/docs):
curl 'localhost:8423/api/v1/images?rating_gte=4&flag=pick'
curl -X PATCH localhost:8423/api/v1/images/<id>/recipe \
-d '{"tone": {"exposure": 0.5}}' -H 'Content-Type: application/json'Prefer files? Edit the .vibe.json sidecar directly and POST /library/scan:
{
"rating": 4,
"flag": "pick",
"recipe": {
"whiteBalance": { "temp": 6500 },
"tone": { "exposure": 0.5, "clarity": 15 },
"masks": [{ "type": "radial", "center": [0.5, 0.4], "radiusX": 0.3,
"radiusY": 0.25, "adjustments": { "exposure": 0.6 } }]
}
}The full recipe grammar (every param, range, and the pipeline order) is one
call away: GET /api/v1/recipe/schema — or the get_recipe_schema MCP tool.
The math is Lightroom-like, not a clone.
viberoom-bench keeps the pipeline honest, cheapest check first:
uv run viberoom-bench regress # 26 recipes vs a pinned baseline; the CI gate.
# catches a 0.5% exposure drift in <1s
uv run viberoom-bench chart # 24 ColorChecker patches, mean dE2000
uv run viberoom-bench pack # ~260 MB CC0 RAW pack (X-Trans, Foveon, CRAW…)
uv run viberoom-bench compare --against libraw darktable
uv run viberoom-bench auto # degrade → recover → score, no dataset needed
uv run viberoom-bench reference --inputs raw/ --references expertC/compare treats libraw as an oracle (a no-op render must match its neutral
decode: 53–55 dB PSNR on Bayer) and darktable as a reference (different
rendering philosophy, so dE 5–14 means "same neighbourhood", not "bug").
auto degrades an image by a known amount and scores the recovery — exact
ground truth, no dataset (wb mode is the real pass/fail; --strategy auto
is diagnostic only). reference scores auto-adjust against expert retouches —
if auto isn't beating noop, it's making things worse. viberoom-bench datasets lists where the big datasets live and what each one proves.
uv run pytest # backend
pnpm --dir frontend build # frontend typecheck + buildState lives in <library>/.viberoom/ — a disposable SQLite index (sidecars are
the source of truth) and the preview cache. Exports land in
<library>/exports/ unless you pick another folder.
Computational auto-adjust: analyzes the image (exposure targeting, percentile tone recovery, gray-world WB) and sets whiteBalance/tone/ vibrance. Keeps existing detail and geometry settings. Returns the new recipe — render_preview afterwards to judge the result.
| Name | Required | Description | Default |
|---|---|---|---|
| image_id | Yes | ||
| white_balance | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of explaining behavior. It discloses that the tool modifies whiteBalance/tone/vibrance, preserves existing detail and geometry settings, and returns the new recipe rather than saving it directly. This is useful and non-obvious behavior, though it does not mention potential side effects like overwriting previous values or needing permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that pack in the core behavior, what is preserved, the return value, and a follow-up instruction. No wasted words, and key information is front-loaded with the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers the essential aspects: what the tool does, what it changes, what it preserves, what it returns, and how to use the result. It does not explain failure modes or parameter details, but for a recipe-adjustment tool this is reasonably complete for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are completely absent for the two parameters, so the description must compensate. It indirectly explains image_id by saying 'analyzes the image' and links white_balance to 'gray-world WB', but it does not explicitly state what the boolean white_balance parameter does (e.g., whether false disables white balance adjustment). The parameter meanings are inferable but not directly spelled out.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a computational auto-adjust that analyzes an image and sets white balance, tone, and vibrance. This distinguishes it from sibling tools like update_recipe or set_recipe, which are manual recipe adjustments, by emphasizing the automatic, analysis-driven nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit workflow hint: 'render_preview afterwards to judge the result.' This tells the agent when to use it relative to the sibling tool render_preview. It does not explicitly rule out alternatives, but the context suggests it is for automatic adjustments rather than manual recipe editing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export the edited image as an sRGB JPEG. quality 1-100; max_dimension resizes the longest edge; path overrides the default /exports/ destination. Returns the written file path.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | ||
| quality | No | ||
| image_id | Yes | ||
| max_dimension | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It clearly states the output format (sRGB JPEG), explains the effects of quality (1-100), max_dimension (resize longest edge), and path (override default destination), and notes the return value (written file path). It does not mention overwrite behavior or prerequisites (e.g., whether the image must be edited), but the essential behavioral traits are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, and uses compact, information-dense phrasing. Every clause adds value: format, parameter effects, and return value. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no annotations, and no output schema, the description covers the main inputs and return value. It also references the library destination, tying to the set_library sibling. It omits potential error behaviors or whether existing files are overwritten, but for a straightforward export tool, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully explain the parameters. It provides meaningful semantics for quality (range 1-100), max_dimension (resizes longest edge), and path (overrides default destination). image_id is implicit from context, and the description adds clarity that would otherwise be missing from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Export the edited image as an sRGB JPEG', using a specific verb and resource with clear output format. This distinguishes it from sibling tools like render_preview (preview) and set_recipe (recipe management), making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when exporting an edited image to JPEG) and lists parameters that affect the output. It does not explicitly name alternatives or state when not to use it, but the context of siblings (e.g., render_preview for on-screen preview) makes usage clear. No exclusions are stated, so it earns a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The image the user currently has selected/open in the Viberoom web UI (or image_id: null if nothing is selected). Use this when the user says 'this image' / 'my current image'.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses an important behavioral trait: returns null if nothing is selected. It also clarifies the state dependency ('currently has selected/open'), which is valuable for an agent to understand potential null results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. The first states what the tool returns, including the null case, and the second gives usage guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, this description fully covers purpose, behavior, and usage. It explains the return value (image id or null), the context (current selection in Viberoom UI), and when to use it. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline score is 4. The description adds no parameter information because none exists, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the currently selected/open image from the Viberoom web UI, with the verb implied by the name 'get'. It distinguishes itself from get_image (which presumably gets by ID) and list_images by focusing on the current selection context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'Use this when the user says "this image" / "my current image"'. This gives a clear trigger for when to invoke this tool, which is sufficient for a simple tool with no alternatives needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full metadata for one image: path, EXIF, rating, flag, edit status.
| Name | Required | Description | Default |
|---|---|---|---|
| image_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden for behavioral disclosure. It lists the output fields, which is useful, but does not mention error behavior, read-only nature, or any side effects. The return-value disclosure is partial but present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the core action ('Full metadata for one image') and a concise enumeration of fields. Every word adds value; no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter, the description covers the essential context: what the tool returns and the scope. It omits edge cases (e.g., not-found behavior) but is reasonably complete given the tool's simplicity, especially when no output schema is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the only parameter image_id. The description only says 'for one image,' which barely reinforces the parameter's purpose. It does not explain the format, source, or how to obtain the ID, so it fails to compensate for the absent schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('get') and resource ('image'), and specifies the scope ('one image') with a list of metadata fields ('path, EXIF, rating, flag, edit status'). This distinguishes it from siblings like list_images (multiple images) and get_current_image (current image, not specific).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: when you need full metadata for a single identified image. However, it does not explicitly mention when to prefer this over list_images or get_current_image, nor does it state any alternative or exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the image's current non-destructive edit recipe (JSON).
| Name | Required | Description | Default |
|---|---|---|---|
| image_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states that the recipe is 'non-destructive' and returned as JSON, but does not confirm read-only behavior, error handling, or response format beyond 'JSON'. There is no mention of side effects or authorization.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence that directly states the tool's function without extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description lacks details about the return value's structure (only says 'JSON'), any error cases, or usage context. With no output schema or annotations, the description should offer more context but remains minimally adequate for a getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, image_id, with zero description coverage. The description does not explain the parameter's role or format, adding no semantic value beyond the schema's 'Image Id' title. While the parameter is self-explanatory, the description fails to compensate for the 0% coverage as required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and identifies the resource as 'the image's current non-destructive edit recipe (JSON)', clearly distinguishing it from sibling tools like set_recipe, update_recipe, reset_recipe, and get_recipe_schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when one needs the current recipe for an image, but it does not explicitly state when to use it versus alternatives (e.g., get_recipe_schema) or provide exclusion criteria. Sibling names are available but not referenced in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The full JSON Schema for edit recipes (all parameters and ranges).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It states the schema is 'full' and includes 'all parameters and ranges,' which clarifies scope. However, it doesn't explicitly state read-only behavior or any side effects, though 'get' implies read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficiently worded sentence that front-loads the core purpose without extraneous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema, no annotations), the description is sufficient to understand what the tool returns. It doesn't provide additional context about use cases, but none is strictly necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description need not explain parameter details. The schema is empty, and the baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing the full JSON Schema for edit recipes, specifying the exact resource and scope. It distinguishes from sibling tools by focusing on the schema rather than actual recipe operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives, but the description implies it is for obtaining schema information. It does not mention exclusions or contrast with get_recipe, so usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List images in the library with optional filters.
rating_gte: only images rated >= this (0-5). flag: 'pick', 'reject', or
'none' for unflagged. Returns metadata including each image's id, which
all other tools take.| Name | Required | Description | Default |
|---|---|---|---|
| flag | No | ||
| sort | No | filename | |
| limit | No | ||
| order | No | asc | |
| offset | No | ||
| has_edits | No | ||
| rating_gte | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that it returns metadata including id, but does not mention pagination behavior, default sort/limit, or explicitly state read-only nature (though 'list' implies it). Provides some value but misses richer behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with core purpose and key parameter details. No waste, efficiently structured despite a line break. Each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters and no annotations or output schema, the description is incomplete: it covers only 2 parameters, gives partial return info, and lacks context on sorting/pagination. It is serviceable but leaves gaps for an agent needing to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains rating_gte (0-5) and flag (pick/reject/none), but omits sort, limit, order, offset, and has_edits, leaving 5 of 7 parameters without any explanation beyond schema titles. Incomplete compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'List images in the library' with optional filters, using a specific verb and resource. It distinguishes itself from siblings like get_image by emphasizing it returns IDs for other tools, making its role as a listing/discovery tool evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says returns ids 'which all other tools take', implying this is the entry point before using other tools. However, it does not explicitly name alternatives or provide when-not-to-use guidance, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render the image WITH its current edits applied and return the JPEG so you can visually inspect the result. size = longest edge in px (256-4096).
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | ||
| image_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey side effects. It states output is a JPEG and that current edits are applied, implying read-only preview, but doesn't explicitly declare non-destructive behavior or resource requirements. This leaves some ambiguity about whether the operation mutates state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, immediately front-loaded with the action and purpose. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter preview tool, the description covers the return format (JPEG), the size parameter semantics, and the preview context. It lacks an explicit note about non-destructiveness, but overall it provides sufficient guidance for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds semantic meaning for 'size' as 'longest edge in px (256-4096)', which is not in the schema. It doesn't elaborate on image_id, but its purpose is self-evident from context; this adequately compensates for the schema's 0% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies 'Render the image WITH its current edits applied and return the JPEG' — a specific verb and resource with scope. It distinguishes from siblings like get_image or export_image by emphasizing 'visually inspect' as a preview purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for inspecting intermediate results after edits, but doesn't explicitly state when not to use or name alternatives like export_image. The size range information suggests configuration, but not when to prefer this over other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove all edits, restoring the image to its unedited state.
| Name | Required | Description | Default |
|---|---|---|---|
| image_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the core destructive action but does not mention irreversibility, side effects on the recipe, permission requirements, or what happens to the current state. For a reset operation, this lack of detail is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no unnecessary words. It is front-loaded and immediately conveys the primary purpose and effect.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and only one required parameter, the description covers the basic action but omits crucial context such as irreversibility, relationship to the recipe, typical use cases, and side effects. An AI agent would lack important information for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (image_id) with 0% description coverage, and the description does not explain the parameter's role or format. Since the description fails to compensate for the low schema coverage, it provides no value beyond the raw property name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action with a specific verb ('Remove all edits') and resource ('image'), and specifies the result ('restoring the image to its unedited state'). This distinguishes it from sibling tools like update_recipe or set_recipe, which modify the recipe rather than reset the image.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you want to discard all edits and revert to the original), but it does not explicitly mention usage context or alternatives. There is no guidance on when not to use it or how it compares to related tools such as set_recipe or auto_adjust.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Flag an image as 'pick' or 'reject', or None to unflag.
| Name | Required | Description | Default |
|---|---|---|---|
| flag | Yes | ||
| image_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does explain the flag values and that None unflags, but it does not mention side effects, permissions, overwriting behavior, or return values. This is adequate for a simple setter but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the action and resource. It avoids unnecessary detail while conveying the key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the schema's clarity, the description is complete enough for an agent to invoke it correctly. It covers the main behavior (set/unset flag) and parameter semantics. It does not elaborate on consequences or error conditions, but these are not critical for a basic flagging operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions for parameters (0% coverage), so the description must compensate. It adds meaning by explaining the flag values and the semantics of None (unflag), which is not obvious from the schema alone. The image_id is self-explanatory, so no further detail is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: flag an image as 'pick' or 'reject', or unflag with None. It uses a specific verb and resource and distinguishes from sibling tools like set_rating by focusing on flagging specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool—when you want to flag an image—but does not explicitly mention alternatives or exclusions. Sibling tools like set_rating exist, but the description does not state when to prefer set_flag over them, leaving the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a local folder as the photo library and scan it for images.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It states that it 'opens' a local folder and 'scans' for images, implying a state change, but it does not mention side effects like replacing the current library, required permissions, or whether the scan is recursive. For a tool that mutates the environment state, more disclosure is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence (14 words) that front-loads the primary action and object. There is no redundancy or unnecessary elaboration. Every word contributes to understanding the tool's core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, no annotations, and no output schema, the description provides a basic understanding. However, it is incomplete in key behavioral aspects: it does not clarify whether setting a new library replaces the previous one, what 'scan' entails (e.g., indexing, supported formats), or any return value. Given its role as a setup operation among image-related tools, more context would help the agent use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'path' with no description. The tool description does not mention the parameter by name, but the phrase 'local folder' directly alludes to the 'path' parameter's meaning. Since schema coverage is 0%, the description adds some semantic value, but it does not specify details such as the path being a directory or whether it must be absolute. It partially compensates for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Open a local folder as the photo library and scan it for images.' It uses specific verbs (open, scan) and identifies the resource (local folder, photo library). This distinguishes it from sibling tools, which focus on individual images or recipes rather than library-level setup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: it sets the library before other operations. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. For instance, it does not say 'use this before list_images' or that setting a new library replaces the existing one. The guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the star rating, 0 (unrated) to 5.
| Name | Required | Description | Default |
|---|---|---|---|
| rating | Yes | ||
| image_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden of behavioral disclosure. It only states that the tool sets a rating and the valid range; it does not mention whether the rating overwrites an existing value, requires specific permissions, or how invalid values are handled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence, front-loaded with the action and scope. Every word contributes meaning and there is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is thin. It fails to mention how the rating relates to the broader image workflow, what happens on invalid input, or any return/error behavior, leaving significant context unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions for the two parameters, and the description compensates by explaining the rating range and the meaning of 0 as unrated. However, it does not clarify the image_id parameter beyond what its name implies, leaving a partial gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Set' with the resource 'star rating' and defines the range 0-5, making it clear what the tool does. It distinguishes itself from sibling tools like set_flag and set_library by naming the rating concept.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives, such as set_flag or set_recipe. There is no mention of prerequisites, context, or known alternatives, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Replace the entire edit recipe. Omitted fields reset to defaults.
| Name | Required | Description | Default |
|---|---|---|---|
| recipe | Yes | ||
| image_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavioral traits. It mentions that omitted fields reset to defaults, which is a key behavior, but lacks details on side effects, reversibility, permissions, or return values. It adds value beyond the schema but is incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the verb and object. It communicates the core behavior and the important reset semantics without any filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The essential purpose is clear, and the reset behavior is disclosed, but the tool has no annotations, no output schema, and no parameter documentation. It does not cover prerequisites, return behavior, or how the recipe object should be structured, leaving notable gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of the 'image_id' or 'recipe' parameters. The recipe object is open-ended (additionalProperties), and nothing clarifies its structure or how it relates to the image. The description fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Replace') and a specific resource ('entire edit recipe'), and clearly distinguishes from siblings like update_recipe and reset_recipe by emphasizing full replacement and default-resetting behavior. It is unambiguous about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for full replacement versus partial updates via 'entire' and 'omitted fields reset to defaults,' but it does not explicitly name alternatives or provide explicit when-to-use guidance. The context gives some direction but falls short of clear exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Merge a partial recipe into the image's edit recipe (the usual way to edit). Only supply the fields you want to change; everything else keeps its value. Ranges (Lightroom-style):
- whiteBalance: {temp: 2000-50000 Kelvin (null=as-shot), tint: -150..150 (+magenta)}
- tone: {exposure: -5..5 EV, contrast/highlights/shadows/whites/blacks: -100..100,
toneCurve: {points: [[in,out],...] 0-255 increasing}}
- color: {saturation/vibrance: -100..100,
hsl: {red|orange|yellow|green|aqua|blue|purple|magenta:
{hue/saturation/luminance: -100..100}}}
- detail: {sharpening: {amount: 0-150, radius: 0.5-3, detail: 0-100},
noiseReduction: {luminance: 0-100, color: 0-100}}
- geometry: {rotate: -45..45 deg, orientation: 0|90|180|270, flipH/flipV: bool,
crop: {left,top,right,bottom: 0-1 normalized}}
Example: {"tone": {"exposure": 0.5}, "whiteBalance": {"temp": 6500}}
Use get_recipe_schema for the full JSON Schema.| Name | Required | Description | Default |
|---|---|---|---|
| patch | Yes | ||
| image_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even without annotations, the description discloses the partial merge behavior, field ranges, and constraints. It states unspecified fields keep their values, explaining the merge semantics. It does not explicitly mention side effects like permanent modification or return values, but 'edit recipe' implies mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections and bullet points for each recipe category. The length is justified by the complexity of the patch object, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the complex input structure comprehensively and references get_recipe_schema for full schema details. It does not specify the return value or error handling, but given the complexity and lack of output schema, it is quite complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only shows image_id and patch (additionalProperties), but the description thoroughly documents all nested fields with units, ranges, and an example. This fully compensates for the 0% schema coverage and adds significant meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: merging a partial recipe into the image's edit recipe, described as 'the usual way to edit'. This distinguishes it from siblings like set_recipe by emphasizing partial updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on how to use it ('only supply fields you want to change') and implies it is the standard editing tool. However, it does not explicitly mention when to avoid it or use alternatives like set_recipe or reset_recipe, lacking explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0auto_adjustexport_imageget_current_imageget_imageget_recipeget_recipe_schemalist_imagesrender_previewreset_recipeset_flagset_libraryset_ratingset_recipeupdate_recipeEach tool targets a distinct resource and action: library setup, listing/querying images, retrieving current/specific image metadata, rating/flagging, recipe CRUD and auto-adjust, preview/export. Overlap between get_image and list_images is minimal, and get_current_image has a clear trigger ('this image').
All tool names follow a consistent verb_noun snake_case pattern (set_library, list_images, get_recipe, update_recipe, render_preview). The verbs are descriptive and the nouns indicate the target resource. No mixed conventions or vague verbs.
14 tools is right-sized for a photo library and editing workflow. Each tool covers a distinct operation from library intake to export, without redundancy or bloat. The count supports the full editing lifecycle without feeling overwhelming.
The tool surface covers the complete photo editing workflow: library setup, image exploration, metadata management (rating/flag), non-destructive recipe editing (get, set, update, reset, auto-adjust), preview rendering, and export. The get_recipe_schema tool fills the gap for discovering editable parameters. There are no obvious dead ends or missing critical operations.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AgentDocs (agentdocs.eu) MCP: read, search, write, comment, share & attach images to Markdown docs.
Agent-native notes, tasks, dev-docs, vaults, sync & handoffs. MCP + OpenAPI dual surface.
Independent directory of agentic AI tools — search, compare & recommend via MCP. Read-only.
OCR, transcription, file extraction, and image generation for AI agents via MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/RatulMaharaj/viberoom'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
