Which integrations are available for this server?

Integrates with GitHub Copilot to provide cost prediction and model routing, allowing Copilot-powered agents to estimate costs and select the cheapest suitable model for code generation tasks.

How do I use ModelCostSaver?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ModelCostSaver What's the cheapest model for summarizing a 2000-word article?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

ModelCostSaver

by sachinuppal

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Local

ModelCostSaver

Predict the cost of an LLM call before you make it, and pick the cheapest model that still does the job, offline, from your editor.

No API keys Offline by default No telemetry License Dependencies

ModelCostSaver is a Model Context Protocol server. It gives any AI coding agent or IDE a free, zero-config tool that answers the three questions every agent should ask before an LLM call:

What will this prompt cost on each candidate model? (predict_cost, estimate_cost)
Which is the cheapest model that meets the task? (select_optimal_model)
How do my options compare side by side? (compare_models)

It is pure pricing-and-routing math over a bundled, dated catalog, so the core needs no API keys and makes no network calls.

Quick start

Run it directly with npx (no install, no keys):

npx -y @workswarm/modelcostsaver

Or write the config for your editor in one command:

npx -y @workswarm/modelcostsaver install --client cursor

Add to Cursor — one click installs it in Cursor. Or drop the block below into ~/.cursor/mcp.json, or run npx -y @workswarm/modelcostsaver install --client cursor.

Listed on the official MCP registry and editor MCP directories as io.github.sachinuppal/modelcostsaver.

Related MCP server: TokenLens MCP

The seven tools

Tool	What it answers
`estimate_cost`	Cost of one call when you already know (or can estimate) the token counts.
`predict_cost`	Forecast cost across a candidate set from a prompt, before the call. Ranked cheapest-first.
`select_optimal_model`	The cheapest model that meets the task tier, capabilities, and budget, with full reasoning.
`compare_models`	A side-by-side cost table for a fixed token shape, with `relativeToCheapest`.
`list_models` / `get_pricing`	The pricing catalog, filterable by provider, tier, capability, or max input price.
`optimize_request`	"I plan to call model X, can I do better?" Returns the cheaper option and the savings.
`record_usage`	Append a local usage record (opt-in; off unless `MODELCOSTSAVER_LEDGER=on`).

Every cost-bearing result carries catalogVersion and asOf so you can see how fresh the prices are. Every selection carries a reasoning array, never a black-box pick.

Trust: no keys, offline, no telemetry

For a tool that sits in your editor, trust is the whole pitch. ModelCostSaver is:

No API keys. The core does pricing math, not provider calls. Nothing to leak.
Offline by default. The core tools return correct answers with no network access. The only outbound request is an opt-in catalog refresh (MODELCOSTSAVER_REFRESH=on), a single GET of a static JSON, zod-validated before it can replace the bundled catalog, and it always falls back to the bundle on any failure.
No telemetry. Ever. The default is silent and local. record_usage only writes when you set MODELCOSTSAVER_LEDGER=on, and only to a JSONL file under your own config dir.
Two dependencies. @modelcontextprotocol/sdk and zod. Nothing else. Small supply-chain surface, fast npx cold start.
Apache-2.0. An open-source developer tool published by Workswarm as @workswarm/modelcostsaver. The shipped bundle contains no proprietary or internal-service code: no internal-framework imports and no internal identifiers, just dependency-free pricing-and-routing math.

stdout carries only JSON-RPC; all logs go to stderr.

Install per IDE

ModelCostSaver speaks stdio MCP, so the entry is the same npx command everywhere. Use install --client <name> to write it idempotently, or paste the block by hand.

Cursor

~/.cursor/mcp.json (global) or .cursor/mcp.json (project):

{ "mcpServers": { "modelcostsaver": { "command": "npx", "args": ["-y", "@workswarm/modelcostsaver"] } } }

npx -y @workswarm/modelcostsaver install --client cursor

Claude Code

claude mcp add modelcostsaver -- npx -y @workswarm/modelcostsaver

or a .mcp.json in the repo root (which install --client claude writes):

{ "mcpServers": { "modelcostsaver": { "command": "npx", "args": ["-y", "@workswarm/modelcostsaver"], "env": { "MODELCOSTSAVER_PROVIDERS": "anthropic" } } } }

Claude clients run Claude for their own inference, so the install seeds MODELCOSTSAVER_PROVIDERS=anthropic as a sensible default for target: self recommendations. Override it per call or with the env var. See Self vs code.

