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

With no annotations, the description carries the full burden for behavioral disclosure. It provides critical scaling semantics (1.0 = no change, >1.0 = increase, <1.0 = decrease), which is helpful for numeric parameters. However, it does not disclose whether the original file is modified in place, whether an output path is required, or any side effects. This is a significant gap for a mutating 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?

The description is two sentences, succinct, and front-loaded with the purpose. The scaling rule is efficient and earns its place. No redundant information.

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

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

For a tool with 7 parameters, no output schema, and no annotations, the description is incomplete. It explains the value scaling but does not cover critical context: whether at least one property must be set, behavior if no numeric params are given, file handling (in-place vs output), or validation ranges. An agent would need to infer or experiment to use it safely.

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

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

Schema description coverage is 0%, so the description must compensate. It adds a universal rule for all numeric parameters (gamma, contrast, etc.) that explains the value meaning, which the schema does not. However, it does not explain the 'path' or 'output' parameters, leaving their roles to inference. The blanket rule is useful but not per-parameter.

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 the tool's action ('Adjust image properties') and the resource type (image properties), which distinguishes it from sibling tools like raster_convert, raster_resize, and raster_crop that perform geometric/format transformations. However, it does not explicitly list which properties are adjustable, relying on the schema to convey that.

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

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

No guidance is provided on when to use raster_adjust versus alternatives like raster_filter or raster_enhance. The sibling tool list suggests related operations, but the description offers no exclusions, prerequisites, or contextual cues for selection.

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 disclosing side effects, return values, or file handling. It merely states the conversion action without explaining whether the original is modified, where output is written, or what happens if output is omitted.

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 sentence with no redundancy and is front-loaded with the action. It is concise and well-structured, even if it lacks depth.

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 4 parameters, no output schema, and no annotations, yet the description provides only the core purpose. It does not explain return values, output path behavior, quality semantics, or any edge cases, making it far from complete.

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

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

Schema description coverage is 0%, so the description must compensate. It adds value by listing valid values for the format parameter, but it ignores path, output, and quality. This is only marginal compensation for a 4-parameter tool.

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 clearly states the tool's function with a specific verb ('Convert') and resource ('image to another format'), listing supported formats. This distinguishes it from siblings like raster_resize or raster_crop, which perform different operations.

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

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

No guidance is provided about when to use this tool versus alternatives. It does not mention prerequisites, typical use cases, or situations where another tool would be more appropriate.

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 bears the burden of explaining behavior. It adds a useful detail about inclusive pixel coordinates, which is a behavioral nuance. However, it does not disclose what happens to the original image, what the output parameter does, or any side effects.

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, concise sentence that is front-loaded with the key action and object. It contains no fluff or repeated information, making it highly readable and efficient.

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 annotations and no output schema, the description must provide more context. It covers the core operation but leaves the optional 'output' parameter unexplained, and it does not clarify the return value or file handling. This makes it incomplete for a tool with six parameters and no supportive annotations.

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 description adds meaning by specifying that the coordinates define an inclusive rectangle, which clarifies the relationship between left, top, right, and bottom. However, it does not explain the 'path' or 'output' parameters, leaving some parameters underspecified given the schema's 0% description coverage.

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 clearly states the operation: 'Crop image to the specified rectangle (inclusive pixel coordinates).' It names a specific verb ('crop') and resource ('image'), and the coordinate specification distinguishes it from sibling operations like resize or rotate.

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 verb 'crop' clearly implies the use case, and the mention of a rectangle with inclusive coordinates provides context. It does not explicitly list alternatives or exclusions, but the purpose is self-evident enough to guide selection among similar raster tools.

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 disclose behavior, but it only says 'auto-enhance image' without explaining side effects such as overwriting the original file, return values, or permission requirements. The 'factor' parameter is mentioned in the schema but not described, and the 'output' parameter's behavior is completely unclear. This is a significant transparency gap for a mutation-like operation.

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 very short but under-specified for a tool with four parameters. While it has no fluff, it omits critical information about parameters and behavior, making it less concise and more incomplete. The 'mode:' listing is helpful but the overall message is too sparse to be considered well-structured.

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 the tool's complexity (4 parameters, no output schema, no annotations), the description is highly incomplete. It does not explain how the output is handled, what the factor does, or how the enhancement is applied. The sibling tools cover a similar space, so more context is needed to differentiate and guide correct invocation.

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

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

