rawtherapee-mcp-server

by lucamarien

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.4
Disambiguation4/5
Most tools have clearly distinct purposes with detailed descriptions. However, the large number of preview and local adjustment tools could cause minor confusion, e.g., differentiating preview_raw from preview_with_adjustments.
Naming Consistency5/5
Tool names follow a very consistent verb_noun pattern (e.g., add_device_preset_tool, adjust_crop_position, list_templates). A few exceptions exist (e.g., analyze_image instead of analyze_image_metadata) but overall highly predictable.
Tool Count2/5
With 49 tools, the server is overpopulated. While RawTherapee is complex, this number exceeds typical MCP server scopes (per guidelines, 25+ is too many) and may overwhelm agents.
Completeness5/5
The tool set covers the full RAW processing workflow: metadata, profiles (create/read/update/delete), local adjustments, presets, templates, batch processing, lens correction, LUTs, and export. No obvious gaps for the domain.
Average 3.8/5 across 49 of 49 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'Process multiple RAW files' without indicating side effects, required permissions, or whether files are modified. 'Process' is vague and fails to inform the agent about destructive or nondestructive behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point, with two sentences and a parameter list. The param list is somewhat tacked on but does not waste words. It is well front-loaded with the key purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description does not mention what the tool returns (e.g., processed file paths or status). It also lacks notes on error handling, batch size limits, or performance considerations, leaving gaps for an AI agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description only lists parameter names without explaining their meaning or constraints (e.g., what 'device_preset' does). It adds minimal value beyond the schema, failing to compensate for the lack of schema descriptions.
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 clearly states 'Process multiple RAW files with the same PP3 profile', specifying the action and resource. It distinguishes from single-file processing tools like process_raw, but could be more precise about what 'process' entails (e.g., conversion to output format).
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?
The description says 'Use this for bulk processing of a set of RAW files with identical settings', providing context. However, it does not explicitly mention when not to use it (e.g., for files with different settings) or point to alternatives like process_raw for individual files.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It mentions JPEG generation and inline return but omits key behavioral details: file location, persistence, permissions, destructiveness. Creating a file implies mutating state, yet no clarification.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Relatively concise at four sentences. Front-loads purpose. Slight repetition of 'preview', but overall efficient. No wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-param tool with no output schema or annotations, the description is incomplete. It does not specify the return format (path vs. data URI) when return_image is False, nor does it clarify the behavior of optional parameters. Gaps leave an AI agent uncertain about expected output and parameter handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It lists four parameter names but provides no additional semantics: no types, ranges, formats, or examples. For instance, max_width lacks unit or bounds; file_path lacks path format.
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?
Clearly states it generates a small preview JPEG for visual analysis of RAW files with processing settings. Mentions composition, exposure, color. However, does not explicitly differentiate from other preview tools like preview_with_adjustments or preview_before_after, leaving some ambiguity.
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?
Describes the use case for quick previews and mentions inline return when return_image is True. But lacks when-not-to-use guidance or alternatives among sibling preview tools. Implicit usage but no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It states that the tool writes a LensProfile section into the profile, revealing its side effect. However, it lacks details on safety, permissions, or error conditions, making it moderately transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with one sentence per key aspect and a clear parameter list. It is well-structured and easy to parse, though it could be slightly more efficient by removing the redundant param list header.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, modifies profile) and lack of output description, the description covers the main function and modes. However, it omits details about return values, error handling, and full parameter semantics, making it adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 8 parameters with 0% description coverage. The description lists all parameters and explains mode values ('auto'|'lcp'), but does not clarify the effect of boolean parameters like correct_distortion or defaults beyond what schema shows. This adds minimal meaning beyond the schema.
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 clearly states it applies lens correction to a PP3 profile and specifies two modes (auto and lcp). It differentiates from siblings like check_lens_support by focusing on application rather than checking, though not explicitly.
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?
The description explains when to use each mode: auto for automatic detection from RAW EXIF, lcp for specifying an .lcp file. It does not provide when-not-to-use or alternatives, but the guidance is clear enough for typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden but lacks critical behavioral details. It explains intensity scaling but does not disclose mutability, whether it overwrites existing settings, or what happens when save_as is null. Insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and front-loaded with the main purpose. Lists presets and intensity scaling efficiently. The param list is slightly redundant given the schema but not wasteful. Good structure overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters and an output schema (not explained), the description is moderately complete but lacks behavioral transparency about saves and overwrites. Could be more comprehensive for a mutation tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Lists available presets and explains intensity scaling, adding meaning beyond the schema. However, schema coverage is 0%, and profile_path, preset, and save_as are not described besides listing them. Partially compensates, but gaps remain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it applies a predefined local adjustment preset to a PP3 profile, specifying the resource and action. It distinguishes from siblings like 'apply_lut' or 'apply_template' by focusing on local adjustments and listing specific presets.
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?
Implies usage for local adjustment presets but does not explicitly state when to use this tool versus alternatives like 'apply_template' for global adjustments. No when-not or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals that the tool writes the [Film Simulation] section, adding behavioral context. However, it does not disclose side effects, irreversibility, or permissions needed. With no annotations, the description should provide more, but it is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences logically ordered: purpose, then detail, then parameter hints, then parameter listing. No wasted words, but could be more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description need not explain returns. However, it omits guidance on save_as default behavior and edge cases. Among many sibling tools, the description is adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden. It clarifies lut_name as relative path from RT_HALDCLUT_DIR and strength as blend intensity (0-100), but profile_path and save_as remain unexplained. Partial compensation.
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 clearly states the tool applies a HaldCLUT film simulation LUT to a PP3 profile and writes the [Film Simulation] section. It is specific in verb and resource, but does not differentiate from sibling tools like preview_lut or preview_lut_comparison.
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?
The description gives usage hints for lut_name path and strength range, but lacks explicit guidance on when to use this tool versus alternatives, no when-not or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a destructive action (delete) and notes a restriction (only custom presets), but lacks details on reversibility, permissions, or side effects. With no annotations, the description carries full burden and is minimally adequate.
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 description is relatively short but includes a redundant 'Params: preset_id' line that adds no new information, reducing conciseness.
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?
Given only one parameter and an existing output schema, the description covers core functionality and restrictions. It is mostly complete for a simple deletion tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must add meaning. It merely lists 'preset_id' without explaining its role or format, adding no value beyond the schema.
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 clearly states the action ('delete') and the resource ('custom device preset'), and distinguishes it from built-in presets. It is specific and actionable.
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?
Explicitly instructs to use for custom presets and warns that built-in presets cannot be deleted, providing clear guidance on when to use and when not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry full burden. It explains that numeric values are interpolated and non-numeric values are taken from the nearer profile, but does not discuss side effects like file creation, overwrite behavior, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise with a clear first sentence. The param list at the end is helpful given no schema descriptions, but it is somewhat unstructured and could be formatted better.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations or output schema, the description is incomplete. It does not explain what the tool returns, any prerequisites, or error handling. For a tool with 7 parameters, this lacks completeness for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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. It lists all 7 parameters but only explains 'factor' (0.0 gives A, 1.0 gives B). Other parameters like 'profile_a' and 'file_path' have no added meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Blend two PP3 profiles by linear interpolation,' specifying the verb (blend), resource (PP3 profiles), and method. This distinguishes it from siblings like 'compare_profiles' or 'create_profile_variant' which have different purposes.
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?
The description says 'Useful for creating intermediate looks between two processing styles,' which implies the use case. However, it does not provide explicit when-not-to-use guidance or mention alternative tools for similar tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description conveys that it renders multiple previews with Kelvin temperature reference, but it lacks details on side effects, performance, output format, or limitations beyond RAW files.
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 description is short with a front-loaded purpose, but the param list is redundant with the schema and adds clutter, making it slightly less concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description partially explains that multiple renders are produced with Kelvin reference, but it omits details on return format (e.g., images vs. JSON) and how outputs are presented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description only lists parameter names without explaining valid values (e.g., preset options) or how max_width affects output, adding minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool previews different white balance presets on a RAW file for comparison, distinguishing it from other preview tools like preview_raw or preview_with_adjustments.
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?
The description implies usage for choosing white balance but does not explicitly state when not to use it or mention alternative tools like preview_raw or preview_lut.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the deletion and re-indexing behavior, which is useful. However, without annotations, it lacks details on side effects, permissions required, or error conditions.
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?
Two sentences plus param list, no fluff. Front-loaded with purpose and key behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core functionality and re-indexing but omits parameter details and usage context. Adequate but with gaps given the tool's mutation nature and 3 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Lists parameter names but provides no explanation of their meaning, format, or constraints. With 0% schema description coverage, the description fails to add value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb 'Remove' and resource 'Locallab spot from a PP3 profile' clearly defines purpose. Distinguishes from siblings like 'add_local_adjustment' or 'adjust_local_spot'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no exclusions or prerequisites mentioned. Only states what it does, not when it should be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does not mention whether saving overwrites existing templates, permission requirements, or side effects. Only that it saves, which is already implied by the name.
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 description is concise but includes redundancy (e.g., 'Save an existing PP3 profile' and 'save a tuned profile'). The parameter list is embedded in a sentence rather than formatted, reducing readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/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 are covered. However, the description omits prerequisites (e.g., profile existence) and error behavior (e.g., duplicate names). While functional, it leaves gaps for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should add meaning to parameters. It merely lists parameter names (profile_path, name, description) without explaining their purpose, format, or constraints, such as the required path or uniqueness of name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Save an existing PP3 profile as a reusable custom template,' providing a specific verb and resource. It distinguishes the tool from siblings by mentioning reuse with 'apply_template' and 'generate_pp3_profile'.
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?
It advises use for saving tuned profiles for later reuse and names specific alternatives (apply_template, generate_pp3_profile). However, it does not explicitly mention when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It explains that the adjustment only affects pixels within the specified brightness range, which is good. However, it does not disclose whether creating a new spot overwrites existing spots or if multiple spots can be added. The behavior regarding file modification (saving) is partially covered by the save_as parameter, but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for adjustment_type, parameters, and luminance_range. It is somewhat verbose but front-loaded with the core purpose. Every sentence provides useful information, though some redundancy exists (e.g., repeating 'custom' context).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity (8 params, nested objects, no annotations), the description covers most key aspects. However, it lacks details on the transition, strength, spot_name, and save_as parameters, and does not explain the output schema referenced in the context. The behavioral aspect of whether multiple adjustments can be stacked is also missing.
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?
The schema has 0% description coverage, so the description adds significant value. It details the valid values for adjustment_type (shadows, midtones, highlights, custom) with approximate luminance ranges, lists all parameter keys and their value ranges, and explains the structure of luminance_range for custom types. This goes well beyond the bare schema.
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 clearly states the tool adds a luminance-based local adjustment to a PP3 profile and explains that it creates a Locallab spot targeting a specific luminance range. While this distinguishes it from sibling tools like adjust_local_spot or apply_local_preset, it does not explicitly contrast with them, so a 4 is appropriate.
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?
The description implies use cases such as shadow recovery or highlight compression, but it does not provide explicit guidance on when to use this tool versus alternatives like adjust_local_spot or apply_local_preset. It also lacks when-not-to-use instructions, so the guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions returning an inline thumbnail when include_preview is True, but does not disclose side effects like file output behavior or whether the original is modified. Missing key behavioral details for a processing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus a parameter list. The list is somewhat redundant but helpful. Front-loaded with purpose. Could be slightly more concise by integrating parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no output schema, and no annotations, the description is too sparse. It explains only a few parameters and omits details on defaults, behavior of output_dir, preview_max_width, and return values beyond the thumbnail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description adds meaning for template_name (built-in or custom), device_preset (crop/resize), and include_preview (returns thumbnail). Other parameters like file_path, output_format, output_dir, preview_max_width lack explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool applies a PP3 template to a RAW file for quick processing with a predefined style. It distinguishes itself from sibling tools like 'apply_local_preset' or 'apply_lut' by focusing on full templates.
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?
Explicitly says 'Use this for quick processing with a predefined style', providing a clear when-to-use. However, it does not mention when not to use or contrast with alternative tools like 'process_raw'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it computes histograms, statistics, and clipping percentages, and optionally includes an SVG. It is read-only and does not modify data. Without annotations, this adds value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and front-loaded with the main purpose. The 'Params' line is slightly redundant but not harmful. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the main outputs and file types. With an output schema present, it is fairly complete but lacks details on file_path requirements and edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only lists parameter names ('file_path, include_svg') without explaining expected formats, values, or behavior. Schema coverage is 0%, so description does not compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it computes RGB histograms and image statistics for processed images of specific formats. It also lists the returned data, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus sibling analysis tools like 'analyze_image' or 'get_image_info'. It implies tonal analysis but lacks explicit usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the profile is updated in-place and accepts named positions or pixel offsets, but lacks details on bounds checking, success/failure signals, or side effects. With no annotations, additional behavioral context would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at four sentences with front-loaded purpose. The parameter list at the end is helpful, though slightly redundant. Could be more tightly structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core action but omits return value, error scenarios, and interaction with other tools. Given 6 parameters and no output schema, it is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/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. It explains horizontal and vertical (named positions or offsets) but only lists other parameters without elaboration. This provides partial meaning but is insufficient for all six parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('reposition an existing crop') and the resource ('PP3 profile'), distinguishing it from sibling tools like adjust_local_spot or adjust_profile. The verb is specific and the scope is well-defined.
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?
The description implies usage for repositioning crops but does not specify when to use this tool versus alternatives like adjust_profile or analyze_image. No exclusion criteria or prerequisites are mentioned, leaving guidance implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It only states that the tool generates preview thumbnails, which is a read-like operation, but does not disclose any other behavioral traits such as error handling, performance, or whether any files are modified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately sized with a clear first sentence for purpose, a second paragraph for context, and a param list at the end. It is efficient but could be more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and no annotations, the description covers purpose and use cases. However, it lacks information about the output format (e.g., whether previews are returned or saved) and does not explain all parameters in detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/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. It lists all parameters at the end and explains include_exif, but other parameters like file_paths, profile_path, max_width, and max_images are only listed by name with no additional meaning beyond their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear verb and resource: 'Generate small preview thumbnails for multiple RAW files.' It distinguishes from sibling tools like batch_process and process_raw by emphasizing quick scanning and previews.
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?
The description provides explicit use cases: 'selecting images from a series or verifying batch settings before full-resolution processing.' This gives clear context for when to use the tool, though it does not explicitly state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions output filenames include device name and preview behavior, but does not disclose whether the original file is modified, required permissions, or side effects like file creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with purpose, no wasted words. The parameter list at the end is useful but could be better structured as bullet points.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no output schema, and no annotations, the description lacks details on output location, error handling, and expected results. The core functionality is covered, but contextual gaps remain for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description lists all 7 parameters and explains include_previews meaning. However, it does not explain the role of device_presets or constraints like output_format values, adding only marginal value beyond the schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it exports a RAW file optimized for multiple devices in one call, with device-specific crop/resize. This verb+resource combination distinguishes it from siblings like process_raw and batch_process.
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?
Implies usage for batch exporting to multiple devices but lacks explicit when-to-use or when-not-to-use guidance. No alternatives are named, and the distinction from siblings like batch_process is not clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 implies a read-only operation ('get', 'check') and reveals that including the thumbnail returns an inline image, but it does not disclose failure modes, required permissions, or whether the file must already exist. Some behavioral context is given but incomplete.
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?
The description is three concise sentences that immediately state the purpose and supported formats. The parameter list is appended without redundancy. No wasted words, and the most important information is front-loaded.
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?
Given the tool's simplicity and lack of output schema, the description adequately covers what the tool returns (dimensions, format, file size, bit depth, optional thumbnail) and specifies supported file types. It does not detail error handling or return structure, but for a read-only info tool, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only lists parameter names at the end. It provides semantic meaning only for include_thumbnail (explaining it returns an inline thumbnail), but file_path and thumbnail_max_width are left unexplained beyond their names. This is minimal additional value over the schema.
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 clearly states the tool retrieves technical information (dimensions, format, file size, bit depth) from processed image files, distinguishing it from sibling tools like read_exif or get_histogram by the specific attributes listed. It does not explicitly compare to siblings but the scope is well-defined.
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?
The description explicitly says 'Use this to check dimensions, format, file size, and bit depth', providing clear context for when to invoke this tool. However, it does not mention when not to use it or point to alternatives for other types of information, lacking exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool generates preview images at different EV values and lists parameters. However, it lacks details on side effects (likely none), permissions, or what happens to existing data. The simulation behavior is clear but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long and front-loaded with the main action. The parameter list at the end is somewhat redundant but not excessive. It is concise and structured well, though it could omit the parameter listing to avoid redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description should explain return format and behavior. It mentions generating preview images but does not specify how they are returned (e.g., base64, URLs). It also omits details on how 'stops' affects output. This leaves gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description only lists parameter names without explaining their semantics. For example, 'stops' as an array of numbers is ambiguous, and 'profile_path' and 'max_width' lack context. The description adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool simulates exposure bracketing by rendering multiple EV previews, using specific verbs (simulate, render) and resource (EV previews). It effectively distinguishes itself from sibling preview tools like preview_raw or preview_white_balance by focusing on exposure bracketing.
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?
The description explains it is useful for determining optimal exposure before a full-resolution render, providing clear context. While it does not explicitly list when not to use or alternatives, the purpose alone guides appropriate usage among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool returns an inline thumbnail when include_preview is True and mentions the profile controls parameters. However, it does not discuss side effects (e.g., file overwriting), authentication needs, or the main return value when thumbnail not requested.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise with 4 sentences, starting with the main action and then elaborating. The param list is included but could be more structured (e.g., bullet points). Still, it is not verbose and front-loads key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters and no output schema, the description is incomplete. It does not explain the return value when include_preview is False, nor does it specify constraints on output_format or quality settings. Missing details on profile requirements or output behavior leave gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate. It lists all 8 parameter names but only adds meaning for 'include_preview' (returns thumbnail). No explanations for allowed values, defaults, or constraints on other parameters like output_format, jpeg_quality, or bit_depth. The bare list is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: processing RAW files with a PP3 profile to convert to JPEG, TIFF, or PNG. It specifies the verb ('process'/'convert'), resource, and method. This distinguishes it from siblings like 'preview_raw' or 'batch_analyze' which serve different purposes.
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?
The description provides a clear usage context: 'Use this to convert a RAW file to JPEG, TIFF, or PNG using a PP3 profile.' It implies when to use but does not explicitly exclude alternatives or mention when not to use. This meets the 'clear context, no exclusions' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes outputs but does not explicitly state that the tool is read-only or non-destructive. However, the nature of analysis implies safety; a statement about side effects would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with two paragraphs and a param list. The param list is almost redundant with the schema, but the overall structure is clear and front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description provides a good high-level overview but lacks details on parameter behavior and response structure. For a comprehensive tool, more detail on outputs would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description only lists parameter names without explaining defaults, types, or purposes. The mention of 'histogram statistics' and 'inline thumbnail' hints at the boolean params, but no concrete parameter semantics are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Comprehensive single-call analysis of a RAW or processed image' and lists the combined outputs (EXIF, processing recommendations, histogram, thumbnail). This distinguishes it from sibling tools like get_histogram or read_exif which are more focused.
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?
Explicitly advises use for 'initial assessment of an image before deciding on processing settings', giving clear context. Lacks explicit exclusions or alternatives, but the context is sufficient for guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that built-in templates cannot be deleted, but does not detail irreversible nature, permissions, or error handling. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three lines: purpose, usage, and param list. However, the param line is redundant with the schema, slightly detracting from conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with an output schema, the description is fairly complete but misses constraints like case sensitivity or error cases (e.g., template not found). Could be improved for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It only mentions 'Params: template_name' without explaining format, validation, or role, adding little beyond the schema field name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a custom PP3 template' with a specific verb and resource, and distinguishes from built-in templates which cannot be deleted, aligning well with sibling tools like delete_device_preset.
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?
The description provides clear guidance: 'Use this to remove a custom template that is no longer needed. Built-in templates cannot be deleted.' It gives context on when to use but does not compare to alternatives like delete_device_preset.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses that it lists data and shows relationships, but does not mention any side effects, permissions, or output specifics like pagination, which is adequate for a read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences and a params line, front-loading the main purpose. The params line is slightly redundant with the schema, but overall efficient.
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?
Given the low complexity (one optional parameter) and the existence of an output schema, the description adequately covers the tool's functionality, including the context of the inheritance system and the data returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the single parameter 'parent_profile'. The description adds that it is an optional filter, which provides some meaning beyond the schema's type and default definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists profile variants and shows parent->variants relationships with override summaries and effective PP3 paths, distinguishing it from sibling tools like 'create_profile_variant' or 'compare_profiles'.
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?
The description mentions an optional filter by parent_profile, implying it's for viewing existing variants, but does not explicitly state when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 describes the output format (grayscale mask) but does not explicitly state it is read-only or mention any side effects, permissions, or rate limits.
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?
The description is exceptionally concise, using two sentences and a parameter list. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters and no output schema. The description explains the output's visual meaning but omits parameter details (e.g., defaults, roles) and does not cover behavioral aspects like idempotency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description only lists parameter names without any explanation of their meaning (e.g., what profile_path or spot_index represent). This fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states 'Preview a luminance mask' with a clear explanation of the grayscale output. Distinguishes itself from sibling tools like preview_lut or preview_before_after by focusing on luminance masking.
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?
Provides a clear use case: 'verify the luminance range targets the correct tonal areas before processing.' Though it doesn't list exclusions or alternatives, the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates returns all sections and key-value pairs, but does not explicitly state it is non-destructive, which is important given no annotations. However, the read-only nature is implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is mostly concise with three focused sentences, but the redundant 'Params: profile_path' line marginally harms structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with output schema, the description covers purpose and return value but lacks parameter details and behavioral assurances like non-destructiveness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description only mentions the parameter name without describing its format or constraints, despite 0% schema coverage, so it adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool displays a PP3 profile in human-readable format for inspection, differentiating it from sibling tools that modify or compare profiles.
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?
The description explicitly recommends using this tool to inspect profiles before applying, providing clear context. It does not contrast with siblings but the use case is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the fallback behavior for device_preset (cropping vs resize-only), which is valuable. But it does not mention potential side effects like overwriting existing profiles, authorization needs, or the output structure (though output schema exists). More behavioral context would be helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise with three sentences plus a parameter list. The final line 'Params: ...' is somewhat redundant given the schema, but overall it is not overly verbose. Could be slightly tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and a key behavioral nuance, but lacks completeness for a 6-parameter tool with no annotations. Missing context such as naming constraints, overwrite behavior, or prerequisites. The output schema exists but is not referenced.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It adds meaning for base_template (starting point) and device_preset (cropping behavior). However, it merely lists parameter names without explaining the 'parameters' object structure, file_path role, or description usage. The added value is partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a PP3 processing profile for RAW development. It specifies the action (Create) and the resource (PP3 profile), and distinguishes itself from sibling tools like 'adjust_profile' or 'apply_template' which modify or apply existing profiles.
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?
The description explains when to use the tool: to generate a new processing profile. It provides two usage modes (with base_template or from scratch) and highlights a critical behavior difference for device_preset with/without file_path. However, it does not explicitly mention when not to use it or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must describe behavior. It implies read-only via 'list' but does not explicitly confirm non-destructiveness or mention auth/rate limits. Adequate but could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise three sentences that front-load purpose and list output fields. The 'Params: profile_path' line is slightly redundant but not harmful. Every sentence earns its place.
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?
Given one required parameter and existence of output schema (context signal), description covers main points: what it does, what it returns, and when to use. Could mention prerequisites like file existence, but generally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% with no parameter description. Description only mentions 'profile_path' without explaining what it is (e.g., path to .pp3 file). Adds minimal value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb ('List') and resource ('all Locallab spots'), and clarifies output details. It distinguishes from sibling tools like remove_local_adjustment and adjust_local_spot by focusing on inspection.
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?
Explicitly states 'Use this to inspect local adjustments before previewing or modifying them', giving clear context for when to use. Lacks explicit exclusions but implies appropriate timing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It accurately describes a read operation with no side effects, but lacks details on error handling, file compatibility beyond RAW, or performance considerations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a parameter note. Purpose is front-loaded, and the second sentence adds value. The 'Params:' line is slightly redundant but not harmful. Overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return details are less critical. Description lists sample returned fields, which is good. Missing details: error handling, file existence checks, or whether non-RAW files are rejected. Could be more thorough for a tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has one parameter (file_path) with no description. The description adds 'Params: file_path' but does not explain its format, constraints, or behavior (e.g., absolute vs relative path). For a single obvious parameter, this is baseline value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (read EXIF metadata), the resource (RAW image file), and lists specific metadata fields (ISO, aperture, etc.). Distinguishes from siblings like inspect_metadata and get_image_info by targeting EXIF specifically from RAW files.
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?
Provides a clear use case: informs processing decisions like noise reduction and lens correction. However, it does not explicitly compare to alternatives or state when not to use it, missing some usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It mentions 'without removing and re-adding it' hinting at non-destructive behavior, but lacks details on side effects, permission needs, immediate application, or save_as behavior. Moderate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose. It lists changeable aspects and then parameters. The parameter list is somewhat redundant with schema but helpful given no schema descriptions. No wasted sentences.
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 are covered externally. The description specifies required and optional inputs adequately for a modification tool. It does not mention error cases or invalid spot_index, but given the complexity (7 params), it is reasonably complete.
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 compensates by listing all parameter names and their general purpose in a sentence. It adds meaning beyond the schema, but does not explain structures of parameters or luminance_range objects fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it modifies an existing Locallab spot in a PP3 profile, listing specific changeable aspects (processing parameters, luminance range, strength, enable/disable). This distinguishes it from sibling tools like add_device_preset_tool or remove_local_adjustment.
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?
The description implies usage for modifying an existing spot without removing/re-adding, but does not explicitly state when to use versus alternatives or provide any when-not-to guidance. Sibling tools are not compared.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 discloses key behaviors: merging overrides, writing to a specific file path, and tracking in profile_hierarchy.json. However, it does not mention whether validation occurs, permissions needed, or potential side effects beyond file creation. A bit more detail would be ideal, but the current disclosure is strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact paragraph with clear front-loading of purpose, followed by process and parameters. It could be slightly more concise by removing the 'Params:' listing that partially repeats the schema, but it remains efficient overall.
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?
Given the tool has 4 parameters, no annotations, and an output schema (not shown), the description covers the merging logic, file output, and hierarchy tracking. It does not describe the return value explicitly, but the output schema likely handles that. The description feels sufficiently complete for a creation tool with moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameter descriptions (0% coverage), so the description compensates by listing parameters and providing an example for 'overrides'. However, it does not fully describe constraints for 'parent_profile' (name vs path), 'variant_name' (allowed characters), or 'description' format. The example helps, but ambiguity remains.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Create a child PP3 profile variant derived from a parent template,' which clearly states the action and resource. The details about merging overrides and tracking relationships further clarify what the tool does, distinguishing it from siblings like 'generate_pp3_profile' or 'apply_template'.
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?
The description explains the process but lacks explicit guidance on when to use this tool versus alternatives. Users must infer from context when to choose this over similar siblings like 'update_base_profile' or 'generate_pp3_profile'. No when-not-to-use or alternative references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explains the return structure (dict with files list and count) and names the parameters. However, it does not disclose behavioral details like whether the operation is read-only or potential error conditions, which would enhance transparency.
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?
The description is concise: three sentences front-loaded with the purpose. No redundant sentences, and every sentence adds value. It is well-structured for quick parsing.
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?
Given the tool's simplicity, an output schema exists, and the description explains the return format. It mentions supported RAW files but could be more explicit about which extensions are supported. Still, it is complete enough for the use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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. It only lists parameter names and notes the default for 'recursive'. For 'directory', no additional semantics (e.g., path format) are given. This adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'scan' and the resource 'directory for supported RAW image files', and the use case 'discover which RAW files are available for processing'. This effectively differentiates it from siblings like 'list_output_files' which handle output files.
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?
The description explicitly says 'Use this to discover which RAW files are available for processing', providing clear context for when to invoke the tool. However, it lacks explicit exclusions or alternatives, such as noting when to use 'list_output_files' instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the dual render and inline return of images, but does not mention side effects, permissions, or data limitations. Adequate but not comprehensive.
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?
The description is concise with three short sentences front-loading purpose, explaining process, and listing parameters. No redundant information.
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?
For a tool with 3 params and no output schema or annotations, the description is mostly complete. It explains the dual render and output format (inline images). Missing details like error handling or proof of read-only nature, but sufficient for basic understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 lists the three parameter names but provides no additional meaning or explanation beyond what the names imply. For example, it does not specify file_path as path to RAW file or what max_width controls.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates before/after preview images to compare processing effects, specifying the action and resource. It explains the dual render of a RAW file with default and specified settings, distinguishing it from siblings like preview_raw or compare_profiles.
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?
The description implies when to use (to compare processing effects) but does not explicitly state when not to use or differentiate from alternatives like compare_profiles or preview_lut_comparison. It provides clear context but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility. It discloses that the tool returns per-image EXIF data, processing recommendations, and summary histogram statistics (mean, clipping) without full 256-bin channel data or SVG, and optionally includes small thumbnails. This provides good insight into what is included and excluded, though it does not mention side effects (likely read-only) 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the main purpose front-loaded in the first sentence. It efficiently conveys the tool's value, outputs, and optional features. The parameter list at the end is clear, though a brief explanation of each parameter's role could enhance conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description covers the core outputs (EXIF, recommendations, stats, optional thumbnails) but omits details on output structure, error handling, or ordering of results. For a batch tool with 4 parameters and no output schema, this leaves some gaps for an agent expecting precise response format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/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. It lists parameter names and the description mentions that include_thumbnails controls optional thumbnails and thumbnail_max_width sets their size. However, it does not explain file_paths format or max_images semantics beyond the defaults in the schema, leaving some ambiguity for an AI agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs batch analysis of multiple images, listing specific outputs: EXIF data, processing recommendations, and summary histogram statistics. It also distinguishes itself as a lightweight alternative to calling analyze_image N times, differentiating it from sibling tools like analyze_image.
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?
The description explicitly frames this tool as a lightweight alternative to calling analyze_image N times, providing context for when to use it over the single-image counterpart. However, it does not mention when not to use it or compare with other batch tools like batch_preview or batch_process, leaving some ambiguity around alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It does not disclose behavioral traits such as being read-only, permission requirements, or output structure. However, the operation is inherently simple and non-destructive, so the lack of detail is less critical.
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?
The description is very concise: three sentences, no fluff. The purpose is front-loaded, and the param list is appended efficiently. Every sentence earns its place.
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?
The tool is simple (list files with two optional filters) and has an output schema, so the description need not detail return values. It covers purpose, usage, and basic param info, which is largely sufficient for this low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/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. It lists the two parameters and gives example values for format_filter ('jpeg, tiff, png'), but does not explain what the parameters do (e.g., that format_filter filters by format). This adds some value but is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the purpose: 'List processed output files in the output directory.' It specifies the verb 'list' and the resource 'processed output files,' and differentiates from the sibling 'list_raw_files' by focusing on output files from processing.
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?
The description includes a usage hint: 'Use this to see what images have been processed and are available.' This implies when to use it, but does not explicitly state when not to use it or mention alternatives like 'list_raw_files'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully bears the burden of disclosure. It explains sequential rendering, return of all thumbnails, labeling, and typical render time (2-5s per LUT). It does not discuss destructive effects, but as a preview tool, this is acceptable. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with 4 sentences plus a param list. The first sentence captures the purpose, the second explains behavior, the third provides performance expectations. The param list adds context but is somewhat redundant with the schema. Overall, it is well-structured and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and no annotations, the description covers purpose, behavior, and param hints. Missing details: what 'base_profile' is, units for 'max_width', and exactly what the output (thumbnails) looks like. Adequate for a preview tool but with minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/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. It provides a list of parameters with brief explanations: 'lut_names (list of 2-5 LUT relative paths)', 'strength (0-100)', 'max_width (per image)'. This adds meaning but does not explain 'file_path' or 'base_profile' in detail, leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Render side-by-side inline previews for 2-5 HaldCLUT LUTs for quick comparison', which is a specific verb+resource combination. This distinguishes it from sibling tools like 'preview_lut' (single LUT) and 'compare_profiles' (profile comparison).
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?
The tool's purpose is clear for quick LUT comparison, but no explicit guidance is given on when to use versus alternatives like 'preview_lut' for a single LUT or 'batch_preview' for batch processing. The context is implied but not formally structured.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not explicitly state read-only behavior, but 'inspect' implies no side effects. It could be improved by confirming no modifications or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with categories of returned data and a clear params section. It is longer than necessary but every sentence adds value. Could be slightly tightened without losing information.
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?
Given the output schema exists (handling return structure), the description covers purpose, data categories, and param constraints. It lacks details on error handling or limits, but is sufficient for selecting and invoking this tool correctly.
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 coverage is 0%, but the description adds critical constraint: file_path must be an exported JPEG or TIFF. This compensates for the missing schema description, though format or path examples could further aid.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it inspects EXIF metadata, classifies by sensitivity, and lists specific categories (GPS, serial numbers, camera settings, etc.). This distinguishes it from siblings like read_exif (raw EXIF) or strip_metadata by adding classification and privacy recommendations.
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?
The description implies usage for inspecting exported JPEG/TIFF metadata with sensitivity classification. It does not explicitly mention when not to use (e.g., for raw files) or alternatives like read_exif, but the context is clear and the tool's unique value (classification) is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides valuable behavioral details: writes losslessly to EXIF APP1 segment, no JPEG recompression, and keywords stored as XPKeywords in UTF-16LE semicolon-separated format. However, it omits failure modes (e.g., file write errors, missing EXIF segment).
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?
Two concise paragraphs; the first sentence fronts the core purpose. Every sentence adds value (technical detail on EXIF, keyword format, param listing). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers main behavior adequately given 6 parameters and no annotations, but lacks details on the output (has an output schema not mentioned) and edge cases (e.g., what happens if file is not JPEG or locked). It is functional but not exhaustive.
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 coverage is 0%, so the description must compensate. It lists all 6 parameters, explains the purpose of each, gives an example for copyright, and notes that keywords is a list and output_path defaults to in-place. This adds significant meaning beyond the schema's bare type definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes metadata (copyright, artist, description, keywords) into an exported JPEG file. The verb 'write' and specific resource 'JPEG file' are precise, and it distinguishes itself from siblings like 'strip_metadata' and 'inspect_metadata' by focusing on writing.
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?
The description implies usage for writing metadata but lacks explicit when-to-use or when-not-to-use guidance. No mention of alternatives like 'strip_metadata' for removal or 'inspect_metadata' for reading, nor any prerequisites (e.g., file must be a JPEG).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes reading EXIF and parsing XML database, but lacks details on side effects, authorization needs, or error conditions. No annotations to supplement.
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?
Concise, front-loaded with main purpose, every sentence adds value. No redundant information.
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?
Covers core behavior and parameters adequately; return value not detailed (output schema exists). Could mention output format but not essential.
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 has 0% description coverage; description lists all parameters and briefly explains each, adding meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool checks if a camera/lens combination has a Lensfun calibration profile. Uses specific verb and resource, and contrasts with sibling tools like apply_lens_correction.
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?
Explains two modes of use (auto-detection via file_path or manual params). Does not explicitly state when not to use, but contextually clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 discloses that when file_path and include_preview are provided, the tool 'renders both profiles as inline images for visual comparison'. This is a key behavioral trait beyond what the input schema conveys.
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?
The description is very concise: three main sentences plus a parameter list. Every sentence adds value, and the core purpose is front-loaded. No unnecessary words.
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?
Given the absence of annotations and output schema, the description covers the main purpose, usage context, and the preview feature. It does not explicitly describe the output format (textual diff? images?), but the mention of 'show the differences' and 'renders as inline images' provides sufficient expectation for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It lists all five parameters and explains the role of file_path and include_preview in enabling visual preview. However, the required parameters profile_a and profile_b lack details on their format (e.g., file path vs. profile ID), leaving ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('compare two PP3 profiles and show the differences') and the resource ('PP3 profiles'). It provides specific use cases ('before choosing between them' or 'to see what changed after adjustments'), which distinguishes it from sibling tools like adjust_profile or read_profile.
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?
The description gives explicit context for when to use the tool: 'before choosing between them' or 'to see what changed after adjustments'. It does not explicitly state when not to use it or mention alternatives, but the guidance is clear and helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states it creates a neutral base template and mentions the AI's role in calling generate_pp3_profile, but does not disclose side effects (e.g., saving, permissions) or details on what 'creates' implies. Moderate transparency.
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?
Each sentence adds value: purpose, usage scenario, interpretation process, and parameter list. No wasted words, front-loaded with purpose. The description is concise and well-structured.
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?
Covers purpose, usage, and parameters. With an output schema present (not shown), return values are likely documented. Could include more on behavioral details (e.g., saving), but overall adequate for the tool's simplicity.
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 coverage is 0%, but the description lists all three parameters and adds context: 'description' is a natural language style, 'name' is the template name, and 'reference_image_path' is optional with default null. This goes beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a new PP3 template from a natural language description. It differentiates from sibling tools like 'generate_pp3_profile' by noting that this tool creates a neutral base template and then the AI interprets the description and calls the profile generator.
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?
Explicitly says 'use this to create a template when the user describes a look in words' with an example. It lacks explicit when-not-to-use or comparison to alternatives, but the context and sibling list provide enough differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes rendering a JPEG using RT CLI with full profile including Locallab spots, and optional histogram. This gives good insight into the tool's behavior. However, it does not explicitly state non-destructive nature, but 'preview' implies that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: purpose, mechanism, usage note, and parameter list. It is concise and front-loaded. The parameter list at the end is slightly redundant but acceptable given schema coverage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, mechanism, and usage advice, but lacks detail on the output (e.g., return format like file path or data stream). With no output schema, this omission leaves ambiguity about what the tool produces.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists all four parameter names (file_path, profile_path, max_width, include_histogram), which is helpful given 0% schema coverage. However, it does not elaborate on their meanings or constraints, e.g., max_width units or file path formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Preview a RAW file with all active local adjustments applied', providing a specific verb and resource. It distinguishes from sibling tools like 'preview_raw' by emphasizing adjustments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this after add_luminance_adjustment or apply_local_preset to verify the effect visually'. This provides clear when-to-use guidance and implies a workflow, differentiating from other preview tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses that 'Custom presets are saved to disk and available in future sessions,' which adds valuable behavioral context. No conflicts with annotations.
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?
The description is concise (4 sentences) with each sentence serving a clear purpose: purpose, when to use, behavior, and parameter list. No unnecessary words.
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 simple creation tool with an output schema, the description covers purpose, usage guidance, persistence, and parameter list. It is complete given the tool's straightforward nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description lists the parameters (preset_id, name, width, height, category). However, it provides no additional details like units or constraints, so only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create and persist a custom device/format preset for cropping and resizing,' providing a specific verb and resource. It distinguishes from siblings like list_device_presets and delete_device_preset.
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?
The description says 'Use this to add a preset for a device or format not in the built-in list,' giving clear context for when to use the tool. However, it does not explicitly mention when not to use it or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes return format (dict with built_in and custom lists) but lacks detail on side effects, permissions, or pagination. Adequate for a simple list tool.
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?
Three concise sentences: purpose, usage guidance, return format. No wasted words.
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?
With no parameters and an output schema, the description fully covers what the tool does and returns.
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?
Zero parameters, so baseline is 4. No additional parameter info needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'list' and resource 'PP3 processing templates', distinguishes built-in and custom, and references related tools (apply_template, generate_pp3_profile).
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?
Explicitly says to use for discovering templates for apply_template or generate_pp3_profile. No exclusions, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It mentions returning an inline thumbnail and optional merging, but it does not describe error handling, performance, or whether the tool is read-only. Basic transparency is present but not comprehensive.
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?
The description is concise, front-loading the main purpose and then listing parameters inline. Every sentence is necessary, with no fluff.
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?
Given no output schema and no annotations, the description covers the main behavior, output type, and optional merge feature. It lacks details on error conditions or prerequisites, but overall it is sufficient for an agent to understand the tool's function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description lists all parameters with added context: base_profile is an optional PP3 path, strength is 0-100. This compensates well, making parameters meaningful beyond their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it renders an inline preview of a RAW file with a HaldCLUT film simulation applied, differentiating it from siblings like preview_raw (no LUT) and apply_lut (processing vs preview). The verb 'render' and resource 'inline preview' are specific.
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?
It explains when to use the optional base_profile parameter to preserve WB/exposure, providing context. However, it lacks explicit guidance on when to prefer this tool over siblings like preview_lut_comparison or apply_lut.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors: applying adjustments, regenerating variants, and preserving override settings. It lacks detail on potential side effects, but overall transparency is good given no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loading the main purpose in the first sentence. The additional details are relevant and well-structured, though slightly verbose in listing parameters.
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?
Given the presence of an output schema, the description sufficiently covers core functionality and parameters. It lacks preconditions or error handling details but is adequate for a knowledgeable agent.
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?
With 0% schema coverage, the description adds meaning by explaining profile_name as a template name/path, adjustments as a key-value dict in adjust_profile format, and propagate's default. This compensates well for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates a base PP3 template and optionally propagates changes to variants. It uses specific verbs and resources, distinguishing itself from similar tools like adjust_profile.
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?
The description implies usage for updating base templates with propagation, referencing the same format as adjust_profile. However, it does not explicitly state when not to use it or provide direct comparisons with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description transparently explains that the operation is lossless and only rewrites the EXIF APP1 segment. It also clarifies default removals and the effect of 'strip_all'. Without annotations, this fulfills the burden well.
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?
The description is concise with no wasted words. The first sentence states the core purpose, followed by technical details and parameter listing in a logical order.
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?
Given the output schema existence and the complexity of 10 parameters, the description covers the main functionality, lossless behavior, and parameter interactions. It lacks explicit mention of error handling or file existence prerequisites but is largely sufficient.
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?
The description lists all parameters and explains the behavior of key ones like 'strip_all' and 'output_path'. With 0% schema description coverage, it adds meaningful context beyond the schema defaults and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'strip' and the resource 'EXIF metadata from an exported JPEG file', making the purpose unambiguous. It also distinguishes itself from siblings like 'read_exif' and 'set_metadata' by focusing on removal.
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?
The description provides clear guidance on default behavior and how to use parameters like 'strip_all' and 'keep_copyright'. However, it does not explicitly state when not to use this tool or mention alternatives like 'inspect_metadata' for viewing metadata.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that only specified parameters change and others are preserved, and explains dual input formats; but does not mention error handling or validation behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Reasonably concise with a clear structure—purpose, usage, behavior, parameter details—but could be slightly more streamlined.
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?
Given the parameter complexity and absence of annotations, the description covers purpose, usage, behavior, and parameter semantics comprehensively; output schema exists so return values need not be explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Provides examples and explains that adjustments can be friendly or raw PP3 section/key pairs, adding significant meaning beyond the schema which has 0% description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it modifies specific parameters in an existing PP3 profile, distinguishing it from creation (generate_pp3_profile) and read-only (read_profile) tools.
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?
Explicitly recommends use for tweaking individual settings without recreating the entire profile, though no explicit when-not-to-use or alternatives are mentioned beyond the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description covers scanning behavior, source directories, file types (PNG/TIFF), and grouping logic. It does not address edge cases (e.g., missing directory, no files found) or permissions, but the core behavior is well described.
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?
The description is concise, starting with the main purpose, then detailing the scanning process, and ending with a clear list of parameters. Every sentence adds value without redundancy.
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?
The description covers the scanning and grouping logic, and parameter usage. The output schema exists, so return values need not be detailed. However, it could mention that results are grouped by category (which it does) and perhaps the format (list of paths) but that is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description fully explains both parameters: directory as an optional override and category as an optional filter. It provides context beyond the schema's type definitions, making the tool easy to use.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists HaldCLUT film simulation LUT files, specifies the scanning source (RT_HALDCLUT_DIR or optional directory), and groups by category. It is distinct from sibling tools like apply_lut or preview_lut which apply or preview specific LUTs.
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?
The description indicates it is used to list available LUT files and optionally filter by category or override directory. It does not explicitly contrast with alternatives, but the purpose is clear enough that an agent would understand when to use it for listing vs applying a LUT.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the return value (a dict with specific fields) and implies read-only behavior. Without annotations, it could explicitly state no side effects, but the description is sufficiently transparent for a status check.
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?
Two sentences plus a return type line. Front-loaded with purpose, no wasted words. Highly efficient.
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?
Given no parameters and the presence of an output schema, the description fully covers the tool's purpose and results. No gaps remain.
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?
No parameters exist, so schema coverage is complete. The description explains what the tool does without needing parameter details, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') and resource ('RawTherapee installation status and server configuration'), and clearly distinguishes from sibling tools like check_lens_support by focusing on the tool itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises 'Call this first when troubleshooting' and states use cases: verify installation, check version, view directories. No alternative tools mentioned but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description reveals it is read-only and returns a dict grouped by category. No side effects mentioned, but adequate for a listing tool.
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?
Two focused sentences plus a concise note on return type. No unnecessary words, front-loaded with purpose.
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 zero-parameter tool with an output schema, the description covers what it does, when to use it, and what it returns. Complete and self-contained.
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?
No parameters, so schema coverage is 100%. Description adds value by explaining the categories (mobile, desktop, photo_formats, custom) that the output is grouped by.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool lists device/format crop and resize presets, distinguishing it from siblings add_device_preset_tool and delete_device_preset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use it: 'to discover available presets for mobile wallpapers, desktop wallpapers, and photo aspect ratios.' Also implies not for adding/deleting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![rawtherapee-mcp-server MCP server](https://glama.ai/mcp/servers/lucamarien/rawtherapee-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/lucamarien/rawtherapee-mcp-server)

Score Badge

Copy to your README.md:

[![rawtherapee-mcp-server MCP server](https://glama.ai/mcp/servers/lucamarien/rawtherapee-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/lucamarien/rawtherapee-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/lucamarien/rawtherapee-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server