Claude Desktop

Add the same mcpServers block to claude_desktop_config.json.

VS Code / GitHub Copilot

.vscode/mcp.json:

{ "servers": { "modelcostsaver": { "command": "npx", "args": ["-y", "@workswarm/modelcostsaver"], "type": "stdio" } } }

npx -y @workswarm/modelcostsaver install --client vscode

Windsurf

~/.codeium/windsurf/mcp_config.json with the same mcpServers block, or:

npx -y @workswarm/modelcostsaver install --client windsurf

Cline / Zed / Antigravity

Same stdio command/args. Use the matching installer:

npx -y @workswarm/modelcostsaver install --client cline
npx -y @workswarm/modelcostsaver install --client zed
npx -y @workswarm/modelcostsaver install --client antigravity

After adding the server, restart the client and confirm the seven tools appear in the tool list.

Two axes: self vs code

ModelCostSaver advises; it does not route traffic. So every recommendation is filtered to what you can actually act on, along two independent axes.

Axis 1, availability. Recommendations are scoped to a set of allowed providers. The default is derived from the connected client (read from the MCP handshake): a Claude client defaults to anthropic because its own inference is Claude; multi-provider clients (Cursor, VS Code, Windsurf, Cline, Zed, Antigravity) and unknown clients default to all providers. The scope and its source are always echoed in reasoning, and it is overridable: a per-call providers arg, then MODELCOSTSAVER_PROVIDERS, then config, then the client default, then all.

Axis 2, target.

target: 'self' (default): the agent's or your own next inference in this client. The Axis-1 scope applies. In Claude Code this means cross-tier Anthropic moves (Opus to Haiku), which you can act on right now.
target: 'code': a model you will call from your own application, where you supply that provider's key. The client scope does not apply, so all in-catalog providers are eligible.

ModelCostSaver is always honest about the gap: if the globally-cheapest model is outside your actionable set, it is surfaced as cheaperIfAvailable with the reason, never silently chosen. For example, a Claude Code target: self summarize call selects claude-haiku-4-5 and notes that a cheaper non-Anthropic model exists if you pass target: code.

How it predicts

Tokens. Exact counts if you supply them; otherwise a heuristic estimate (~4 chars/token, tunable via MODELCOSTSAVER_CHARS_PER_TOKEN). The heuristic is approximate but common-mode across candidates, which is what relative ranking needs. Output tokens come from your explicit value, then the task class cap, then the model cap, then a conservative default.
Cost. (inTok / 1e6) * inputPerMillion + (outTok / 1e6) * outputPerMillion, in full-precision USD and as integer usdMicros. A prediction is never rounded to cents.
Selection. Resolve the target tier (from an explicit taskClass, else a transparent keyword/length classifier), filter candidates by tier (degrade up, never below the floor), capabilities, and provider scope, forecast each, drop those over budget into rejected, and pick the cheapest survivor. Every step is recorded in reasoning, and a fallbackChain is returned for retry-on-failure.

Configuration

All config is optional. Precedence: tool-call arg, then env var, then modelcostsaver.config.json (cwd, then your user config dir), then the built-in default.

Key	Env	Default	Purpose
tier overrides	`MODELCOSTSAVER_TRIVIAL_MODEL`, `_FAST_MODEL`, `_STANDARD_MODEL`, `_REASONING_MODEL`	catalog cheapest per tier	Pin a preferred model per tier.
providers	`MODELCOSTSAVER_PROVIDERS`	client-derived	Allowlist for recommendations (Axis 1).
default provider	`MODELCOSTSAVER_PROVIDER`	none	Bias `select_optimal_model`.
include local	`MODELCOSTSAVER_INCLUDE_LOCAL`	`off`	Surface self-hosted / $0 models.
chars/token	`MODELCOSTSAVER_CHARS_PER_TOKEN`	`4`	Tune the token estimator.
refresh	`MODELCOSTSAVER_REFRESH`	`off`	Enable the opt-in remote catalog refresh.
catalog url	`MODELCOSTSAVER_CATALOG_URL`	bundled	Override the refresh source.
ledger	`MODELCOSTSAVER_LEDGER`	`off`	Enable the local `record_usage` write.
telemetry	`MODELCOSTSAVER_TELEMETRY`	`off`	Kept off; listed for transparency.

Pricing data

Prices change often, so ModelCostSaver ships a versioned, dated seed and is honest about its freshness.

