Skip to main content
Glama
Sign In
Model Finder

Model Finder

by Abhiindigloo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Estimate monthly token cost

modelfinder_estimate_cost
Read-onlyIdempotent

Estimate monthly token spend from request volume, token counts, and provider prices, including cached input and retry pass rates, to compare models and plan evaluations before running them.

Instructions

Estimate monthly token cost from requests per month, average tokens per request and USD-per-million prices, with optional cached-input share and pass rate (cost per accepted result, counting retries). Use for planning or to compare models before running an eval. Read-only and local: no network calls, no files written. Prices are not looked up: pass them from the provider's official pricing page. Returns cost per request, monthly cost and the assumptions used.

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": {
      "requests_per_month": "<requests_per_month>",
      "input_tokens": "<input_tokens>",
      "output_tokens": "<output_tokens>",
      "input_price_per_million": "<input_price_per_million>",
      "output_price_per_million": "<output_price_per_million>"
    },
    "name": "modelfinder_estimate_cost"
  }
}

Input Schema

NameRequiredDescriptionDefault
pass_rateNoOptional eval pass rate; failures are assumed retried.
input_tokensYesAverage input tokens per request.
output_tokensYesAverage output tokens per request (include reasoning tokens).
cached_fractionNoShare of input tokens billed at the cached rate (0-1).
response_formatNomarkdown (default) for a readable summary, json for the full machine-readable result.markdown
requests_per_monthYese.g. 100000
input_price_per_millionYesUSD per 1M input tokens.
output_price_per_millionYesUSD per 1M output tokens.
cached_input_price_per_millionNoRequired when cached_fraction > 0.

Output Schema

NameRequiredDescriptionDefault
assumptionsYes
monthly_cost_usdYes
cost_per_request_usdYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.3.5

TDQS

A4.4/5.0
Behavior4/5

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

Goes beyond the annotations by disclosing the key caveat that prices are not looked up and must be supplied from the provider's pricing page, and by explaining what the pass rate does (cost per accepted result, counting retries). The 'read-only and local: no network calls, no files written' sentence largely restates readOnlyHint/openWorldHint, so it earns credit for the price caveat rather than that line.

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 calculation and its inputs, then the use case, then the safety caveat, then the return shape. Dense but every sentence carries information; the only mild redundancy is the read-only/local line that duplicates annotation hints.

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 nine-parameter calculator with an output schema, the description covers inputs, the planning use case, the critical external dependency (prices passed in, not fetched), and what is returned. 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.

Parameters4/5

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

Schema coverage is already 100%, so the baseline is 3; the description adds real meaning on top by defining what pass_rate actually computes (cost per accepted result, with failures retried) and framing cached-input share as an optional modifier. It does not spell out response_format's effect beyond what the schema enum already says.

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 ('Estimate monthly token cost') and enumerates the exact inputs that drive it (requests per month, average tokens per request, USD-per-million prices). It is clearly distinguishable from the sibling modelfinder_estimate_memory, which covers a different resource.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Use for planning or to compare models before running an eval' gives a concrete decision context tied to the eval-oriented siblings. It does not name an explicit alternative or a when-not-to-use condition, so it stops short of full routing guidance.

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

Deploy Server

Other Tools