@compute-finance/mcp is a live AI compute pricing oracle that delivers real-time LLM model prices from major providers (Anthropic, OpenAI, Google, xAI) and tools to analyze cost, compare models, and audit Claude Code sessions.
Live Pricing Data
Full model basket (data_get_basket): all tracked models with provider, family, input/output USD prices per million tokens, and cache pricing components.
Single model price (data_get_price): lookup by canonical name (e.g., claude-opus-4.7, gpt-5.5) for basket and catalog-only models.
Full model catalog (data_get_catalog): every tracked model including non-index entries with current prices and cache/reasoning blocks.
Compute Price Index (data_get_cpi): raw oracle response with all pricing, SCU, and basket version data.
SCU (Standard Compute Unit) & Index
Current SCU (data_get_scu): per-family blended-cost breakdown and inverse computeIndex purchasing-power view.
Detailed breakdown (data_get_breakdown): per-family blended costs attributed to model families.
SCU at timestamp (data_get_scu_at): step-function point lookup without interpolation.
Baseline SCU (data_get_baseline): frozen genesis denominator for the computeIndex.
Historical Data
SCU time series (data_get_history): per-revision, daily, or weekly granularity over any date range.
Model price history (data_get_model_price_history): input/output USD price series for any basket model.
Model price at date (data_get_model_price_at): effective price at a specific timestamp.
Basket reconstitutions (data_get_reconstitutions): model swaps with SCU before/after values.
Methodology changelog (data_get_methodology): every methodology version with formula, family rules, and spec links.
Cost Estimation & Comparison
Estimate cost (compute_estimate): nominal USD cost for any tracked model given input/output token counts.
Compare models (compute_compare): ranked list of basket models by cost for a workload, grouped by family.
Claude Code Session Analysis
Session cost report (render_session_report): formatted report with prompts, tool calls, tokens, and cost for a session.
Per-inference breakdown (render_consumption_report): bar chart and per-reply cost breakdown with cache hit ratios.
Active sessions overview (render_active_sessions): table of recent sessions with cost summaries.
Raw session JSON (analyze_session): token totals, effective/nominal cost, cache breakdown, and counterfactual costs across all basket models.
Raw inference JSON (analyze_inferences): per-inference data including tool usage, cache hit ratio, and duration.
Aggregate Telemetry
Session history stats (telemetry_get_history): cumulative cost, per-profile medians, and cache insights across all logged sessions.
Cost Hook Integration
Automatically injects session cost summaries into Claude's context for real-time display during conversations (Claude Code specific).
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@compute-finance/mcp compare GPT-4o and Claude 3.5 Sonnet pricing"
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.
Live AI compute pricing oracle — real-time LLM model prices across nine vendors (Anthropic, OpenAI, Google, DeepSeek, xAI and four more) via the Compute Finance Oracle.
A stdio MCP server. Works in any MCP client. Includes optional Claude Code skills for session cost analysis.
npx @compute-finance/mcp setupThis single command:
Registers the MCP server at user scope (claude mcp add)
Installs Claude Code skills (/cf-session-management, /cf-session-consumption, /cf-active-sessions)
Installs the cost hook — a UserPromptSubmit hook that injects session cost into Claude's context so every response can show how much you've spent
Restart Claude Code after setup.
Or register manually without skills/hook:
claude mcp add --scope user compute-finance -- npx @compute-finance/mcpAdd to your MCP config (.cursor/mcp.json, VS Code settings, etc.):
{
"mcpServers": {
"compute-finance": {
"command": "npx",
"args": ["@compute-finance/mcp"]
}
}
}git clone https://github.com/compute-finance/mcp.git
cd mcp
npm install && npm run build
npx . setupRelated MCP server: ohmytoken
21 tools across five layers — no API key required. All tools are read-only.
Tool | Description |
| Every model in the current SCU index, with provider, family (e.g. |
| Price for a single model (e.g. |
| Current Standard Compute Unit — value plus a methodology-versioned |
| Per-family blended-cost breakdown alone — methodology-versioned discriminated union with one entry per family representative |
| Full Compute Price Index as last attested on-chain — |
| Historical index changes — model swaps, SCU before/after |
| Methodology changelog — every version with its formula summary and spec link, plus the version in force |
| SCU index time series over a date range — |
| Per-model input/output USD price time series for any oracle-tracked model — same granularity semantics as |
| Every model with a recorded price, index members and non-index entries alike — |
| Per-model input/output USD price effective at a timestamp — |
| Frozen SCU denominator behind |
| SCU value active at a timestamp via step function — no interpolation, |
Models are identified by their canonical vendor-prefixed id — anthropic/claude-opus-4.8, openai/gpt-5.5, qwen/qwen-3.5-flash. Every tool taking a model also accepts the bare name (gpt-5.5) and answers with the canonical id. The vendor slug is not always the provider key (alibaba → qwen, xai → x-ai, moonshot → moonshotai), so reuse an id the API returned rather than assembling one. data_get_scu, data_get_breakdown and data_get_reconstitutions are the exception: they pass the attested manifest through verbatim and so report bare model keys, because a / is not a legal manifest key.
Cache pricing comes from the Compute Finance Oracle. Session and consumption reports show effective (cache-aware) cost when the oracle has published the relevant cache components; otherwise they show nominal cost (input rate applied to every input variant) and label effective as unavailable for that model.
Alongside cache, the oracle publishes a reasoning output price — reasoning.reasoningOutput, on the same base as every other component; the whole reasoning block is null for a model with no usable reasoning price. It is catalogue data. Session and consumption reports do not bill it: Claude Code transcripts count thinking blocks rather than reasoning tokens, and those tokens are already inside output_tokens.
Every price is reported on two bases: base_* is the provider list price, identical for every model the oracle tracks, and billed_* is what compute.finance charges — base × (1 + routing_fee_rate). Compare models on base_*, budget on billed_*. The rate ships once per response and billed_* is null when the oracle does not publish it. Session and consumption reports are on the base basis throughout.
Every current-price answer comes from one place: the live catalogue the exchange bills against. Index membership decides which models data_get_basket and compute_compare list, never what a model costs, so two models the catalogue prices alike quote alike. data_get_cpi is the exception by design — it serves the prices the latest on-chain revision attested, which change only when an operator publishes the next one and may therefore lag the catalogue. Read it as attestation history, not as a quote.
Some models get pricier past a context length. data_get_basket and data_get_price publish that as context_tiers, a ladder ascending by from_input_tokens and always at least one rung: the first starts at 0 and restates the flat rate, so a model priced the same at every size has exactly one rung and nothing has to branch on whether a model happens to be tiered. Rungs carry base_* and billed_* like every other price; only the flat rate enters the SCU index. compute_estimate and compute_compare pick the rung from the whole input side of the request — prompt plus cache reads plus cache writes, all charged at the full input rate there since neither tool applies a cache discount — over half-open ranges, so an input landing exactly on a threshold takes that rung, and both return the chosen rung as applied_context_tier so the rate behind the number is visible. data_get_catalog passes the oracle document through unchanged, so there contextTiers is absent rather than one-rung on a flat model.
The ladder comes from the catalog endpoint, and the two kinds of tool part ways whenever it cannot answer for a model — the read failed, or it succeeded and the model was not in it, which is upstream drift rather than a flat price. data_get_basket and data_get_price still serve their prices and set context_tiers to null — an unknown ladder, never a one-rung stand-in for a ladder nobody read. compute_estimate and compute_compare error instead: a cost quoted at the flat rate would understate exactly the long context the ladder exists to price.
max_input_tokens is the largest input a model accepts, null when the model declares no window of its own — not unbounded: the request-body ceiling still applies, there is just no per-model limit. Above a declared window the oracle refuses the request outright, so compute_estimate and compute_compare set exceeds_max_input_tokens. They still quote the cost: these tools are read-only and an agent sizing a context needs the number before it reshapes the request, but the flag says plainly that the request as supplied would be rejected.
Prices also carry a provenance mark saying how far the number has been checked: verified — an operator recorded a vendor source for it; inferred — derived from a sibling number or a vendor default, with no source recorded; promotional — a discounted list price that is expected to end. Every value bills as shown; the mark says how much to trust it, not what it costs. Marks are set by hand and hold as of the operator's last pass, not as a live check against the vendor. Every cache and reasoning component carries its own mark wherever it appears, and so does every base price: data_get_catalog marks currentPrice.provenance for every model, index member or not, while data_get_basket, data_get_price and compute_estimate carry the same pair as base_price_provenance. A rung follows the same rule: the first repeats the base price's mark, and a higher rung is always a catalogue number, marked in both directions with the single mark the vendor quotes it under. Session and consumption reports print each cache multiplier with its mark; when the oracle publishes no cache pricing for a model they say so and print no marks.
Tool | Description |
| Nominal USD cost for a model given input/output token counts — |
| Rank every model in the current SCU index by cost for a workload, grouped by family — the same three cost figures per row, each on that model's own rung |
Tool | Description |
| Pre-formatted session cost report — used by |
| Pre-formatted per-inference breakdown — used by |
| Overview of recent sessions across projects — used by |
Reports surface three orthogonal counts: prompts (what you typed), inferences (assistant replies — tool-loop sessions produce several per prompt), and tool calls (tool_use blocks). The triplet is identical across all three reports for the same session.
Tool | Description |
| Raw JSON session analysis (for custom UI, not skills) |
| Raw JSON per-inference breakdown (for custom UI, not skills) |
The analyze_session counterfactual quotes each model's base rate and never a long-context rung. A rung is picked per request, and a session's summed input is not one giant request — a hundred 5k-token calls are not a single 500k-token one — so pricing the total on a higher rung would overcharge. Expect those rows to sit below compute_compare for a model that gets pricier past a context length.
Tool | Description |
| Aggregate stats across logged sessions — cumulative cost, per-profile medians, insights |
The setup command installs a UserPromptSubmit hook into ~/.claude/settings.json. Every time you send a message, the hook reads the current session transcript, prices it against the live oracle, and injects a cost summary into Claude's context via additionalContext. Claude then appends a 💰 Compute.Finance · … line at the end of its response.
Guards — the hook fires only when all three conditions are met:
Session cost exceeds $1
Session has at least 5 user prompts
At least 10 minutes since the last fire (per session)
On any failure (oracle down, transcript missing, parse error) the hook exits silently — it never blocks your prompt.
If setup can't write to settings.json, add the hook manually:
{
"hooks": {
"UserPromptSubmit": [
{
"matcher": "",
"hooks": [
{
"type": "command",
"command": "npx @compute-finance/mcp hook-prompt"
}
]
}
]
}
}Remove the UserPromptSubmit entry from ~/.claude/settings.json.
All data stays on your machine. The only network calls are unauthenticated GETs to api.compute.finance — the oracle endpoints under /v1/oracle/* and the OpenAPI document at /openapi.json, read once at startup to document oracle response shapes. Session logs (~/.compute-finance/sessions.jsonl, ~/.compute-finance/inferences.jsonl) are never uploaded.
Raw JSON per-inference breakdown — token counts, tool usage, effective/nominal cost, cache hit ratio, duration per inference. One row per assistant reply. inferences[].effective_usd is null when the oracle has not published cache pricing for the model; nominal_usd stays populated as an upper-bound. Source: local Claude Code transcript + Oracle API. For pre-formatted output use render_consumption_report. Omit session_id for the most recent session.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | ||
| session_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral details beyond annotations: effective_usd is null when cache pricing is unavailable, nominal_usd acts as an upper-bound, and one row corresponds to one assistant reply. It does not contradict annotations, and while it omits rate limits or error behavior, the null-value semantics add meaningful context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with each clause serving a purpose: output type, data fields, null semantics, source, alternative tool, and a usage tip. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately summarizes the return shape (per-inference fields and row semantics). It also covers the null-cost edge case and sourcing, though cwd remains undocumented and pagination/limits are not addressed, keeping it from a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage and two optional parameters, the description gives partial guidance by explaining that omitting session_id targets the most recent session. However, cwd is not explained at all, leaving a gap in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Raw JSON per-inference breakdown' and enumerates specific data fields (token counts, tool usage, cost, cache hit ratio, duration), making the tool's purpose unmistakable. It also distinguishes itself from render_consumption_report by explicitly naming the pre-formatted alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly suggests when to use this raw JSON tool versus the pre-formatted render_consumption_report, and gives a practical usage hint about omitting session_id for the most recent session. It does not broadly enumerate all alternatives, but the key alternative is named and the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Raw JSON session analysis — token totals, effective/nominal cost with cache breakdown, counterfactual across all basket models, profile classification. current_model_cost is on the base (provider list) basis, stated in current_model_cost_basis; counterfactual_nominal rows carry base_usd_cost and billed_usd_cost, so the session and the counterfactual are directly comparable on base. usage.prompts counts user messages, usage.inferences counts assistant replies, usage.tool_calls counts tool_use blocks. current_model_cost.effective_usd is null when the oracle has not published cache pricing for the model; nominal_usd stays populated as an upper-bound. Source: local Claude Code transcript + Oracle API. For pre-formatted output use render_session_report. Omit session_id for the most recent session.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | ||
| session_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint: false and idempotentHint: true, but the description adds valuable behavioral context: the effective_usd is null when cache pricing is unavailable, nominal_usd serves as an upper bound, and usage counters are defined. This goes beyond the generic annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and front-loaded with the core purpose, then dives into field semantics. Backticks and sentence fragments keep it readable. A few extra sentences could be trimmed, but every sentence earns its place by explaining output nuances.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description carries the burden of explaining return values, and it does so thoroughly: field-level details, null handling, basis comparison, and source of data. It also covers usage and alternative tooling, making it complete for an analysis tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Two parameters exist (cwd, session_id) with 0% schema coverage. The description clarifies session_id by noting omission yields the most recent session, but says nothing about cwd. Partial compensation for schema gaps is provided, but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Raw JSON session analysis' and enumerates specific outputs: token totals, effective/nominal cost, counterfactual across basket models, and profile classification. This clearly distinguishes it from siblings like render_session_report, which is explicitly named as the alternative for pre-formatted output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit usage directive: 'For pre-formatted output use render_session_report.' It also gives a concrete instruction for parameter behavior: 'Omit session_id for the most recent session.' This tells the agent both when to use this tool and when to prefer an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rank all basket models by nominal cost for a workload. Source: Oracle API. Each row carries base_usd_cost (provider list price), routing_fee_usd and billed_usd_cost (what compute.finance charges); ranking is by base_usd_cost, and since the routing fee is one global rate the order is identical on either basis. Returns the sorted list plus a grouping by family (e.g. openai.gpt, anthropic.claude). Covers basket members only — for a catalog-only model use compute_estimate, whose numbers are on the same basis. Use to answer 'which model is cheapest?' or 'how much would this cost on a different model?'.
| Name | Required | Description | Default |
|---|---|---|---|
| input_tokens | Yes | ||
| output_tokens | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior, so the bar is lower. The description adds valuable context: the ranking basis (base_usd_cost), the equivalence with billed cost due to a global routing fee, the return structure (sorted list plus family grouping), and the exclusion of catalog-only models. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence earns its place: core action, data source, field meanings, ranking rationale, return format, scope boundary, and alternative tool. The description is front-loaded with the primary purpose and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description covers what is returned (sorted list and family grouping), the ranking logic, the meaning of the cost columns, and the tool's scope. It also provides a comparison to a sibling tool, making the tool fully understandable for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate for the two parameters (input_tokens, output_tokens). It mentions 'for a workload' and the cost fields, implying that these parameters define the workload, but it does not explicitly state that input_tokens and output_tokens are token counts or how they affect the cost calculation. This is a moderate gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Rank all basket models by nominal cost for a workload.' It also distinguishes from the sibling tool compute_estimate by explicitly noting the basket-only scope, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use this tool versus an alternative: 'Covers basket members only — for a catalog-only model use compute_estimate.' It also names concrete use cases: 'which model is cheapest?' or 'how much would this cost on a different model?'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Nominal USD cost for any oracle-tracked model given input/output token counts (no cache discounts) — basket members and catalog-only models on identical terms. Returns base_usd_cost (provider list price), routing_fee_usd and billed_usd_cost (what compute.finance charges), plus the routing_fee_rate they derive from. Compare models on base_usd_cost; budget on billed_usd_cost. price_source ('oracle-basket' | 'oracle-catalog') names the serving endpoint only and does not change the pricing basis, so two models with the same provider price return the same cost. Errors with 'Model not tracked by oracle' for unknown keys. Source: Oracle API (/v1/oracle/resolve + /v1/oracle/basket). For cache-aware cost, use analyze_session on a real transcript. Accepts canonical names like 'claude-sonnet-4.6'.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | ||
| input_tokens | Yes | ||
| output_tokens | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and idempotent, and the description adds valuable non-obvious behavioral details: price_source names only the serving endpoint and 'does not change the pricing basis,' so equal provider prices yield equal costs. It also discloses the exact error message for unknown models and the underlying Oracle API endpoints, which goes beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and is dense with operational details, but it is slightly long at roughly 120 words. Most sentences earn their place—return fields, error behavior, and alternative guidance—but the API source citation and price_source clarification could be condensed. Still, it is well-structured and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, yet the description enumerates the returned fields (base_usd_cost, routing_fee_usd, billed_usd_cost, routing_fee_rate, price_source) and their intended use, documents the error condition, and provides an alternative tool for cache-aware costs. This makes the tool's behavior and outputs sufficiently transparent for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains that input_tokens and output_tokens are 'token counts' and gives a canonical model name example ('claude-sonnet-4.6'). It does not explicitly mention non-negative integer constraints, but the semantics and examples make the three required parameters functionally clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-object phrase: 'Nominal USD cost for any oracle-tracked model given input/output token counts' and immediately clarifies scope by adding '(no cache discounts)'. It distinguishes itself from siblings like compute_compare and analyze_session by noting identical terms for basket and catalog models and by naming cache-aware analysis as a different alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool versus alternatives: 'For cache-aware cost, use analyze_session on a real transcript.' It also provides field-level guidance on how to interpret results, e.g., 'Compare models on base_usd_cost; budget on billed_usd_cost,' which helps the agent choose the right value for a given task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Frozen SCU denominator for the inverse computeIndex purchasing-power view: the SCU of the first confirmed revision (methodologyVersion 1), captured set-once and never changes. Source: Oracle API (/v1/oracle/baseline). The published computeIndex on /v1/oracle/scu, /v1/oracle/latest and each /v1/oracle/history point equals (baseline.scuUsd / point.scuUsd) × 100 — 100 at genesis, rises as compute gets cheaper. Returns null until the first revision is confirmed.
Oracle response schema (auto-derived from OpenAPI at startup): {"type":"object","properties":{"date":{"type":"string"},"scuUsd":{"type":"number"},"methodologyVersion":{"type":"integer","minimum":0,"exclusiveMinimum":true}},"required":["date","scuUsd","methodologyVersion"]}
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description discloses key behavioral traits: the value is captured set-once and never changes, it returns null until the first revision is confirmed, and it includes the exact formula relating baseline to published computeIndex values. This is rich, non-obvious context that annotations alone would not convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Although the description is longer than typical, every sentence earns its place: definition, immutability, source, formula, null behavior, and return schema. It is information-dense but well-structured, with no filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description includes the complete Oracle response schema, explains the null state, provides the calculation formula, and covers the lifecycle ('set-once'). Despite having no formal output schema, the description fully compensates and leaves no material ambiguity about the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts no parameters, which is the baseline 4 case. There are no parameter semantics to clarify, and the description adds full clarity by explaining what the baseline represents and how it is sourced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description precisely identifies the tool as the frozen SCU denominator (baseline) for the computeIndex inverse purchasing-power view, using methodologyVersion 1 and set-once semantics. This clearly distinguishes it from sibling tools like data_get_scu or data_get_scu_at, which return current or point-in-time values.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context on when this tool is relevant—as the immutable baseline in the computeIndex formula—and notes the null-before-first-revision behavior. It does not explicitly name alternatives or state when not to use it, but the description makes the specialized role evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
All models in the oracle basket — provider, family (e.g. openai.gpt, anthropic.claude, google.gemini, xai.grok), base_* USD and wei prices per million tokens (the provider list price), billed_* prices (what compute.finance charges), and per-component cache pricing (cachedInput, cacheWrite5m, cacheWrite1h) with provider attribution, priced on the same base. routing_fee_rate ships once at the top level; billed_* is null when the oracle does not publish it. Compare models on base_*; budget on billed_*. Source: Oracle API. For a single model, use data_get_price instead.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already indicating read-only and idempotent behavior, the description adds valuable context beyond them: it explains that billed_* can be null when the oracle does not publish it, that routing_fee_rate ships at the top level, and the exact pricing basis. This is rich behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is slightly long but every sentence contributes meaningful detail about fields, pricing, and usage. It is well-structured with examples and separators, making it readable despite its density. It could be trimmed slightly but is not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Since there is no output schema, the description fully compensates by explaining all important aspects: data fields, pricing units, null behavior, source, and comparison/budgeting guidance. It is contextually complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics, and it effectively uses the space to describe the return fields, which is appropriate given the absence of an output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves all models in the oracle basket and details the specific data fields (provider, family, prices, cache pricing). It explicitly distinguishes itself from the sibling tool data_get_price, which is for single-model queries, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance on when to use this tool versus alternatives: 'For a single model, use data_get_price instead.' It also gives usage context ('Compare models on base_*; budget on billed_*') and identifies the data source, fulfilling both when-to-use and when-not-to-use criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Per-family blended-cost breakdown of the SCU — methodology-versioned discriminated union (keyed by methodologyVersion) with one entry per family representative (family, modelKey, inputPriceUsdPerMillion, outputPriceUsdPerMillion, blendedCostUsd). Source: Oracle API (/v1/oracle/scu.breakdown). Use to attribute SCU contributions to specific model families. For the full SCU response with reference workload, use data_get_scu instead.
Oracle response schema (auto-derived from OpenAPI at startup): {"type":"object","properties":{"scuUsd":{"type":"number"},"computeIndex":{"type":"number","nullable":true},"referenceWorkload":{"type":"object","properties":{"inputTokens":{"type":"number"},"outputTokens":{"type":"number"}},"selfRequired":true},"methodologyVersion":{"type":"integer","minimum":0,"exclusiveMinimum":true},"breakdown":{"oneOf":[{"type":"object","properties":{"methodologyVersion":{"type":"number","minimum":1,"maximum":1},"familyRepresentatives":{"type":"array","items":{"type":"object","properties":{"family":{"type":"string"},"modelKey":{"type":"string"},"inputPriceUsdPerMillion":{"type":"number"},"outputPriceUsdPerMillion":{"type":"number"},"blendedCostUsd":{"type":"number"}},"required":["family","modelKey","inputPriceUsdPerMillion","outputPriceUsdPerMillion","blendedCostUsd"]}}},"required":["methodologyVersion","familyRepresentatives"]}]},"updatedAt":{"type":"string"}},"required":["scuUsd","computeIndex","referenceWorkload","methodologyVersion","breakdown","updatedAt"]}
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, open-world, and non-destructive traits. The description adds value by disclosing the data source (Oracle API), the methodology-versioned discriminated union nature, and the response schema. It does not mention rate limits or pagination, but the openWorldHint and readOnlyHint already signal external reads and safety, so this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description front-loads key purpose and usage in the first two sentences, which is good. However, the inclusion of the full Oracle response schema (a large JSON block) makes it verbose. While this schema compensates for the lack of an output schema, it could be condensed or moved to a separate field. The length detracts from conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There are no parameters and no external output schema, so the description carries the full burden of documenting the response. It provides the complete response schema, clarifies the breakdown structure, and explains the source. This is fully complete for a parameterless tool with rich annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters (0 params, 0 required), so the baseline is 4 per the rubric. The description adds no parameter details because none exist, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a per-family blended-cost breakdown of the SCU, with specific fields and a methodology-versioned discriminated union. It distinguishes itself from sibling data_get_scu by explicitly noting the full SCU response is available there, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('attribute SCU contributions to specific model families') and provides a direct alternative ('For the full SCU response with reference workload, use data_get_scu instead'). This is clear guidance on usage vs. alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full catalog of tracked models — every model with a recorded price, including non-index entries. Source: Oracle API (/v1/oracle/catalog). Each entry carries modelKey, displayName, provider, family, indexMember flag (true if current family representative in the latest confirmed revision), currentPrice with input/output USD per million tokens and observedAt timestamp, and per-component cache/reasoning blocks. For basket-only display, use data_get_basket instead.
Oracle response schema (auto-derived from OpenAPI at startup): {"type":"object","properties":{"models":{"type":"array","items":{"type":"object","properties":{"modelKey":{"type":"string"},"displayName":{"type":"string"},"provider":{"type":"object","properties":{"key":{"type":"string"},"name":{"type":"string"}},"required":["key","name"]},"family":{"type":"string","nullable":true},"indexMember":{"description":"Whether this model is the current family representative in the latest confirmed SCU revision.","type":"boolean"},"releasedAt":{"type":"string","format":"date-time","nullable":true},"currentPrice":{"type":"object","properties":{"inputPriceUsdPerMillion":{"type":"number"},"outputPriceUsdPerMillion":{"type":"number"},"observedAt":{"type":"string","format":"date-time"}},"required":["inputPriceUsdPerMillion","outputPriceUsdPerMillion","observedAt"]},"cache":{"type":"object","properties":{"cachedInput":{"type":"object","properties":{"usdPerMillion":{"type":"number","nullable":true},"ratioOfInput":{"type":"number","nullable":true},"source":{"type":"string"},"sourceUrl":{"type":"string","nullable":true},"createdAt":{"type":"string"}},"required":["usdPerMillion","ratioOfInput","source","sourceUrl","createdAt"],"nullable":true},"cacheWrite5m":{"type":"object","properties":{"usdPerMillion":{"type":"number","nullable":true},"ratioOfInput":{"type":"number","nullable":true},"source":{"type":"string"},"sourceUrl":{"type":"string","nullable":true},"createdAt":{"type":"string"}},"required":["usdPerMillion","ratioOfInput","source","sourceUrl","createdAt"],"nullable":true},"cacheWrite1h":{"type":"object","properties":{"usdPerMillion":{"type":"number","nullable":true},"ratioOfInput":{"type":"number","nullable":true},"source":{"type":"string"},"sourceUrl":{"type":"string","nullable":true},"createdAt":{"type":"string"}},"required":["usdPerMillion","ratioOfInput","source","sourceUrl","createdAt"],"nullable":true},"read_multiplier":{"type":"number","nullable":true},"write_multiplier_5m":{"type":"number","nullable":true},"write_multiplier_1h":{"type":"number","nullable":true}},"required":["cachedInput","cacheWrite5m","cacheWrite1h","read_multiplier","write_multiplier_5m","write_multiplier_1h"],"nullable":true},"reasoning":{"type":"object","properties":{"reasoningOutput":{"type":"object","properties":{"usdPerMillion":{"type":"number","nullable":true},"ratioOfInput":{"type":"number","nullable":true},"source":{"type":"string"},"sourceUrl":{"type":"string","nullable":true},"createdAt":{"type":"string"}},"required":["usdPerMillion","ratioOfInput","source","sourceUrl","createdAt"],"nullable":true}},"required":["reasoningOutput"],"nullable":true}},"required":["modelKey","displayName","provider","family","indexMember","releasedAt","currentPrice","cache","reasoning"]}},"truncated":{"type":"boolean"},"generatedAt":{"type":"string","format":"date-time"}},"required":["models","truncated","generatedAt"]}
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the added context about the Oracle API source, the non-index inclusion, and the meaning of indexMember flag provides meaningful behavioral detail. No contradiction with annotations is present, and the description adds value beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The prose portion is concise and front-loaded, but the embedded Oracle response schema is extremely long and bloats the description. While the schema adds significant reference value (since no output schema exists), the overall description is not concise; it could be summarized or linked more efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the lack of a formal output schema, the description embeds a complete auto-derived response schema, detailing every field including nested structures, types, and nullability. It also covers the source and inclusion criteria, leaving little ambiguity about the tool's behavior. For a read-only catalog tool, this is thoroughly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (vacuously). The description still clarifies the tool's scope and return content, which naturally compensates for not needing parameter documentation. A baseline of 4 is appropriate given the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear and specific statement: 'Full catalog of tracked models — every model with a recorded price, including non-index entries.' It distinguishes the tool from a sibling by explicitly directing basket-only queries to data_get_basket, and the verb 'get' plus resource 'catalog' is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case ('Full catalog') and explicitly names an alternative ('For basket-only display, use data_get_basket instead'). It does not enumerate all possible exclusions or full when-not-to-use scenarios, but the guidance given is practical and specific.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full Compute Price Index — raw oracle response with provider, family, integration flag, raw and marked-up prices, scuUsd, basket version, last-updated timestamp. Source: Oracle API. Use data_get_basket for a cleaner view focused on pricing; use this for the complete index data. For the per-family blended-cost breakdown, use data_get_breakdown.
Oracle response schema (auto-derived from OpenAPI at startup): {"type":"object","properties":{"models":{"type":"array","items":{"type":"object","properties":{"id":{"type":"string"},"displayName":{"type":"string"},"provider":{"type":"object","properties":{"key":{"type":"string"},"name":{"type":"string"}},"required":["key","name"]},"family":{"description":"Provider product line (e.g. 'openai.gpt'). One family per basket slot; the latest released model in the family is the representative.","type":"string"},"weiPricePerMillion":{"type":"object","properties":{"input":{"type":"number"},"output":{"type":"number"}},"required":["input","output"]},"usdPricePerMillion":{"type":"object","properties":{"input":{"type":"number"},"output":{"type":"number"}},"required":["input","output"]},"markedUpWeiPricePerMillion":{"type":"object","properties":{"input":{"type":"number"},"output":{"type":"number"}},"required":["input","output"]},"markedUpUsdPricePerMillion":{"type":"object","properties":{"input":{"type":"number"},"output":{"type":"number"}},"required":["input","output"]},"releasedAt":{"type":"string","format":"date-time","nullable":true},"cache":{"type":"object","properties":{"cachedInput":{"type":"object","properties":{"usdPerMillion":{"type":"number","nullable":true},"ratioOfInput":{"type":"number","nullable":true},"source":{"type":"string"},"sourceUrl":{"type":"string","nullable":true},"createdAt":{"type":"string"}},"required":["usdPerMillion","ratioOfInput","source","sourceUrl","createdAt"],"nullable":true},"cacheWrite5m":{"type":"object","properties":{"usdPerMillion":{"type":"number","nullable":true},"ratioOfInput":{"type":"number","nullable":true},"source":{"type":"string"},"sourceUrl":{"type":"string","nullable":true},"createdAt":{"type":"string"}},"required":["usdPerMillion","ratioOfInput","source","sourceUrl","createdAt"],"nullable":true},"cacheWrite1h":{"type":"object","properties":{"usdPerMillion":{"type":"number","nullable":true},"ratioOfInput":{"type":"number","nullable":true},"source":{"type":"string"},"sourceUrl":{"type":"string","nullable":true},"createdAt":{"type":"string"}},"required":["usdPerMillion","ratioOfInput","source","sourceUrl","createdAt"],"nullable":true},"read_multiplier":{"type":"number","nullable":true},"write_multiplier_5m":{"type":"number","nullable":true},"write_multiplier_1h":{"type":"number","nullable":true}},"required":["cachedInput","cacheWrite5m","cacheWrite1h","read_multiplier","write_multiplier_5m","write_multiplier_1h"],"nullable":true},"reasoning":{"type":"object","properties":{"reasoningOutput":{"type":"object","properties":{"usdPerMillion":{"type":"number","nullable":true},"ratioOfInput":{"type":"number","nullable":true},"source":{"type":"string"},"sourceUrl":{"type":"string","nullable":true},"createdAt":{"type":"string"}},"required":["usdPerMillion","ratioOfInput","source","sourceUrl","createdAt"],"nullable":true}},"required":["reasoningOutput"],"nullable":true}},"required":["id","displayName","provider","family","weiPricePerMillion","usdPricePerMillion","markedUpWeiPricePerMillion","markedUpUsdPricePerMillion","releasedAt","cache","reasoning"]}},"scuUsd":{"type":"number"},"routingFeeRate":{"type":"number"},"revisionVersion":{"type":"number","nullable":true},"methodologyVersion":{"type":"integer","minimum":0,"exclusiveMinimum":true,"nullable":true},"lastUpdated":{"type":"string"}},"required":["models","scuUsd","routingFeeRate","revisionVersion","methodologyVersion","lastUpdated"]}
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, non-destructive). The description adds context that this is the raw, unfiltered response from the Oracle API, and includes the full response schema, which clarifies what the agent will receive. It doesn't mention caching or rate limits, but for a zero-parameter fetch, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The human-written part is concise and front-loaded: a one-line summary plus two sentences of usage guidance. The appended JSON schema is large and auto-generated, but since there's no separate output schema field, it's the only way to convey return structure. It's slightly bloated but justified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read-only tool, the description covers purpose, source, alternatives, and the full response shape. The 'integration flag' is not further explained, but the overall context is complete given the simplicity of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully covers everything. Per the baseline rule for 0-param tools, this scores 4; the description adds no parameter semantics because none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns the 'Full Compute Price Index' as a 'raw oracle response' with specific fields, and explicitly distinguishes itself from siblings like data_get_basket and data_get_breakdown. This gives a precise verb+resource with differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly advises when to use this tool ('complete index data') versus alternatives ('cleaner view' via data_get_basket, 'per-family blended-cost breakdown' via data_get_breakdown). This is direct and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
SCU index time series — date-range history of Standard Compute Unit values with optional bucketing granularity. Source: Oracle API (/v1/oracle/history). Each point carries scuUsd, methodologyVersion, revisionVersion, metadataHash, and computeIndex when populated. per-revision emits one point per revision; daily and weekly buckets carry the last revision's value forward across empty buckets (step-function close). Defaults to per-revision over the full range. For a single point at a specific timestamp, fetch the individual revision via data_get_cpi.
Oracle response schema (auto-derived from OpenAPI at startup): {"type":"object","properties":{"from":{"type":"string"},"to":{"type":"string"},"granularity":{"type":"string","enum":["per-revision","daily","weekly"]},"count":{"type":"integer","minimum":0,"exclusiveMinimum":false},"truncated":{"type":"boolean"},"data":{"type":"array","items":{"type":"object","properties":{"date":{"type":"string"},"scuUsd":{"type":"number"},"computeIndex":{"type":"number","nullable":true},"revisionVersion":{"type":"integer","minimum":0,"exclusiveMinimum":true},"methodologyVersion":{"type":"integer","minimum":0,"exclusiveMinimum":true},"metadataHash":{"type":"string","pattern":"^0x[0-9a-f]{64}$"}},"required":["date","scuUsd","computeIndex","revisionVersion","methodologyVersion","metadataHash"]}}},"required":["from","to","granularity","count","truncated","data"]}
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, openWorld, idempotent), the description adds substantial behavioral detail: per-revision emits one point per revision, while daily/weekly buckets use a step-function carrying the last revision forward. It also documents the fields carried by each point, which is valuable for understanding the response.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but well-structured, with a clear lead sentence, behavioral explanation, and a full response schema. The schema is somewhat lengthy but directly useful; no filler or redundancy. It earns its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema in structured data, the description embeds the response schema and explains source, bucketing behavior, field details, and an alternative tool. This makes the tool fully understandable without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty (0 parameters), so the description carries the full burden. It explains the conceptual parameters—date range, granularity, and defaults—and even includes the response schema fields. This adds meaning far beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'SCU index time series — date-range history of Standard Compute Unit values.' It clearly distinguishes from siblings by explicitly directing single-point lookups to data_get_cpi, ensuring the tool's scope is well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance: it notes the default behavior (per-revision over full range) and advises using data_get_cpi for a single point at a specific timestamp. This provides a clear alternative and helps the agent decide when to use this tool versus a sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Methodology changelog — every registered methodology version with its formula summary, family rule, reference workload, and spec reference, plus activeVersion (the version in force now). Source: Oracle API. Use to interpret SCU values and to pin integrations to a methodology version.
Oracle response schema (auto-derived from OpenAPI at startup): {"type":"object","properties":{"activeVersion":{"type":"integer","minimum":0,"exclusiveMinimum":true},"entries":{"type":"array","items":{"type":"object","properties":{"version":{"type":"integer","minimum":0,"exclusiveMinimum":true},"title":{"type":"string"},"meanType":{"type":"string"},"weighting":{"type":"string"},"familyRule":{"type":"object","properties":{"oneFamilyOneSlot":{"type":"boolean"},"familyKeyScheme":{"type":"string"},"representativeSelection":{"type":"string"}},"required":["oneFamilyOneSlot","familyKeyScheme","representativeSelection"]},"referenceWorkload":{"type":"object","properties":{"inputTokens":{"type":"integer","minimum":0,"exclusiveMinimum":true},"outputTokens":{"type":"integer","minimum":0,"exclusiveMinimum":true}},"required":["inputTokens","outputTokens"]},"cacheReasoningInIndex":{"type":"boolean"},"formulaSummary":{"type":"string"},"rationale":{"type":"string"},"specUrl":{"type":"string","nullable":true}},"required":["version","title","meanType","weighting","familyRule","referenceWorkload","cacheReasoningInIndex","formulaSummary","rationale","specUrl"]}}},"required":["activeVersion","entries"]}
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description discloses the source (Oracle API), that it returns a list of all versions plus an activeVersion pointer, and includes the full response schema. This richly documents what the agent can expect from the response.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core description is concise and front-loaded, but the embedded JSON response schema adds significant length. It is useful and well-organized, but the overall description is longer than necessary for a no-parameter read tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a completely specified tool: no input parameters, a fully detailed response schema in the description, clear purpose and use case, and annotations covering safety. The description leaves no gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline of 4 applies. The description does not need to add parameter semantics, and there are no parameters to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a 'Methodology changelog' that returns every registered methodology version with specific fields (formula summary, family rule, reference workload, spec reference) and the activeVersion. This is a specific verb+resource and clearly distinguishes it from sibling tools like data_get_scu or data_get_basket.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Use to interpret SCU values and to pin integrations to a methodology version.' This gives clear context but does not mention alternatives or exclusions, so it falls short of a full 5 per the rubric.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Per-model input/output USD price effective at a specific timestamp. Source: Oracle API (/v1/oracle/models/{model}/price-at). Response is a discriminated union by source: 'manifest' when the model is the family representative in the revision active at that date (cross-links revisionVersion, methodologyVersion, metadataHash, family for verification), or 'providerCost' when only catalog pricing exists (step-function fallback). observedAt reflects when the price was recorded. Returns an error for malformed or future dates, untracked models, or dates preceding all available data.
Oracle response schema (auto-derived from OpenAPI at startup): {"oneOf":[{"$ref":"#/components/schemas/ModelPriceAtManifestDto"},{"$ref":"#/components/schemas/ModelPriceAtProviderCostDto"}],"discriminator":{"propertyName":"source"}}
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds substantial behavioral context by explaining the discriminated union by source, the observedAt field, and the exact error scenarios (malformed/future dates, untracked models, missing prior data). This goes well beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat long, but it is front-loaded with purpose and includes critical details such as error conditions and the response schema. Every sentence adds value, though the explicit JSON schema snippet could potentially be condensed without losing essential meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description provides a rich explanation of response types, error behavior, and verification fields, which is very helpful. However, it does not explain how the timestamp parameter is supplied given the empty input schema, which is a notable invocation gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there are no parameter details to document. The baseline for zero parameters is 4. The description's mention of 'at a specific timestamp' implies a parameter exists, but the schema does not reflect that, creating a minor gap in how to actually invoke the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns per-model input/output USD price at a specific timestamp, with a source API and a detailed response structure. It distinguishes itself from siblings like data_get_model_price_history and data_get_price by focusing on point-in-time lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this tool is for historical price lookups at a specific timestamp and lists error conditions (future dates, untracked models). However, it does not explicitly name alternative tools or describe when not to use them, so it lacks the explicit direction that would earn a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Per-model input/output USD price time series — date-range history for a single model that has appeared in at least one confirmed SCU basket. Source: Oracle API (/v1/oracle/models/{model}/price-history). Each point carries input/output USD per million tokens plus revisionVersion, methodologyVersion and metadataHash. Catchup revisions whose manifest is unavailable are surfaced in unavailableRevisions. Same granularity (per-revision/daily/weekly) and limit semantics as data_get_history. Models that have never appeared in any confirmed revision return an error.
Oracle response schema (auto-derived from OpenAPI at startup): {"type":"object","properties":{"from":{"type":"string"},"to":{"type":"string"},"granularity":{"type":"string","enum":["per-revision","daily","weekly"]},"count":{"type":"integer","minimum":0,"exclusiveMinimum":false},"truncated":{"type":"boolean"},"modelKey":{"type":"string"},"family":{"type":"string"},"unavailableRevisions":{"type":"array","items":{"type":"integer","minimum":0,"exclusiveMinimum":true}},"data":{"type":"array","items":{"type":"object","properties":{"date":{"type":"string"},"inputPriceUsdPerMillion":{"type":"number"},"outputPriceUsdPerMillion":{"type":"number"},"revisionVersion":{"type":"integer","minimum":0,"exclusiveMinimum":true},"methodologyVersion":{"type":"integer","minimum":0,"exclusiveMinimum":true},"metadataHash":{"type":"string","pattern":"^0x[0-9a-f]{64}$"}},"required":["date","inputPriceUsdPerMillion","outputPriceUsdPerMillion","revisionVersion","methodologyVersion","metadataHash"]}}},"required":["from","to","granularity","count","truncated","modelKey","family","unavailableRevisions","data"]}
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Model pricing key (e.g. 'gpt-5.5'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds valuable behavioral context: it explains that models never appearing in confirmed revisions return an error, and that unavailableRevisions surfaces catchup revisions with missing manifests. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The first two sentences are concise and front-loaded with purpose and source. The inclusion of the full Oracle response schema is lengthy, but it is necessary given the lack of a formal output schema and provides critical return structure. The overall structure is logical.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the required scope, error conditions, granularity semantics, and a full response schema, making it self-sufficient despite the absence of an output schema. It also references a sibling for shared semantics, which completes the picture for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% description coverage for the single 'model' parameter with an example. The description reinforces that it is a single model, but does not add new semantic details beyond the schema, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning per-model input/output USD price time series for a single model over a date range, with explicit mention of the source API endpoint. This distinct scope (single model, price history) separates it from siblings like data_get_model_price_at (point-in-time) and data_get_price (current price).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states it is for a single model's history and references data_get_history for granularity/limit semantics, providing useful context. However, it does not explicitly say when to prefer this over alternatives or when not to use it, though the scope is clear enough for an agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Price for a single oracle-tracked model — basket members and catalog-only entries on identical terms. Returns base_input/base_output USD per million tokens (the provider list price), routing_fee_rate, and billed_* = base × (1 + routing_fee_rate) — what compute.finance charges. Wei prices are populated for basket members and null otherwise. Per-component cache pricing (cachedInput, cacheWrite5m, cacheWrite1h) is on the base basis. Compare models on base_*: two models with the same provider price return the same numbers regardless of basket membership. price_source ('oracle-basket' | 'oracle-catalog') names the serving endpoint only and does not change the pricing basis. Errors with 'Model not tracked by oracle' for unknown keys. Source: Oracle API (/v1/oracle/resolve + /v1/oracle/basket). Accepts canonical names like 'claude-opus-4.7' or 'gpt-5.5'.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Model name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description goes far beyond this by detailing the computed fields (billed_* = base × (1 + routing_fee_rate)), null wei prices for non-basket members, the semantic of price_source, and the exact error message for unknown models. This is rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-organized, front-loading the main purpose and then detailing return fields and behaviors. Each sentence contributes necessary information, though it is longer than typical for a single-parameter tool. The structure with semicolons and bullet-like clauses makes it scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description thoroughly explains all return fields (base_*, routing_fee_rate, billed_*, wei prices, cache pricing), error handling, the source API, and naming conventions. This makes the tool self-contained for an agent to understand its behavior and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only has one parameter 'model' with minimal description and an example. The description adds canonical name examples ('claude-opus-4.7', 'gpt-5.5') and clarifies that any oracle-tracked model is accepted, which meaningfully enriches the parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Price for a single oracle-tracked model', identifying a specific verb (get price), resource (oracle-tracked model), and scope (single). It also distinguishes from siblings by noting basket members and catalog-only entries are treated identically, contrasting with data_get_basket and data_get_catalog.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is the unified price tool for single models, and advises comparing models on base_* to avoid basket membership effects. It does not explicitly name alternative tools or state when not to use it, but the differentiation is implicit through the endpoint and comparison guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Historical basket changes — model swaps with date, basket version, models added/removed, SCU before/after. Source: Oracle API. Sorted most recent first. Use the optional limit parameter to cap results.
Oracle response schema (auto-derived from OpenAPI at startup): {"type":"object","properties":{"entries":{"type":"array","items":{"type":"object","properties":{"id":{"type":"string"},"revisionVersion":{"type":"integer"},"methodologyVersion":{"type":"integer","minimum":0,"exclusiveMinimum":true},"previousVersion":{"type":"integer","nullable":true},"publishedAt":{"type":"string"},"summary":{"type":"string"},"scuBefore":{"type":"number","nullable":true},"scuAfter":{"type":"number"},"changes":{"type":"array","items":{"type":"object","properties":{"type":{"type":"string"},"modelKey":{"type":"string"},"description":{"type":"string"},"before":{"type":"object","additionalProperties":{}},"after":{"type":"object","additionalProperties":{}}},"required":["type","description"]}},"txHash":{"type":"string","nullable":true}},"required":["id","revisionVersion","methodologyVersion","previousVersion","publishedAt","summary","scuBefore","scuAfter","changes","txHash"]}}},"required":["entries"]}
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max events to return (most recent first). Defaults to all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, setting a solid baseline. The description adds the source (Oracle API), sorting order, and a complete response schema. However, it does not disclose potential large default result sets, pagination details, or error behaviors beyond what the schema implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The initial two sentences are concise and informative, but the description then includes a large, auto-derived Oracle response schema, making the overall text verbose and lengthy. The key details are front-loaded, yet the massive schema block reduces clarity and could discourage full reading.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and strong annotations, the description covers purpose, source, sorting, limit usage, and includes a full response schema. This provides the agent with enough information to select and invoke the tool correctly, though it could briefly mention when to choose it over similar sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'limit' is fully documented in the schema with a clear description and default. The text 'Use the optional limit parameter to cap results' adds no new meaning beyond the schema. Since schema description coverage is 100%, this is a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool provides 'Historical basket changes' with specific details like model swaps, dates, basket versions, and SCU before/after. This is a specific verb and resource, and it effectively distinguishes itself from sibling tools by focusing on reconstitution events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers contextual guidance such as 'Sorted most recent first' and 'Use the optional limit parameter to cap results,' but it does not explicitly compare this tool to alternatives like data_get_history or data_get_basket. The usage is implied but not explicitly stated with when/when-not conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current Standard Compute Unit (SCU) — value plus the methodology-versioned breakdown discriminated union listing every family representative with USD-per-million-token prices and blended cost. Also carries computeIndex: the inverse purchasing-power view (baseline / scuUsd) × 100, anchored at 100 at the first confirmed revision. The response carries methodologyVersion; see data_get_methodology for the formula in force. For the breakdown alone, use data_get_breakdown; for the baseline denominator, use data_get_baseline. Source: Oracle API.
Oracle response schema (auto-derived from OpenAPI at startup): {"type":"object","properties":{"scuUsd":{"type":"number"},"computeIndex":{"type":"number","nullable":true},"referenceWorkload":{"type":"object","properties":{"inputTokens":{"type":"number"},"outputTokens":{"type":"number"}},"selfRequired":true},"methodologyVersion":{"type":"integer","minimum":0,"exclusiveMinimum":true},"breakdown":{"oneOf":[{"type":"object","properties":{"methodologyVersion":{"type":"number","minimum":1,"maximum":1},"familyRepresentatives":{"type":"array","items":{"type":"object","properties":{"family":{"type":"string"},"modelKey":{"type":"string"},"inputPriceUsdPerMillion":{"type":"number"},"outputPriceUsdPerMillion":{"type":"number"},"blendedCostUsd":{"type":"number"}},"required":["family","modelKey","inputPriceUsdPerMillion","outputPriceUsdPerMillion","blendedCostUsd"]}}},"required":["methodologyVersion","familyRepresentatives"]}]},"updatedAt":{"type":"string"}},"required":["scuUsd","computeIndex","referenceWorkload","methodologyVersion","breakdown","updatedAt"]}
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare read-only, idempotent, non-destructive, and open-world. The description adds meaningful behavioral context beyond these, explaining the computeIndex anchoring, methodology versioning, and the breakdown structure. It also mentions the Oracle API source, giving the agent a clear picture of data provenance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but front-loaded with the core purpose and alternatives before diving into a detailed response schema. Every section serves a purpose, although the embedded Oracle schema could arguably live in an output schema field instead of the description. Still, it is well-organized and not repetitive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even with no output schema field, the description includes a complete response schema and explains all high-level concepts (computeIndex, breakdown, methodologyVersion). It also references relevant sibling tools and the data source, making the tool fully contextualized for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description still adds substantial value by detailing the output semantics (each field in the breakdown, the computation of computeIndex, methodologyVersion). This exceeds the baseline by making the tool's behavior fully understandable despite having no inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the current SCU value plus a methodology-versioned breakdown and computeIndex, using a specific verb ('get') and resource ('SCU'). It distinguishes from sibling tools by explicitly naming data_get_breakdown and data_get_baseline for alternative views.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'For the breakdown alone, use data_get_breakdown; for the baseline denominator, use data_get_baseline' and 'see data_get_methodology for the formula in force.' It clearly tells when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
SCU value active at a specific timestamp via step function — no interpolation. Source: Oracle API (/v1/oracle/scu-at). Resolves the latest confirmed revision with publishedAt ≤ date and returns its scuUsd, scuUsd18, computeIndex, revisionVersion, methodologyVersion, publishedAt, and metadataHash. Monotonicity is non-strict — when two confirmed revisions share publishedAt the highest revisionVersion wins. computeIndex is derived as (baseline.scuUsd / scuUsd) × 100, the same formula as data_get_scu and each data_get_history point. Returns null when the date precedes the genesis revision; errors on malformed or future dates. Use data_get_history for a bucketed series; use data_get_scu_at for a single-point lookup.
Oracle response schema (auto-derived from OpenAPI at startup): {"type":"object","properties":{"at":{"type":"string","format":"date-time"},"scuUsd":{"type":"number"},"scuUsd18":{"type":"string"},"computeIndex":{"type":"number","nullable":true},"revisionVersion":{"type":"integer","minimum":0,"exclusiveMinimum":true},"methodologyVersion":{"type":"integer","minimum":0,"exclusiveMinimum":true},"publishedAt":{"type":"string","format":"date-time"},"metadataHash":{"type":"string","pattern":"^0x[0-9a-f]{64}$"}},"required":["at","scuUsd","scuUsd18","computeIndex","revisionVersion","methodologyVersion","publishedAt","metadataHash"]}
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses key behavioral traits: step-function resolution with no interpolation, tie-breaking by highest revisionVersion, the computeIndex derivation formula, and exact null/error conditions. This adds substantial context beyond what annotations alone convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and then adds necessary details about monotonicity, null/error behavior, and alternatives. The inline output schema is lengthy but serves as a substitute for a formal output schema field. Each sentence carries information, though the description could be trimmed slightly without losing value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (step semantics, tie-breaking, derived fields, error conditions) and the absence of a formal output schema, the description covers everything the agent needs: source, return fields, edge cases, and relationship to sibling tools. It is fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description references a 'date' or 'timestamp' and explains its semantics (e.g., 'with publishedAt ≤ date'), which is the only parameter documentation provided. However, the implicit parameter is not formally declared in the schema, leaving a minor structural gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a clear, specific verb and resource: 'SCU value active at a specific timestamp via step function — no interpolation.' It also names the source API and lists the exact fields returned, making the tool's function unmistakable and distinguishing it from siblings like data_get_history and data_get_scu.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'Use data_get_history for a bucketed series; use data_get_scu_at for a single-point lookup.' It also clarifies edge-case behavior (non-strict monotonicity, null for genesis-preceding dates, errors on malformed/future dates), giving the agent clear criteria for when and how to invoke the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pre-formatted table of recent Claude Code sessions across all projects — per-session Prompts · Inferences · Tool calls, tokens, and effective/nominal cost. Source: local Claude Code transcripts + Oracle API. Print the text field verbatim. Defaults to last 24h, top 10.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Limit to sessions from this working directory. | |
| hours | No | Look-back window in hours (default 24). | |
| limit | No | Max rows (default 10). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate no strong side effects (readOnlyHint false, destructiveHint false, idempotentHint true). The description adds valuable behavioral context: data source (local transcripts + Oracle API), defaults (24h, top 10), and an explicit instruction to print the `text` field verbatim. This goes beyond annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose, then provides source, output handling, and defaults. Every sentence carries distinct information, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 optional parameters and no output schema, the description adequately covers purpose, data source, output handling, and defaults. Minor gaps exist: it does not explain what 'effective/nominal cost' means or whether any prerequisites are needed, but these are not critical for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all three parameters. The description additionally clarifies that `hours` defaults to 24 and `limit` defaults to 10, and that `cwd` limits to a working directory, enriching the schema's explicit definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool renders a pre-formatted table of recent Claude Code sessions with detailed metrics (Prompts, Inferences, Tool calls, tokens, costs). However, it does not explicitly differentiate from the sibling tool 'render_session_report', which could serve a similar purpose, so it lacks full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for display (print text verbatim) and notes default look-back and limit, but it does not explicitly state when to use this tool over alternatives like 'render_session_report' or whether it complements 'analyze_session'. No exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pre-formatted per-inference breakdown for cf-session-consumption skill. Source: local Claude Code transcript + Oracle API. Bar chart, tool aggregates, mechanical facts; one row per assistant reply (Innn). Header carries the canonical Prompts · Inferences · Tool calls triplet — same numbers as render_session_report and render_active_sessions. Print the text field verbatim. Pass full=true to show every inference instead of top-10/last-5.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | ||
| full | No | If true, show every inference (no top-10/last-5 truncation). Default false. | |
| session_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the data source (local Claude Code transcript + Oracle API), output structure (rows per reply, canonical triplet), and truncation behavior (top-10/last-5 unless full=true). It also instructs to print the `text` field verbatim. Annotations already provide idempotency and destructive hints; the description adds useful behavioral context beyond that. There is no direct contradiction with readOnlyHint=false, though the description's implied read-only nature could be clearer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with three sentences packing purpose, output details, and usage instruction. It is front-loaded with the tool's identity and avoids fluff. Minor issue: 'Bar chart, tool aggregates, mechanical facts' is a cryptic list that could be clearer.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a rendering tool with no output schema, the description explains the output format (bar chart, rows per reply, header triplet), the `text` field, and the full parameter behavior. It also notes consistency with sibling reports. The only gap is the lack of clarity on cwd and session_id parameters, but overall the description gives sufficient context to invoke the tool and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, with full described in the schema and the description also clarifying its effect (show every inference vs. truncation). However, cwd and session_id have no schema description and are not mentioned in the description, leaving their purpose unexplained. The description does not compensate for the low coverage on these two parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a pre-formatted per-inference breakdown report for cf-session-consumption, with output specifics (bar chart, tool aggregates, one row per assistant reply). It does not start with a direct verb like 'Renders' but the name and content make the purpose clear. It distinguishes from siblings by noting the canonical triplet matches render_session_report and render_active_sessions, but doesn't fully explain how it differs from those.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (per-inference breakdown, source data) and gives parameter-level guidance for full=true, but does not explicitly state when to choose this tool over its siblings or when not to use it. With 20 sibling tools, explicit guidance would be valuable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pre-formatted session cost report for cf-session-management skill. Source: local Claude Code transcript + Oracle API. Reads the transcript, prices it, logs to history, returns a text string. Header carries the canonical Prompts · Inferences · Tool calls triplet (user prompts, assistant replies, tool_use blocks — three distinct counters). Print verbatim — do not reformat or interpret. Omit session_id for the most recent session.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | ||
| session_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, it discloses 'logs to history' as a side effect and 'returns a text string' as output shape. The 'print verbatim — do not reformat' instruction is extra behavioral guidance without contradicting the idempotentHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Six short, front-loaded sentences each carry useful information: purpose, source, behavior, output format, print instruction, parameter nuance. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given only two optional string parameters and no output schema, the description adequately covers return type and core semantics. A minor gap is not explaining cwd or showing a sample report format, but overall enough for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds meaning for session_id ('omit... for most recent session'). The cwd parameter remains unexplained, so parameter understanding is only partially improved.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly identifies a 'pre-formatted session cost report' with explicit actions: reads transcript, prices it, logs, and returns text. Distinguishes from siblings via output format and report scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description frames when it applies ('for cf-session-management skill', source, output use) and gives specific print verbatim and most-recent-session nuances. Does not explicitly name alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Aggregate stats across logged sessions (deduped, last-wins). Source: local ~/.compute-finance/ storage + Oracle API. Sample size, cumulative effective vs nominal cost, per-profile medians, insights (cache dominance). Insights require at least 5 sessions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnly/idempotent, and the description adds meaningful behavioral context: deduplication with last-wins, combined local/Oracle source, and a 5-session minimum for insights. These traits are not derivable from annotations and help set expectations for output and limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core purpose, followed by source and output details. The metrics list is terse but informative, and the 5-session threshold is an efficient addition, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description compensates by enumerating the returned aggregate fields and the key threshold for insights. It provides sufficient context for what the tool returns, making it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the description is not required to explain parameter semantics. It instead lists the output metrics (sample size, cumulative effective vs nominal cost, per-profile medians), which is the relevant semantic content given the tool has no inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool aggregates stats across logged sessions, with specific details like deduped/last-wins, source, and key metrics. This distinguishes it from sibling data_get_history and other data tools by focusing on telemetry over sessions rather than raw data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on what the tool aggregates (session stats) and its data source, implying use for telemetry rollups. It does not explicitly name alternatives or when-not-to-use, but the context is sufficient for selecting among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.7.0analyze_inferencesanalyze_sessioncompute_comparecompute_estimatedata_get_baselinedata_get_basketdata_get_breakdowndata_get_catalogdata_get_cpidata_get_historydata_get_methodologydata_get_model_price_atdata_get_model_price_historydata_get_pricedata_get_reconstitutionsdata_get_scudata_get_scu_atrender_active_sessionsrender_consumption_reportrender_session_reporttelemetry_get_historyThe data_get_* family contains several tools with overlapping returns (e.g., data_get_basket, data_get_catalog, data_get_cpi all list model prices; data_get_scu embeds the breakdown). However, each tool has a specific use case described, so careful agents can distinguish them. The render_/analyze_ pairs are clearly differentiated by output format (formatted vs raw). Overall, moderate overlap exists but not severe.
Most tools follow a readable snake_case with clear prefixes: render_, compute_, analyze_, data_get_. However, the pattern is inconsistent: render_/compute_/analyze_ are verb-first, while data_get_/telemetry_get_ are noun-first (noun+verb). Additionally, compute_compare uses a verb after the verb, breaking the noun/verb pattern.
With 21 tools, the server feels heavy for an MCP, especially with two distinct domains (oracle data retrieval and session cost reporting). Many tools are narrowly scoped (e.g., data_get_breakdown vs data_get_scu). However, the breadth of oracle endpoints and session analysis justifies most tools, so it's borderline rather than excessive.
The server comprehensively covers oracle pricing data (prices, SCU, history, methodology, reconstitutions, baseline) and session analysis (summary, consumption, active sessions, raw JSON, telemetry). The main gap is a lack of a general session listing beyond recent active sessions, and no write/update capabilities, but these are outside the evident read-only scope.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Live LLM API pricing: token prices, comparisons, cheapest-model lookups. No key required.
Compare LLM API pricing, estimate workload costs, and benchmark cloud compute. By OptimNow.
Live LLM API price + status radar across 11 providers, with public per-model price HISTORY.
Compare up-to-date pricing for 40+ LLMs (incl. Chinese) & estimate cost from tokens. EN/zh.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/compute-finance/mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
