Capture One AI MCP Server

Overview Schema Source Related Servers Discussions Admin

operations

Track Capture One photographic briefs, checkpoints, reviews, and comparisons, and reconcile existing receipts to keep edits auditable on macOS.

Instructions

Get/list/reconcile existing receipts; reconcile never dispatches recovery writes.

action=task adds persistent photographic briefs and versions on Mac. Mutations require a unique request_id and fresh target/token (stop only needs task_id). task_action: start payload={goals:[...],protections:[...],mode:optimize|reference_match,strength:light|close|maximum, references:[{id,role,kind:same_scene|cross_scene}],reference_analysis?:{tone,color,texture,limitations,priority}}; bind {candidate_request_id}; update merges brief fields; checkpoint {preview_request_id,label}; review {checkpoint_id,seen_sha256,improved:bool,assessment:{goal,protections,light_color,edges,remaining,reference?}}; feedback {kind:brightness|temperature|strength|subject|background|prefer_previous|custom,message,protect?:[...],checkpoint_id?}; accept {checkpoint_id,user_confirmation}; restore {checkpoint_id} WRITES saved selected-layer color parameters through adjust, without restoring layer structure/mask pixels. Render/review again. get/diagnose/compare are read-only; compare {roles:[initial,previous,current,accepted]} returns images. Reference images and visual judgments are supplied by the vision client; the backend cannot prove aesthetics. P1 reference_plan {checkpoint_id,targets:[{id,reference_id,observation,uncertainty,region,direction, protect:[...],priority:1..5,limitation}]}; IDs reference the current brief, priority 1 is highest. recognize {checkpoint_id,aspect,user_confirmation,supersedes?:[recognition_id]} records partial USER approval. feedback may add interpretation:{problem,region,direction,method:global|color_range|local|inspect_only,risks}. P1 checkpoints freeze intent. review additionally requires exact id/status/note lists for captured target_results (pending|close|conflict|limited), protection_results (preserved|changed|uncertain), feedback_results (resolved|improved|unchanged|worse|conflict). See checkpoint.intent for required IDs. compare can alternatively use {checkpoint_ids:[...]} for up to three recognized historical versions. anchor_analysis measures actual-render patches without writing C1. payload={checkpoint_id,reference_id, reference_checkpoint_id OR reference_path+reference_sha256,assume_srgb?:{reference:bool,target:bool}, anchors:[{id,role,kind:neutral|color,reference_box:[l,t,r,b],target_box:[l,t,r,b]}]}. Boxes use normalized EXIF-oriented preview coordinates, never RAW/mask coordinates. No automatic neutralization. Reuse fixed anchors with {checkpoint_id,baseline_analysis_id,alignment_confirmed:true} after looking at the new render. An embedded ICC is converted; untagged RGB requires explicit assume_srgb. Lab deltas are not C1 slider values. reference_plan may link anchor_analysis_id from its current checkpoint. References must be explicitly provided images.

Input Schema

Name	Required	Description	Default
`action`	Yes
`target`	No
`payload`	No
`task_id`	No
`request_id`	No
`task_action`	No
`operation_id`	No
`observation_token`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 29, 2026

TDQS

A3.9/5.0

Behavior5/5

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 so extensively: it distinguishes read-only actions from mutations, states request_id and target/token requirements, explains that restore writes saved color parameters without restoring layer structure/mask pixels, and clarifies that anchor_analysis does not write C1. It also discloses coordinate-system and color-space assumptions, including normalized EXIF-oriented boxes and ICC/assume_srgb behavior.

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

Conciseness3/5

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

The content is front-loaded with the core get/list/reconcile behavior before the task-action detail, and much of the density is justified by the tool's 15 task_actions. However, the semicolon-heavy wall of text is difficult to parse and could be organized more clearly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

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 do not need description, and the tool's complexity is matched by substantial behavioral and payload detail. The remaining gaps are the lack of explicit sibling-tool selection guidance and incomplete coverage of a few top-level parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must supply parameter meaning, and it does so richly for task_action payloads, checkpoint/review structures, IDs, request_id/task_id conditions, and coordinate boxes. It still leaves some top-level parameters such as operation_id and the general target/token shape unclear, so it is strong but not fully complete.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the primary actions (get/list/reconcile) and explains that action=task adds persistent photographic briefs and versions on Mac, so the broad purpose is understandable. It does not explicitly differentiate this tool from siblings such as read, adjust, or preview, which keeps it below a 5.

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

Usage Guidelines3/5

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

It gives some usage conditions, such as get/diagnose/compare being read-only, mutations requiring a unique request_id and fresh target/token, and stop only needing task_id. However, it never states when to choose this tool over the sibling tools or when not to use it, leaving selection guidance largely implied.

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

Deploy Server