Costory: Your Finops MCP

preview_alert

Read-only

Backtest a cost-alert condition BEFORE creating it: replays the condition against the last lookbackDays (default 45) of data and reports how many times it would have fired. Takes the same queries + condition + dedup as create_alert (no notification channel needed). Returns the evaluation window, firingDays (distinct days the condition held), firingRows (per-group fires), notificationsCount (fires that survive the dedup window) and a sample of firing dates. Use this to sanity-check a condition/threshold (and tune dedup) before calling create_alert. EXAMPLE: "Would 'alert if 7-day AWS spend tops $50k' have fired this month?" → { queries: [{ type: "cost", name: "a", metricId: "cost", currency: "USD", filterCel: "cos_provider in ["AWS"]" }], condition: "rollingSum(a, 7, DAY) > 50000", dedup: { kind: "CALENDAR", calendarUnit: "WEEK" }, lookbackDays: 30 }

Input Schema

TableJSON Schema

Name	Required	Description
`slug`	No	Organization slug. Omit to auto-detect from your account (fails if you belong to multiple orgs).
`dedup`	No	Deduplication config controlling how often a still-firing alert notifies. Either CALENDAR (kind: CALENDAR, calendarUnit: WEEK \| MONTH) = at most once per current ISO week / calendar month, or ROLLING (kind: ROLLING, windowDays: N) = at most once every N days. Optional here: when provided the result also reports how many notifications would actually be sent after dedup.
`queries`	No	Same series objects as the `query` tool `queries` array (referenced by `condition`).
`condition`	Yes	Alerts v3 firing rule: a single boolean expression over the query names (`name` field of each query). Supports arithmetic (+ - * /), comparisons (> >= < <= == !=), logical and/or/not, parentheses, and these window functions: rollingSum(a, N, UNIT) (trailing sum over the last N units, UNIT ∈ DAY\|WEEK\|MONTH, inclusive of today), weekToDateSum(a) (Monday-to-date), monthToDateSum(a) (1st-of-month-to-date), and timeShift(a, N, UNIT) (value shifted back N units; may wrap a window function). Examples: `a > 1000`, `rollingSum(a, 7, DAY) > 1000`, `(a - timeShift(a, 1, DAY)) / timeShift(a, 1, DAY) > 0.2`, `a > 10000 or rollingSum(a, 7, DAY) > 50000`.
`lookbackDays`	No	Trailing window length in days to replay the condition over (default 45).

TDQS

A4.8/5.0

Behavior5/5

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

The annotations already mark the tool as read-only and non-destructive, but the description adds deeper behavioral context: it replays the condition over `lookbackDays` and returns specific computed metrics (`firingDays`, `firingRows`, `notificationsCount`). It also clarifies that dedup is optional here and affects only the reported notification count, which is useful behavior not captured in annotations.

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

Conciseness4/5

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

The description is a single paragraph followed by a concrete example; every sentence provides distinct information, from the backtest purpose to the returned fields and the explicit usage note. While the example is lengthy, it earns its place by demonstrating a realistic parameter combination, making the structure efficient for the tool's complexity.

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?

This is a new tool with no output schema, yet the description fully specifies the return payload (evaluation window, `firingDays`, `firingRows`, `notificationsCount`, and sample dates). It also explains prerequisites (same queries/condition/dedup as create_alert), the default lookback, and provides an example, giving an agent everything needed 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?

The input schema already provides 100% parameter documentation with detailed descriptions, so the baseline is 3. The description enhances this by explaining how the parameters interact: it states `condition` is replayed against `lookbackDays`, and that `dedup` can be omitted or included to see notification impact. The included example maps a real query/condition/dedup to the parameter structure, which adds practical semantic value beyond 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?

The description opens with 'Backtest a cost-alert condition BEFORE creating it', clearly identifying the verb (backtest), resource (cost-alert condition), and temporal context. It distinguishes itself from create_alert by explicitly referencing the same queries/condition/dedup without the notification channel, which separates it from the sibling tool.

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 states 'Use this to sanity-check a condition/threshold (and tune dedup) before calling create_alert', giving direct when-to-use guidance. It also clarifies what is not needed (notification channel) and references create_alert as the alternative, so an agent knows when not to invoke this tool.

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

All Costory: Your Finops MCP tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0

Disambiguation4/5

Tools are organized by resource (alerts, dashboards, reports, events, virtual dimensions) with distinct actions, so most are clearly separable. The main confusion risks are the three report-delivery side-effect tools (run_report_now, retry_report_execution, transfer_report_execution) and the generic get that spans five resource types, though detailed descriptions mitigate these.

Naming Consistency4/5

The dominant verb_noun pattern (create_*, list_*, update_*, preview_*, get_*) is consistent and predictable across the set. Deviations like bare verbs query/search/get and the noun-only virtual_dimension_overlap_matrix are readable but break the otherwise uniform convention.

Tool Count3/5

44 tools is heavy and exceeds the comfortable range, but the server covers a genuinely broad FinOps platform spanning querying, dashboards, reports, alerts, events, virtual dimensions, docs, skills, and suggestions. Each tool has a distinct job, though the sheer count makes agent navigation harder.

Completeness3/5

Core workflows are well covered: query → dashboard/report/alert/event, plus a full virtual-dimension draft lifecycle. Notable gaps include alerts being create-only with no update/delete, no deletes for dashboards/events/published virtual dimensions, and budget management limited to query/get with no create/update.

Resources

Need Help?