The bundled catalog.json carries a catalogVersion, an asOf date, and a source on every entry.
Default behavior is offline: it reads only the bundled catalog.
MODELCOSTSAVER_REFRESH=on fetches a single static JSON, validates it with zod, caches it with a TTL, and falls back to the bundle on any failure.
A pricingOverrides map in modelcostsaver.config.json lets you inject negotiated or enterprise rates without forking.

Verify before you trust a number for billing. The seed is re-checked against each provider's public pricing page at release; the asOf date tells you when. For absolute precision in your own accounting, confirm against your provider invoice.

Development

npm install        # first time only
npm run build      # tsup bundle to dist/index.js
npm test           # vitest
npm run typecheck  # tsc --noEmit
npm run smoke      # stdio JSON-RPC smoke test (asserts stdout stays clean)

License

Apache-2.0. See NOTICE.

Available Tools

7 tools

compare_modelsCompare modelsB

Compare models side by side for a fixed token shape, cheapest first, with the multiple of the cheapest. Offline.

ParametersJSON Schema

Name	Required	Description
`models`	Yes	Models to compare (alias or id).
`inputTokens`	Yes	Input tokens for the comparison.
`outputTokens`	Yes	Output tokens for the comparison.
`providers`	No	Axis 1: provider availability allowlist (spec 5.4).
`target`	No	Axis 2: "self" (default) applies the client scope; "code" considers all providers.

Output Schema

ParametersJSON Schema

Name	Required	Description
`rows`	Yes
`cheapest`	Yes
`mostCapable`	Yes
`cheaperIfAvailable`	No
`unknownModels`	Yes
`providerScope`	Yes
`scopeSource`	Yes
`catalogVersion`	Yes
`asOf`	Yes

TDQS

B3.4/5.0

Behavior2/5

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

No annotations provided, so description should disclose behaviors. It states 'Offline' but does not clarify what that entails (e.g., no network call, local cache). No mention of permissions, side effects, or data sources. The sorting and ratio calculation are mentioned but minimal.

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?

One sentence covering key aspects: comparison, sorting, ratio, offline. It is efficient but could be more structured (e.g., bullet points). No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With output schema present, return values are covered. However, ambiguity about 'Offline' and lack of explanation for 'multiple of the cheapest' leaves gaps. Adequate for a simple comparison tool but not fully comprehensive.

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 all parameters are documented. The description adds limited value beyond schema: 'fixed token shape' reinforces input/output tokens, but no extra formatting or constraints.

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 clearly states the tool compares models side by side for a fixed token shape, sorts cheapest first, and includes the multiple of the cheapest. It mentions 'offline' and distinguishes from sibling tools like estimate_cost and get_pricing by focusing on comparison.

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

Usage Guidelines3/5

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

No explicit guidance on when to use this tool vs siblings such as select_optimal_model or estimate_cost. The description implies usage for fixed token shapes and offline computation, but does not specify prerequisites or exclude alternatives.

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

estimate_costEstimate costA

Estimate the cost of a single LLM call for one model from known or estimated token counts. Offline, no keys.

ParametersJSON Schema

Name	Required	Description
`model`	Yes	Model alias or full id, e.g. "sonnet" or "claude-sonnet-4-6".
`inputTokens`	No	Exact input tokens; optional if inputText is given.
`outputTokens`	No	Exact output tokens; defaults to the model output cap.
`inputText`	No	Prompt text; estimated to tokens if inputTokens is absent.
`expectedOutputText`	No	Expected output text; estimated if outputTokens is absent.
`charsPerToken`	No	Override the chars-per-token heuristic divisor.

Output Schema

ParametersJSON Schema

Name	Required	Description
`model`	Yes
`provider`	Yes
`tier`	Yes
`inputTokens`	Yes
`outputTokens`	Yes
`tokensWereEstimated`	Yes
`cost`	Yes
`breakdown`	Yes
`pricing`	Yes
`catalogVersion`	Yes
`asOf`	Yes

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It discloses offline behavior and no key requirement, but lacks details on idempotency, caching, error conditions, or whether it uses live pricing data. Adds some transparency but insufficient for a tool with zero annotations.

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 concise sentences, front-loaded with purpose. No fluff or redundancy. Every word adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 6 params and an output schema available, the description covers basic purpose and key behavioral trait (offline, no keys). However, it doesn't differentiate from similar sibling predict_cost, nor explain expected input format details or error cases. Adequate but not thorough.

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 coverage is 100%, so the description need not repeat parameter details. It adds the global context 'Offline, no keys' and mentions charsPerToken override, but no additional semantics beyond the schema for individual parameters. Baseline 3 is appropriate.

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?

Clearly states verb 'estimate cost' and resource 'single LLM call for one model'. Distinguishes from siblings like compare_models, get_pricing, and predict_cost by focusing on a single call with known/estimated token counts and emphasizing offline usage.

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

Usage Guidelines3/5

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

Mentions 'Offline, no keys' implying no API call needed, but does not explicitly state when to use this tool versus alternatives like predict_cost or select_optimal_model. No when-not-to-use guidance.

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

get_pricingList models / pricingC

Return the model catalog with pricing, optionally filtered. capabilities are arrays. Offline.

ParametersJSON Schema

Name	Required	Description
`provider`	No	Filter to a single provider.
`tier`	No	Filter to a single tier.
`capability`	No	Require a capability.
`maxInputPerMillion`	No	Only models at or below this input price per 1M tokens.
`includeLocal`	No	Include local / self-hosted $0 models (off by default).

Output Schema

ParametersJSON Schema

Name	Required	Description
`models`	Yes
`count`	Yes
`catalogVersion`	Yes
`asOf`	Yes
`source`	Yes

TDQS

C2.8/5.0

Behavior2/5

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

No annotations are provided, so the description carries the burden. It mentions 'Offline' which suggests cached data but is ambiguous. It does not explicitly state it is read-only or disclose any behavioral traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short but includes an ambiguous phrase 'capabilities are arrays' and 'Offline'. Every sentence could be more informative, but it is not overly verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 5 parameters and an output schema, the description is minimal. It does not explain the 'Offline' aspect or how caching works, nor does it provide context for the pricing data.

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 has 100% description coverage for parameters, so baseline is 3. The description adds minimal meaning beyond 'capabilities are arrays', which is somewhat unclear and does not enhance parameter understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns the model catalog with pricing and supports optional filtering. However, it does not explicitly distinguish itself from the sibling tool 'list_models', which could be a potential overlap.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives like 'estimate_cost' or 'compare_models'. The description lacks context for usage.

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

list_modelsList models / pricingB

Return the model catalog with pricing, optionally filtered. capabilities are arrays. Offline.

ParametersJSON Schema

Name	Required	Description
`provider`	No	Filter to a single provider.
`tier`	No	Filter to a single tier.
`capability`	No	Require a capability.
`maxInputPerMillion`	No	Only models at or below this input price per 1M tokens.
`includeLocal`	No	Include local / self-hosted $0 models (off by default).

Output Schema

ParametersJSON Schema

Name	Required	Description
`models`	Yes
`count`	Yes
`catalogVersion`	Yes
`asOf`	Yes
`source`	Yes

TDQS

B3.2/5.0

Behavior3/5

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

With no annotations, the description bears full burden for behavioral disclosure. It notes that capabilities are arrays and that data is offline (static), which adds value. However, it omits details on data freshness, pagination, rate limits, or any side effects. The 'Offline' hint is useful but insufficient for full transparency.

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?

The description is very concise, with only two short sentences and a fragment. It front-loads the main purpose. However, the fragments ('capabilities are arrays. Offline.') are not grammatically integrated, which slightly detracts from structure. Overall efficient but could be more polished.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (list with optional filters) and the presence of an output schema, the description is adequate but minimal. It does not mention pagination, sorting, or any limits, which would be useful for large catalogs. It meets basic needs but leaves gaps for complex queries.

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 coverage is 100%, so baseline is 3. The description adds minimal parameter context beyond the schema: 'optionally filtered' and 'capabilities are arrays' hint at filtering but do not specify syntax. It does not significantly enhance the schema's descriptions, so the score remains at baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states it returns the model catalog with pricing and optional filtering, which clearly communicates the tool's purpose. The name and title align well. However, it does not explicitly differentiate from sibling tools like get_pricing or compare_models, but the purpose is still clear.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives such as compare_models, select_optimal_model, or get_pricing. It lacks any 'when to use' or 'when not to use' context, making it hard for an AI to choose appropriately.

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

optimize_requestOptimize requestA

Check whether a cheaper capable model exists for a call you plan to make, and report the savings. Offline.

ParametersJSON Schema

Name	Required	Description
`currentModel`	Yes	The model you plan to call (alias or id).
`inputTokens`	Yes	Input tokens for the call.
`outputTokens`	Yes	Output tokens for the call.
`taskClass`	No	Task class; sets the tier the recommendation must still meet.
`crossProvider`	No	Consider other providers too (may need a different API key). Default false.
`providers`	No	Axis 1: provider availability allowlist (spec 5.4).
`target`	No	Axis 2: "self" (default) applies the client scope; "code" considers all providers.
`includeLocal`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`current`	Yes
`recommended`	Yes
`savingsUsd`	Yes
`savingsPct`	Yes
`alreadyOptimal`	Yes
`reasoning`	Yes
`providerScope`	Yes
`scopeSource`	Yes
`catalogVersion`	Yes
`asOf`	Yes

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It states 'Offline' (no actual call) and reports savings, but does not disclose read-only nature, permissions, rate limits, or other side effects. More detail would be helpful.

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 a single sentence, highly concise, and front-loads the purpose. Every word earns its place with no waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 8 parameters and an output schema, the description provides the essential purpose and offline nature. With output schema, return details are not needed. A bit more context on parameter roles (e.g., taskClass) would improve completeness, but it is mostly adequate.

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 88% (high), so baseline is 3. The description does not add meaning beyond the schema for parameters. It sets context but does not elaborate on how parameters like taskClass or crossProvider affect the recommendation.

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 clearly states the verb 'Check' and resource 'cheaper capable model for a call you plan to make,' and reports savings. It is specific and distinguishes from sibling tools like compare_models or select_optimal_model by focusing on a planned call and being offline.

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

Usage Guidelines3/5

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

The description mentions 'Offline' implying use before making a call, but it does not explicitly state when to use vs. alternatives like compare_models or select_optimal_model. No when-not or alternative guidance is provided.

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

predict_costPredict costA

Forecast the cost of a prompt across candidate models before the call. Returns a cheapest-first ranking with assumptions. Offline.

ParametersJSON Schema

Name	Required	Description
`prompt`	No	The prompt to forecast; estimated to tokens if inputTokens absent.
`inputTokens`	No	Exact input tokens (skips prompt estimation).
`contextTokens`	No	Known context tokens already loaded.
`candidates`	No	Candidate models (alias or id); defaults to all chat-capable.
`expectedOutputTokens`	No	Exact output tokens; else inferred from taskClass/model.
`taskClass`	No	Drives the default output cap.
`providers`	No	Axis 1: provider availability allowlist (spec 5.4).
`target`	No	Axis 2: "self" (default) applies the client scope; "code" considers all providers.
`includeLocal`	No
`charsPerToken`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`forecasts`	Yes
`cheapest`	Yes
`cheaperIfAvailable`	No
`providerScope`	Yes
`scopeSource`	Yes
`notes`	Yes
`catalogVersion`	Yes
`asOf`	Yes

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, the description carries the burden. It states 'Offline' and 'returns a cheapest-first ranking with assumptions', which hints at read-only and non-destructive behavior. However, it does not detail error handling, rate limits, or implications of 'assumptions'.

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 concise sentences that front-load the action and outcome. Every word serves a purpose with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema and 10 parameters, the description is minimally complete but could better explain its relationship to sibling tools. It covers the core purpose and behavior sufficiently for an agent to select it.

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 coverage is high (80%), so baseline is 3. The description adds no extra meaning beyond the schema; it does not explain the role of key parameters like 'providers' or 'target'.

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 clearly states the tool's action ('forecast'), the resource ('cost of a prompt across candidate models'), and the output ('cheapest-first ranking'). It distinguishes itself from siblings like 'estimate_cost' and 'compare_models' by emphasizing it is done 'before the call' and is 'offline'.

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

Usage Guidelines3/5

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

The description implies use before making a call but does not provide explicit guidance on when to use this tool versus alternatives such as 'estimate_cost' or 'select_optimal_model'. No exclusions or scenarios are mentioned.

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

select_optimal_modelSelect optimal modelB

Pick the single cheapest model that meets the task tier, capabilities, and budget, with full reasoning and a fallbackChain. Offline.

ParametersJSON Schema