Schema coverage is 0%, so the description must compensate. It does explain the valid values for 'mode' (contrast, color, sharpness, all), which is useful since the schema only defines it as a string with a default. However, it provides no meaning for 'path', 'factor', or 'output', leaving the agent to guess their roles and formats.

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 starts with 'Auto-enhance image', which is a clear verb+resource statement that differentiates from tools like raster_resize or raster_crop. It also specifies the main mode options (contrast, color, sharpness, all), adding purpose detail. However, it does not explicitly distinguish itself from raster_adjust or raster_filter, which could overlap in functionality.

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 description provides no guidance on when to use this tool versus its siblings like raster_adjust or raster_filter. It does not mention typical use cases, prerequisites, or situations where an alternative would be preferred. This leaves the agent without clear selection criteria.

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. It mentions the action and filters but does not disclose output behavior, side effects, or how parameters like radius and threshold affect results.

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 sentence with a clear list of supported filters. It is concise, front-loaded, and contains no redundant information.

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

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

With 5 parameters, no output schema, and no annotations, the description is too sparse. It does not cover return values, side effects, or parameter semantics, making it incomplete for an agent to successfully invoke the 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 schema covers 5 parameters with 0% description coverage. The description does add a list of valid filter values, but does not explain path, output, radius, or threshold_value, leaving most parameters underspecified.

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 clearly states 'Apply a named filter' and enumerates supported filter types, distinguishing this from sibling tools that handle conversion, resizing, cropping, etc.

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 guidance on when to use this tool vs alternatives, though the list of supported filters implies usage for those specific operations. No exclusions or alternative tools are mentioned.

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 full burden of behavioral disclosure. It states that the tool returns metadata, which implies a read-only operation with no side effects. However, it does not mention any potential caveats, such as behavior if the path is invalid or whether the file must exist, which would provide additional transparency.

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, concise sentence that front-loads the purpose and includes a list of return fields. Every word contributes value; there is no fluff or redundancy.

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, with one parameter and no output schema. The description adequately covers what is returned (key metadata fields) and distinguishes it from sibling operations. It does not describe error handling or specific units, but these are not essential for such a straightforward metadata-reading 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 schema has one parameter, 'path', with no description, and the tool description does not explain the meaning of the path parameter or what format it expects. With 0% schema description coverage and no compensation in the description, the parameter semantics are under-specified, even though 'path' is a common parameter.

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 ('Return') and resource ('image metadata') and enumerates the exact fields returned (dimensions, format, mode, DPI, file size). This distinguishes it clearly from sibling tools like raster_convert or raster_resize, which perform transformations rather than just reading information.

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 description implies usage: use this tool to get metadata rather than to modify the image. However, it does not explicitly state when to use this tool or provide exclusions/alternatives. The context is fairly clear from the sibling tool names, but there is no direct guidance in the description itself.

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 full burden for behavioral transparency. It only says 'Resize image' without disclosing whether the original is modified, what the output parameter does, or if a new file is created. The behavior is opaque apart from the resize action itself.

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 that gets straight to the point. No redundant words or irrelevant details. It is appropriately concise for the information it conveys.

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 6-parameter tool with no annotations and no output schema, this description is too thin. It does not explain return values, output behavior, parameter combination rules, or effects on the original file. It covers the basic resize modes but leaves significant gaps for the agent to infer.

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

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

Schema description coverage is 0%, so the description must compensate. It explicitly explains the fit modes (cover/contain/fill), scale factor, and width/height, giving semantic meaning to four of the six parameters. However, it omits the 'output' parameter and does not clarify parameter interactions, so it is not a 5.

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 starts with a clear, specific verb ('Resize') and resource ('image'), which distinguishes it from sibling tools like raster_crop or raster_rotate. It also mentions the key modes (width/height, scale, fit), but does not explicitly differentiate from alternatives, so it falls short of a 5.

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

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

The description implies usage by saying 'Provide width/height, scale factor, or fit mode,' but it does not give explicit guidance on when to choose this tool over siblings, nor does it mention any exclusions or prerequisites. It offers basic usage modes but no context on selection criteria.

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 carries the full burden of behavioral disclosure. It adds useful context about expand=True enlarging the canvas to fit, but it omits other behaviors such as rotation direction, the effect of expand=False, and what happens to the output. This is a partial but not complete disclosure.

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 extremely concise and front-loaded, consisting of two short sentences. Every word contributes meaning, with no redundancy or filler.

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

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

Despite having 4 parameters, no annotations, and no output schema, the description is too sparse to be complete. It only briefly mentions expand behavior and leaves path, output, and other rotational nuances unexplained. The description does not provide enough context for an agent to invoke the tool correctly in all cases.

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

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

Schema description coverage is 0%, so the description must compensate for parameter explanations. It addresses degrees and expand, but completely ignores the path and output parameters, leaving them ambiguous. This is insufficient for a 4-parameter tool.

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+resource pattern ('Rotate image by degrees') that clearly identifies the tool's function. This distinguishes it from sibling raster tools like raster_resize, raster_crop, and raster_convert, which handle different operations.

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 description provides no guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or alternative tool suggestions, leaving the agent without direction for tool selection.

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