Create AI images from text prompts with adjustable size, steps, and model settings.
AI生成图片
| Name | Required | Description | Default |
|---|---|---|---|
| cfg | No | 提示词相关性，取值范围[1-30]，默认值7。（可选） | |
| num | No | 生成数量，默认1张 | |
| seed | No | 随机种子，生成图片的seed，默认-1随机生成。（可选） | -1 |
| model | No | 模型code，默认通用FLUX模型 | |
| steps | No | 采样步数，默认20。（可选） | |
| width | No | 图片宽，默认512。（可选） | |
| height | No | 图片高，默认512。（可选） | |
| prompt | Yes | 作画描述，建议包含风格和细节 | |
| uc_prompt | No | 作画负面描述。（可选） | |
| sampler_index | No | 采样模式是指扩散去噪算法的采样模式。（可选） | |
| init_image_url | No | 底图url。（可选） |
Changes observed during successful MCP inspections.
v0.1.4Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It doesn't mention mutation effects, side effects, asynchronous behavior, or that the tool returns a task ID or requires querying later. Given that sibling tools include query_generate_task, the generation is likely async, but this isn't disclosed. The description only restates the function and discloses no behavior.
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 short, only six characters, which is efficient in length but not structured as useful guidance. It doesn't front-load any distinguishing information beyond the name, so it is under-specification rather than conciseness. A minimal viable description should at least say what the tool does that the name alone doesn't convey.
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 11 parameters, no annotations, no output schema, and two siblings that suggest an async workflow, the description is too sparse. It doesn't mention that the result might be a task, that users need to supply rich prompts, or how this relates to query_generate_task. The schema covers parameters well, but the overall operational context is missing. An agent could call it, but may not know what to expect back or what to do next.
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 itself documents prompt, cfg, seed, steps, etc. The description adds no parameter-level nuance beyond the schema. Baseline 3 is appropriate when the schema is fully documented; the description doesn't need to repeat parameter definitions. However, it doesn't add any cross-parameter guidance (e.g., how cfg relates to prompt adherence) - though that is optional.
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 'AI生成图片' is a tautology that essentially restates the tool name 'generate_image' (generate an image). It identifies the resource (image generation) but doesn't provide specific detail about what kind of image generation model or output to expect, and the sibling tools are query_generate_task and query_model_infos, so some differentiation is needed to distinguish between initiation vs. querying. It's minimally recognizable to an agent but adds little beyond the name.
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 query_generate_task or query_model_infos. Siblings are clearly task-query and model-info functions, implying this tool initiates generation, but the description never states that. For an 11-parameter tool, an agent is left to infer that it should call this one first based on the schema rather than being told.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.