Name	Required	Description
`task`	No	Free-text task; used for the tier heuristic when taskClass is absent.
`taskClass`	No	Explicit task class; overrides the heuristic.
`requiredCapabilities`	No	Capabilities the model must support.
`maxCostUsd`	No	Budget ceiling for the predicted call cost.
`estimatedInputTokens`	Yes	Estimated input tokens for the forecast.
`estimatedOutputTokens`	Yes	Estimated output tokens for the forecast.
`providers`	No	Axis 1: provider availability allowlist (spec 5.4).
`target`	No	Axis 2: "self" (default) applies the client scope; "code" considers all providers.
`includeLocal`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`selected`	Yes
`runnerUp`	No
`rejected`	Yes
`reasoning`	Yes
`fallbackChain`	Yes
`budgetExceeded`	No
`shortfallUsd`	No
`providerScope`	No
`scopeSource`	No
`cheaperIfAvailable`	No
`catalogVersion`	Yes
`asOf`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

Without annotations, the description only says it picks cheapest model with reasoning and fallbackChain; no details on side effects, auth requirements, or how 'offline' affects behavior.

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?

Description is very concise (one sentence) with no waste, though it could benefit from slight expansion.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having an output schema, the description is too brief for a complex selection tool; missing explanation of 'task tier', 'fallbackChain', and how inputs are used.

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 coverage is high (89%), so baseline 3. Description adds only minor context (e.g., mapping task tier to parameters), not enough to raise score.

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 clearly states the tool selects the single cheapest model meeting task tier, capabilities, and budget, distinguishing it from siblings like compare_models or estimate_cost.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives; no when-not-to-use or when-to-use-this particular context provided.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

7 tool updatesv0.1.1Jun 23, 2026
- First observedcompare_models
- First observedestimate_cost
- First observedget_pricing
- First observedlist_models
- First observedoptimize_request
- First observedpredict_cost
- First observedselect_optimal_model

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0

Scored 2026-06-23 14:46 across 7 tools

Disambiguation2/5

Several tools have overlapping purposes (e.g., compare_models, predict_cost, optimize_request, select_optimal_model all compare or select models based on cost). Additionally, get_pricing and list_models have identical descriptions, causing ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case (e.g., estimate_cost, list_models, select_optimal_model).

Tool Count5/5

7 tools is well-scoped for a model cost estimation server, covering the essential operations without being excessive.

Completeness4/5

The tools cover listing, pricing, cost estimation, comparison, and optimization. However, the presence of a duplicate tool (get_pricing and list_models) indicates a minor gap in tool design.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcp A
com.modelpricewatch
Live LLM API pricing: token prices, comparisons, cheapest-model lookups. No key required.
AI & Machine Learning Research & Data
52
acp-mcp-serverOAuth
com.agenticcontrolplane
See, price, and control every tool call your AI agents make: policy checks, cost, and audit tools.
Agent Orchestration Monitoring Security
1
modelglass
io.github.Modelglass
Sourced AI-model pricing and capability data — compare and route to the cheapest capable model.
11
LLM Abacus A
com.llmabacus
Compare up-to-date pricing for 40+ LLMs (incl. Chinese) & estimate cost from tokens. EN/zh.
AI & Machine Learning Developer Tools
22

Related MCP Servers

local-llm-delegation-mcp
mrrodriguez
A
license
A
quality
D
maintenance
Optimizes token costs by intelligently delegating low-complexity tasks to local LLMs via LiteLLM, enabling cost-effective development workflows.
Updated 4 months ago (2026-05-16 03:35 UTC)
3
1
MIT
TokenLens MCP
AI & Machine Learning Monitoring Developer Tools
im43ii
F
license
Not graded
quality
D
maintenance
Analyze AI conversations to estimate token costs, detect waste, and generate optimized prompts directly from your editor.
Updated 5 months ago (2026-04-23 21:38 UTC)
1
-
tierline
AI & Machine Learning Developer Tools
jayj221
A
license
Not graded
quality
B
maintenance
Enables LLM clients and coding agents to analyze prompts and recommend the cheapest AI model that meets the task requirements across text, voice, video, and other modalities, projecting monthly cost savings against a flagship baseline.
Updated 23 days ago (2026-08-19 18:37 UTC)
MIT
promptopt
Developer Tools Text Summarization
hawktuahcoin-hurhur
A
license
Not graded
quality
A
maintenance
Enables local, offline prompt compression, smart asking when needed, and routing to the cheapest capable model to save tokens and costs for terminal AI agents.
Updated 19 days ago (2026-08-23 02:47 UTC)
74
1
MIT