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., "@lr-mcp Show me the edited JPEGs of my five newest photos"
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.
An unofficial MCP server for Adobe Photoshop Lightroom — the cloud-based Lightroom app, not Lightroom Classic. It talks to the Lightroom Partner API (https://lr.adobe.io) with your own Adobe credentials.
This project is not affiliated with, endorsed by, or sponsored by Adobe. Adobe, Photoshop and Lightroom are either registered trademarks or trademarks of Adobe in the United States and/or other countries.
Tool | What it does |
| Browser OAuth sign-in (only needed when tokens are missing or expired) |
| Subscription status and cloud storage usage |
| Search albums by path and get their ids |
| Filter by album, capture date, rating, pick/reject flag, camera, lens, ISO, file name |
| Capture info plus a summary of the photo's edit settings (XMP) |
| Return edited JPEG renditions as images the model can see (up to 12) |
| Save 640 – 2560 px or full-size JPEGs to disk |
| Manage project albums owned by this server |
Edits (develop settings) and ratings of existing photos are read-only.
Photos cannot be deleted.
Albums you created in Lightroom cannot be modified; only project albums created through the API can.
Preset contents cannot be read.
Related MCP server: Apple Photos MCP
Setup takes about ten minutes. Steps marked [human] need a person at a browser; an AI agent can do the rest (see For AI agents).
An Adobe account with a Lightroom plan or trial.
uv (uv --version). It installs Python 3.12+ itself if needed.
openssl (openssl version). Preinstalled on macOS and most Linux distributions.
uv tool install lr-mcp
lr-mcp doctorThis puts an lr-mcp command in ~/.local/bin (run uv tool update-shell and open a new terminal if the shell cannot find it). All later steps use it. Update with uv tool upgrade lr-mcp.
doctor checks the setup in order and prints the first thing to fix. Before you start step 1, it confirms that the sign-in callback port (8000 by default) is free; if it is not, choose another port now (see step 2) so the redirect URI you enter in step 1 matches.
Each user needs their own credential: until Adobe reviews an integration it accepts only 25 beta users, so a shared client ID is not practical.
Sign in to the Adobe Developer Console and click Create new project.
In the project, click Add API, choose Lightroom Services, then pick the OAuth Web App credential type.
Set Default redirect URI to https://localhost:8000/callback and Redirect URI pattern to https://localhost:8000/.*, then save. (If you chose another port in step 0, use it here instead of 8000.)
Open Lightroom Services in the project's left menu, click Manage beta users, and add the email of the Adobe account you will sign in with. Without this, the API refuses the account.
Open Credentials → OAuth Web App and keep the Client ID and Client Secret at hand for step 2.
Settings live in a .env file in the state directory, which doctor prints on its first line (~/.config/lr-mcp/ by default). Environment variables with the same names override the file.
Variable | Required | Description |
| yes | Client ID (also called API key) |
| yes | Client secret |
| no | Sign-in callback port, default |
Create the file, then open it in an editor and paste the two values after the = signs (add LR_MCP_PORT=<port> if you are not using 8000):
mkdir -p ~/.config/lr-mcp
printf 'ADOBE_CLIENT_ID=\nADOBE_CLIENT_SECRET=\n' > ~/.config/lr-mcp/.env
chmod 600 ~/.config/lr-mcp/.env
open -e ~/.config/lr-mcp/.env # macOS; on Linux use any editor, e.g. nanoTo keep the state somewhere else, set the environment variable LR_MCP_HOME to a directory. It cannot go in .env (it says where .env is), so it must also be set for lr-mcp login and in the MCP client config ("env" in step 5). If XDG_CONFIG_HOME is set, the default is $XDG_CONFIG_HOME/lr-mcp.
lr-mcp loginA browser window opens on the Adobe sign-in page. Sign in with the account added as a beta user and allow access. Adobe then redirects to https://localhost:8000/callback, which uses a self-signed certificate, so the browser shows a certificate warning: choose Advanced → Proceed to localhost (Chrome) or Show Details → visit this website (Safari). The page then says "Signed in" and the terminal prints where the tokens were saved. Tokens are stored with mode 600 and refreshed automatically.
lr-mcp doctorEvery line should start with [ok], ending in Catalog found. Setup is complete. Otherwise it prints a fix: for the first problem and exits with status 1.
Claude Desktop. Edit the config file (create it if missing):
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Add an entry under mcpServers, keeping any existing ones (if a lightroom entry already exists, replace it). Claude Desktop does not read your shell's PATH, so use the absolute path printed by which lr-mcp:
{
"mcpServers": {
"lightroom": {
"command": "/Users/<you>/.local/bin/lr-mcp"
}
}
}If you set LR_MCP_HOME, add "env": {"LR_MCP_HOME": "/path/to/dir"} to the entry. Quit Claude Desktop completely and reopen it; the lr_* tools then appear in the tools menu. On macOS the server log is ~/Library/Logs/Claude/mcp-server-lightroom.log.
Claude Code:
claude mcp add lightroom -s user -- lr-mcpThe client config can be added before or after signing in; without tokens the tools reply "Not signed in" and lr_login can do the sign-in from the chat.
Symptom | Fix |
| Run |
| Put |
| Step 2: fill in |
The Adobe sign-in page shows an error right away | Usually a wrong |
|
|
| The signed-in account is not a beta user (step 1.4) or has no Lightroom plan. |
The sign-in page says the redirect URI is invalid | The console's redirect URI must be exactly |
The sign-in redirect shows another app's page or never loads | Something else listens on the port ( |
| The browser stopped at the certificate warning; proceed past it next time. |
| Run |
Tools missing in Claude Desktop | Use the absolute path to |
If a user asks you to set this server up:
Never ask the user to paste the client secret into the chat, and never print .env. Create the file with empty values (step 2, using the state directory doctor prints) and ask the user to fill it in with an editor. To check it without revealing values, grep -cE '^ADOBE_CLIENT_(ID|SECRET)=.+' <state dir>/.env must print 2; doctor shows only the first characters of the client ID.
Install (step 0) and run lr-mcp doctor before giving the user the console steps: it checks the callback port first, and the redirect URI they enter must use a free port. Run doctor again after every step; a fix: that starts with [human] is something to hand to the user.
The user must create the credential, add the beta user, fill in .env, and finish the browser sign-in. Give them the exact console steps from step 1, with the port doctor reported in the redirect URI and pattern.
lr-mcp login blocks for up to 5 minutes while the user signs in. Run it in the background or ask the user to run it, and warn them about the certificate page.
Setup is done when doctor prints Catalog found. Setup is complete. Add the client config (step 5) before or after that. For Claude Desktop, merge into the existing JSON instead of overwriting it, use the absolute path from which lr-mcp, pass LR_MCP_HOME in "env" if it is set, and tell the user to quit and reopen the app.
git clone https://github.com/longfin/lr-mcp && cd lr-mcp
uv sync
uv run lr-mcp doctor
uv run pytestTo run a checkout from an MCP client, use uv run --directory /path/to/lr-mcp lr-mcp as the command. Without installing, uvx lr-mcp <command> also works.
Account info: subscription status and cloud storage usage.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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. It discloses the response content (subscription status, storage usage) and is implicitly a safe, zero-parameter read, but says nothing about authentication requirements, side effects, or freshness of the data. For a low-risk read tool this is adequate but not rich.
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 short sentence that front-loads the resource and enumerates the returned data with zero filler. Nothing could be removed without losing 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?
An output schema exists, so the description need not explain return values, and with zero parameters the invocation surface is trivial. The only missing context is whether authentication is required before calling, which is minor for this tool.
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 no parameter semantics to document; baseline for a parameterless tool is 4. Nothing in the description conflicts with the empty schema.
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 the specific resource (account) and the exact information it exposes (subscription status, cloud storage usage), which clearly separates it from siblings like lr_login, lr_get_photo, and lr_list_albums. It lacks an explicit verb (e.g., 'retrieve'), but the resource and scope are 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?
There is no indication of when to call this tool versus alternatives, nor any prerequisite such as needing to be logged in first (notably, lr_login is a sibling). It only implies usage by virtue of what data it returns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add photos to a project album. Albums the user created cannot be modified.
| Name | Required | Description | Default |
|---|---|---|---|
| album_id | Yes | ||
| asset_ids | Yes |
| Name | Required | Description |
|---|---|---|
| result | 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. It usefully discloses a hard failure condition (user-created albums reject this operation), but says nothing about permissions, duplicate handling, existing membership, batch size limits, or partial-failure behavior for an array of asset_ids.
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 short sentences, zero padding, with the core action front-loaded and the constraint immediately following. Nothing 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, and the key constraint is present. But for a mutation with no annotations and no parameter documentation, the description leaves gaps around permissions, duplicate/existing asset behavior, and limits on the asset_ids array.
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 neither parameter is documented anywhere, so the description must compensate. It only obliquely implies that asset_ids are the photos and album_id identifies the target album, giving no ID format, batch constraints, or ordering semantics.
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 ('Add photos to a project album'), which clearly separates it from lr_create_project_album and lr_delete_project_album. It does not name those siblings, but the 'project album' qualifier does establish which album subtype this applies to.
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?
'Albums the user created cannot be modified' functions as a when-not condition, telling the agent this call is only valid for project albums. However, it never explicitly routes the agent between this tool and its siblings (e.g., creating an album first), leaving usage implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a project album owned by this server (shown under Connections in Lightroom). Adds asset_ids right away if given.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| asset_ids | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It usefully reveals ownership scope, where the album surfaces in Lightroom, and that asset_ids are attached at creation time, but it omits auth/permission requirements, name-uniqueness behavior, and failure modes for a mutation 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?
Two short sentences, front-loaded with the core action and followed by the optional-parameter behavior. Every clause carries information; no 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?
An output schema exists, so return values need not be described, and the tool is simple with only two parameters. Still, for an unannotated mutation tool it leaves gaps around authentication, duplicate names, and what happens when asset_ids reference invalid or inaccessible assets.
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. It clarifies the semantics of asset_ids (assets are added immediately at creation rather than in a later call), which is genuinely useful, but adds nothing about the required name parameter or accepted ID format.
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?
States a specific verb and resource ('Create a project album') and adds a differentiating ownership detail ('owned by this server') plus the Lightroom UI location. It implicitly separates itself from lr_add_to_project_album and lr_delete_project_album, though it never names a sibling explicitly.
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 on when to create a new album versus adding to an existing one via lr_add_to_project_album, and no prerequisites (e.g., whether lr_login must run first). Usage is only faintly implied by the create verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a project album created by this server. Only the album is removed; photos stay in the catalog.
| Name | Required | Description | Default |
|---|---|---|---|
| album_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose a genuinely non-obvious trait — the album is removed but catalog photos are preserved — which is valuable. However, it omits irreversibility, required permissions, and what happens if the album does not exist.
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 tight sentences, front-loaded with the action and followed by the key side effect. No filler, no restatement of the tool name.
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 described. For a destructive mutation with no annotations, the definition covers the main data-safety concern (photos survive) but leaves permissions, reversibility, and parameter provenance 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?
There is one required parameter (album_id) with 0% schema description coverage, and the description says nothing about its format, origin, or how to obtain it (e.g., from lr_list_albums). The description therefore fails to compensate for the schema 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?
States a specific verb (Delete) and resource (project album) and scopes it to albums 'created by this server,' which distinguishes it from lr_add_to_project_album and lr_create_project_album. The clarifying clause that photos remain makes the exact effect 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?
Usage is implied by the verb and scope, but there is no explicit when-to-use guidance, no named alternative (e.g., use lr_add_to_project_album for membership changes), and no stated prerequisites. An agent can infer intent but must guess at edge cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save photos as JPEG files. Pass either asset_ids or album_id (the whole album). size: '640' | '1280' | '2048' | '2560' | 'fullsize' (original resolution with edits; slower). dest_dir defaults to ~/Downloads/lightroom/. Files are named after the original file name with a .jpg extension.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | 2048 | |
| album_id | No | ||
| dest_dir | No | ||
| asset_ids | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the side effect (writing files to disk), the default destination directory, the output file naming convention, and a performance tradeoff ('fullsize... slower'). It omits auth requirements (an lr_login sibling exists) and whether existing files at the destination are overwritten.
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?
Front-loaded with the action, then parameter semantics, then destination/naming details; every sentence adds information. The telegraphic fragment style ('size: '640' | ...') is compact, though slightly clipped relative to prose alternatives.
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 no explanation; the description covers input modes, size choices, destination default, and file naming. What is missing is only peripheral: auth expectations and overwrite/error behavior for a filesystem-writing tool.
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 schema has no enums, so the description must compensate — and it does: it supplies the full allowed size list (640/1280/2048/2560/fullsize) with resolution semantics, the either/or relationship between asset_ids and album_id, and the dest_dir default path template.
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?
States a specific verb and effect: save photos as JPEG files to local disk. This clearly separates it from read-only siblings like lr_get_photo, lr_view_photos and lr_list_photos, which retrieve rather than persist photos.
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?
Gives meaningful input-mode guidance ('Pass either asset_ids or album_id (the whole album)'), which implies the two modes are mutually exclusive. However, it never says when to prefer this tool over siblings such as lr_view_photos or lr_get_photo, and gives no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Details for one photo: capture info, rating/flag, original file, and a summary of its edits.
| Name | Required | Description | Default |
|---|---|---|---|
| asset_id | Yes | ||
| include_develop | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but 'Details for one photo' does signal a read-only retrieval, which is the main safety-relevant fact. It adds no information about permissions, catalog/account requirements, or side effects, so it is adequate rather than rich.
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 front-loaded sentence that packs the retrieval verb and the returned content with no filler. Slightly list-like rather than prose, but every clause 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?
An output schema exists, so return values need no further explanation, and the tool is a simple two-parameter read. However, the undocumented parameters and absent usage/alternative guidance leave real gaps for correct 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?
Schema description coverage is 0% and the description never mentions either parameter. 'asset_id' semantics (catalog ID, filename, or URN) are unstated, and 'include_develop' (default true) is only loosely hinted at by the phrase 'a summary of its edits' — an agent cannot tell what toggling it does.
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 clear retrieval action on a single resource ('Details for one photo') and enumerates what comes back: capture info, rating/flag, original file, and edit summary. The singular 'one photo' implicitly separates it from list-oriented siblings like lr_list_photos and lr_view_photos, though it never names them.
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?
Usage is only implied: an agent can infer this is the per-asset detail lookup versus the list tools, but the description never states when to prefer it over lr_view_photos, lr_list_photos, or lr_download_photos. No prerequisites, auth, or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List albums as 'Folder / Album' paths with their ids. query: case-insensitive substring of the path, e.g. 'kyoto' or '2024'. Folders are tagged [folder]; project albums created by this server are tagged [project].
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| include_folders | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses that matching is case-insensitive and that results are tagged [folder] vs [project], but says nothing about whether this is a safe read-only call, pagination/limits, or auth requirements. Since an output schema exists, the return-value gap is acceptable, but the operational context is thin.
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?
Short and front-loaded: the core behavior leads, then query semantics, then the tag convention. Every line carries information; only the tag sentence feels slightly detached from the rest.
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 2-parameter read tool with an output schema, the description covers purpose and matching rules, but leaves include_folders unexplained and provides no behavioral context (permissions, result size). Adequate, not 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 coverage is 0%, so the description must compensate. It explains 'query' well (case-insensitive substring of the path, with concrete examples), but 'include_folders' is never mentioned — the [folder] tagging hints at folders without clarifying what toggling the flag does. One of two parameters is effectively documented.
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?
States a specific verb and resource ('List albums') and pins down the output form ('Folder / Album' paths with their ids), plus the distinction between folders and server-created project albums. It is clearly the read/listing counterpart to the create/add/delete album siblings, though it never names an alternative.
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 statement of when to use this tool versus lr_list_photos, lr_view_photos, or the album mutation tools. The query examples imply a browse/filter workflow, but the agent must infer that this is the discovery step for album ids; no exclusions or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List photos matching filters, oldest capture first. album_id: search inside one album; omit to search the whole catalog (then narrow it with captured_after). captured_after / captured_before: 'YYYY-MM-DD' or 'YYYY-MM-DDTHH:MM:SS'. min_rating: minimum star rating (1-5). flag: 'pick' or 'reject'. camera / lens / filename: case-insensitive substrings. min_iso: minimum ISO. Each line: id | file | captured | rating | flag | exposure | camera + lens
| Name | Required | Description | Default |
|---|---|---|---|
| flag | No | ||
| lens | No | ||
| limit | No | ||
| camera | No | ||
| min_iso | No | ||
| album_id | No | ||
| filename | No | ||
| min_rating | No | ||
| captured_after | No | ||
| captured_before | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses sort order and the exact output line format, but never mentions the result-count cap or pagination behavior, even though a limit parameter with default 100 exists. A read-only listing tool needs at least that much.
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?
Front-loaded purpose sentence followed by a tight per-parameter glossary and a one-line output format; nearly every clause carries information. The parameter block reads as a run-on list, but nothing 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?
For a 10-parameter filter tool with no annotations, the description covers nine parameters plus ordering and return format, which is close to complete. The single gap is the limit parameter and its default, leaving silent truncation behavior unexplained.
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 largely does: it gives date formats for captured_after/before, the 1-5 rating range, the 'pick'/'reject' flag values, and case-insensitive substring semantics for camera/lens/filename. Only limit (default 100) is left undocumented.
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?
States a specific verb and resource ('List photos matching filters') and adds the default ordering ('oldest capture first'). It does not differentiate itself from the ambiguous sibling lr_view_photos, so an agent must still guess which of the two to pick.
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?
Usage is only implied through the album_id note ('omit to search the whole catalog (then narrow it with captured_after)'), which is a helpful narrowing hint. There is no explicit statement of when to prefer this over lr_view_photos or lr_get_photo, and no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sign in to Adobe in the browser and store tokens. Only needed when another tool reports that the user is not signed in or the token refresh failed. Waits up to 5 minutes for the user to finish signing in.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does disclose key behavior: it drives a browser interaction and blocks up to 5 minutes waiting for the user. It does not state what happens on timeout or failure, nor whether tokens persist across sessions, which are the remaining behavioral gaps.
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?
Three short sentences, each earning its place: what it does, when to call it, and the timeout constraint. The action and the trigger condition are front-loaded.
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 no explanation, and there are no parameters to document. The description covers purpose, trigger condition, and the 5-minute blocking window; only failure/timeout behavior is left unstated, a minor gap for an interactive auth tool.
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?
Zero parameters, so per the rubric the baseline is 4. There is nothing parameter-related for the description to compensate for, and it correctly avoids describing nonexistent 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?
States a specific verb and resource ('Sign in to Adobe in the browser and store tokens') that is unmistakably distinct from the read/write photo and album siblings (lr_get_photo, lr_list_albums, etc.). An agent can identify this as the authentication tool without inspecting any 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?
Explicitly limits invocation: 'Only needed when another tool reports that the user is not signed in or the token refresh failed.' This gives a concrete trigger condition and implicitly rules out proactive calls, which is exactly the when/when-not guidance an agent needs for an auth tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch photos as images to look at them (JPEG with edits applied). Up to 12 per call. size: 'thumbnail2x' (small, for scanning many) | '640' | '1280' | '2048'.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | 640 | |
| asset_ids | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It does usefully reveal the return format ('JPEG with edits applied') and a hard batch cap of 12, but says nothing about permissions, what happens if more than 12 asset_ids are passed, or error behavior.
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?
Front-loaded purpose, then the batch limit, then a compact pipe-delimited size legend. No filler, though the size line is tersely formatted and could read more cleanly.
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 two-parameter tool with no annotations and no output schema, the description covers return format, batch limit, and size semantics, which is the core. It still leaves gaps on the origin of asset_ids and on failure modes when the cap is exceeded.
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 size field has no enum, so the description is the sole source of valid size values ('thumbnail2x', '640', '1280', '2048') and explains their tradeoff ('small, for scanning many'). It also implies asset_ids is an array bounded at 12, though it never states where those IDs come from.
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?
States a specific verb and resource ('Fetch photos as images to look at them') and clarifies the payload is rendered JPEGs, which distinguishes it from metadata-oriented siblings like lr_get_photo and lr_list_photos. It never names an alternative sibling explicitly, so it falls short of a 5.
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 phrase 'to look at them' implies the use case (visual inspection rather than metadata retrieval or file download), and 'Up to 12 per call' sets a batching constraint. However, it never states when to prefer lr_get_photo or lr_download_photos instead, so usage is only implied.
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.0lr_accountlr_add_to_project_albumlr_create_project_albumlr_delete_project_albumlr_download_photoslr_get_photolr_list_albumslr_list_photoslr_loginlr_view_photosScored across 10 tools
Most tools have clearly distinct purposes: listing (lr_list_photos/lr_list_albums), inspecting (lr_get_photo), viewing (lr_view_photos), downloading (lr_download_photos), and album mutation tools. However the photo-retrieval trio (get_photo vs view_photos vs download_photos) shares overlapping territory, distinguished mainly by descriptions rather than names.
Nearly all tools follow a consistent lr_ + verb_noun pattern (list_photos, get_photo, download_photos, create_project_album). The exceptions lr_login and lr_account (noun-only, no verb) are minor deviations that remain readable and predictable.
Ten tools is well-scoped for a Lightroom client covering auth, account, photo browsing/export, and project-album lifecycle. Each tool clearly earns its place with no redundancy.
Read workflows (list/get/view/download), auth, account, and the full project-album lifecycle (create/add/delete) are covered. Notable gaps: lr_get_photo surfaces rating/flag but there is no tool to update photo rating/flag, and no tool to remove photos from an album.
Search photos and video moments by visual meaning, people, dates, and folders across local libraries, Apple Photos, and OneDrive. Manage collections, groups, favorites, people, and duplicate review. Synced metadata remains searchable while the desktop is offline; local and Apple Photos media access needs the owning device online with remote access enabled. OneDrive media can be accessed directly from the cloud. OAuth or Bearer API keys. Paid Cloud Access required; hosted visual search uses prepaid credits. Text-in-image search is semantic matching, not guaranteed exact OCR. Setup: https://organizewith.ai/en/guides/connect-ai-assistants
Generate, manage and explore your Switch AI image and video library, scoped to your account.
Travel tools for AI agents: plan and edit real trips, search stays and tours, import travel videos.
Sync Lightroom, Figma, Dropbox & Canva assets to WordPress and Shopify via natural language.
