frame

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.