Skip to main content
Glama

Calculate a MaxVideoAI project budget

calculate_project_budget
Read-only

Use this when the user needs current pricing estimates of concrete video production proposals, including single- or mixed-model shots, clip counts and explicit creative attempts. The host owns the creative plan and names each proposal; give mixed-model shots a factual rationale. Validate each selected mode with get_model_details. Compare proposals using the same output and attempts assumptions before calling an alternative cheaper or lower-cost. Separate base production from creative-attempt allowance: creative attempts are billable scenarios; technical failures follow the returned job and refund state. Estimates do not reserve a price or authorize generation. Prices use the connected environment and may differ between staging and production. If audio is always_generated or unavailable, omit settings.audio; only send it when optional. If aspectRatios is empty, omit aspectRatio; otherwise use a supported value. Do not use it to invent the creative plan, reserve a price, create a generation quote, inspect the wallet, or spend funds.

Input Schema

NameRequiredDescriptionDefault
proposalsYesOne to four user-named video production proposals, including single-model or mixed-model approaches.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / proposals / items / properties / lines / items / properties / referenceRoles / anyOf
      Previous value: -[
      -  {
      -    "items": {
      -      "description": "How this declared reference will be used for the video line.",
      -      "enum": [
      -        "source",
      -        "first_frame",
      -        "last_frame",
      -        "reference"
      -      ],
      -      "type": "string"
      -    },
      -    "maxItems": 50,
      -    "type": "array"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "items": {
      +      "description": "How this declared reference will be used for the video line.",
      +      "enum": [
      +        "source",
      +        "first_frame",
      +        "last_frame",
      +        "reference"
      +      ],
      +      "type": "string"
      +    },
      +    "maxItems": 66,
      +    "type": "array"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
  2. Changed1 schema field changed
    • addedInput schema / properties / proposals / items / properties / lines / items / properties / settings / properties / keyframeIndexes
      Added value: +{
      +  "anyOf": [
      +    {
      +      "maxLength": 128,
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Use only when model details report keyframeIndexes. Unique integer frame positions, comma-separated in the same order as referenceRoles; FLUX 3 Max uses 24 fps and accepts 0 through durationSec × 24 inclusive. One position per declared image reference."
      +}
  3. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare a read-only, closed-world, non-destructive call, and the description adds substantive context beyond them: estimates neither reserve a price nor authorize generation, prices are environment-dependent and can differ between staging and production, creative attempts are billable while technical failures follow the returned job/refund state.

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?

Front-loaded with the triggering condition, then ordered rules (validate, compare, separate base from attempts, disclaimers). Dense and mostly waste-free, though the audio/aspectRatio omission instructions largely restate the nested schema field descriptions.

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?

Covers the hard parts of a deeply nested, four-proposal pricing call: capability validation, comparison fairness and the non-binding nature of estimates. It only lightly gestures at the return content ('the returned job and refund state'), and with no output schema a sentence on the per-proposal/line breakdown would close the remaining gap.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds cross-field meaning the schema does not: the host owns and names the proposals, mixed-model lines need a factual rationale, and audio/aspectRatio omission rules are tied to get_model_details output. It also clarifies that attempts beyond the first are a deliberate billable iteration allowance rather than retries.

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 — producing current pricing estimates for named, concrete video production proposals, including mixed-model shots, clip counts and creative attempts. The negative list (do not invent the creative plan, reserve a price, create a generation quote, inspect the wallet, spend funds) clearly separates it from prepare_generation, confirm_generation and get_account_status.

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?

Explicit triggering condition ('when the user needs current pricing estimates'), explicit validation prerequisite (check each mode with get_model_details), explicit fairness rule for comparisons (same output and attempts assumptions), and an explicit when-not list. Very little 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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.