lr-mcp

Overview Schema Source Related Servers Discussions Admin

lr_list_photos

Instructions

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. hour_from / hour_to: time of day in the camera's local capture time, 0-23 inclusive; wraps past midnight when hour_from > hour_to (e.g. 19 and 4 for night shots). max_fnumber / min_fnumber: f-number bounds, e.g. max_fnumber=2 for f/2 or wider, min_fnumber=8 for f/8 or narrower. Useful when lens info is missing (manual lenses). Photos without the needed capture time or f-number are excluded when these are set. Each line: id | file | captured | rating | flag | exposure | camera + lens

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "lr_list_photos"
  }
}

Input Schema

Name	Required	Description	Default
`flag`	No
`lens`	No
`limit`	No
`camera`	No
`hour_to`	No
`min_iso`	No
`album_id`	No
`filename`	No
`hour_from`	No
`min_rating`	No
`max_fnumber`	No
`min_fnumber`	No
`captured_after`	No
`captured_before`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv0.2.0Oct 22, 2026

addedInput schema / properties / hour_from

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Hour From"
+}

addedInput schema / properties / hour_to

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Hour To"
+}

addedInput schema / properties / max_fnumber

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Max Fnumber"
+}

addedInput schema / properties / min_fnumber

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Min Fnumber"
+}

First observedv0.1.0Oct 19, 2026

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the burden and does disclose non-obvious behavior: result ordering (oldest capture first), silent exclusion of records missing capture time or f-number, case-insensitive substring matching, and the per-line output shape. It does not disclose authentication requirements, the default result cap, or whether results are truncated.

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

Conciseness5/5

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

Front-loaded with the purpose and ordering in the first clause, then one compact line per parameter with zero filler. Given 14 undocumented parameters, the length is fully earned.

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

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 14-parameter, annotation-free listing tool with an output schema, the description covers filter semantics, edge cases, and result ordering, which is what an agent needs to call it correctly. The absence of 'limit'/pagination notes is the only remaining gap and is minor relative to the overall coverage.

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 compensate, and it largely does: it documents 13 of 14 parameters with accepted formats ('YYYY-MM-DDTHH:MM:SS'), inclusive ranges, wrap-around semantics for hour_from/hour_to, and the physical meaning of max_fnumber/min_fnumber. The notable gap is 'limit' (default 100), which is never mentioned, so an agent cannot know results may be silently truncated.

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?

States a specific verb and resource ('List photos matching filters') plus a default ordering ('oldest capture first'), so the agent knows exactly what operation this performs. It does not explicitly differentiate itself from ambiguous siblings like lr_view_photos or lr_get_photo, leaving the agent to infer that this is the filter/search-oriented lister.

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

Usage Guidelines4/5

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

Gives concrete usage context: omit album_id to search the whole catalog, then narrow with captured_after; and notes that photos lacking the needed capture time or f-number are excluded when those filters are set. That is clear guidance on how to compose the filters, but there is no explicit statement of when to prefer this over lr_view_photos or lr_get_photo.

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

Deploy Server