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., "@Capture One AI Windows Check the current photo, raise exposure a bit, and show me a preview."
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.
让视觉 AI 在 Windows 上读取和调整 Capture One，并取得 C1 实际渲染的预览。提供 MCP stdio + JSON CLI，不绑定 AI 厂商、账号或聊天客户端。
0.2.0a1 预览版，实测 Capture One 16.8.6.3784 / Windows / Session。 使用 C1 内部托管对象和原生处理内核，不是官方公开稳定 SDK。其他 C1 版本、Catalog 和多照片批量任务尚未完成兼容验证；启动器拒绝未验证版本。
Native Capture One editing for Windows through MCP and a JSON CLI. Vision models plan edits; the local bridge executes them and returns real Capture One previews. Unofficial, version-specific, MIT-licensed.
曝光、对比度、亮度、饱和度、白平衡、HDR。
RGB / R / G / B 色阶；RGB / R / G / B / Luma 五通道原生曲线。
Basic、Advanced、Skin 混色器；主色轮和阴影／中间调／高光色彩平衡。
调整图层创建、选择、透明度、改名、开关、复制和排序。
主体／背景 AI 蒙版；反相、复制、组合、羽化、渐变和亮度范围。
模块重置与快照复用；当前集合内按 UUID 选图和翻页。
C1 原生照片／灰度蒙版预览，长边 128～1600 像素；预览与 RAW 坐标映射。
全局和局部调整共用同一接口。正常流程不导入预设、不截图识色、不发送键鼠输入，不要求展开面板。清晰度、锐化、降噪、镜头／几何及人像精修不在当前范围；默认不切文档、不导出。
Related MCP server: capture-one-mcp
需要 64 位 Windows、有效授权的 C1 16.8.6.3784、64 位 Python 3.11+、PowerShell 7.6+ 与 .NET 10 Windows Desktop Runtime。本机验收 Python 3.14.7 / PowerShell 7.6.5，其他 Python 版本未逐项实测。安装依赖需要联网，运行库和 C1 均不随包分发。
下载 Releases 的 Windows ZIP，解压到固定目录。在该目录的 PowerShell 7 中执行：
.\Install.ps1 -SessionPath 'D:\Photos\MySession\MySession.cosessiondb'
.\Start-CaptureOne.ps1
.\Run.ps1 context --compact在 C1 打开配置的 Session，选中照片。首次加载桥接时应先正常退出 C1，再用本项目启动器启动；仅打开普通 C1 快捷方式不会加载桥接。启动器默认不会关闭已运行的 C1；确需正常重启时显式传 -Restart。见 安装说明。
安装器生成 config/mcp-server.local.json，把它加入支持本地 MCP 的 AI 客户端。核心字段是本机 Python 路径和 -m c1ai mcp。刷新 MCP 连接即可取得六个工具定义；客户端须支持图片块并使用视觉模型。见 AI 接入。
视觉 AI → MCP / CLI → 串行执行器与操作记录 → C1 内部命名管道
→ C1 原生参数／图层／蒙版对象 → 参数回读 + C1 原生预览context 确认环境；read(fields=[]) 获取当前照片；preview(kind=native) 实际看图。
images(create_candidate) 创建并登记变体副本，保留原版本。
按画面选择模块：read → adjust → preview，使用读取返回的目标和观察凭据。
全局完成后再决定是否加局部蒙版；达到目标即停止。
参数使用绝对值，同模块相关参数合并提交。每次写入有唯一编号；超时先查询原编号，不重复派发。只有登记候选副本可写，参数回读不等于视觉效果合格。
文档 | 内容 |
安装、启动、配置、升级和排错 | |
通用 MCP / CLI 接入与 AI 调色流程 | |
六个工具、请求示例、单位和返回值 | |
混色器、色阶、图层、蒙版和模块复用 | |
选图、原生预览和坐标映射 | |
已验证范围与未完成事项 | |
原生调用与原图保护 | |
开发和发布包生成 |
运行状态在当前用户 %LOCALAPPDATA%\CaptureOneAI，不进入仓库。分发包不含照片、预览、Session、私人配置、连接令牌或历史操作数据库。预览只保留最近 8 张缓存，不是永久成片导出。
Apply one qualified numeric or structured module using its exact observed module token.
Structured modules: curves {channel,points:[[x,y],...]}; color_mixer {mode:'basic',color,hue?,saturation?,lightness?} or {mode:'advanced'|'skin',action:'add'|'update'|'remove',rgb? ,index?,hue?,saturation?,lightness?,smoothness?,uniformity_hue?,uniformity_saturation?,uniformity_lightness?,enabled?,inverted?}; levels {channel,input_black?,input_white?,midtone?,output_black?,output_white?}; color_balance {wheel,x?,y?,lightness?}; layers {action,layer_ref?,creation_operation_id?,opacity?}; masks {action:'create_subject'|'create_background'}. Layers also support rename {layer_ref,name}, set_enabled {layer_ref,enabled}, duplicate {layer_ref,name?}, move {layer_ref,index}; index is zero-based excluding Background. Masks on the selected adjustment layer: invert, clear, fill {density:0..1}, copy {source_layer} replaces the entire mask; combine {source_layer,mode:add|subtract|intersect}; feather {radius:0..300}; linear_gradient {start:[x,y],stop:[x,y],midpoint:0.01..0.99}; radial_gradient {center:[x,y],radius_x,radius_y,falloff:0..1,angle:-360..360,inverted:bool}; luma_range {shadow,shadow_falloff,highlight,highlight_falloff,radius,sensitivity,inverted}. Gradient coordinates/radii use normalized RAW dimensions, not rotated viewer coordinates. Luma endpoints 0..255 ordered shadow_falloff<=shadow<=highlight<=highlight_falloff, radius 0..300, sensitivity 0..100. select_submask {index} uses the native indexes returned by masks read; -1 selects the whole mask. Brush/gradient operations follow C1's selected submask semantics. Luma range replaces existing luma components, preserving the other masks. Each color module also accepts {action:'reset'} (C1 defaults) or {action:'paste',source_observation_token} (a saved complete read of the same module). Read the destination module before applying; source snapshot may belong to another layer/photo. Native qualification remains required. No presets or style files are created. Scalar parameters, levels, all mixers, color wheels and curves share the C1 internal model endpoint for Background and the selected adjustment layer. Select a layer then re-read the module; target.layer binds every write to that layer. Native AI masks use AutoMaskingManager without requiring the tool panel to be visible. Levels endpoints use 0..255, midtone -1..1. Advanced H/S/L limits are +/-30, -100..200, +/-100; Skin +/-5, +/-30, +/-10. Smoothness 1..30; Skin uniformity 0..100. Advanced/Skin may also update hue_low/high and saturation_low/high: signed offsets from the source color, low<=-2, high>=2, hue span<=359 degrees. Skin has one range. Read gives current native ranges and indexes; no screenshot or UI color picking is required.
| Name | Required | Description | Default |
|---|---|---|---|
| patch | Yes | ||
| module | Yes | ||
| target | Yes | ||
| request_id | No | ||
| observation_token | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does disclose substantial semantics: module patch shapes, mask replacement behavior, target.layer binding, token binding, and that no presets or style files are created. It still does not clearly state reversibility/undo behavior or general permission/failure characteristics.
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 purpose is front-loaded and the detail is largely relevant to a complex tool, but the description is a dense wall of semicolon-separated jargon. It would be much easier to scan with structured grouping by module or parameter.
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 complex nested schema, zero schema description coverage, and no annotations, the description is unusually complete about supported modules and patch structures. Some top-level parameter and workflow gaps remain, notably request_id and the precise meaning of 'qualified'.
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 compensate, and it does explain much of module, patch, observation_token, and target.layer semantics in detail. However, it does not define the top-level target shape fully and never mentions the optional request_id parameter.
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 first sentence states a specific verb and resource: apply one qualified numeric or structured module using an observed module token. It is clear this is a mutation/adjustment tool, but it does not explicitly distinguish itself from the sibling read or operations tools beyond saying to read the destination module first.
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 a clear prerequisite workflow: read the destination module before applying, select a layer and re-read, and note that native qualification remains required. It does not name alternatives or spell out when not to use this tool, which keeps it from a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read application, target, capabilities, shared editing workflow and unresolved operations.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. 'Read' implies non-mutation, but the description says nothing about cost, size, whether the snapshot is cached or live, or whether 'unresolved operations' reflects pending writes — all relevant for a context tool.
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?
A single terse sentence with no filler, and the enumeration is front-loaded. It is arguably over-compressed for the ambiguity it needs to resolve, but nothing in it is wasted.
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?
An output schema exists, so return values need not be explained. Still, with no annotations and a generic name shared with a sibling 'read' tool, the definition leaves the agent without the when/why context needed to choose it confidently.
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 takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly implies a parameterless snapshot by not referencing any inputs.
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 does name what the tool returns (application, target, capabilities, shared editing workflow, unresolved operations), which is more than a tautology of the bare name 'context'. However, it is a noun list with only the verb 'Read' rather than a stated resource and scope, so an agent cannot easily tell how it differs from the sibling 'read' or 'operations' tools.
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?
There is no statement of when to call this versus the sibling 'read' or 'operations' tools, and no prerequisites or exclusions. The agent must infer that this is an initial session-context fetch, which is a guess rather than guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the active native collection (including offscreen photos), or select by variant_uuid.
Follow next_offset with the same collection_token. next/previous follow the filtered collection. create_candidate clones the selected variant; edits remain restricted to registered copies.
| Name | Required | Description | Default |
|---|---|---|---|
| tool | No | ||
| limit | No | ||
| scope | No | filtered | |
| action | Yes | ||
| offset | No | ||
| target | No | ||
| request_id | No | ||
| variant_id | No | ||
| variant_uuid | No | ||
| collection_token | No | ||
| observation_token | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full behavioral burden. It does disclose two useful traits: 'including offscreen photos' and 'edits remain restricted to registered copies', but it never states that create_candidate mutates state, what prepare_* actions do, whether anything is persisted, or what permissions are 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?
Four short sentences with the primary action front-loaded, so it is compact. However it references 'next_offset', which is not an actual parameter name (the schema has 'offset'), making a key instruction ambiguous.
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?
An 11-parameter, seven-action tool with no annotations and zero schema descriptions needs substantially more explanation. The output schema covers return values, but action-specific prerequisites, argument requirements, and side effects for most actions are 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?
With 0% schema description coverage across 11 parameters, the description must compensate and does so for only a few: variant_uuid, collection_token, offset, and partially scope ('filtered collection'). tool, limit, target, variant_id, request_id, and observation_token are entirely undocumented anywhere.
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 first sentence clearly states 'list the active native collection' and 'select by variant_uuid', but the tool exposes seven actions and the description accounts for only list/select/next/previous/create_candidate. prepare_adjustments and prepare_tool, plus the tool and scope parameters, are never explained, and nothing distinguishes this tool from siblings like adjust or 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?
It gives sequencing advice for pagination ('follow next_offset with the same collection_token') and what next/previous traverse, which is useful. But it never says when to choose this tool over adjust, read, or preview, and offers no when-not guidance for any action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read full logs or reconcile current evidence without dispatching recovery writes.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| request_id | No | ||
| operation_id | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose the important trait that no recovery writes are dispatched, which is useful context. However, it says nothing about permissions, idempotency of reconcile, log volume limits, or what 'evidence' means in practice.
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?
One short sentence with no waste, and the negative constraint is front-loaded rather than buried. Conciseness is fine, but it is concision at the cost of the details an agent needs, which is under-specification rather than elegance.
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 output schema covers return values, so that gap is excused. But for a three-parameter tool with a required action enum and zero schema descriptions, the description leaves the selection logic and identifier semantics completely unaddressed, which is not enough to call it correctly for reconcile or get.
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 mentions no parameter at all. The required action enum, request_id, and operation_id are entirely undefined in prose, so an agent cannot tell what to pass for reconcile versus get or list.
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 names two activities (reading full logs, reconciling current evidence) but never maps them to the three action values, and it does not distinguish this tool from siblings such as read or adjust. An agent knows roughly the domain but not which capability belongs to which action.
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 clause 'without dispatching recovery writes' implies an exclusion against a write-path tool, likely adjust, but never names the alternative or states when to choose this versus read or context. It is a hint, not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Default native renders current C1 adjustments asynchronously, without export or focus.
kind=mask renders the selected layer's whole composite mask. max_size is 128..1600. map_points maps {x,y} pixel-edge coordinates using C1's nonlinear transform; use the same kind/max_size and returned preview_id. Divide RAW x/y by raw_dimensions to make normalized gradient coordinates. A changed photo, layer or revision invalidates the id. Only the most recent preview job is retained; eight PNG cache files are retained. Legacy kind=render exports, kind=viewer/action=capture samples the display.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | native | |
| action | No | render | |
| points | No | ||
| target | Yes | ||
| max_size | No | ||
| direction | No | preview_to_raw | |
| preview_id | No | ||
| request_id | No | ||
| observation_token | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description carries the full burden, and it does disclose genuinely non-obvious behavior: asynchronous execution, single most-recent-job retention, eight retained PNG cache files, and id invalidation on revision change. However it never explains how the async result is retrieved or when the job is complete, says nothing about side effects on disk or project state, and gives no error or permission context. Useful behavioral signal, but the async contract and side effects are underspecified.
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 text is dense and mostly earns its length given 9 parameters and multiple modes, but it is not front-loaded: it opens mid-thought with "Default native renders..." rather than stating what the tool does. Sub-modes run together in prose without structure, and terms like "without export or focus" are unexplained, slowing scanning for a long description.
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 9-parameter tool with a nested required `target` object, an unknown `observation_token` credential, no annotations and no output schema, the description leaves too much undone. It explains the mode nuances but not the two required inputs, not the response shape, and not how an async preview is obtained — the agent cannot confidently construct a call from this alone.
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% across 9 parameters, so the description must compensate and it only partly does: it defines `kind` values, the `max_size` range (128..1600), `points` as {x,y} pixel-edge coordinates, `preview_id` reuse/invalidation, and implies `direction` by explaining the RAW-to-normalized division. Both required parameters, `target` (a nested open object) and `observation_token`, are never mentioned, nor is the `action` enum's full set (prepare, restore_destination). Two undocumented required params is a serious 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 does convey a verb and resource ("renders current C1 adjustments asynchronously") and enumerates the kind modes, so an agent can infer this produces previews of a photo's edits. But it never states the purpose in a plain leading sentence and leans on undefined jargon ("C1", "native", "focus"), and it draws no distinction from siblings like `images` or `read`. The tool name "preview" plus mode-specific detail leaves the core purpose only implicit.
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?
It routes between modes explicitly: `kind=mask` for the selected layer's composite mask, `kind=render` as legacy export, `kind=viewer/action=capture` to sample the display, and `map_points` must reuse the same kind/max_size and returned preview_id. It also states invalidation conditions (changed photo, layer or revision) and retention behavior, which tells the agent when a cached id is still usable. What's missing is guidance on the non-legacy `action` values and when to prefer this tool over sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read native parameters with provenance, module guidance/units and an observation token.
Read fields=[] for target/preview without loading adjustment parameters. Read module=... before edits. Parameter targets are absolute, not deltas; skip modules without a visible purpose.
| Name | Required | Description | Default |
|---|---|---|---|
| fields | No | ||
| module | No | ||
| target | No | ||
| modules | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It usefully discloses that results include provenance, module guidance/units, an observation token, that fields=[] avoids loading adjustment parameters, and that targets are absolute rather than deltas. However, it does not explicitly state read-only/no side effects, permissions, or other operational constraints.
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 short and front-loads the core action, followed by practical usage notes. There is little wasted text, though the line break and terseness make some guidance feel compressed rather than fully structured.
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 output schema exists, so return values need not be explained in depth. Still, for a generic 'read' tool with no annotations and 0% schema description coverage, the description leaves sibling routing, parameter value formats, and some operational behavior unclear.
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 compensate for all four parameters. It adds meaningful semantics for fields (empty array behavior), module (read before edits), target (absolute, not delta), and modules (skip modules without a visible purpose), but it does not specify accepted values, target object structure, or the relationship between module and modules.
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 and resource: reading native parameters, including provenance, module guidance/units, and an observation token. It is clear what the tool does, but it does not differentiate itself from siblings such as context or preview, and 'native parameters' is somewhat domain-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?
It gives explicit usage guidance: use fields=[] for target/preview without loading adjustment parameters, read module=... before edits, and skip modules without a visible purpose. It does not name alternative sibling tools for comparison, but it establishes clear when-to-use conditions and one exclusion.
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.
v0.1.0adjustcontextimagesoperationspreviewreadScored across 6 tools
The broad purposes are mostly separable: adjust writes, images manages collections, preview renders, and read returns parameters. However, context, read, and operations all expose inspection/state information, and context explicitly includes unresolved operations while operations handles log/reconciliation evidence, creating boundary ambiguity.
Names mix imperatives and nouns: read and adjust are verbs, while context, images, preview, and operations are noun-like or ambiguous. There is no predictable verb_noun pattern, making the set feel less systematic even though each name is individually readable.
Six tools is a reasonable size for a desktop-editing integration, with each tool covering a major slice of the workflow. The small surface is appropriate given that adjust carries most of the editing complexity.
The surface covers context/state, parameter reads, adjustments, image selection, previews, and logs, which is substantial. But there are notable lifecycle gaps: no explicit export/save tool, no undo or recovery-dispatch operation, and limited image-management actions beyond selection and cloning.
AI-cull, edit and export RAW photos locally with the imagic desktop app, from any MCP client.
Hosted MCP server for AI photo editing: nothing to install, no desktop photo editor needed.
Compose, edit and render video with your AI agent. Turn footage into finished edits with content-aware reframing, word-timed captions and motion graphics. Hosted MCP with OAuth sign-in; cloud processing uses credits.
MCP Server for Slima - AI Writing IDE for Novel Authors with AI Beta Reader.
