Skip to main content
Glama

ModelCostComparison

by io.github.Lazige
OverviewDiscussionsAdmin

list_models

Read-onlyIdempotent

Use first when you know a model name or provider but need exact pricing-offer IDs for pricing or calculations. Search recorded labels and API IDs; case, spacing and punctuation variants are accepted. Multiple tariffs are returned as separate choices. Defaults to current reviewed offers; check costing_supported before calculating. This discovers pricing offers, not model capability recommendations.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum offers per page to return: 1–50; default 20.
queryNoOptional model name, recorded label or API ID to search. Use when the exact offer ID is unknown; omit to browse. Matching tolerates case, spacing and punctuation differences.
cursorNoOpaque next_cursor returned by list_models. Omit on the first page; on later pages repeat the original filters and limit unchanged. Restart without a cursor if it expires or the dataset changes.
statusNoUse current (default) for reviewed offers. Choose expired, unreviewed or all only to inspect catalogue records; those records may not support calculations.current
provider_idNoOptional exact provider_id returned by list_providers or offer identity. Use to restrict results to one provider; omit for all providers.
pricing_tierNoOptional exact tariff name from offer identity, such as standard or peak. Use to restrict results to a tariff; omit to include all tariffs.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • addedInput schema / properties / cursor / description
      Added value: +"Opaque next_cursor returned by list_models. Omit on the first page; on later pages repeat the original filters and limit unchanged. Restart without a cursor if it expires or the dataset changes."
    • addedInput schema / properties / limit / description
      Added value: +"Maximum offers per page to return: 1–50; default 20."
    • addedInput schema / properties / pricing_tier / description
      Added value: +"Optional exact tariff name from offer identity, such as standard or peak. Use to restrict results to a tariff; omit to include all tariffs."
    • addedInput schema / properties / provider_id / description
      Added value: +"Optional exact provider_id returned by list_providers or offer identity. Use to restrict results to one provider; omit for all providers."
    • addedInput schema / properties / query / description
      Added value: +"Optional model name, recorded label or API ID to search. Use when the exact offer ID is unknown; omit to browse. Matching tolerates case, spacing and punctuation differences."
    • addedInput schema / properties / status / description
      Added value: +"Use current (default) for reviewed offers. Choose expired, unreviewed or all only to inspect catalogue records; those records may not support calculations."
  2. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description adds genuine context beyond that: default scoping to 'current reviewed offers,' that multiple tariffs surface as separate choices, and that non-current records may not support calculations — useful behavioral traits not captured by annotations.

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 'use first' trigger and dense with routing information, with no wasted sentences. It is slightly run-on with several clauses packed together, but every sentence carries actionable content.

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?

For a discovery/list tool with an output schema (so return values need not be explained), the description covers the when-to-use trigger, default scope, tariff behavior, and a calculation-readiness caveat. Nothing an agent needs to invoke it correctly is missing.

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?

Schema description coverage is 100%, so the schema already documents all six parameters including defaults, enums, and variant-tolerance. The description largely restates these (defaults to current, tolerates variants), adding little syntax or format meaning beyond the structured fields, so baseline 3 applies.

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 specific resource (pricing offers/models) and its outcome (exact pricing-offer IDs) with a clear verb implied by 'search recorded labels and API IDs.' It explicitly differentiates itself from siblings by noting it 'discovers pricing offers, not model capability recommendations' and positions itself as 'use first' for obtaining offer IDs.

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 prescribes when to use it ('use first when you know a model name or provider but need exact pricing-offer IDs for pricing or calculations') and gives a downstream prerequisite ('check costing_supported before calculating'). It also draws a clear boundary against non-pricing discovery use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All ModelCostComparison toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources