Skip to main content
Glama

ViewMax MCP

by io.github.bytevirts
OverviewDiscussionsAdmin

generate_image

Create an image generation task (text-to-image, or image-to-image when image_urls are provided). Pro/Ultra flagship models (GPT Image 2, GPT Image 2.5, Nano Banana 2, Grok Imagine) and Ultra ViewMax C1 cost 0 credits within the shared daily fair-use pool; otherwise this consumes credits. Call wait_for_task with the task_id for the result URLs.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modelYes
sceneNo
promptYes
qualityNo
image_urlsNo
aspect_ratioNo
idempotency_keyNoOptional, 1-200 visible ASCII characters without spaces. Reuse the same key when retrying after a timeout; a repeated key returns the original task and is not charged again.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / idempotency_key
      Added value: +{
+  "description": "Optional, 1-200 visible ASCII characters without spaces. Reuse the same key when retrying after a timeout; a repeated key returns the original task and is not charged again.",
+  "pattern": "^[\\x21-\\x7e]{1,200}$",
+  "type": "string"
+}
  2. Changed2 schema fields changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • removedInput schema / additionalProperties
      Removed value: -false
  3. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Beyond the annotations (which only declare openWorld=true, readOnly=false, idempotent=false, destructive=false), the description discloses the credit cost model — 0 credits for Pro/Ultra flagship models within the shared daily fair-use pool, otherwise credits are consumed — and that the operation is asynchronous and requires a follow-up wait_for_task call. That is substantive operational context not available in structured fields.

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?

Three tight sentences: purpose + modes first, then cost caveat, then the required next call. Every sentence carries load and nothing is repeated from the schema or annotations.

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?

With 7 parameters, 14% schema coverage, and no output schema, the description correctly covers the async workflow and result retrieval path, but leaves model selection, prompt/scene relationship, quality, and aspect_ratio guidance entirely to guesswork. Adequate for invocation, incomplete for confident parameter choice.

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?

Schema coverage is only 14% (just idempotency_key), so the description must compensate for six undocumented parameters. It partially does so for image_urls (triggers image-to-image) and model (flagship models are free within the fair-use pool), but scene, prompt, quality, and aspect_ratio semantics are entirely unaddressed in both schema and description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource ("Create an image generation task") and immediately qualifies the two operating modes, text-to-image vs image-to-image, tied to the image_urls parameter. This clearly separates it from generate_video, generate_music, and generate_speech siblings without needing to name them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states the condition that selects image-to-image ("when image_urls are provided") and the required follow-up workflow ("Call wait_for_task with the task_id for the result URLs"). It does not, however, point to list_image_models/get_image_model for choosing a model, nor state any exclusion for the non-image generation siblings.

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

All ViewMax MCP toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources