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

No annotations are supplied, so the description carries the full burden; it does usefully disclose that the operation 'does not change the recipe' (a read-only, non-mutating guarantee). However, it omits what happens when the combined axes exceed 12 tiles (error vs. truncation), what the return value is (an image? a reference?), and whether all axes are optional and what happens with none supplied.

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

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

Two short sentences, front-loaded with the primary action and scope, followed by the combinatorial rule and the non-mutation guarantee. Every sentence adds information an agent needs; nothing is padded.

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

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

For a 4-parameter, all-optional tool with no annotations and no output schema, the description should say what is produced and how the 12-tile cap is enforced. It covers the input composition well but leaves the output side and the over-cap behavior undocumented, which is a meaningful gap when no output schema exists.

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

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

Schema coverage is 100%, so parameter meaning is already documented, but the description adds genuinely new semantics the schema lacks: axes are combined as a cartesian product, and there is a hard ceiling of 12 tiles that constrains how many values per axis are sensible. The example ('3 films x 2 exposures = 6 tiles') makes the combinatorics unambiguous.

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

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

The description gives a specific verb and resource — 'Render a labelled contact sheet of variations of the current recipe' — plus a concrete scope (up to 12 tiles) and the combinatorial behavior of the axes. It is clearly distinct from siblings like develop, frame, or loupe, though it never explicitly names a sibling to differentiate against.

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

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

Usage is only implied: an agent can infer you call this when you want to visually compare film/paper/exposure variations, and the example '3 films x 2 exposures = 6 tiles' hints at how to compose the call. There is no explicit when-to-use, when-not-to-use, or pointer to an alternative (e.g. single-variation tools) if the comparison exceeds the tile cap.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It states that only passed fields are changed and that a developed preview is returned, but it does not say whether changes persist, whether they are undoable, what permissions are needed, or how costly a 'full' quality render may be. For a state-changing tool with 23 parameters, this is a significant gap.

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

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

The description is a single front-loaded sentence with no filler. It states the action, the partial-update rule, and the return value efficiently.

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

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

Given 23 parameters, no annotations, and no output schema, the description is too thin. It does not explain what the developed preview contains, how it relates to the current state, or when to use this tool rather than its siblings. The rich parameter schema helps, but the description remains incomplete for a tool of this complexity.

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

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

Schema description coverage is 100%, so the schema already documents each parameter in detail. The description adds only the useful partial-update clarification that 'only the fields you pass' are changed, which slightly extends beyond the schema but does not provide parameter-specific meaning. The baseline of 3 is appropriate when the schema does the heavy lifting.

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

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

The description uses a specific verb and resource: 'Change the film recipe' and 'return the developed preview.' It is clear what the tool does, but it does not distinguish itself from siblings such as frame, compare, or list_stocks, leaving the agent to infer when this tool is preferred.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and no alternatives are named. The phrase 'only the fields you pass' describes partial-update behavior but does not tell the agent under what circumstances to call develop versus frame, compare, or list_stocks.

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

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

With no annotations, the description carries the full burden and it does contribute real behavior: tiled rendering to bound memory and a concrete timing estimate (~75 s for 40 MP RAW). It still omits consequential traits for a write operation — whether an existing file at output_path is overwritten, what happens on partial/failed renders, and whether the render reflects uncommitted state.

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

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

Two short sentences, front-loaded with the action before the performance caveat; nothing is padded. It could arguably be tightened further by folding the timing note into the same sentence, but no wording is wasted.

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

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

For a two-parameter tool with no annotations and no output schema, the description covers the action and its performance profile, which is a reasonable minimum. It falls short on the side effects an agent needs to call it safely — overwrite behavior, failure handling, and relationship to other rendering siblings.

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

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

Schema description coverage is 100%, so both max_size (long-edge pixels, default full resolution) and output_path (absolute path, allowed extensions) are already documented in the schema. The description adds no parameter-level meaning beyond that, which is the baseline 3 case.

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

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

