Ask Claude about your cloud costs, then request the fix

The server exposes 18 tools. The cost trend, findings and plan tools can be limited to one connected cloud account.

• Cost: get_cost_trend (date range, unblended or amortized, daily or monthly, with tax and credits excluded by default) and get_cost_by_account.
• Findings and scans: list_findings, which says when the scan ran; get_run_status, which reports for each account whether collection completed, was partial or failed, and how many records it returned; and list_cloud_accounts.
• Plan and remediation: get_plan, which sorts actions into safe to run automatically, needs approval and disallowed; list_approvals; list_executions and get_execution_status, with before and after resource state and any rollback; and get_savings_summary, for savings re-checked after a change rather than estimates.
• LLM usage: get_llm_usage_summary, get_llm_usage_by_model, get_llm_usage_by_agent, get_llm_usage_timeseries and list_llm_calls.
• Write: create_approval, decide_approval and trigger_scan.

create_approval only raises a request. It takes the action type and target resource, and optionally the originating finding, an estimated monthly saving and a cloud account. The request lands in the same approval queue as one raised in the app and shows in the notification bell, and where Slack is connected it posts an approval card. When a finding is given, the target account is taken from that finding, not from the caller.

decide_approval with “approved” runs the full execution pipeline: guardrails, including the spend ceiling, the change in your AWS account, the post-check and automatic rollback for reversible actions. It needs an admin-role token and a paid plan or active trial. Denying works on any plan.

Before an approved change runs, the plan stage checks it again: an action outside the supported list is refused, and the account’s safety policy, including the production block, and your guardrails apply.

When a route refuses a call, the tool passes on the refusal and its reason, such as a missing role, a plan limit or a blocked execution. A token without the write scope is refused before any route is called. trigger_scan starts a scan and returns at once, and get_run_status reports its progress.

The server accepts a machine token (gfm_…) or a signed-in user’s session. A token belongs to one workspace, and every result is limited to that workspace.

• Only owners can create, list or revoke tokens, and only from a signed-in session.
• The secret is shown once. GetFinOps stores only its SHA-256 hash and records when each token was last used.
• Scopes are read, the default, and write. A read-scoped token can use only the read tools, and outside MCP it can only make read (GET) requests to the API. A token also carries a role, member by default.
• Tokens can have an expiry date. Expired or revoked tokens are refused, and repeated failed attempts are rate-limited.
• Actions taken through MCP are recorded in the audit trail as “mcp:” followed by the token creator’s email or the token’s name.

The endpoint is POST /api/mcp on your workspace’s address, using the MCP streamable HTTP transport. It keeps no session: each request carries its own token.

Setup → MCP walks you through it. An owner creates a token with the read scope, and the page fills it into a config for Claude Code, Claude Desktop or Cursor. Test connection runs the MCP initialize and tools/list calls and shows how many tools loaded. The token is held only in the page’s memory, never in browser storage.

• It does not skip approvals or guardrails, and it has no tools for changing autonomy or safety settings.
• It does not make changes in GCP. Remediation runs in AWS only.
• It does not create or revoke tokens.
• It does not provide MCP resources or prompts, only tools.
• It does not include a local server to install. It is a remote HTTP endpoint.