AI Rate Card

agent_cost

Read-only

What a coding / tool-using agent costs a month on each model: tasks a day, model calls per task, context tokens per call, answer and reasoning tokens per call, percent of the context read from the prompt cache - priced at the cheapest real-time seller of each model (default: 13 usual coding models), cheapest first, USD, 30 days, with each model's reasoning class. Rows have card_url and cite.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "agent_cost"
  }
}

Input Schema

Name	Required	Description
`steps`	No	model calls per task, default 30
`tasks`	No	tasks a day, default 10
`models`	No	model ids to compare; default the usual coding models
`output`	No	answer tokens per call, default 800
`context`	No	input tokens per call (the resent context), default 30000
`cache_pct`	No	percent of context from the prompt cache, default 70
`reasoning`	No	reasoning tokens per call (billed as output), default 1500

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 9, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations only supply readOnlyHint=true, so the description carries the rest and does add value: it discloses the pricing basis (cheapest real-time seller of each model), default model set (13 usual coding models), sort order (cheapest first), units (USD, 30 days), and output extras (card_url, cite, reasoning class). It does not state result-set size limits or how unavailable models are handled, which keeps it short of a 5.

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?

It is a single front-loaded sentence: the metric leads, followed by the cost inputs, then the pricing/sort/unit qualifiers. The dash-separated enumeration is dense and requires re-reading, but every clause carries distinct information and nothing is redundant with the schema.

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?

There is no output schema, so the description supplies the return shape itself (rows sorted cheapest first, per-model reasoning class, card_url and cite fields). Combined with 100% schema coverage and readOnlyHint, an agent has nearly everything needed; only result-size limits and the exact row fields remain unspecified.

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 seven parameters are already documented with defaults in the schema. The description restates the same parameter meanings in prose (tasks per day, calls per task, context/answer/reasoning tokens, cache percent) without adding syntax, units, or interaction details, so the baseline of 3 applies.

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 a concrete metric and resource (monthly cost of a coding/tool-using agent on each model) plus the cost drivers it models, so an agent knows exactly what it computes. It never differentiates itself from close siblings such as estimate_cost, cheapest_for_workload, or compare_models, so an agent cannot route between them from this text alone.

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?

Usage is only implied by the phrase 'coding / tool-using agent', which scopes the tool to that workload class. There is no explicit when-to-use, no when-not-to-use, and no named alternative, which is a real gap given four or five sibling cost tools.

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

All AI Rate Card tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?