Generate a new image by combining 2 to 10 local reference images uploaded together, guided by a text prompt. Fuses multiple references into one output with configurable size, quality, and model.
Generate an image from 2-10 local reference images, uploaded together. Uses paid quota.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | 1024x1024 | |
| model | No | ||
| prompt | Yes | ||
| api_key | No | ||
| quality | No | ||
| image_paths | Yes | ||
| response_format | No | b64_json |
Changes observed during successful MCP inspections.
v0.2.0Input schema / properties / api_keyAdded value: +{
+ "maxLength": 200,
+ "minLength": 1,
+ "type": "string"
+}v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds 'Uses paid quota,' a material cost disclosure not present in the annotations. It does not mention output behavior, upload/storage implications, or failure/rate-limit behavior; annotations already cover read-only/idempotency/destructive traits, so the additional burden is modest.
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 core operation and key constraint, followed by the cost warning. No filler or repetition of schema fields.
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 seven parameters and no output schema, the description doesn't specify expected output, quality/model semantics, or how to handle the paid quota; it only states the input constraint. An agent would need to guess at substantial behavior.
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, but it only clarifies image_paths semantics (local 2-10 reference images uploaded together). It leaves prompt, size, model, quality, response_format, and api_key unexplained beyond their schema names/types.
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?
Clearly identifies the operation: generate an image from local reference images, with the count bound 2-10 and the upload requirement. This differentiates it from image_generate/image_edit by input mode, though it never names a sibling or explicitly distinguishes from image_batch_edit.
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 the appropriate use case: when the agent has 2-10 local reference images to use as inputs. It provides no exclusion criteria or explicit guidance on choosing among image_generate, image_edit, and image_batch_edit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.