Skip to main content
Glama

Price one generation for approval

aimixer_quote

Use this when the user wants to actually generate ONE image/video with the selected model and real account-owned inputs, after aimixer_options. Validates exact prompt, mode, media, current user coins and the rules of this account's route, and returns signed price, pricing_revision, approval_handle and approval_url. It creates a temporary approval record but does NOT debit or start generation; it is not a read-only operation. Missing prompt or references must be supplied before this call. An explicit human approval of the exact cost must precede aimixer_submit, using a ChatGPT/Claude MCP App inline button, website approval, OR the literal user's unambiguous answer to the localized question 'Списать N монет за ?'. If the user answers affirmatively, pass the exact reply as submit.user_consent_text with this same signed quote and approval_handle. No generic 'yes', inferred consent or invented managed media references. The quote itself never authorizes spending. Pass lang = the user's language so the approval card matches the chat.

Input Schema

NameRequiredDescriptionDefault
fileNoOriginal image/video/audio ChatGPT attachment, automatically imported before generation. No extra upload tool or public URL is needed.
langNoThe user's conversation language (ru, en, es, pt); the approval card uses it.
familyYes
valuesNoOnly model-public settings returned by aimixer_options.effective_values and its controls. Do not supply provider route, payer IDs, or billing internals.
audio_urlsNo
image_urlsNo
video_urlsNo
source_urlsNo
result_originsNo
audio_durationsNo
video_durationsNo
element_payloadsNo
canvas_project_idNo
file_media_familyNoType of attachment if MIME/name alone is ambiguous.
image_source_urlsNo
execution_model_keyNoExact typed execution model advertised by the selected family. Currently used by Topaz; never put provider ids into values.model.
image_urls_by_bucketNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / lang
      Added value: +{
      +  "description": "The user's conversation language (ru, en, es, pt); the approval card uses it.",
      +  "maxLength": 16,
      +  "minLength": 2,
      +  "type": "string"
      +}
  2. First observed

TDQS

A4.2/5.0
Behavior5/5

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

Annotations declare readOnlyHint=false and the description confirms 'it is not a read-only operation', creating no contradiction and adding substance: it creates a temporary approval record, does not debit, does not start generation, and a quote never authorizes spending. The consent-text rule (exact localized reply) and the 'no generic yes / inferred consent' constraint are behavior the annotations cannot express.

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?

Front-loaded with the 'Use this when' trigger and otherwise dense, but the approval-flow paragraph is long and repeats the consent/signed-quote idea several times. It earns most of its length given the complexity, yet could be tightened without losing meaning.

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?

The workflow, safety and approval context is unusually complete for a 17-parameter tool, and no output schema exists to require return-value explanation. However, with low schema coverage the description leaves the majority of input parameters opaque, which is a real gap for a call with this many optional media fields.

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

Parameters2/5

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

Schema description coverage is only 29% across 17 parameters, so the description must compensate but does not. It gives useful meaning for a few (lang rationale, values must come from aimixer_options, 'no invented managed media references', prompt/mode/media must exist) but leaves most of image_urls, video_urls, source_urls, result_origins, element_payloads, canvas_project_id and audio/video_durations unexplained.

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 (price/quote) and resource (one image/video generation) and pins the exact trigger ('the user wants to actually generate ONE image/video... after aimixer_options'). It also names the outputs (signed price, approval_handle, approval_url), letting an agent tell it apart from aimixer_submit and aimixer_batch_quote without opening a 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 places the call in the workflow: after aimixer_options, before aimixer_submit, and requires that missing prompt/references be supplied first. It also defines the boundary behavior ('does NOT debit or start generation') and the mandatory human-approval precondition, so both when-to-use and when-not are covered.

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