viberoom
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 "Deploy 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.jsonnext 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-mcpdrives 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.
Setup from source
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: shutter-mcp
Run it as a PWA (no backend)
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.
What works in the browser
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.
What needs the Python package
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.
Hosting it
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 PagesLet an agent drive
claude 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.
Is it actually correct? (benchmarks)
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.
Development
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.
Available Tools
14 toolsauto_adjustA
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.
Inputs: image_id (required), white_balance.
export_imageA
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.
Inputs: image_id (required), path, quality, max_dimension.
get_current_imageA
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'.
Inputs: no named parameters.
get_imageA
Full metadata for one image: path, EXIF, rating, flag, edit status.
Inputs: image_id (required).
get_recipeB
Get the image's current non-destructive edit recipe (JSON).
Inputs: image_id (required).
get_recipe_schemaA
The full JSON Schema for edit recipes (all parameters and ranges).
Inputs: no named parameters.
list_imagesA
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.Inputs: flag, sort, limit, order, +3 more.
render_previewA
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).
Inputs: image_id (required), size.
reset_recipeB
Remove all edits, restoring the image to its unedited state.
Inputs: image_id (required).
set_flagA
Flag an image as 'pick' or 'reject', or None to unflag.
Inputs: flag (required), image_id (required).
set_libraryA
Open a local folder as the photo library and scan it for images.
Inputs: path (required).
set_ratingB
Set the star rating, 0 (unrated) to 5.
Inputs: rating (required), image_id (required).
set_recipeB
Replace the entire edit recipe. Omitted fields reset to defaults.
Inputs: recipe (required), image_id (required).
update_recipeA
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.Inputs: patch (required), image_id (required).
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelogβ¦
TDQS
Scored across 14 tools
Each 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.
Maintenance
Related MCP Connectors
AI-cull, edit and export RAW photos locally with the imagic desktop app, from any MCP client.
Browse, search, upload, tag, transfer, and delete images in your Raster libraries over MCP.
Image infrastructure for agents. Upload, transform, and deliver images through MCP, CLI, or API.
Persistent memory, knowledge graph, task management and more for AI agents via MCP.
Related MCP Servers
- AlicenseBqualityDmaintenanceEnables AI agents to control Adobe Lightroom Classic on macOS for professional photo editing and catalog management. It allows users to inspect photos, apply develop settings, and automate workflows through a secure local bridge without direct catalog database manipulation.2595MIT
- AlicenseAqualityBmaintenanceA local, read-only MCP server that lets AI agents inspect and analyze photo libraries by scanning files, aggregating EXIF stats, finding duplicates, scoring blur, and generating cull reports without uploading any data.6MIT

Lumaflux MCP Serverofficial
AlicenseNot gradedqualityFmaintenanceEnables local agents to browse, import, organize, nondestructively edit, and export photos in a running desktop photo catalog, with revision-checked edits, previews, and batch operations over an authenticated loopback endpoint or bundled stdio adapter.MIT- AlicenseNot gradedqualityBmaintenanceEnables AI agents to run cross-platform batch photo-processing workflowsβincluding RAW decoding, adjustments, noise reduction, white balance, LOG restoration, EXIF tagging, deduplication, selection, HTML galleries, folder watching, and presetsβthrough a unified versioned JSON contract. It also exposes MCP tools for processing, suggestions, autopilot, indexing, search, selection, HDR, face blurring, and more.MIT