Costory: Your Finops MCP

preview_report_widget

Read-only

Read-only preview of ONE report widget — pass the same reportContext + widget object you will later hand to create_report. Returns a token-bounded, per-type result; never creates or delivers. By type: DIGEST → resolvedPeriod, comparison totals, largest changes, root nodes, summary markdown (when display is "summary"), recommendations; TOP_FLOP → bounded top/flop rows; GRAPH_SNAPSHOT → bounded series sample (no image) + explorerUrl; DASHBOARD_PDF/TEXT → validity pointer. Put shared period / groupBy / metric / currency / conditionsCel in reportContext; widgets omit matching fields to inherit. The legacy context alias is temporarily accepted but deprecated; never send both. DIGEST hierarchy: reportContext.groupBy (root, preferred) + additionalGroupBy (deeper levels). DIGEST threshold defaults: 100 absolute / 5% relative / 20 changes (topLargestAbsoluteChange one of 5, 10, 15, 20). DIGEST AI (opt-in): display ("tree" default | "table" | "summary" for LLM executive narrative) and enableAiInvestigation (boolean, default false — per-node deep analysis, independent of display). DIGEST aggBy is Month or Week — never Period (Period is TOP_FLOP). EXAMPLES: • Monthly DIGEST by env → project → service (AI summary) → { reportContext: { datePreset: "LAST_MONTH", groupBy: "cos_environment", metricId: "cost", currency: "USD" }, widget: { type: "DIGEST", queries: [{ type: "cost", name: "a" }], aggBy: "Month", additionalGroupBy: ["cos_sub_account_id", "cos_service_name"], minAbsoluteDiff: 100, minRelativeDiff: 5, topLargestAbsoluteChange: 20, display: "summary", enableAiInvestigation: false } } • Weekly TOP_FLOP → { reportContext: { datePreset: "LAST_WEEK", groupBy: "cos_service_name", metricId: "cost", currency: "USD" }, widget: { type: "TOP_FLOP", queries: [{ type: "cost", name: "a" }], aggBy: "Period", topN: 5, flopN: 5 } }

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).
`widget`	Yes	Single widget to preview (same shape as create/update `widgets[]` items).
`context`	No	Deprecated alias for `reportContext`; supported temporarily for backward compatibility. Do not send both fields.
`reportContext`	No	Optional shared context the widget inherits (same shape as `create_report` `reportContext`).

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this while adding rich behavioral detail: token-bounded results, per-type return shapes (GRAPH_SNAPSHOT has no image, DASHBOARD_PDF/TEXT return validity pointer), deprecated `context` alias with 'never send both', DIGEST AI opt-ins with performance implications, and threshold defaults. This far exceeds 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.

Conciseness4/5

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

The description is long but tightly organized with labeled sections ('By type:', 'DIGEST hierarchy:', 'DIGEST threshold defaults:', 'DIGEST AI (opt-in):') and the core purpose is front-loaded. Two worked examples at the end earn their place. It is dense but not padded; slightly long only because the tool genuinely covers multiple widget variants.

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?

There is no output schema, yet the description fully compensates by enumerating per-type return contents (resolvedPeriod, comparison totals, bounded rows, series sample, validity pointer). It also covers edge cases like deprecated context alias, inheritance rules, DIGEST hierarchy and thresholds, and AI behavior—everything an agent needs to invoke and interpret this complex tool correctly is present.

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

Parameters5/5

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

Schema coverage is 100%, so the schema already documents parameters individually. The description goes well beyond the schema by providing concrete JSON examples, clarifying inheritance semantics (widgets omit fields to inherit from reportContext), documenting the deprecated `context` alias, and constraining values like topLargestAbsoluteChange (5/10/15/20) and aggBy (Month/Week for DIGEST, never Period). This materially improves correct parameter construction.

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?

Opens with a specific verb and resource: 'Read-only preview of ONE report widget'. It explicitly contrasts with create_report by saying 'pass the same reportContext + widget object you will later hand to create_report' and 'never creates or delivers', so an agent can distinguish it from sibling creation/delivery tools without opening schemas.

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

Usage Guidelines4/5

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

The description clearly frames when to use it: preview a single widget before handing it to create_report, and states what it will not do ('never creates or delivers'). It does not explicitly enumerate exclusions for alternatives like get_dashboard_widget_data, but the preview-vs-create contrast is specific enough for safe routing.

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?