blockrun_image

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

The description goes well beyond the sparse annotations by disclosing cost implications ('Pays with USDC on the ACTIVE chain'), multi-image behavior, mask constraints, and the inline preview behavior ('Return a small inline image preview ... in addition to the full-resolution URL'). It also explains that source images can be base64, URLs, or file paths, which is valuable operational context.

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 lengthy but well-structured with clear sections for actions, models, and edit specifics. Every sentence adds useful detail, and the first line front-loads the core purpose. While it is dense, the complexity of the tool justifies the length; a shorter version would lose critical model and pricing 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?

Given the absence of an output schema, the description provides substantial context: return behavior is hinted via 'full-resolution URL' and 'inline preview', and payment, model options, and input formats are all covered. However, it never explicitly describes the full return structure (e.g., a JSON object with URL and metadata), and error cases or rate limits are not mentioned. This leaves a minor gap for a tool with 9 parameters.

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?

With 89% schema coverage, the schema already documents most parameters. The description adds meaningful value by explaining model pricing, model strengths (e.g., 'gpt-image-2 renders on-image text best'), and the exact semantics of multi-image editing ('pass an array of 2–4 source images ... to fuse them in one render'). This enriches parameter understanding beyond the schema.

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 'Generate or edit images via BlockRun', using a specific verb and resource. It further distinguishes itself with actions (generate/edit) and clearly separates from sibling tools like blockrun_video, blockrun_music, and blockrun_speech by focusing solely on image generation and editing.

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?

It clearly states the tool is for image generation/editing and provides model selection guidance (e.g., 'gpt-image-2 renders on-image text best; nano-banana-pro for 4K photorealism; cogview-4 / grok-imagine-image for cheap drafts'). It also references blockrun_wallet for payment context, but does not explicitly mention when not to use this tool relative to other siblings beyond the inherent scope.

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