generate

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 states that the prompt is sent verbatim, requires manual LoRA syntax, explains that missing sampling parameters are filled from the model's actual history under use_profile_defaults, clarifies that shift and dimensions default to architecture-specific values when left unset, and discloses that return values are file paths only when the output folder is readable. It also details denoising_strength effects and the near-1.0 expectation for edit/video models. This is thorough and goes far beyond a bare statement of purpose.

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?

Three paragraphs, each with a distinct focus: purpose, prompt/profile defaults, and img2img specifics. Every sentence adds meaningful information. The core purpose is stated first, and the most critical caveat (verbatim prompt, LoRA) comes immediately after. There is no fluff or redundant phrasing.

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 complex 14-parameter tool with no output schema, this description covers the essential usage nuances: the verbatim prompt behavior, profile default handling, dimension/shift semantics, img2img initiation, and denoising strength guidance. It also notes the conditional return format. What is omitted (error cases, exact output object structure) is minor and not required for correct invocation. Given the tool's complexity, the description is impressively 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 explain the parameters. It does so selectively but effectively: it explains shift as Forge's distilled_cfg_scale, dimensions default to the architecture's own values, init_image switches to img2img, denoising_strength controls drift with concrete ranges, and use_profile_defaults influences whether other parameters are ignored. These are the non-obvious ones; standard parameters like steps, cfg_scale, and negative_prompt are left to the agent's prior knowledge, which is reasonable given their commonality.

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+resource: 'Generate an image from an already-written prompt.' This clearly distinguishes it from all sibling tools (profiles, progress, loras, models, etc.), which are about model management and introspection, not generation. No ambiguity about what the tool does.

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?

While it doesn't explicitly name alternative tools, the context makes the intended use unambiguous: it is the image-generation tool. It does provide clear guidance on when to use img2img (pass init_image) versus text-to-image, and explains the behavior of use_profile_defaults to avoid overriding model-specific settings. This is sufficient routing for an agent.

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