Example prompts & workflows

Real prompts you can paste into any connected client, with the tools each one typically drives. Phrase questions naturally — the agent picks the tools. Prefix with “Using CloudQuell, …” if you have several connectors enabled.

Each workflow below is read-only unless noted.

Start here. Cost data is ingested daily, not in real time, and the cloud providers’ own billing exports lag 2-3 days. Before you put any figure in front of a person, ask:

“Using CloudQuell, can I trust the numbers right now?” → get_data_freshness — a fresh / stale / degraded verdict, the reason, and every connection’s last successful ingest. If it isn’t fresh, say which connections are affected instead of presenting the totals as complete.

---

0a. Monday morning — the whole picture in one call

“Using CloudQuell, what should I look at this week?” → get_finops_briefing {}

One call, eight sections, in this order: data freshness, month-end forecast, top movers, anomalies, budgets at risk, expiring commitments, open savings. Freshness comes first so every number below it carries its trust level — if the verdict isn’t fresh, the briefing opens with a warning and you should repeat that caveat in anything you pass on.

Then drill into only what earns it. A good follow-up is two or three of these, not all eight:

“The RDS mover is most of that increase — why?” → investigate_anomaly { service: "AmazonRDS" }

“Show me the budgets that are over.” → get_budget_status

“What’s expiring in the next 30 days?” → get_expiring_commitments { status: "expiring_soon" }

⚠️ A missing section is not a zero. Anything listed in sectionsUnavailable could not be produced — “budgets: unavailable” never means “no budgets at risk”. Say which sections were missing.

Variations:

“Using CloudQuell, give me the AWS-only briefing with the top 3 of each.” → get_finops_briefing { provider: "aws", items_per_section: 3 }

“…and include our Anthropic and OpenAI spend.” → get_finops_briefing { include_ai_spend: true } — reported as its own section, because those dollars are billed by the AI providers and are not part of the cloud totals. Never add the two together.

There is also a cloudquell-weekly-briefing skill / MCP prompt that runs exactly this workflow, including the drill-down thresholds.

0b. Headless — a scheduled agent with a cak_ key

A cak_ service key (Settings → API Keys) needs no browser login and is read-only, which makes it the right credential for an unattended run: the agent physically cannot change anything.

# One JSON-RPC call, no OAuth flow. The daily briefing, three items per section.
curl -sS https://mcp.cloudquell.com/mcp \
  -H "Authorization: Bearer $CQ_API_KEY" \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{
        "jsonrpc": "2.0", "id": 1, "method": "tools/call",
        "params": {
          "name": "get_finops_briefing",
          "arguments": { "period": "daily", "items_per_section": 3 }
        }
      }'

The text content is a ready-to-post markdown briefing; structuredContent is the same data keyed by section, if your job wants to threshold on it before posting.

For a scheduled job, report only when something crosses a threshold — a daily message that always says “everything is fine” gets filtered within a fortnight. Check sectionsUnavailable first, so a failed section is never mistaken for good news.

---

0. What changed? — the fastest way into a bill

“Using CloudQuell, what changed in our bill this month versus last?”

1. compare_periods { preset: "mom", group_by: "service" } — two windowed queries run in parallel and joined into a movers table ranked by the size of the change, each row flagged new (spend only this period), gone (only last), or changed. Deltas are period_a minus period_b.
2. investigate_anomaly { service: "<the top mover>" } — the documented follow-up for why it moved, down to the resources.

Variations:

“How does this week compare to last week, by account?” → compare_periods { preset: "wow", group_by: "account" }

“Compare June 2026 to June 2025.” → compare_periods { period_a: { start_date: "2026-06-01", end_date: "2026-06-30" }, period_b: { start_date: "2025-06-01", end_date: "2025-06-30" } }

“Same comparison, but on the amortized basis finance uses.” → add cost_basis: { use_amortized: true, include_credits: true } — it is applied identically to both periods, and echoed back as costBasis so you can state it.

group_by is service or account here. Product / usage-type / tag pivots have no windowed aggregation on this data source, so they are not offered.

---

1. Anomaly investigation — “why did spend spike?”

The most common FinOps question, and the workflow the tools are shaped around.

“Using CloudQuell, what cost anomalies showed up this month, and what’s driving the biggest one?”

