Skip to main content
Glama

generate task

generate_task
Destructive

Create one independent billable Studio task. All creation tools use input with original model parameters, reference_files and explicit file_bindings. Read list_models.defaults for the default model of this tool, then get_model_schema for the complete schema. generate_task requires model; shortcuts may omit it. Explicit model selects that public task model. Set the documented mode in input; no mode, model fields, defaults or voice choices are inferred or injected. Flat model parameters and legacy reference_images/reference_audio are not accepted. Backend validation is authoritative. Use session_title for a new topic, session_id to continue, and session_id plus base_run_id for a version. Preserve returned model/task_id/session_id/run_id/media_type. Never automatically resubmit or change model/session after rejection or an unconfirmed submission. In user-facing replies, omit technical identifiers by default, including user/profile IDs, task_id, session_id, run_id, base_run_id, voice_id, and file IDs. Retain the exact returned identifiers for tool arguments, task queries, session continuation, version appends, and voice reuse; never redact, regenerate, or guess these references. Show an identifier only when the user explicitly asks for it or a specific troubleshooting step requires that exact value, and show only the reference needed. Prefer plain-language status, model names, result previews/download links, and Studio links built from the returned session_id. This changes reply presentation only; tool result fields remain available for the workflow.

Input Schema

NameRequiredDescriptionDefault
inputYesFollow the complete get_model_schema.schema for model parameters, including nested objects and arrays. Values pass unchanged to backend validation; no plugin field or mode whitelist. Use direct media URLs or reference_files with explicit file_bindings, without mixing them. Routing, identity and session overrides are not model inputs. Metadata does not prove content or access.
modelYes
session_idNoUse a returned or user-provided Studio session ID to add related work to that project. Never guess a session ID.
base_run_idNoTo revise a specific work, pass its returned run_id and the same session_id. Omit to create an independent work in the project.
file_bindingsNoUse paths declared in schema.mcp.attachments. Replace [] with an explicit input array index, e.g. elements[0].image_urls; provide parent objects and their metadata in input. Bind every file once using zero-based file_indices in intended order. Never overwrite direct URLs or guess fields or ordering.
session_titleNoRequired for a new Studio topic: 1-255 characters after trimming. Ignored when session_id is provided.
reference_filesNoChatGPT files in original order. file_id is metadata, never a URL or permission proof. Temporary download URLs are used only in this call. Do not invent MIME, byte size, dimensions or duration.

Output Schema

NameRequiredDescriptionDefault
errorYes
modelYes
stateYes
run_idNo
task_idYes
progressYes
voice_idYes
created_atYes
media_typeYes
session_idNo
completed_atYes
preview_urlsYes
text_outputsNo
download_urlsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the annotations, it discloses that the task is billable, that backend validation is authoritative, that no mode/model/defaults/voice are inferred, that legacy fields are rejected, and that identifiers must be preserved but omitted from user-facing replies. This adds substantial behavioral context for a mutating, non-idempotent creation tool.

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

Conciseness3/5

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

The core purpose is front-loaded, but the description is dense and repetitive, especially around preserving versus omitting identifiers. The reply-presentation guidance could be tightened without losing meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a 7-parameter nested creation tool with an output schema, the description covers the necessary workflow, validation expectations, session/version semantics, file binding rules, and identifier handling. No return-value explanation is needed because an output schema exists.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

It adds meaningful semantics beyond the 86%-covered schema: model is required and selects the public task model, input must follow get_model_schema, no mode or fields are inferred, flat legacy parameters are rejected, and session_title/session_id/base_run_id have distinct workflows. It also explains file_bindings and reference_files usage constraints.

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 states a specific action and scope: 'Create one independent billable Studio task.' It distinguishes itself from shortcut creation tools by noting that generate_task requires a model while shortcuts may omit it, though it does not explicitly name those alternatives.

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 gives detailed workflow guidance: read list_models.defaults, use get_model_schema, set session_title for a new topic, session_id to continue, and session_id plus base_run_id for a version. It also warns not to resubmit after rejection. It lacks an explicit 'use this instead of X when Y' routing statement for sibling tools.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources