Open Google Image Generator MCP

by miracorhan

Overview Schema Source Related Servers Discussions Admin

Python

Local

tool_batch_generate

Batch-generate images from up to 10 prompts in one call with 4 concurrent jobs and a shared filename prefix.

Instructions

Generate images for multiple prompts in a single call (max 10, max 4 concurrent).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "params": "<params>"
    },
    "name": "tool_batch_generate"
  }
}

Input Schema

Name	Required	Description	Default
`params`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv3.3.0Oct 18, 2026

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations, the description carries the full burden, and it does add genuine behavioral facts: a cap of 10 prompts and 4 concurrent generations. It omits what happens on partial failure (does one bad prompt abort the batch?), whether the call is safe/read-only-side-effect-free, and typical latency for a 10-prompt batch.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single tight sentence with the operation front-loaded and the constraints parenthesized, no filler whatsoever. Every clause earns its place.

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?

For a batch mutation-style tool with no annotations and no output schema, the description is adequate but thin: it never states the return shape (per-prompt results? a list of file paths?), the failure mode, or how output files are named beyond what the schema says. An agent could call it correctly but not predict its response.

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?

Top-level schema description coverage is reported at 0% (the single `params` wrapper), though the nested BatchGenerateParams object does document each field, including its own "max 10" note. The description adds only the concurrency figure, leaving model_tier override behavior, output_prefix naming, and output_dir defaults to the schema.

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 gives a specific verb and resource ("Generate images") plus an explicit scope ("for multiple prompts in a single call"), which cleanly separates it from the single-prompt sibling tool_generate_image. It does not name that sibling explicitly, so it lands just short of a 5.

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?

Batch usage is implied by "multiple prompts in a single call," which tells an agent this is the bulk path, but there is no explicit when-to-use/when-not guidance and no named alternative such as tool_generate_image for single-prompt work or tool_run_pipeline for chained work.

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