What happens:

1. list_anomalies — derives the month-over-month / new-service spikes, ranked by severity.
2. investigate_anomaly (service from step 1) — chains the weekly trend + MoM row, the per-resource breakdown for the anchor date, and the ±7-day daily series, and returns a verdict on whether the trend looks anomalous.
3. (optional) get_weekly_cost_slices (that service) — to chart the trend.

Follow-ups:

“Drill into AmazonRDS for 2026-06-15 — which resources and accounts drove it?” → investigate_anomaly { service: "AmazonRDS", date: "2026-06-15" }

“Just give me the RDS resources for that ONE day, nothing else.” → get_resource_breakdown { service: "AmazonRDS", date: "2026-06-15", granularity: "daily" } — the per-resource step on its own. Note the default granularity is monthly, which covers the whole calendar month containing date; pass "daily" when you are chasing a single day’s spike.

“That spike is a known one-off backfill — dismiss it.” (write — needs admin:write + confirm) → dismiss_anomaly { service: "AmazonRDS", period: "2026-06", reason: "known backfill", confirm: true }

2. Waste & savings — “where can we cut?”

“Using CloudQuell, show me our top 10 savings opportunities worth at least $100/month, and how much we could save in total.”

1. get_savings { minMonthlySavings: 100, limit: 10 } — returns the headline rollup (banked / open / potential), the by-action-type breakdown, and the top recommendations sorted by savings.

Follow-ups:

“Just the commitment-purchase ones for the prod account.” → get_savings { actionType: "PURCHASE", accountId: "prod" }

“Which services have the most untagged spend? We want to fix allocation first.” → get_tag_coverage { limit: 10 }

“Mark recommendation rec-123 as applied.” (write) → update_recommendation_status { recommendation_id: "rec-123", status: "applied", confirm: true }

3. Budgets & forecast — “are we on track?”

“Using CloudQuell, where will we land this month, and which budgets are over or forecast to go over?”

1. get_forecast — projected month-end spend for the whole org, plus the services and accounts driving it. This is a projection computed from the daily data already ingested, using the same algorithm and anchors as the dashboard’s “Forecasted Month-End” KPI — so the two agree. Always report the confidence note with the number: early in a month it may say “only 4 days of current-month data”, and a method of flat-mtd means it deliberately refused to extrapolate.
2. get_budget_status — joins each budget with current actual + forecast and a derived status (on_track / warning / over). (This forecast comes from the budget engine and is scoped per budget — a different number from get_forecast, which is org-wide.)
3. (optional) get_budgets / get_budget — to inspect a specific budget’s definition, thresholds, and scope.

Follow-ups:

“Which services are pushing us over?” → the byService rows from get_forecast, ranked by projected spend. They pace independently, so they do not sum to the org total — use them for ranking, not arithmetic.

“Set up a $50k monthly budget for prod AWS starting July 1, alert at 80% and 100%.” (write) → create_budget { name: "Prod AWS monthly", amount: 50000, start_date: "2026-07-01", period: "monthly", threshold_pcts: [80, 100], confirm: true }

4. Commitment coverage — “what should we renew?”

“Using CloudQuell, which Reserved Instances or Savings Plans expire soon, and how well are they utilized?”

1. get_expiring_commitments (defaults to expiring_soon) — the renewal list + the rollup (count expiring within 60 days, already expired, total dollars saved).
2. (optional) list_commitments — the full portfolio with utilization % to spot under-used commitments.

Follow-up:

“Cross-reference: are there purchase recommendations that would cover what’s expiring?” → get_savings { actionType: "PURCHASE" } alongside the expiry list.

5. Cost Q&A — “slice it for me”

“Using CloudQuell, what was our AWS spend by service in May, and how does it compare to April?”

1. query_costs { view: "overview", start_date: "2026-05-01", end_date: "2026-05-31" } — MTD/period totals + the per-service comparison.
2. For a finer pivot: compare_periods { group_by: "service" } or { group_by: "account" } — those are the only two group-bys this data source can aggregate over an arbitrary window. Product / usage-type / tag pivots are served by the cost-pivot-v2 job API, which this server does not yet expose; query_costs { view: "detailed" } returns the pivot VOCABULARY (available services / tag keys / linked accounts), not pivot tables.

