Validating responses

AI agents can misread or over-summarize. Treat the CloudQuell dashboard and reports as the source of truth, and use these habits to verify what an agent tells you — especially before acting on a number.

1. Cross-check against the dashboard

Every tool surfaces the same data as the CloudQuell UI. To verify an answer:

The agent said…	Check it against…
Month-to-date / by-service totals	the Overview dashboard
A savings number	the Savings view (banked / open / potential)
An anomaly / spike	the Anomalies feed and the service’s trend chart
Budget actual vs. forecast	the Budgets view (status, thresholds)
Commitment utilization / expiry	the Commitments view
Allocation by cost center	the Allocation view

If a figure doesn’t match, trust the dashboard and re-ask the agent with a tighter scope (exact dates, exact account) — the discrepancy is usually a filter or timeframe mismatch.

2. Expand the tool call to see the real query

Most MCP clients let you expand a tool invocation to see its inputs and raw output. Do this when a number surprises you:

• Inputs tell you the actual filters used — the view, start_date/end_date, account_id, service, limit. A “wrong” answer is often a too-broad or too-narrow filter.
• Raw output is the parsed payload (ask for response_format: detailed to see every field). The lastUpdated timestamp tells you as of when; currency tells you the unit.

Example: if “savings look low,” expand get_savings — check whether a minMonthlySavings floor or an actionType/accountId filter trimmed the list, and whether recommendations.truncated is true (more matched than were returned).

3. Watch for truncation

If a result was too large, the tool returns { "truncated": true, "message": … } instead of partial data. That message is not the answer — it’s an instruction to narrow the request. Re-ask with a filter, a lower limit, or concise format. The server never silently drops rows, so a non-truncated result is complete within its limit.

4. Know what’s derived vs. reported

Some answers are computed in the tool, not read verbatim from the backend — verify the reasoning, not just the number:

• list_anomalies / investigate_anomaly derive anomaly signals from month-over-month and week-over-week movement (there is no precomputed anomaly list). Check the pctChange, baselineAvg, and currentCost it shows, and the reason (mom_increase vs. new_service).
• investigate_anomaly ends with a verdict string — that’s the tool’s summary, backed by the momRow, topResources, and dailySeries in the same result. Read those to confirm the verdict.
• Percentage changes can be null when the prior-period base is zero — a null %, not “0% change.”

5. Reconcile before you act

For anything finance- or change-related:

• Before trusting a total, confirm the date range and currency, and that it’s scoped to the accounts you mean.
• Before a write (creating a budget, changing a recommendation’s status), have the agent restate exactly what it will do, then confirm. The confirm: true gate exists precisely so a mutation is never a side effect of a question.
• After a write, re-read with the matching tool (e.g. get_budgets after create_budget) to confirm the change landed as intended.

6. Round-trip with a report

For board- or invoice-grade numbers, export the equivalent saved report or dashboard CSV from CloudQuell and reconcile against the agent’s figure. Finance shouldn’t act on a number that can’t be tied back to the bill — and the agent’s job is to get you to that number faster, not to replace the reconciliation.