Skip to main content
Glama

Costory: Your Finops MCP

preview_virtual_dimension_draft

Read-only

Preview per-rule costs or a groupBy breakdown (read-only BigQuery). virtualDimensionId in inputs equals id from list/get/search. Operates on the latest pending draft if one exists (draftPersisted: true); otherwise previews published rules in memory without creating a draft (draftPersisted: false — not publishable). To publish changes after editing published-only state, call update_virtual_dimension_draft for an existing virtualDimensionId (or create_virtual_dimension_draft for a brand-new VDIM) — preview alone does not persist. Call after a successful create/update. Read the "summary" field first. Both modes share the same time window: optional datePreset (official presets — TRAILING_30_DAYS default, same enum as dashboards) or explicit from/to (YYYY-MM-DD, same shape as query); mutually exclusive. mode "costs": per-rule costs with totals.namedRulesSharePercent / totals.leftoverSharePercent, each rule's conditionCel and allocatesTo, plus howToRead. mode "breakdown": spend inside a target rule (ruleId or ruleIndex) split by groupBy — returns period (datePreset or from/to), scope.explanation, topValues[{ value, cost, percentOfScope }], and dailyTotals (not raw chart JSON). Discover valid groupBy values via search with type: ["dimensions"]. position (from get and preview costs output) and ruleIndex (preview/overlap input) refer to the same 0-based ordinal in the ordered rule list [...rules, leftover]. Prefer ruleId over ruleIndex. Target leftover via ruleId of leftoverRule or ruleIndex: rules.length. Optional currency (default USD) — pass the same value as query cost queries to align totals. costMetric selects the cost column (default cost); valid ids: cost, effective_cost, list_cost, contracted_cost (also accepts contracted_costs), unblended_cost, net_unblended_cost, amortized_cost, net_amortized_cost. EXAMPLES: • "Preview Environment VDIM draft costs" → { virtualDimensionId: "<virtualDimensionId from create/list>", mode: "costs" } • "What cos_region values sit inside Production?" → { virtualDimensionId: "<virtualDimensionId from create/list>", mode: "breakdown", ruleId: "<from get/preview costs>", groupBy: "cos_region", datePreset: "TRAILING_30_DAYS" } • "Preview costs in EUR to match earlier queries" → { virtualDimensionId: "<virtualDimensionId from create/list>", mode: "costs", currency: "EUR", from: "2025-01-01", to: "2025-03-31" }

Input Schema

