Skip to main content
Glama

framesail

by com.framesail
OverviewDiscussions(1)Admin

Generate asset reference image

generate_asset_reference

Render an asset's reference image in the channel's art style — the visual anchor that keeps a character/environment looking identical across every shot. EVERY character, environment, and object asset needs one before generate_voiceover (the server enforces this; fire the jobs for all assets, then one await_jobs). Async — the job writes the image onto the asset row: await_jobs(project_id), then list_assets and view_image the file_path to check likeness.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modelNoImage model ID; empty uses the asset's saved drawer choice, else the account default, else the server default
asset_idYesID of the asset to render a reference image for, from list_assets
settingsNoModel-specific settings (e.g. image quality/orientation); valid keys come from the model's settings_schema in list_models
editable_sectionsNoPer-call prompt section overrides, keyed by section name; see get_section_template for the reference-image job

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / model / description
      Previous value: -"Image model ID; empty uses the server default for reference images"New value: +"Image model ID; empty uses the asset's saved drawer choice, else the account default, else the server default"
  2. Changed4 schema fields changed
    • addedInput schema / properties / asset_id / description
      Added value: +"ID of the asset to render a reference image for, from list_assets"
    • addedInput schema / properties / editable_sections / description
      Added value: +"Per-call prompt section overrides, keyed by section name; see get_section_template for the reference-image job"
    • addedInput schema / properties / model / description
      Added value: +"Image model ID; empty uses the server default for reference images"
    • addedInput schema / properties / settings / description
      Added value: +"Model-specific settings (e.g. image quality/orientation); valid keys come from the model's settings_schema in list_models"
  3. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations declare write/non-idempotent/non-destructive, but the description adds the key traits beyond them: the call is async, the job writes the image back onto the asset row, and the server enforces the prerequisite ordering. It does not mention cost or failure/retry behavior, which is the one remaining gap for an image-generation job.

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

Conciseness4/5

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

Purpose is front-loaded in the first clause and every sentence carries information (role, prerequisite, ordering, verification loop). It is dense and slightly instruction-heavy, but no sentence is wasted.

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

Completeness4/5

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

With no output schema, the description usefully explains where the result lands and how to verify it (view_image the file_path) plus the correct batching pattern. It is nearly complete for a 4-param async job, though cost/time expectations are unaddressed.

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 description coverage is 100%, so model, settings, and editable_sections are already documented in the schema. The description adds no parameter-level detail (e.g., guidance on which model or section overrides to use), so the baseline 3 is correct.

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?

States a specific verb and resource ("Render an asset's reference image") plus the scope (in the channel's art style) and the artifact's role as a cross-shot visual anchor. An agent can distinguish this from generate_voiceover, regenerate_segment_asset, and create_asset without opening any schema.

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

Usage Guidelines5/5

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

Explicitly states when it must be used ("EVERY character, environment, and object asset needs one before generate_voiceover"), that the server enforces this ordering, and names the follow-up tools (await_jobs, list_assets, view_image). Nothing about sequencing is left to inference.

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

All framesail 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