"Render the current recipe at full resolution and save it" gives a specific verb (render/save) and object (current recipe, full resolution), so the agent knows this is a file-producing operation rather than a viewer. It does not, however, distinguish itself from siblings like develop or frame, which could plausibly also produce rendered output.

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

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

Usage is only implied: "the current recipe" signals this operates on already-applied edits rather than raw input, but there is no statement of when to choose export over develop, frame, or loupe, and no prerequisites or exclusions are given.

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

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

With no annotations at all, the description carries the full behavioral burden and mostly succeeds: it discloses the partial-update semantics, that every call re-measures straight lines and reports residual tilt or keystone with a suggested auto correction, and that it returns a framed preview. It does not say whether the framing is non-destructive to the source image or what error conditions look like, which are notable gaps for a 13-parameter mutation tool.

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

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

Four short sentences, front-loaded with purpose, then behavior, then the reset recipe. The measurement sentence is the densest but earns its place because the returned diagnostic report is not obvious from the name. Minor redundancy in restating that every call re-measures under the new framing.

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

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

For a 13-parameter tool with no annotations and no output schema, the description covers what changes, what the response contains (framed preview plus a tilt/keystone report), and one important invocation pattern. It falls short only on non-destructiveness and failure behavior, which an agent would want before chain-calling with undo and export.

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

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

Schema description coverage is 100%, so the schema already explains every parameter in detail, including ranges, defaults, and what auto levels mean. The description adds little beyond restating that only passed fields change and describing the reset_framing-plus-nothing invocation pattern. Baseline 3 is appropriate when the schema does this much work.

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

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

The description opens with a specific verb and resource set: 'Compose the picture: straighten, perspective correction, crop, rotate and flip.' That enumerates exactly which geometric operations the tool owns, which implicitly separates it from siblings like develop (tone/color) and loupe (viewing). It never explicitly names those siblings, so the differentiation is inferred rather than stated.

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

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

'Only the fields you pass change' establishes this as a partial-update tool, and 'Call with reset_framing=true and no other fields to look at the whole uncropped photo' gives a concrete invocation recipe. What is missing is any explicit routing against alternatives (e.g., when to use this versus develop or compare), so an agent must infer the boundary from the operation list.

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

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

No annotations are provided, so the description carries the full burden and discloses almost nothing: it does not confirm the call is read-only and side-effect free, whether it fails when no image is loaded, or how the state is represented. Only the 'get_' naming convention implies a safe read.

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

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

Four words with zero waste, but the brevity crosses into under-specification: it is a noun fragment rather than a statement, so there is nothing to front-load and no structure to speak of.

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

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

For a zero-parameter read of editor state with no output schema and no annotations, the description should at least say it returns the currently open image and its applied recipe/settings, and what happens when no image is open. It gestures at the return contents but leaves the critical edge case and format unexplained.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate or document; the baseline for a parameterless tool applies.

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

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

The fragment 'Current image and recipe' names the two pieces of data returned, which does add content beyond the tool name 'get_state', but it contains no verb and never states that it retrieves/returns anything. It is distinguishable from siblings like open_image or develop only by inference from the noun phrase.

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

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

There is no guidance on when to call this versus open_image, loupe, or compare, nor any precondition (e.g., must an image already be open). Usage is left entirely to the agent's inference from the name.

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

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

No annotations are supplied, so the description carries the disclosure burden. It does reveal the shape of what comes back (type: negative/positive, use: still/cine), which is genuinely useful, but it never states that the call is read-only with no side effects, nor whether the catalog is static or reflects current darkroom state.

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

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

One sentence, front-loaded with the verb and resource, with the returned fields trailing as supporting detail. Nothing is redundant or padded.

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

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

With no output schema, the description is the only source of return-value information, and it covers only two fields. It does not say what the stock identifiers look like or whether the names returned are the values that develop and export expect, which is the key downstream question for a zero-parameter catalog tool.

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

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

The tool takes zero parameters, which is the baseline-4 case; there is nothing for the description to disambiguate. It correctly avoids inventing parameter talk and instead spends its words on output semantics.

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

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

The description gives a specific verb ("List") and a concrete resource ("film stocks and print papers"), and even names the sub-fields exposed. It reads clearly against the action-oriented siblings (develop, frame, export, undo), though it never explicitly contrasts itself with them.

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

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

Usage is only implied: an agent can infer this is the discovery step before develop or export, but the description states no when-to-use condition, no prerequisites, and names no alternative. A single clause like "call before develop to obtain valid stock names" would have lifted this to 4-5.

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

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

With no annotations, the description must carry the behavioral load. It usefully discloses that the crop includes grain and halation (i.e. the processed look, not raw source pixels) and that it renders at full resolution, but it never states that the operation is non-destructive, whether a full-res render is expensive/slow, or what the response actually contains.

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

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

A single sentence with the verb and resource front-loaded and no wasted wording; nothing to trim.

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

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

The tool is simple (three optional, defaulted numeric parameters), and the description covers what is produced. However, with no annotations and no output schema, the return value (image payload vs. reference) and the cost of a full-resolution render are left unexplained.

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

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

Schema description coverage is 100% and each of size/center_x/center_y is documented with defaults and coordinate conventions, so the schema does the heavy lifting. The description adds only the notion of cropping from 'the framed picture', not any meaning about how size or center interact.

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

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

Specific verb ('Render') plus a precise resource ('a full-resolution crop of the framed picture') and an explicit rationale ('to inspect fine detail at 100%'). It is clearly distinct from develop, frame, export and undo, though it never names a sibling it could be confused with (compare is the nearest candidate).

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

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

The trailing clause gives a clear use context: inspect fine detail at 100% magnification. It stops short of exclusions or alternatives, so an agent is not told when to prefer this over compare or export, but the intended situation is unambiguous.

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

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

With no annotations provided, the description must carry behavioral disclosure. It reveals that the operation loads into the film lab and returns a preview with the current recipe, but it does not clarify whether loading replaces the current image, mutates state, requires permissions, or how errors are handled.

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

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

The description is a single front-loaded sentence with no redundant wording. It communicates the core action and return value efficiently.

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

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

The tool has five parameters but a rich schema that fully documents them, and the description covers the main purpose and a partial return value. However, with no annotations and no output schema, it leaves state effects and preview/recipe output structure underspecified.

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

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

The input schema has 100% description coverage, documenting path, temperature, white_balance, input_is_linear, and input_color_space. The description does not add any parameter-level meaning beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description states a specific verb and resource: loading an image or RAW into the film lab and returning a preview with the current recipe. This is clear enough to distinguish the operation from develop/export-type siblings, but it does not explicitly name alternatives or scope boundaries.

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

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

Usage is implied by the film-lab context and preview return, suggesting it should be used when opening an image before further processing. However, it gives no explicit when-to-use guidance, prerequisites, or comparison to siblings such as develop, loupe, or compare.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses that a change is reverted and a preview is returned, but not whether the revert is destructive or reversible, whether repeated calls step further back, or how failure with an empty history is signalled. For a state-mutating tool with zero annotation coverage this is a significant gap.

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

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

A single short sentence with the action front-loaded and the return value appended. No wasted wording, no redundancy with the name.

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

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

For a zero-parameter tool with no output schema, saying it returns the preview is genuinely useful. However, the missing details on undo depth, history preconditions, and failure behaviour leave real gaps for an agent that must decide when this call is safe.

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

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

The tool takes no parameters, which is the baseline-4 case. The description correctly implies nothing needs supplying and that the target is implicit (the last change).

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

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

The description gives a specific verb ('Revert') and a specific resource ('the last recipe change'), and adds that it returns the preview. An agent can distinguish this from siblings like develop, frame, or get_state. The only weakness is that 'recipe change' is domain jargon that doesn't pin down which edits count as undoable.

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

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

There is no guidance on when to call undo instead of inspecting state with get_state, or on whether undo is single-level or repeatable. Nothing says what happens when there is no prior change to revert, so the agent must guess at preconditions.

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