MCP tools
The MCP server behind Agentic FinOps exposes twelve tools: nine data tools that read CloudPouch’s local cost and savings data, and three action tools that make CloudPouch collect data. No tool creates, modifies, or deletes anything in your AWS account, and no tool exposes your AWS credentials. For what the server is and how it is secured, see Agentic FinOps (MCP server).
Throughout the tables, “Pro” includes an active Pro trial.
Data tools
Section titled “Data tools”These nine tools read data CloudPouch already holds on your machine. They do not call AWS.
| Tool | What your assistant gets | Free | Pro |
|---|---|---|---|
cloudpouch_get_status | Whether CloudPouch is connected, which plan is active, and what is available | Yes | Yes |
cloudpouch_list_profiles | The AWS profiles CloudPouch knows, with run metadata | Yes | Yes |
cloudpouch_get_cost_summary | Total and per-service AWS cost for one profile and period | Yes | Yes |
cloudpouch_compare_costs | Month-to-month account summary, all service deltas, and the top 15 usage-type movers | Yes | Yes |
cloudpouch_compare_service_costs | Per-service usage-type drill-down of that comparison | Yes | Yes |
cloudpouch_get_savings_summary | Total potential savings and the per-service breakdown | Summary level only | Full |
cloudpouch_list_analysis_runs | Saved Savings Scan history | No — explicit upgrade message | Yes |
cloudpouch_list_opportunities | Individual savings opportunities | No — explicit upgrade message | Yes |
cloudpouch_get_opportunity | One savings opportunity with its evidence | No — explicit upgrade message | Yes |
cloudpouch_compare_costs and cloudpouch_compare_service_costs reuse the Compare screen’s own comparison logic, so the month-to-month numbers your assistant reports match what the Compare screen shows, exactly.
When CloudPouch holds no local data for a question, the data tool does not guess. It explains how to fetch that data — in CloudPouch, or over MCP with the action tools below.
Action tools
Section titled “Action tools”These three tools trigger CloudPouch’s own data collection. They change CloudPouch’s local state — fresher cached cost data, a new run in your scan History — and nothing in AWS.
| Tool | What it does | Plan required |
|---|---|---|
cloudpouch_refresh_cost_data | Refreshes CloudPouch’s local Cost Explorer data for one profile and period. An optional force flag skips the cache. The result names its source — aws when Cost Explorer was queried in this call, cache when the local data was already fresh — plus the exact date window used | Any activated plan, Free included |
cloudpouch_run_savings_scan | Starts a Savings Scan for a profile. The CloudPouch window visibly switches to that profile and runs the scan through the same machinery as the in-app button; the finished run lands in History. The period defaults to Previous month | Any activated plan, Free included |
cloudpouch_get_scan_status | Polls a started scan. It reaches persisted together with the run identifier analysisRunId, which cloudpouch_get_savings_summary can then read back | Any activated plan, Free included |
Cost Explorer data collected this way follows CloudPouch’s UTC timeframe rules, including the first-day-of-month exception — see Billing and reports.
Periods accepted by cloudpouch_refresh_cost_data
Section titled “Periods accepted by cloudpouch_refresh_cost_data”Current month, Previous month, Last six months, Year.
What a refresh costs
Section titled “What a refresh costs”cloudpouch_refresh_cost_data goes through the same single-flight Cost Explorer queue the Billing view uses. An unforced repeat serves cache and never pays AWS twice. A forced refresh queries Cost Explorer and is billed by AWS per request, like any other Cost Explorer query, up to three requests per call. A forced refresh is not free.
Scan status is reported honestly
Section titled “Scan status is reported honestly”If CloudPouch reloads mid-scan, cloudpouch_get_scan_status reports renderer-lost and reconciles against saved History rather than leaving your assistant polling. It never reports a stale “running”.
Errors the action tools return
Section titled “Errors the action tools return”Instead of blocking, the action tools answer with a structured error and an instruction.
| Condition | Error |
|---|---|
| A scan is already running, including one you started in CloudPouch | ALREADY_RUNNING |
| Called against the Organizations view | UNSUPPORTED_SCOPE |
| Unknown profile | NOT_FOUND |
| CloudPouch window closed, or sitting on the Login screen | RENDERER_UNAVAILABLE, with an instruction such as “open CloudPouch and sign in” |
| No activated plan | NOT_ACTIVATED |
How Free and Pro apply
Section titled “How Free and Pro apply”- Gating is per tool, not per group.
- The three action tools are not Pro-gated. They work on every activated plan, Free included, in parity with the in-app buttons. A session with no activated plan gets
NOT_ACTIVATED, deliberately not an upgrade message. - A Free caller of a Pro-only tool receives an explicit upgrade message, never a bare refusal.
- MCP is governed by the same internal boundary that governs the CloudPouch interface, so an assistant on Free cannot read detail that the Free interface hides.
- On Free,
cloudpouch_get_savings_summarycalled with an explicitanalysisRunIdanswers with the upgrade message. Called without one, it serves the newest run at summary level.