Skip to main content
Glama

Estimate a monthly bill

estimate_monthly_cost
Read-only

Estimate your monthly AI API bill in USD for one model across all priced providers, ranked cheapest first, using token volumes or category units.

Instructions

Estimate a monthly workload bill in USD across every priced provider for one model, ordered cheapest first (standard list prices only; excludes caching, batch, and volume discounts; unpriced providers are omitted). For text LLMs pass input_million_tokens and/or output_million_tokens; for all other categories pass units. Use model_prices for raw per-unit rates or compare_models for a two-model headline comparison.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "model": "<model>"
    },
    "name": "estimate_monthly_cost"
  }
}

Input Schema

NameRequiredDescriptionDefault
modelYesModel name or slug, e.g. "gpt-oss-120b" or "flux".
unitsNoNon-LLM categories only: monthly volume in category units (images, video seconds, audio hours, million characters for tts, thousand searches, or million tokens for embedding).
categoryNoOptional category filter: text (LLMs), image, video, transcription (speech-to-text), tts (text-to-speech), search (web search), or embedding.
input_million_tokensNoText LLMs only: monthly input tokens in millions (e.g. 10).
output_million_tokensNoText LLMs only: monthly output tokens in millions (e.g. 2).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv1.0.1
    • changedInput schema / properties / category / description
      Previous value: -"text (LLMs), image, video, transcription, tts, search or embedding"New value: +"Optional category filter: text (LLMs), image, video, transcription (speech-to-text), tts (text-to-speech), search (web search), or embedding."
    • changedInput schema / properties / input_million_tokens / description
      Previous value: -"LLMs: input tokens per month, in millions"New value: +"Text LLMs only: monthly input tokens in millions (e.g. 10)."
    • changedInput schema / properties / model / description
      Previous value: -"Model name"New value: +"Model name or slug, e.g. \"gpt-oss-120b\" or \"flux\"."
    • changedInput schema / properties / output_million_tokens / description
      Previous value: -"LLMs: output tokens per month, in millions"New value: +"Text LLMs only: monthly output tokens in millions (e.g. 2)."
    • changedInput schema / properties / units / description
      Previous value: -"Other categories: monthly usage in the category's unit"New value: +"Non-LLM categories only: monthly volume in category units (images, video seconds, audio hours, million characters for tts, thousand searches, or million tokens for embedding)."
  2. First observedv1.0.0

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the readOnlyHint/openWorldHint annotations, the description discloses the pricing basis (standard list prices only), the exclusions (caching, batch, volume discounts), the omission of unpriced providers, the currency, and the sort order. These are exactly the caveats an agent needs before presenting a number as authoritative.

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?

Two sentences, both dense with decision-relevant content, with the exclusions parenthesized rather than sprawling into extra prose. The alternative-tool routing is placed last, after the primary scope is established.

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 carries the burden of describing the result and does so: a per-provider USD estimate ordered cheapest first with unpriced providers dropped. For a five-parameter, read-only estimation tool, nothing essential is missing.

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 schema already documents each parameter's meaning; the description's added value is the routing logic between the token parameters and units, which helps the agent avoid mixing categories. It stops short of adding format or validation detail beyond what the schema provides, so not a 5.

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 opens with a precise verb and resource ("Estimate a monthly workload bill in USD") and scopes it to one model across every priced provider, ordered cheapest first. This is specific enough that an agent can immediately distinguish it from siblings like model_prices and compare_models.

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 states which parameters to pass for text LLMs versus all other categories, and names two alternatives with the conditions that select them (model_prices for raw per-unit rates, compare_models for a two-model headline comparison). No usage decision 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.