---

1b. Pivots — “break it down by X”

“What are we spending by usage type this quarter?”

1. run_cost_pivot { "dimensions": ["subcategory"], "provider": "aws", "granularity": "monthly", "months_back": 3 } — one row per usage type, one column per month, sorted by _total.
2. Read returnedWindow, not the request: the backend clamps windows silently and a windowNote appears when it served something different.

“Which application tag owns our daily spend, and when did it jump?”

1. get_available_tag_keys FIRST — tag keys are case- and hyphen-sensitive, and a wrong key silently returns a single lowercase untagged row.
2. run_cost_pivot { "dimensions": ["tag:user_app"], "provider": "aws", "granularity": "daily", "months_back": 14 }.
3. If it returns a jobId instead of rows, the Athena job is still going — call get_cost_pivot { "job_id": "…" } a second or two later. Don’t resubmit.

“What is each cost centre actually spending on?”

1. get_allocation_breakdown for the per-centre totals and the Unallocated size.
2. run_cost_pivot { "dimensions": ["cost_center", "service"], "provider": "aws" } for the services behind each one; add "cost_centers": ["UNALLOCATED"] to look only at what is not attributed yet.

If a pivot returns RESPONSE_TOO_LARGE, ask a smaller question — drop a dimension or shorten the window. Changing limit will not help: it is applied after the backend has already built the whole response.

If you’re unsure of the exact filter values:

“What services and accounts can I filter on?” → get_metadata (or get_available_services / get_available_linked_accounts). account_id accepts either the sub-account name or its 12-digit account id.

To pin the accounting basis:

“Same numbers, but amortized with credits applied — the view finance uses.” → query_costs { …, cost_basis: { use_amortized: true, include_credits: true } }. The response echoes the applied basis as costBasis; quote its summary when you report the figures. Leaving cost_basis off uses your organization’s saved cost settings.

6. Allocation & cost centers — “who owns this spend?”

“Using CloudQuell, break down current spend by cost center, and show me what’s unallocated.”

1. get_allocation_breakdown — per-cost-center spend, rolled-up spend, % of total, and the synthetic Unallocated bucket.
2. (optional) list_cost_centers + list_allocation_rules — to see the taxonomy and the rules that produced the allocation.

7. Alerts & history — “did anything fire?”

“Using CloudQuell, have any cost alerts or budget thresholds fired since June 1? Any failed deliveries?”

1. list_triggered_alerts { since: "2026-06-01" } — the unified firing history.
2. list_triggered_alerts { since: "2026-06-01", severity: "failed" } — only failed deliveries.
3. (optional) list_alert_rules — the rules that could fire.

8. Organization context — “whose data is this?”

“Using CloudQuell, which organization am I looking at, and what can I do in it?”

1. get_current_organization — the org every other tool acts on, its tier and status, and your role in it (your_role). That role, not the OAuth scope, is what the backend checks when a write is attempted.
2. (optional) list_organizations — every org you belong to, if you need to confirm you are looking at the right company. Switching organizations is done in the CloudQuell app, not through these tools.
3. list_members / list_invites — who has access, and which invitations are outstanding. list_invites returns the invite_id that cancel_invite needs.

---

A note on multi-step workflows

investigate_anomaly is a single tool that chains three backend reads for you — it mirrors the manual “anomaly → resource breakdown → daily trend” flow in one call. Prefer it over orchestrating the pieces yourself when you want a verdict on one service. Use the individual tools (list_anomalies, get_weekly_cost_slices, get_resource_breakdown, query_costs view=detailed) when you want to explore broadly first, then dive in.

The natural full sweep is: get_data_freshness (can I trust this?) → compare_periods (what changed?) → investigate_anomaly or get_resource_breakdown (why?) → get_forecast (where does it land?).

Prompts, not just tools

The six CloudQuell FinOps workflows are also served as MCP prompts — cloudquell-weekly-briefing, cloudquell-spend-review, cloudquell-anomaly-triage, cloudquell-budget-guardrails, cloudquell-savings-actions and cloudquell-allocation-hygiene. If your client lists prompts, pick one instead of composing the steps yourself; each takes optional period and provider arguments to focus the run.