Skip to content

Connect Claude or Cursor to your cloud costs

The GetFinOps MCP server puts your cost, findings, remediation and verified-savings data directly in your AI assistant — so instead of exporting a CSV and pasting it into a chat, you just ask.

It can also act, through the same approval workflow a person uses, with the same role checks and safety policy, and automatic rollback of reversible changes. With a default token an assistant can only read. With the write scope it can request a fix, and it can approve one only if its token also has the admin or owner role (details below).


What you can ask

  • "What changed in my AWS spend this week, and which account drove it?"
  • "Show me high-severity findings we haven't triaged yet."
  • "How much have we actually saved — verified, not projected."
  • "What did that stop-instance remediation actually do?"

Because the tools return your live data rather than a snapshot, the answers stay current.


1. Create an API token

The quickest path is the dashboard's MCP page (Setup → MCP). An owner creates a read-only token there, copies a ready-made config for their client, and tests the connection before leaving the page. Anyone else can paste a token an owner gave them. Tokens can also be created in Settings → API Tokens, or via the API:

curl -X POST https://<your-workspace>.app.getfinops.cloud/api/tokens \
  -H "authorization: Bearer <your-JWT>" \
  -H "content-type: application/json" \
  -d '{"name":"Cursor laptop","scopes":["read"]}'

The response contains the token once. Store it like a password — only a hash is kept server-side, so it cannot be shown again. You can revoke it at any time.

Start read-only

scopes: ["read"] is the default and is all you need to ask questions. Add "write" only when you want the assistant to raise remediation requests or start scans. A write-scoped token with the admin role can also approve requests, which runs the fix.


2. Point your client at it

Claude Desktop's config file starts local servers, so the remote endpoint is reached through the mcp-remote bridge (requires Node.js). The token goes in env rather than args, because some clients split arguments on spaces.

{
  "mcpServers": {
    "getfinops": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://<your-workspace>.app.getfinops.cloud/api/mcp",
               "--header", "Authorization:${AUTH_HEADER}"],
      "env": { "AUTH_HEADER": "Bearer gfm_<id>.<secret>" }
    }
  }
}
claude mcp add --transport http getfinops \
  https://<your-workspace>.app.getfinops.cloud/api/mcp \
  --header "authorization: Bearer gfm_<id>.<secret>"
{
  "mcpServers": {
    "getfinops": {
      "url": "https://<your-workspace>.app.getfinops.cloud/api/mcp",
      "headers": { "authorization": "Bearer gfm_<id>.<secret>" }
    }
  }
}

Restart the client and the GetFinOps tools appear.


3. What the tools do

Read — available to any token:

Tool Answers
get_cost_trend Cost over time. Date range, unblended vs amortized, daily or monthly, per cloud account. Tax, credits and refunds excluded by default.
get_cost_by_account Month-to-date spend split across your connected accounts.
list_findings Cost, security and tag-governance findings with their triage status.
list_executions What was actually changed in your cloud — per-stage detail, before/after state, rollbacks.
get_savings_summary Verified realized savings, re-measured after execution. Not estimates.
list_approvals The remediation queue. Any token can read it; approving needs an admin-role token.
list_cloud_accounts Your connected cloud accounts and their environment labels — the ids the other tools accept as cloudAccountId.
get_run_status The latest scan and how each account fared: completed, partial or failed, and how many records it contributed.
get_plan The remediation plan: which findings are auto-safe, which need approval, which are not allowed — and why.
get_execution_status The outcome of a remediation.
get_llm_usage_summary What GetFinOps' own AI features cost this month and last, by model and by source. Our records at list prices, not your provider's invoice.
get_llm_usage_by_model Requests, tokens and cost per model.
get_llm_usage_by_agent Cost per AI feature (for example the SRE narrative), per run.
get_llm_usage_timeseries AI cost by day, week or month.
list_llm_calls Every individual AI call: tokens, cost, whether the output was cut off, and the provider's request id.

Write — only with the write scope:

Tool Behaviour
create_approval Requests a remediation. Creates a pending approval; executes nothing. Appears in your queue and Slack exactly like one raised by a person.
decide_approval Approves or denies. Approving runs the remediation — and requires an admin token on a paid plan or an active trial. Approving a destructive action or disable_block_public_access also requires confirm: true (see below).
trigger_scan Starts a fresh scan. The scan itself changes nothing in your cloud, but if you have turned automatic execution on, the action types you graduated to automatic run at the end of it, as they do after the daily scan. It also costs money (Cost Explorer requests and AI calls), and the daily scheduled scan usually makes it unnecessary.

Why this is safe to give an agent

The write tools do not have a private back door into your cloud. They call the same internal endpoints the dashboard calls, so every existing control still applies:

  • Approving is admin-only. A default token is read-only and can neither raise nor approve a request. A write-scoped token can raise one, and can approve it only if it also has the admin or owner role.
  • Destructive actions need explicit confirmation. Approving delete_volume, delete_snapshot, delete_instance, terminate_instance, delete_database, delete_bucket, resize_db, restrict_sg or disable_block_public_access (which removes S3 Block Public Access) is refused unless the call passes confirm: true, and so is a decide_approval call whose approval cannot be read. Either way it's refused before anything is touched. A token calling the REST endpoints directly gets the same rule: approving one of these actions through POST /api/automation/approvals/:id/decide, or running one through the safety override POST /api/safety/override, answers 400 confirm_required without confirm: true.
  • Your safety policy still governs. Production-account blocks, action allow-lists, spend ceilings and blast-radius limits are unchanged.
  • Rollback still happens. If the post-execution check fails, a reversible change is automatically reverted. A deletion cannot be undone.
  • Everything is attributed. MCP-driven actions are recorded as mcp:<user> in the audit trail, so you can always see what an assistant did versus a person.
  • Scoped to one workspace. A token only ever reaches the workspace it was created in.

The honest summary: an assistant can investigate freely and propose changes; the decision to apply one stays with a human, unless you deliberately grant a token the rights to do more.


Revoking access

Delete the token — in the dashboard, or:

curl -X DELETE https://<your-workspace>.app.getfinops.cloud/api/tokens/<token-id> \
  -H "authorization: Bearer <your-JWT>"

It stops working on the next request. Tokens can also be given an expiry when created.


Where to go next


See your own numbers →