Skip to main content
Glama

arsaze_estimate_generation_cost

Read-only

Show the user exactly what a generation will cost in credits BEFORE running it, as an interactive card with a Generate button.

Call this FIRST, instead of asking "shall I generate? it will use some
credits" — you do not know the rate, it is set per plan and per model by
an admin and changes without any code change, so any number you state
from memory will eventually be wrong. This reads the user's real plan
and real balance and prices the run the same way the generation itself
will.

Nothing is charged and nothing is reserved by calling this. It is a
quote. Generation only starts if the user then asks for it.

kind: "video", "image" or "voice".
provider: the model id you intend to use — get real ones from
  video_gen.list_providers / image_gen.list_providers, never from
  memory. Omit to quote the plan's standard rate for that kind.
duration_seconds: the duration you intend to request. Only affects
  duration-priced models; harmless to pass otherwise.
quantity: how many separate generations (e.g. number_of_images).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindYes
providerNo
quantityNo
duration_secondsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A5/5.0
Behavior5/5

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

Beyond the readOnlyHint=true and destructiveHint=false annotations, the description discloses that the call is a non-charging, non-reserving quote, that it reads the user's real plan and balance, and that it prices identically to the eventual generation. This is valuable behavioral context that annotations alone do not convey.

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?

The description is front-loaded with the core action and result, followed by an explicit usage rule and a compact parameter legend. Every sentence carries necessary information, so the length is justified and nothing is wasted.

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?

With no output schema, the description's promise of an interactive card with a Generate button provides the needed output contract. The non-charge/reservation statement and complete parameter guidance give the agent everything required to invoke it correctly in context.

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?

With schema description coverage at 0%, the description fully compensates by explaining every parameter: allowed kind values, provider sourced from real list_providers calls, duration_seconds only affecting duration-priced models, and quantity as the count of separate generations. Each schema field gains operational meaning.

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 states a precise verb and resource: show the user, as an interactive quote card, exactly what a generation will cost in credits before running it. It clearly frames the tool as a quote and distinguishes it from generation tools and the credits-display sibling arsaze_show_credits.

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?

It explicitly says when to call: FIRST, before any generation, instead of asking a generic 'shall I generate?' or guessing rates. The rationale that rates are admin-set and change without code changes, plus the caveat that generation only starts if the user follows up, gives the agent a clear decision rule.

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.