NameRequiredDescriptionDefault
toNoExplicit window end (YYYY-MM-DD). Use with from instead of datePreset — same shape as query.
fromNoExplicit window start (YYYY-MM-DD). Use with to instead of datePreset — same shape as query.
modeYes`costs` (per-rule costs including leftover and rule metadata) or `breakdown` (drill into a rule).
slugNoOrganization slug. Omit to auto-detect from your account (fails if you belong to multiple orgs).
ruleIdNoTarget rule id (breakdown mode; preferred over ruleIndex)
groupByNoDimension to split by (breakdown mode)
currencyNoCost currency (default USD). Pass the same currency as prior query calls to align preview totals.
ruleIndexNoTarget rule index (breakdown mode fallback)
costMetricNoCost column id (default cost). Valid: cost, effective_cost, list_cost, contracted_cost, unblended_cost, net_unblended_cost, amortized_cost, net_amortized_cost (also accepts contracted_costs → contracted_cost).
datePresetNoOfficial date preset (same values as dashboards/query context). Default TRAILING_30_DAYS. Mutually exclusive with from/to.
virtualDimensionIdYesVirtual dimension id (stable public identifier)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / currency / enum
      Previous value: -[
      -  "USD",
      -  "EUR",
      -  "GBP",
      -  "CNY"
      -]New value: +[
      +  "USD",
      +  "EUR",
      +  "GBP",
      +  "CNY",
      +  "KRW"
      +]
  2. Changed1 schema field changed
    • changedInput schema / properties / datePreset / enum
      Previous value: -[
      -  "TRAILING_90_DAYS",
      -  "TRAILING_30_DAYS",
      -  "TRAILING_45_DAYS",
      -  "TRAILING_7_DAYS",
      -  "TRAILING_3_DAYS",
      -  "TRAILING_14_WEEKS",
      -  "MTD",
      -  "QTD",
      -  "YTD",
      -  "CURRENT_MONTH",
      -  "CURRENT_QUARTER",
      -  "CURRENT_YEAR",
      -  "LAST_WEEK",
      -  "LAST_MONTH",
      -  "LAST_6_MONTHS",
      -  "LAST_12_MONTHS",
      -  "LAST_4_YEARS",
      -  "LAST_3_MONTHS",
      -  "LAST_INVOICE_MONTH"
      -]New value: +[
      +  "TRAILING_90_DAYS",
      +  "TRAILING_30_DAYS",
      +  "TRAILING_45_DAYS",
      +  "TRAILING_7_DAYS",
      +  "TRAILING_3_DAYS",
      +  "TRAILING_1_DAYS",
      +  "TRAILING_14_WEEKS",
      +  "MTD",
      +  "QTD",
      +  "YTD",
      +  "CURRENT_MONTH",
      +  "CURRENT_QUARTER",
      +  "CURRENT_YEAR",
      +  "LAST_WEEK",
      +  "LAST_MONTH",
      +  "LAST_6_MONTHS",
      +  "LAST_12_MONTHS",
      +  "LAST_4_YEARS",
      +  "LAST_3_MONTHS",
      +  "LAST_INVOICE_MONTH"
      +]
  3. Changed1 schema field changed
    • changedInput schema / properties / datePreset / enum
      Previous value: -[
      -  "TRAILING_90_DAYS",
      -  "TRAILING_30_DAYS",
      -  "TRAILING_45_DAYS",
      -  "TRAILING_7_DAYS",
      -  "TRAILING_3_DAYS",
      -  "TRAILING_14_WEEKS",
      -  "MTD",
      -  "QTD",
      -  "YTD",
      -  "LAST_WEEK",
      -  "LAST_MONTH",
      -  "LAST_6_MONTHS",
      -  "LAST_12_MONTHS",
      -  "LAST_4_YEARS",
      -  "LAST_3_MONTHS",
      -  "LAST_INVOICE_MONTH"
      -]New value: +[
      +  "TRAILING_90_DAYS",
      +  "TRAILING_30_DAYS",
      +  "TRAILING_45_DAYS",
      +  "TRAILING_7_DAYS",
      +  "TRAILING_3_DAYS",
      +  "TRAILING_14_WEEKS",
      +  "MTD",
      +  "QTD",
      +  "YTD",
      +  "CURRENT_MONTH",
      +  "CURRENT_QUARTER",
      +  "CURRENT_YEAR",
      +  "LAST_WEEK",
      +  "LAST_MONTH",
      +  "LAST_6_MONTHS",
      +  "LAST_12_MONTHS",
      +  "LAST_4_YEARS",
      +  "LAST_3_MONTHS",
      +  "LAST_INVOICE_MONTH"
      +]
  4. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations cover only the read-only safety profile, but the description adds substantial behavioral context beyond them: it operates on the latest pending draft when one exists (draftPersisted: true) and otherwise previews published rules in memory without creating a draft (draftPersisted: false, not publishable). It also clarifies both modes share the same time window and that datePreset/from-to are mutually exclusive.

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

Conciseness4/5

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

Front-loaded with the core purpose and mode behavior, and most sentences carry distinct information (draft persistence, rule targeting, return fields, currency). It is nonetheless very long and dense, with some overlapping restatement of from/to and costMetric between description and schema, so it is not maximally tight.

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

Completeness5/5

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

With no output schema, the description carries the return-value burden and does so: it names totals.namedRulesSharePercent/totals.leftoverSharePercent, conditionCel, allocatesTo, howToRead, and breakdown's period/scope.explanation/topValues/dailyTotals. Combined with mode, targeting, and window semantics, an agent has what it needs to invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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

Schema description coverage is 100%, so the baseline is 3, but the description meaningfully enriches semantics: ruleId is preferred over ruleIndex, how to target leftover via the leftoverRule id or ruleIndex: rules.length, the shared 0-based ordinal between position and ruleIndex, currency alignment with query, and the costMetric valid-id list. This is real added meaning over the schema.

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

Purpose5/5

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

States a specific verb (Preview) and resource (virtual dimension draft) with the two operating modes named explicitly ('per-rule costs or a groupBy breakdown (read-only BigQuery)'). An agent can distinguish this from update_virtual_dimension_draft and create_virtual_dimension_draft without opening any schema.

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

Usage Guidelines5/5

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

Explicitly says when to call ('After a successful create/update') and draws the line against alternatives: 'preview alone does not persist', routing to update_virtual_dimension_draft or create_virtual_dimension_draft to publish. Mode selection (costs vs breakdown) and how to discover valid groupBy values are also spelled out.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources