Skip to main content
Glama

Estimate the cost of a chain

estimate
Read-onlyIdempotent

Pre-price an invocation chain BEFORE spending money. Each step is either a concrete offering ("node_id/offering_id") or a select query that picks the best match, plus expected input and output tokens. Returns per-step cost bounds in USD, the pinned card_revision that makes each estimate enforceable at invocation, and chain totals. Use it to compare routes or budget a multi-model pipeline; nothing is invoked or charged.

Input Schema

NameRequiredDescriptionDefault
stepsYesSteps in execution order.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / steps / items / properties / select / properties / region / description
      Previous value: -"Data residency: every pinned region and every live serving site must lie inside this ISO 3166 code, e.g. \"CA\" (also matches \"CA-QC\") or \"EU\"."New value: +"Data residency: every pinned region and every live serving site must lie inside this ISO 3166 code, e.g. \"CA\" (also matches \"CA-QC\") or \"EU\" (also matches member states such as \"DE\"; \"EEA\" adds IS, LI, NO)."
  2. Changed3 schema fields changed
    • addedInput schema / properties / steps / items / properties / select / properties / exclude_lineage
      Added value: +{
      +  "description": "Comma-separated ISO country codes; drops offerings whose declared model lineage includes any of them, e.g. \"CN\". Offerings that declare no lineage are kept.",
      +  "type": "string"
      +}
    • addedInput schema / properties / steps / items / properties / select / properties / location_basis
      Added value: +{
      +  "description": "Minimum evidence for the serving locations: claimed < documented (the provider's own dated page) < measured (registry probes) < attested. Offerings without known locations are excluded.",
      +  "enum": [
      +    "claimed",
      +    "documented",
      +    "measured",
      +    "attested"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / steps / items / properties / select / properties / region
      Added value: +{
      +  "description": "Data residency: every pinned region and every live serving site must lie inside this ISO 3166 code, e.g. \"CA\" (also matches \"CA-QC\") or \"EU\".",
      +  "type": "string"
      +}
  3. Changed2 schema fields changed
    • addedInput schema / properties / steps / items / properties / select / properties / local
      Added value: +{
      +  "description": "true: only models that run on the user's own machine (the Ollama library: no server, free, ranked by Ollama pulls, with local.sizes_memory per size). false: only hosted offerings. Omit for both (hosted listed first). The result's counts give { hosted, local }.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / steps / items / properties / select / properties / memory_gb
      Added value: +{
      +  "description": "RAM/VRAM the user can give a local model, in GB: keeps local models with a size that fits (4-bit estimate). Hosted offerings are unaffected.",
      +  "minimum": 1,
      +  "type": "number"
      +}
  4. Changed1 schema field changed
    • changedInput schema / properties / steps / items / properties / select / properties / jurisdiction / description
      Previous value: -"Only operators that declare a country inside it: \"eea\" (EU + Iceland, Liechtenstein, Norway) or comma-separated ISO country codes, e.g. \"DE,FI\". Imported listings declare no country and are excluded."New value: +"Only operators that declare a country inside it: \"eea\" (EU + Iceland, Liechtenstein, Norway) or comma-separated ISO country codes, e.g. \"DE,FI\". Registered nodes declare their country; imported listings of known providers carry an inferred one (jurisdiction.basis = \"inferred\"); listings without a country are excluded."
  5. Changed1 schema field changed
    • addedInput schema / properties / steps / items / properties / select / properties / jurisdiction
      Added value: +{
      +  "description": "Only operators that declare a country inside it: \"eea\" (EU + Iceland, Liechtenstein, Norway) or comma-separated ISO country codes, e.g. \"DE,FI\". Imported listings declare no country and are excluded.",
      +  "type": "string"
      +}
  6. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the read-only and idempotent annotations, it discloses that no invocation or charge occurs and that results are cost bounds rather than a single guaranteed price. It also explains the practical significance of the returned pinned card_revision: making an estimate enforceable at invocation.

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 tool’s purpose, then efficiently covers inputs, outputs, use cases, and side-effect safety. Every sentence contributes operational information without unnecessary background or repetition.

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?

Despite the detailed nested schema, the description supplies the mental model needed to invoke the tool and interpret its results: ordered chain steps, per-step USD bounds, enforceable revisions, and totals. The absence of an output schema is mitigated by this explicit return-value summary, while the schema documents the detailed filters and constraints.

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?

The description usefully summarizes the step shape—either a concrete offering or a select query, plus token estimates—but this largely repeats the fully documented schema. It adds no further guidance on estimating token counts, selection tie-breaking, or other parameter behavior, so the high schema coverage leaves this at the baseline.

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?

“Pre-price an invocation chain” states a specific action and resource, while “compare routes or budget a multi-model pipeline” clarifies its planning role. This clearly distinguishes cost estimation from the discovery- and recommendation-oriented sibling tools.

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?

The description gives explicit timing (“BEFORE spending money”) and concrete use cases: comparing routes and budgeting a pipeline. “Nothing is invoked or charged” also supplies a clear when-not boundary by ruling out use for execution or payment.

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.