Skip to main content
Glama

Expand a cropped photo

luw_expand_image

Luw.ai Expand AI: outpaint a tightly cropped architectural or interior photo to a wider view. Costs 1 credit.

Instructions

Luw.ai Expand AI: outpaint a tightly cropped architectural or interior photo to a wider view. Costs 1 credit.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
imageYesPhoto to expand (https:// URL, local file path, or data: URI).
formatNoOutput image format.
precisionNoHow strictly to keep the input's structure: 90 = precise, 75 = balanced, 40 = creative.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.3.2

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false, idempotentHint=false, openWorldHint=true, and destructiveHint=false, so the mutation profile is covered. The description adds the genuinely useful cost signal ('Costs 1 credit'), but omits that this is an async/generated-output operation likely requiring luw_get_result to retrieve the result.

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 short sentences, with the core operation front-loaded before the cost note. The 'Luw.ai Expand AI:' branding prefix is minor filler, but the rest wastes nothing.

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?

No output schema exists, so the description is the only source for what the call returns or how the result is delivered; it says nothing about the response or the likely need to poll a get-result tool. For a credit-consuming generation tool with three parameters, that is a real gap.

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 100%, so image, format, and precision are all already documented with their formats, enum values, and precision semantics (90 precise / 75 balanced / 40 creative). The description contributes no additional parameter meaning, making the baseline 3 correct.

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 names a specific operation (outpaint/expand) on a specific resource (a tightly cropped architectural or interior photo) and states the outcome (a wider view), which separates it cleanly from luw_upscale_image, luw_background, and luw_edit_image. It does not explicitly name a sibling alternative, so it lands just below the top score.

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 phrase 'tightly cropped architectural or interior photo' implies the intended input condition, but the description never states when to prefer this over luw_upscale_image or luw_edit_image, nor any prerequisite such as uploading first. Usage is inferable rather than explicit.

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