Return active (unacknowledged) cost anomalies detected from historical baselines.

Args: provider: Filter to a specific provider. None = all. severity: "high", "medium", or "low". None = all severities. limit: Max anomalies to return (default 20). account: Named AWS account from accounts.yaml to filter results.

Examples: - "Are there any cost anomalies I should know about?" - "Show me high-severity cost spikes" - "What spiked in AWS this week?" - "Any anomalies in the production account?"

Note: Anomalies require at least 7 days of snapshot history. Run 'finops snapshot' or wait for the daily job to accumulate data.

Mark an anomaly as acknowledged (dismissed). It will no longer appear in active anomalies.

Args: anomaly_id: The ID from get_anomalies().

Examples: - "Dismiss anomaly 42, it was a planned migration" - "Acknowledge that spike, it was expected"

Detect accounts with unusual spend changes versus their prior period. Returns accounts that significantly spiked or dropped in cost. Requires a Pro plan (org_reports).

Args: days_back: Look-back period to compare (default 30 vs prior 30)

Examples: - "Which accounts had unusual spend changes?" - "Are any accounts spiking this month?" - "Show me account-level anomalies"

Return cloud costs broken down by engineering team, using tag attribution rules.

Requires:

• Tag rules configured in ~/.finops/tag_rules.yaml (run 'uvx nable' → tags)

• Cloud providers that support tag-based cost grouping (AWS, Azure, GCP)

Args: start_date: ISO date. Defaults to 30 days ago. end_date: ISO date. Defaults to today. provider: Filter to a specific provider.

Examples: - "How much is the data team spending?" - "Show me cloud costs by team this month" - "Which team has the highest AWS bill?"

Fetch tagged cost data from AWS/Azure/GCP and store team attributions. Run this after setting up tag_rules.yaml to populate team cost data.

Args: start_date: ISO date. Defaults to 30 days ago. end_date: ISO date. Defaults to today.

Examples: - "Run tag attribution now" - "Update team cost data"

FinOps efficiency scorecard, a 0–100 score with letter grade across 5 dimensions: compute efficiency, waste reduction, commitment coverage, tag hygiene, and anomaly response. Tracked over time so you can see if you're improving.

Scope options:

• "overall" , everything combined (default)

• team=platform , filter by team tag

• environment=prod , filter by environment tag

• provider=aws , single provider view

Examples: - "What's our FinOps score?" - "Show me the efficiency scorecard for the platform team" - "How is our AWS efficiency rated?" - "What's our worst performing dimension?" - "Are we improving or getting worse on cloud efficiency?" Args: scope: "org" (default) or "team" for a single team's scorecard. team: Team name from your attribution tags, when scope="team". environment: Limit to one environment (e.g. "prod"). provider: Limit to one provider (e.g. "aws"). None = all.

Aggregate Kubernetes costs by any pod label across all namespaces. Great for chargeback: see spend by team, environment, app, or any label.

Workloads without the label are grouped under 'untagged'. If tagging coverage is low, the response includes a warning with the tagged %.

Common label_key values: team, env, environment, app, component, tier, app.kubernetes.io/name, app.kubernetes.io/part-of

Examples: - "Show me Kubernetes costs by team" - "Which team is spending the most on Kubernetes?" - "Break down K8s costs by environment" - "How much is the payments team spending in the cluster?" - "Show K8s cost by app label" - "What percentage of our cluster is untagged?" Args: label_key: Kubernetes label key to group costs by (e.g. "app", "team"). context: Kubernetes context name from list_kubernetes_contexts(). Default context when omitted.

Break costs down by AWS Organizational Unit (OU). When OUs map to departments or teams, this gives you a clean chargeback report. Requires a Pro plan (org_reports).

Args: days_back: Look-back period in days (default 30)

Examples: - "Break down costs by business unit" - "Show OU-level cost breakdown" - "How much is each department spending in AWS?"

Scan Terraform state for resources missing required tags. Runs terraform show -json in tf_dir (or reads state_path directly). Required tags configured via FINOPS_REQUIRED_TAGS env var (comma-separated, default: team,environment,service).

Args: tf_dir: Path to the Terraform working directory (must be initialized). state_path: Optional path to a .tfstate file. Skips terraform CLI if provided.

Examples: - "Audit tags in our infra repo" - "Which resources are missing the team tag?"

Generate HCL patches for all open tag violations in tf_dir. Shows a unified diff per .tf file, does NOT write to disk. Run audit_terraform_tags first to populate violations.

Args: tf_dir: Same directory passed to audit_terraform_tags.

Examples: - "Show me the tag fixes needed" - "What HCL changes are required to fix our tagging?"

Apply tag fixes to .tf files and open a GitHub PR. Requires GITHUB_TOKEN env var and a git remote configured for github_repo.

Args: tf_dir: Path to the Terraform working directory (must be a git repo). github_repo: GitHub repo in "owner/repo" format. branch: Branch name to create. Defaults to "fix/add-required-tags". base_branch: Target branch for the PR. Defaults to "main". pr_title: PR title.

Examples: - "Open a PR to fix the tagging gaps" - "Create the tag fix PR against main"

The nable agent team: Budget Guard, Savings Analyst, and the Ledger, with each agent's status on this install and the one step that finishes its setup.

Budget Guard gates agent actions (cost + budget + policy + your approval history). Savings Analyst judges genuine savings on your real rates and drafts the fix as a PR. The Ledger records decisions, verifies savings landed, and teaches the other two. All propose-only.

Call this when the user asks about nable's agents, "set up the agent team", "is the budget guard on?", "why isn't nable learning?", or after activating a license, so they see what just unlocked and what to do next.

Examples: - "Show me the agent team" - "Set up nable's agents" - "Is the budget guard active?"

Break down AWS network/data-transfer spend: how much, and where it goes.

Splits your traffic cost into INTERNAL (cross-AZ, cross-region, NAT, VPC peering, private endpoints) vs EXTERNAL (internet egress, CDN), then a per-scope breakdown and a ranked solve playbook (VPC endpoints, topology-aware routing, CDN, peering). Pulls Cost Explorer grouped by usage type; the classifier keeps only the network line items. AWS today; GCP and Azure decomposition are on the roadmap.

Args: days: Look-back window in days (default 30).

Examples: - "How much are we spending on network traffic and where is it going?" - "What's our internal vs external data transfer cost?" - "Break down our cross-AZ and egress spend"

Identify significant data transfer cost line items from AWS Cost Explorer.

Surfaces internet egress, cross-AZ transfer, inter-region transfer, and NAT Gateway data charges. Each finding includes a specific cost-reduction recommendation (VPC endpoints, CloudFront, regional consolidation).

Args: start_date: ISO date (YYYY-MM-DD). Defaults to 30 days ago. end_date: ISO date. Defaults to today. threshold_usd: Only return usage types costing more than this (default $50).

Examples: - "What are our data transfer costs?" - "How much are we paying for inter-region traffic?" - "Which data transfer charges are most expensive?" - "Are we overpaying for NAT Gateway data transfer?"

Connect an AWS account from inside your MCP client, no terminal needed.

Propose-then-confirm and local-only. It reads AWS credentials that already exist on this machine (named profiles, environment, the default chain), verifies each against STS, and connects the one you choose. It never creates, modifies, or deletes anything in your AWS account, and credentials stay on this machine.

Call it with no arguments first to see which accounts are available (nothing is stored). Then call it again with account_id set to the one to connect.

Examples: - "Connect my AWS account" - "Use the credentials on this machine to connect AWS" - "I want to see my real costs, not the sample data"

Args: account_id: The 12-digit account to connect, from the candidate list a no-argument call returns. Omit to just list what's available.

Manually trigger a cost snapshot right now (fetches yesterday's costs from all providers). Normally this runs automatically at 01:00 UTC daily.

Examples: - "Take a cost snapshot now" - "Update the cost history with today's data"

Analyze EC2 instances with low CPU utilization over the past 14 days and return rightsizing recommendations with projected monthly savings.

Args: avg_cpu_threshold: Flag instances with average CPU below this % (default 20%) max_cpu_threshold: Flag instances whose peak CPU never exceeded this % (default 50%)

Examples: - "Which EC2 instances are over-provisioned?" - "How much could we save by rightsizing?" - "Find underutilized instances we should downsize"

Deep CloudWatch analysis for a specific EC2 instance. Returns CPU, network, and disk utilization percentiles, a rightsizing recommendation, and the Compute Optimizer recommendation if available.

Args: instance_id: EC2 instance ID (e.g. "i-0abc1234567890def") region: AWS region (default: us-east-1) lookback_days: Days of metrics to analyze (default: 14, max: 63)

Examples: - "Is i-0abc1234 over-provisioned?" - "Show CPU trends for i-0abc1234 over the last 30 days"

Detect ALBs, NLBs, and Classic ELBs with near-zero traffic over the past 14 days.

Idle load balancers still incur hourly LCU base charges. ALB/NLB cost ~$5.84/mo minimum; Classic ELBs cost ~$18.25/mo minimum.

Args: regions: AWS regions to scan. Defaults to all opted-in regions. request_threshold: Max requests in 14 days to flag as idle (default 100).

Examples: - "Find idle load balancers we can delete" - "Which ALBs have no traffic?" - "Are there any unused load balancers costing us money?"

Scan for idle/wasted AWS resources that are costing money but doing nothing.

Finds: unattached EBS volumes, unused Elastic IPs, old snapshots with no AMI dependency, stopped EC2 instances (still paying for EBS), load balancers with no healthy targets. That is the full scope: this tool does not look at RDS, DocumentDB, Kendra, or Textract, so a small or zero total here is not a clean bill of health for the account, only for these five resource types. Use get_idle_rds_instances, get_documentdb_costs, audit_textract_environment_waste, or run_full_cost_audit for those.

Results are sorted by monthly waste descending. Protected resources (tagged env=prod, protected=true, etc.) are flagged but never acted on.

Examples: - "Find idle resources wasting money in AWS" - "List any unattached EBS volumes older than 90 days" - "What stopped EC2 instances are we still paying for?" Args: resource_types: Subset to scan, e.g. ["ebs", "eip", "nat"]. All types when omitted. regions: AWS regions to scan. Defaults to all enabled regions. min_idle_days: Only report resources idle at least this many days.

Delete or release idle AWS resources. This is a REAL ACTION that terminates EC2 instances, releases EBS volumes, and frees Elastic IPs. Always runs in dry_run=True mode first so you can review what will be deleted. Requires explicit confirmation before setting dry_run=False.

Requires FINOPS_CLEANUP_ENABLED=true in the environment (opt-in safety gate). Every action is written to ~/.finops-mcp/cleanup_audit.jsonl for audit.

dry_run=True (default): shows what WOULD be deleted, nothing is changed. dry_run=False: actually deletes. Only set this after explicit user confirmation.

Examples: - "Clean up idle EC2 instances and unattached EBS volumes" - "Show me what I can safely delete to save money" - "Terminate the stopped instances that have been idle for 2 weeks" - "Show me what would happen if I cleaned up unattached EBS volumes" - "Delete the EBS volumes we just listed" (then confirm: dry_run=False) - "Clean up all unused Elastic IPs in us-east-1" Args: resource_ids: Explicit resource ids to act on. Required unless scanning by type. resource_types: Idle resource types to include, e.g. ["ebs", "eip"]. regions: AWS regions to scan. Defaults to all enabled regions. min_idle_days: Only include resources idle at least this many days. dry_run: True (default) previews actions without executing anything.

Apply rightsizing recommendations to Terraform source, optionally opening a GitHub PR.

nable reads your Terraform state (terraform.tfstate or terraform show -json) to automatically resolve AWS instance IDs to their Terraform resource addresses. No manual mapping needed as long as your tf_dir has state available.

Resolution order:

1. Terraform state (automatic, reads instance IDs from state)

2. resource_overrides (manual fallback if state is unavailable)

3. recommended_config stored in DB

Modes: dry_run=True Show diffs only. Nothing written to disk. patch_only=True Write .tf files locally. No git, no PR. Use your own workflow. default Write files, commit to a branch, push, open GitHub PR.

After merging and running terraform apply, nable auto-verifies savings by checking AWS and updates the recommendation to "verified".

Args: tf_dir: Path to the Terraform working directory. github_repo: "owner/repo" for GitHub PR. Not needed for dry_run or patch_only. recommendation_ids: Specific rec IDs to act on. Omit to process all open rightsizing recs. resource_overrides: Manual fallback if state resolution fails. Format: [{"recommendation_id": 42, "tf_resource_type": "aws_instance", "tf_resource_name": "api_server"}, ...] branch: Branch to create. Defaults to "fix/rightsizing". base_branch: PR target branch. Defaults to "main". pr_title: PR title. Auto-generated from saving amount if omitted. dry_run: Show diffs without writing files or creating the PR. patch_only: Patch files locally, skip git and GitHub.

Examples: - "Show me what the rightsizing changes would look like" - "Apply the rightsizing fixes to my Terraform repo" - "Open a rightsizing PR against acme/infra" - "Patch the Terraform files but don't create a PR, I'll handle the git flow"

Scan for cloud cost waste patterns using nable's proprietary pattern library.

Runs 13 waste fingerprints across compute, storage, database, network, AI, and governance categories. Each finding includes confidence score, monthly waste estimate, and specific remediation steps.

Args: account_id: AWS account ID to scan. Auto-discovered from the connected AWS account when omitted. min_monthly_waste: only return findings above this monthly USD threshold categories: comma-separated filter e.g. "compute,storage" (omit for all)

Returns structured findings sorted by monthly waste descending, with total_monthly_waste and total_annual_waste summary. Examples: - "Scan for waste patterns" - "Any recurring waste in this account?"

Find places where you're paying for the same capability through two different services or providers at once, the kind of waste a plain cost breakdown never surfaces because every line item looks legitimate on its own. Covers three patterns: multiple LLM inference paths active at the same time (e.g. AWS Bedrock Claude AND a direct Anthropic API key), multiple managed search/retrieval services (Kendra + OpenSearch), and two data platforms at once (Databricks + Snowflake).

This is a "worth a look" flag, not a claim that anything is wasted: running two providers on purpose (failover, per-team routing) is a real pattern too. Every finding tells you exactly how to confirm it yourself.

Use this when: - User asks what redundant or duplicate spend they have - User connects multiple LLM providers and wants a sanity check - User wants a second pass beyond idle-resource / rightsizing checks

Args: days: Lookback window in days (default 30).

Examples: - "Are we paying for the same thing twice?" - "Do I have duplicate or redundant cloud spend?" - "Am I running two LLM providers by accident?" - "Do I need both Databricks and Snowflake?"

Finds non-production EC2 instances (dev/staging/test) running 24/7. Scheduling to business hours only saves 60-70% on compute costs.

Args: regions: AWS regions to scan. Defaults to all opted-in regions. max_results: Max instances to return (default 50).

Examples: - "Find non-prod instances we could schedule to save money" - "How much could we save by scheduling non-production environments?"

Guide connecting Azure while keeping the service-principal secret off the model.

Azure has no local credentials nable can safely auto-detect, so connecting needs a client secret. Unlike connect_aws and connect_gcp (which read credentials already on the machine, so nothing sensitive passes through this conversation), an Azure secret would have to be pasted into the chat to reach a tool argument, which routes it through the model provider. nable does not do that. This tool returns the Cloud Shell script and has you finish the connect in your OWN terminal with finops setup azure, which encrypts the secret into your local vault. The model never sees the secret.

Examples: - "Connect Azure" - "How do I connect my Azure subscription?"

Create or update a spending budget. Budgets fire Slack alerts when spend crosses alert_at_pct, and fail CI checks when it crosses block_at_pct.

Args: name: Budget name (e.g. "Platform Team Monthly") limit_usd: Spending limit in USD scope_type: What to watch, "total", "provider", "team", "service" scope_value: The specific value (e.g. "aws", "platform", "EC2") Use "*" for total account budget period: "monthly" or "weekly" alert_at_pct: Send warning alert at this % of limit (default 80) block_at_pct: Fail CI gate at this % of limit (default 100)

Examples: - "Set a $50,000 monthly budget for AWS" - "Create a $15,000 monthly budget for the platform team" - "Set a $20,000 budget for EC2 with warnings at 75%" - "Add a total monthly budget of $100,000"

Check current spend against budgets. Shows how much has been spent, what's remaining, and whether any budgets are in warning or exceeded status.

Args: budget_name: Filter to a specific budget name (optional, shows all if empty)

Examples: - "Check all budgets" - "How are we doing against budget?" - "Is the platform team over budget?" - "Show budget status for AWS"

List all configured budgets with their limits and scopes.

Examples: - "What budgets do we have?" - "Show me all spending limits" - "List configured budgets"

Delete (deactivate) a budget by ID so it stops alerting and gating agent actions.

Args: budget_id: Budget ID from list_budgets

Examples: - "Delete budget #3" - "Remove the platform team budget"

Import budgets from a budget.yml file. Idempotent, running twice is safe. Use this to version-control your spending limits alongside your infrastructure code.

budget.yml format: budgets: - name: Platform Team Monthly scope_type: team scope_value: platform period: monthly limit_usd: 15000 alert_at_pct: 80 block_at_pct: 100

Args: yaml_path: Path to the budget.yml file

Examples: - "Load budgets from ./budget.yml" - "Sync budgets from /path/to/budget.yml" - "Import the budget configuration file"

Analyze Reserved Instance and Savings Plan coverage, utilization, and waste. Coverage %, utilization, and waste figures are free. Purchase recommendations with $ amounts require a Pro plan (commitment_recommendations).

Examples: - "How well are we using our Reserved Instances?" - "Should we buy more Savings Plans?" - "How much are we wasting on unused RIs?" - "What's our RI/SP coverage?"

Estimate RI/SP commitment coverage for a specific tag slice, even when tagging is incomplete.

At 70% tag coverage we measure the tagged resources directly via Cost Explorer, then solve algebraically for the untagged 30% using account totals, producing a full-domain estimate with confidence rating.

Args: tag_key: Tag key to filter on (e.g. "domain", "team", "service") tag_value: Tag value (e.g. "payments", "platform", "checkout-api") tag_coverage_pct: How complete the tagging is for this domain (0–100). If unknown, leave at 100 and interpret results as lower bounds only.

Examples: - "What's the RI coverage for the payments domain? Tags are about 70% complete" - "How covered is team=platform under Savings Plans?" - "Estimate commitment coverage for env=prod with 85% tag coverage"

Identify wasted Reserved Instance spend from CUR RIFee line items.

Shows which reservations have low utilization and how much money is being wasted on unused reserved capacity. Requires CUR via Athena. Pro plan feature.

Args: start_date: ISO date (YYYY-MM-DD). Defaults to 30 days ago. end_date: ISO date. Defaults to today. min_waste_usd: Minimum wasted dollars to include a reservation (default $10).

Examples: - "Which Reserved Instances are underutilized?" - "How much are we wasting on unused RIs?" - "Show RI waste for this quarter"

Show exactly how much each team saved from Savings Plans and Reserved Instances.

This is the showback problem no other tool solves at line-item granularity. Instead of blending SP/RI discounts across the account, nable attributes the real dollar benefit back to the team or service that consumed the covered usage, using CUR fields that Cost Explorer doesn't expose.

For each team (or tag value): • effective_cost , what they actually paid under SP/RI rates • on_demand_equiv , what they would have paid without commitments • savings_captured , real dollar benefit from Savings Plans + RIs • discount_rate_pct , their effective discount rate • sp_savings / ri_savings, broken out by commitment type

Requires CUR delivery to S3 and Athena. Pro plan feature.

Args: tag_key: Resource tag to group by, "team", "project", "env" (default "team") start_date: ISO date YYYY-MM-DD (default: start of current month) end_date: ISO date YYYY-MM-DD (default: today) include_ri: Include Reserved Instance savings alongside SP savings (default True)

Examples: - "Show me savings plan showback by team this month" - "How much did the payments team save from our savings plans?" - "What's the effective discount rate per team from our commitments?" - "Which team is getting the most benefit from our reserved instances?"

Recommends AWS Database Savings Plans for RDS and Aurora spend. Database SPs (re:Invent 2025) offer up to 45% savings, separate from Compute SPs. Sizes a 1-year no-upfront plan to uncovered baseline spend.

Examples: - "Should we buy Database Savings Plans?" - "How much could we save on RDS with a Database SP?" - "What is our RDS/Aurora Savings Plan coverage?"

Get total spend summarized by service, account, and region.

Args: provider: Provider name (e.g. "aws", "datadog"). None = all. category: "cloud" or "saas". None = all. start_date: ISO date (YYYY-MM-DD). Defaults to 30 days ago. end_date: ISO date. Defaults to today. granularity: "DAILY" or "MONTHLY". account: Named AWS account from accounts.yaml. Uses default when omitted.

Examples: - "How much did we spend last month?" - "Give me an AWS cost summary for January" - "What did the production account spend this month?"

Cost breakdown by service, optionally filtered to a keyword.

Args: service_filter: Case-insensitive substring (e.g. "compute", "storage"). provider: Specific provider. None = all. category: "cloud" or "saas". None = all. start_date: ISO date. Defaults to 30 days ago. end_date: ISO date. Defaults to today. account: Named AWS account from accounts.yaml.

Examples: - "How much did compute cost us?" - "Show me all Datadog product costs" - "What did the staging account spend on EC2?"

Return the top N most expensive services across all configured providers.

Args: limit: Number of top services to return (default 10). provider: Specific provider. None = all. category: "cloud" or "saas". None = all. start_date: ISO date. Defaults to 30 days ago. end_date: ISO date. Defaults to today. account: Named AWS account from accounts.yaml.

Examples: - "What are our biggest cost drivers this month?" - "Top 5 most expensive things in AWS" - "Top cost drivers in the staging account"

Cost trends over time broken down by day or month.

Args: provider: Specific provider. None = all. category: "cloud" or "saas". None = all. days: Look-back window in days (default 30). granularity: "DAILY" or "MONTHLY".

Examples: - "Is our AWS spend trending up or down?" - "Show daily cloud costs for the last 2 weeks" - "What did we spend each month this quarter?"

Fan out cost queries across ALL configured AWS accounts and return a combined view sorted by total spend. Shows each account's total and top services.

Args: start_date: ISO date (YYYY-MM-DD). Defaults to 30 days ago. end_date: ISO date. Defaults to today. granularity: "DAILY" or "MONTHLY".

Examples: - "Show costs across all my AWS accounts" - "What is each client account spending this month?" - "Compare spend across production and staging accounts"

Dedicated summary of all SaaS tool spending (Datadog, Snowflake, GitHub, etc.). Useful for understanding your software vendor bill separate from cloud infrastructure.

Examples: - "How much are we spending on SaaS tools?" - "What's our total software vendor spend?" - "Break down our SaaS costs by tool" Args: start_date: ISO date (YYYY-MM-DD). Defaults to 30 days ago. end_date: ISO date (YYYY-MM-DD). Defaults to today.

Grand total across ALL connected sources, cloud infrastructure + SaaS tools combined. The true "total technology spend" number.

Examples: - "What is our total tech spend this month?" - "How much are we spending on everything combined?" - "Give me our full cloud + software cost picture" Args: start_date: ISO date (YYYY-MM-DD). Defaults to 30 days ago. end_date: ISO date (YYYY-MM-DD). Defaults to today.

Return historical daily cost data for a specific provider + service. Used for trend analysis and understanding anomaly context.

Args: provider: e.g. "aws" service: e.g. "Amazon EC2" account_id: The account/subscription ID days: Look-back window in days (default 30)

Examples: - "Show me 30 days of history for AWS EC2" - "What did Datadog cost each day this month?"

Auto-detect the account's effective private rates by comparing actual billed amounts against public on-demand prices.

Captures EDP discounts, MOSA/negotiated rates, and private pricing automatically from Cost Explorer or CUR, no manual input needed.

Used internally by the commitment optimizer and PR cost estimator. Useful for understanding how large your negotiated discount actually is.

Examples: - "What's our effective AWS discount?" - "Do we have private pricing on AWS?" - "How does our actual rate compare to on-demand list prices?"

Detailed Kubernetes workload cost breakdown with efficiency grades. Supports filtering by namespace and workload kind, sorting by cost or waste.

Args: namespace: Filter to a specific namespace (e.g. "production") kind: Filter by workload type: Deployment, StatefulSet, DaemonSet, Job sort_by: "cost" (default) | "waste" | "efficiency" (worst first) context: Kubeconfig context (default: current context) limit: Max workloads returned (default 50)

Each workload includes: cost, waste, CPU/memory requests vs actual usage, efficiency grade (A-F), and pod labels for attribution.

Examples: - "Show me all workload costs in the production namespace" - "Which Deployments are wasting the most money?" - "Show me StatefulSet costs sorted by waste" - "What are the least efficient workloads in the cluster?" - "List all DaemonSet costs" - "Show me every workload cost sorted by efficiency"

Show the highest-spending AWS accounts in the organization. Requires a Pro plan (org_reports).

Args: limit: Number of top accounts to return (default 10) days_back: Look-back period in days (default 30)

Examples: - "Which 5 accounts are spending the most?" - "Show top spending accounts this month" - "Which teams are the biggest AWS spenders?"

Show the current storage backend (SQLite local or Postgres shared). Helps teams understand whether they're in single-engineer or shared mode.

Examples: - "What database is nable using?" - "Are we in shared mode?" - "Show storage configuration"

Track AWS promotional-credit (Activate) burn-down and detect the moment billing flips from credits to cash, the cliff where an early startup first feels cost pain. AWS sends no native alert for this.

Reads Cost Explorer's RECORD_TYPE (Charge type) to separate gross usage, credits applied, and net cash per month. No CUR/Athena setup needed. AWS has no API for the remaining Activate balance, so runway is inferred from the observed monthly credit-consumption trend, not a stated balance.

Args: months: Months of history to analyze (default 6).

Examples: - "Are my AWS credits about to run out?" - "When do my credits flip to cash?" - "How much of my bill is still covered by credits?"

Compare this account's spend profile against anonymised peer group medians.

Shows where you're above or below the median for companies in your industry vertical across metrics like: EC2%, RDS%, savings plan coverage, idle resource %, LLM spend %, data transfer %, and rightsizing opportunity %.

Args: account_id: AWS account ID to analyse. Auto-discovered from the connected AWS account when omitted. vertical: industry peer group, saas, ecommerce, fintech, media, ai_ml, default days: lookback period for metric calculation

Returns per-metric comparisons with assessments (better/similar/worse) and insights. Examples: - "How does our cloud spend compare to similar companies?" - "Benchmark our costs"

Estimate the monthly AWS cost change from a Terraform plan BEFORE applying it.

Provide one of:

• plan_json: raw JSON string from terraform show -json plan.tfplan

• plan_file: path to a saved plan JSON file

• tf_dir: directory to run terraform plan in automatically

Returns a cost delta breakdown per resource with adds, changes, and removes. Prices: AWS on-demand us-east-1. Supports EC2, RDS, Aurora, ElastiCache, EKS, NAT Gateways, ALB/NLB, ECS Fargate, Lambda, EBS, OpenSearch, MSK, Redshift. Args: plan_json: Terraform plan JSON string (terraform show -json). plan_file: Path to a terraform plan JSON file. tf_dir: Terraform directory to plan and price.

Examples: - "What will this terraform plan cost?" - "Price the plan in ./infra"

Cost preflight for a proposed change: what it costs and whether it fits budget.

Agent-native. Call this BEFORE applying an infrastructure change to get a machine verdict (ok / warn / over_budget / no_budget) plus the monthly and annual cost delta and the budget headroom. Read-only: it estimates and checks, it never applies anything.

Describe the change one of these ways:

• terraform_plan_json / terraform_plan_file / tf_dir : a Terraform plan

• helm_diff : output of helm diff upgrade or a values.yaml diff

• monthly_delta_usd : a known monthly cost delta (escape hatch for any change the estimators don't parse, e.g. "launch a db.r6g.4xlarge")

budget_name selects which budget to check against; default is the first active budget. With no budget configured the verdict is "no_budget" and the cost delta is still returned.

Good triggers: "will this fit my budget", "what will this terraform/helm change cost before I apply it", "cost preflight", "can the agent afford this change". Args: terraform_plan_json: Terraform plan JSON string to price. terraform_plan_file: Path to a terraform plan JSON file. tf_dir: Terraform directory to plan and price. helm_diff: Helm diff text to price instead of terraform. monthly_delta_usd: Known monthly delta, when you already have the number. budget_name: Budget to check the delta against.

Examples: - "What would this change cost per month?" - "Preflight the cost of this terraform plan"

Store your business metrics so nable can connect cloud costs to business outcomes.

Call this once a month (or whenever metrics change) and nable will track trends over time and answer "so what?" when your cloud spend changes.

Args: arr_usd: Annual Recurring Revenue in USD (e.g. 1_200_000 for $1.2M ARR) mrr_usd: Monthly Recurring Revenue in USD. Use this OR arr_usd, not both. mau: Monthly Active Users dau: Daily Active Users paying_customers: Number of paying customers / accounts api_calls_monthly: Your product's API calls per month (not cloud API calls) employees: Total headcount custom_metrics: Any other metric as a dict, e.g. {"free_signups": 4200, "nps": 42} notes: Free-text context, e.g. "Post Series A, hired 8 engineers" metric_date: Date these metrics apply to (YYYY-MM-DD). Defaults to today. cash_on_hand_usd: Cash in the bank, in USD. Powers runway in get_unit_economics(). last_raise_amount_usd: Size of your last round, in USD. last_raise_date: Date of your last round (YYYY-MM-DD). monthly_opex_usd: Total monthly burn including payroll, in USD. Without this, runway is reported as "infra runway" (excludes payroll); with it, nable reports true company runway.

Calling this repeatedly for the same date MERGES: fields you omit keep their prior value, so you can set revenue one call and cash the next.

Examples: - "Set our MRR to $45,000 and MAU to 1,200" - "Update business metrics: ARR $2.4M, 340 paying customers, 8,200 MAU" - "Set cash on hand to $2.4M and monthly opex to $210k"

Return stored business metrics and trend over time.

Args: history_days: How many days of history to return (default 90).

Examples: - "Show our business metrics" - "What business metrics do we have on file?" - "Show MRR and MAU history for the last 6 months"

Connect your total cloud and SaaS spend to business metrics.

Shows hosting cost as % of MRR/ARR, cost per customer, cost per MAU, cost per API call, and other ratios your finance team and investors care about.

Requires business metrics to be set with set_business_metrics() first.

Args: period_days: Cost window to use for the calculation (default 30 days).

Examples: - "What are our unit economics?" - "What's our hosting cost as a percentage of MRR?" - "How much does it cost us per customer per month?" - "What's our cost per API call?" - "Show me our infrastructure unit economics"

Explain what recent cost changes actually mean for the business.

Compares this period to the previous period across all providers, then connects the change to your business metrics to answer: is this spend increase growth-driven and healthy, or is it pure cost inflation?

Requires business metrics set with set_business_metrics().

Args: compare_days: Length of each comparison window in days (default 30). Uses this period vs the same-length period immediately before.

Examples: - "Explain our cost changes this month" - "Is our infrastructure spend healthy given our growth?" - "Why did our bill go up and does it matter?" - "What do the cost changes mean for our gross margin?" - "Are we scaling efficiently?"

Return unified cost data in FOCUS 1.2 format across all connected providers, clouds plus supported usage-based SaaS (e.g. Snowflake).

FOCUS (FinOps Open Cost and Usage Specification) is an open standard for normalizing cost data into one vendor-neutral schema. nable extends it past the clouds to the usage-based long tail, so you can query total spend across AWS, Azure, GCP, and SaaS providers in a single shape.

Args: start_date: ISO date string (YYYY-MM-DD). Defaults to 30 days ago. end_date: ISO date string (YYYY-MM-DD). Defaults to today. provider: Optional filter, e.g. "aws", "azure", "gcp", "snowflake". Omit for all. group_by: Optional grouping. One of "ServiceName", "ServiceCategory", "RegionId", "SubAccountId". Returns aggregated totals when set.

Returns: FOCUS 1.2 normalized cost records with fields: BilledCost, EffectiveCost, ServiceName, ServiceCategory, ProviderName, RegionId, SubAccountId, Tags, etc. Examples: - "Show costs in FOCUS format grouped by service category"

Slice cloud cost any way you want. This is the flexible, moldable cost query: group and filter by ANY combination of dimensions, over any date range, instead of a fixed set of canned reports. Returns both the numbers and a card describing how to chart them (which the UI can render and pin to the dashboard).

Dimensions (group by, up to 3): ServiceName, ServiceCategory, ProviderName, RegionId, RegionName, SubAccountId, SubAccountName, ResourceId, ResourceName, ResourceType, ChargeCategory, ChargeDescription, CommitmentDiscountId, CommitmentDiscountType, plus "date" (a time series, use granularity) and "Tags[]" for any tag (e.g. "Tags[team]"). For line-item detail (AWS only, needs CUR + Athena set up): "usage_type", "instance_type", "resource_id" — using any of these auto-routes the query to the CUR pushdown.

filters / exclusions: each is {dimension, op, values}. op is one of eq, in, neq, not_in, contains, regex. filters keep matching rows; exclusions drop matching rows. Example "EC2 by region last 90 days, excluding Savings Plan credits": dimensions=["RegionId"], filters=[{"dimension":"ServiceName","op":"eq","values":["Amazon EC2"]}], exclusions=[{"dimension":"ChargeCategory","op":"in","values":["Credit"]}], metric="EffectiveCost"

metric: BilledCost | EffectiveCost (amortized, default) | ListCost. granularity: TOTAL | DAILY | MONTHLY (only matters when "date" is a dimension). order_by: "metric" (default, descending) or a dimension name. start_date / end_date: YYYY-MM-DD (default last 30 days). provider: aws|azure|gcp (default all). via: "auto" (default; CUR only when a line-item dimension is requested), "focus", or "cur".

This is read-only: it slices and charts cost data. It never changes anything. Args: dimensions: Fields to group by (e.g. ["service", "region"]). filters: Include-filters, {field: [values]}. exclusions: Exclude-filters, {field: [values]}. metric: "cost" (default) or another supported metric. granularity: "DAILY" or "MONTHLY". order_by: Sort field, defaults to the metric descending. limit: Max rows to return. start_date: ISO date (YYYY-MM-DD). Defaults to 30 days ago. end_date: ISO date (YYYY-MM-DD). Defaults to today. provider: Limit to one provider (e.g. "aws"). None = all. title: Optional title for the resulting card. via: Internal: how the slice was invoked.

List every cloud service that has spend in the period, across AWS, Azure, and GCP.

Use this to discover what services are running before querying a specific one. Returns services sorted by cost so you can see the top drivers at a glance.

Works for any service, EC2, RDS, ElastiCache, AppSync, Kendra, IoT Core, WorkSpaces, Pinpoint, or anything else in your account.

Args: provider: "aws", "azure", "gcp", or blank for all connected providers. start_date: ISO date (YYYY-MM-DD). Defaults to 30 days ago. end_date: ISO date. Defaults to today.

Examples: - "What services are we running on AWS?" - "Show me all GCP services with spend this month" - "What cloud services do we use?"

Get cost breakdown for any named cloud service on AWS, Azure, or GCP.

Handles any service, common ones like EC2 and RDS, or less common ones like AppSync, Kendra, MSK, WorkSpaces, IoT Core, Pinpoint, Forecast, MemoryDB, Clean Rooms, Lake Formation, and 200+ others.

Short names and abbreviations are resolved automatically: "ElastiCache" → "Amazon ElastiCache" "MSK" or "Kafka" → "Amazon Managed Streaming for Apache Kafka" "Step Functions" → "AWS Step Functions"

If the service name is ambiguous, returns a list of close matches.

Args: service_name: Name of the service (short name or full name both work). provider: "aws", "azure", "gcp", or blank to auto-detect. start_date: ISO date. Defaults to 30 days ago. end_date: ISO date. Defaults to today. granularity: "DAILY" or "MONTHLY".

Examples: - "How much did we spend on ElastiCache this month?" - "Show me AppSync costs for the last 7 days" - "What's our MSK spend?" - "How much are we spending on Azure Cognitive Services?" - "Show me GCP BigQuery costs"

Run a full cost optimization audit across all connected AWS resources. Use this when the user explicitly asks for a full audit, cost scan, or optimization sweep. For simple cost questions ("what did I spend last month?") prefer get_cost_summary or get_costs_by_service, they are faster and cheaper.

Good triggers: "run a cost audit", "scan for savings", "find waste", "full optimization report", "what should I optimize?". Not needed for: point-in-time cost queries, single-service questions, forecasts.

Covers: Graviton, public IPv4, Lambda concurrency, S3 Bucket Keys, non-prod scheduling, RDS snapshots, spot adoption, CloudWatch cardinality, CloudWatch orphaned alarms, Logs IA migration, Lambda SnapStart, EFS cross-AZ, NLB cross-zone, S3 IT, S3 Transfer Acceleration, EBS replication, Database SPs, idle/orphaned resources (unattached EBS, unused EIPs, old snapshots, stopped EC2, idle load balancers), and idle RDS instances (no connections in 14d).

Each scanner runs independently. After showing results, ask the user which opportunity to investigate first.

After showing results, offer to export with: 'Want me to export these to CSV?' Args: regions: AWS regions to scan. Defaults to all enabled regions. top_n: How many top results to return.

Examples: - "Run a full cost audit" - "Find everything we could save"

Explain what drove cost changes across all connected providers in the last N days.

Compares this period to the same-length period before it, finds the top drivers of increase and decrease, and summarizes the net change. Works on the free tier without requiring business metrics.

Use when: - "Why did my bill go up?" - "What changed in our costs this month?" - "Show me the top cost drivers vs last month" - "Which services had the biggest cost changes?" - "What's driving our AWS spend increase?"

Args: days: Comparison window length in days (default 30) top_n: Number of top drivers to return (default 10) Examples: - "Why did costs go up this week?" - "What drove spend recently?"

Shows the return on investment from using nable: savings found, acted on, and verified versus the cost of the tool itself.

This report is unique to nable, no other FinOps tool can show this calculation because they cost more per month than many teams' actual savings.

Use when: - "Is nable worth it?" - "How much has nable saved us?" - "Show me the ROI on using nable" - "What's the payback period on the Pro plan?" - "How do savings compare to the subscription cost?"

Args: period_days: Lookback window for savings (default 90 days) Examples: - "What has nable saved us versus what it costs?" - "Show nable ROI"

Forecast future cloud spend using Holt-Winters time-series modelling.

Automatically tunes forecast parameters (alpha/beta/gamma) to your account's historical spend patterns and returns a daily point forecast with 80% prediction intervals.

Args: account_id: AWS account ID (auto-discovered from STS if not provided) service: specific service to forecast (e.g. "EC2", "RDS"), omit for total horizon_days: number of days to forecast (default 30) history_days: days of history to fit the model (default 90, need ≥14)

Returns forecast including method used, MAPE accuracy %, monthly projection, and day-by-day point/lower/upper estimates. Examples: - "Forecast our AWS spend for next month" - "Where will EC2 costs be in 60 days?"

Connect a Google Cloud billing account from inside your MCP client, no terminal.

Propose-then-confirm and local-only. It reads Google Cloud credentials that already exist on this machine (GOOGLE_APPLICATION_CREDENTIALS or gcloud Application Default Credentials), lists the open billing accounts they can see, and connects the one you choose. It never changes anything in GCP, and credentials stay on this machine.

Call it with no arguments to see the billing accounts available (nothing is stored). Then call it again with billing_account_id set to connect one.

Examples: - "Connect my Google Cloud billing" - "Use my gcloud login to connect GCP"

Args: billing_account_id: The billing account to connect (XXXXXX-XXXXXX-XXXXXX), from the candidate list a no-argument call returns. Omit to just list.

How to connect nable to OpenCost for real-rate Kubernetes cost, and whether it is already connected.

Without OpenCost, nable's Kubernetes costs are a zero-setup list-price estimate that does not price GPU, network, or storage. OpenCost (the CNCF project) prices per namespace at your cluster's real rates. nable only READS the OpenCost API; it never deploys or changes anything in your cluster. The steps below are for you to run.

Examples: - "How do I get accurate Kubernetes costs?" - "Connect nable to OpenCost" - "Why are my Kubernetes numbers an estimate?"

What your AI coding tools actually shipped, by model, and what it cost.

Attributes each unit of work to the AI model or agent that wrote it (Claude Code names the exact model in its commit trailer, so Claude work resolves to the model; Copilot, Codex, Cursor, and Devin resolve to the tool), sizes each high/medium/low by diff, and joins LLM spend by model. The line it produces: "Opus 4.8 was 49% of AI spend and shipped 10 PRs: 3 high, 5 medium, 2 low, $X per PR."

unit picks the unit of work: "pr" (merged pull requests), "commit" (commits on the default branch, for teams that push straight to main with no PRs), or "auto" (default: PRs if the repo has any in the window, else commits). The unit actually used comes back in the "unit" field of the result.

Needs GITHUB_TOKEN and GITHUB_ORGS connected, or pass explicit repos like ["owner/name"]. Read-only.

Good triggers: "what has AI shipped", "AI engineering output", "which model wrote the most code", "cost per PR by model", "cost per commit", "is our AI spend producing work". Args: days: Look-back window in days (default 30). repos: Git repos to include (owner/name). All configured repos when omitted. unit: Business unit for cost-per-unit math (e.g. "pr", "commit").

Examples: - "What has AI coding shipped this month and what did it cost?" - "AI engineering report for the last 14 days"

Report spend status across serverless-GPU / inference-infra providers, Modal, Together, and Replicate. For the model-builder slice of AI startups this is the single largest variable cost, billed per GPU-second inside each vendor's own dashboard and invisible to any cloud bill.

Honest note: these vendors gate per-range cost behind paid plans or omit it from their public API. nable confirms each credential and reports what's reachable; until a usable usage endpoint exists, track these bills via the invoice email parser.

Args: days: Lookback window in days (default 30). Ignored if start_date set. start_date: ISO date string (YYYY-MM-DD). Optional. end_date: ISO date string (YYYY-MM-DD). Defaults to today.

Examples: - "How much are we spending on Modal / Replicate / Together?" - "Show my GPU inference infra costs" - "Is my Modal account connected?"

Full AI cost health dashboard with actionable KPIs.

Runs all AI cost health metrics in one call:

• Prompt cache hit rate and estimated savings (Anthropic)

• Context window utilisation per model (are you paying for 200K context but using 2K?)

• Model sprawl score (Herfindahl index of model concentration)

• Peak usage day-of-week and weekend vs weekday patterns

• Prompt efficiency (output/input token ratio, flags verbose or wrong-model usage)

• Error spend estimate (tokens wasted on failed requests)

• AI vs infrastructure spend ratio (benchmark: healthy SaaS = 5–15%)

Each finding includes an estimated monthly savings amount and specific remediation advice.

Args: days: Lookback window in days (default 30). infra_total_usd: Your total cloud infrastructure spend for the same period. Pass this to get AI-vs-infra ratio benchmarking.

Examples: - "Show me our AI cost health dashboard" - "What's our prompt cache hit rate?" - "Are we using the right AI models?" - "How efficient are our AI prompts?" - "What AI cost optimisations should we prioritise?"

List every cloud, SaaS, and LLM provider nable knows, each marked connected or not-configured, plus the active plan. The starting point for "what am I connected to" and for spotting which connector still needs credentials (each not-configured entry names the setup command to run).

Examples: - "Which providers are connected?" - "Is GCP set up yet?" - "What plan am I on?"

Actively test every configured connector with a real API call. Reports health status, last successful data time, and fix instructions for failures.

Examples: - "Are all my connectors healthy?" - "Which connectors are broken or stale?" - "Why am I not getting data from Datadog?"

Side-by-side cost comparison across all configured providers.

Args: category: "cloud" or "saas". None = all. start_date: ISO date. Defaults to 30 days ago. end_date: ISO date. Defaults to today.

Examples: - "Which cloud are we spending the most on?" - "Compare our SaaS tool spending" - "How does AWS compare to Azure and GCP?"

List all cloud accounts, subscriptions, and SaaS org IDs that nable can see, grouped by provider: AWS account ids, Azure subscriptions, GCP billing accounts, and each SaaS provider's org. Use it to find the account id or name other tools accept as their account argument.

Args: provider: Limit to one provider (e.g. "aws"). None = all providers.

Examples: - "What accounts is nable connected to?" - "List my Azure subscriptions"

Set a custom alert policy for anomaly detection on a specific provider or service.

Use this to:

• Mute noisy services you don't care about (e.g. DataTransfer, Tax)

• Raise the threshold for services that are naturally volatile

• Set a minimum $ delta to ignore tiny fluctuations

Supports glob patterns: "DataTransfer*", "Transfer", "EC2*"

Args: provider: "aws", "azure", "gcp", or "" for all providers service_pattern: Exact service name or glob pattern (e.g. "DataTransfer", "*") muted: If True, all anomalies matching this rule are silenced min_pct_change: Only alert if change exceeds this % (overrides default 20%) min_usd_change: Only alert if absolute change exceeds this $ amount note: Why this policy exists (shown in list_alert_policies)

Examples: - "Mute DataTransfer anomalies, they're always noisy" - "Only alert on EC2 if it changes by more than 40%" - "Ignore AWS Tax service anomalies" - "Only alert on changes over $500, ignore tiny fluctuations" - "Set a 50% threshold for Support charges"

List all custom alert policies for anomaly detection.

Shows which services are muted, which have custom thresholds, and why.

Examples: - "What alert policies do I have?" - "Which services are muted from anomaly detection?" - "Show my alert thresholds"

Remove a custom alert policy. The service will revert to the default threshold.

Args: policy_id: The ID from list_alert_policies()

Examples: - "Delete alert policy 3" - "Remove the mute on DataTransfer"

List the names of credentials stored in the encrypted vault (never the values).

Examples: - "What credentials are stored in the vault?" - "Which providers have been configured via setup?"

List tracked recommendations with their current status.

Args: status: Filter by status: "open", "acted_on", "verified", "dismissed", "expired". None = all. source: Filter by source: "rightsizing", "idle", "kubernetes", "waste", "commitment". None = all. limit: Max results (default 30).

Examples: - "Show all open recommendations" - "Which recommendations have we acted on?" - "List verified savings" - "Show dismissed recommendations"

List all configured nable profiles (for multi-account or multi-client setups).

Profiles allow engineers who manage multiple accounts to switch context cleanly. Each profile has its own database and credential namespace.

Use when: - "What profiles do I have configured?" - "Show me my nable profiles" - "Which profile is active?" Examples: - "List my nable profiles" - "Which cost profiles are configured?"

Create a new API key for a team member. Requires admin role in shared mode.

Roles: viewer , read-only cost queries, optionally scoped to one team/provider analyst , viewer + attribution writes, budget management, snapshot triggers admin , full access, can manage keys and connectors

The raw key (nbl_...) is shown ONCE, it is not stored. Save it immediately.

Examples: - "Create a viewer key for Alice scoped to the platform team" - "Give Bob an analyst key" - "Create an admin key for the CI system" Args: name: Human-readable key name (e.g. "ci-reporter"). role: "viewer", "analyst", or "admin". email: Owner email recorded for audit. scope_team: Restrict the key to one team's data. scope_provider: Restrict the key to one provider.

List all active API keys (names, roles, scopes). Raw keys are never shown. Requires admin role in shared mode.

Examples: - "Who has access to finops?" - "List all API keys" - "Show team member access levels"

Revoke an API key by ID. The key is soft-deleted, it stops working immediately. Requires admin role. Use list_api_keys to find the key ID first.

Examples: - "Revoke Alice's key" - "Remove access for key ID 3" Args: key_id: The key id from list_api_keys().

Show the current identity and access level. Works in both permissive and shared auth mode.

Examples: - "Who am I logged in as?" - "What's my role?" - "Do I have analyst access?"

Advisory policy gate: should a proposed remediation action proceed?

The request-path guardrail, advisory. Describe a remediation action you are considering (action_type), optionally with the change to cost (a Terraform plan, a helm diff, or a known monthly delta), and nable returns a machine verdict against your human-authored policy:

• allow: reversible, allowlisted, and within budget. A human can apply it.

• escalate: a one-way door (delete, terminate, buy a commitment) or an over-budget / large-cost change. A human must review it first.

• block: the action type is not in your allowlist.

ADVICE ONLY. nable never applies the action, a human does. This is the propose-only guardrail; nable does not auto-execute anything.

action_type examples: rightsizing, tag_fix, stop_idle, spot_migration, ticket (reversible); idle_cleanup, purchase_commitment, terminate_instance, delete_resource (one-way). Policy knobs via env: FINOPS_POLICY_MAX_AUTO_USD, FINOPS_POLICY_ALLOWED_ACTIONS (comma-separated). Read-only.

Good triggers: "can the agent do X", "is this action within policy", "should I apply this fix", "is it safe to auto-apply this". Args: action_type: The infra action being attempted (e.g. "terraform_apply"). terraform_plan_json: Terraform plan JSON string to evaluate. terraform_plan_file: Path to a terraform plan JSON file. tf_dir: Terraform directory to plan and evaluate. helm_diff: Helm diff text to evaluate instead of terraform. monthly_delta_usd: Known monthly delta, when you already have the number. budget_name: Budget to evaluate the action against.

Examples: - "Is this apply within policy?" - "Check this change against our cost guardrails"

List all pre-built cost views available to your team.

These are ready-to-run reports anyone on the team can call by name using get_view(). Useful to paste into a Claude Project system prompt so teammates know what is available.

Examples: - "What views are available?" - "Show me the list of shared cost reports"

Run a pre-built cost view by name. These are standard reports your whole team can share.

Args: view: View ID from list_views(). Required. tag_key: Tag key to group by (required for 'by_tag' view, e.g. 'team', 'env'). tag_value: Optional filter to a single tag value within by_tag. provider: Optional provider filter (aws, azure, gcp, datadog, etc.). days: Override the default lookback window for time-series views.

Examples: - "Show me the month over month view" - "Run the by_tag view for the team tag" - "Get the anomalies view for AWS" - "What does the top_spenders view show?" - "Run daily_trend for the last 7 days"

Tip: Share these view names in your team's Slack or Claude Project so everyone runs the same report instead of writing queries from scratch each time.

Pin a cost slice to the dashboard as a saved card. Takes the same slicing arguments as slice_costs (dimensions / filters / exclusions / metric / etc.), plus a title and a rolling lookback days. The pinned card re-runs its slice live on each dashboard load over the trailing days, so it always shows fresh numbers. scope: "instance" (shared on this nable) or "me". Read-only on the cloud: this only saves a view definition locally. Args: title: Card title shown on the dashboard. dimensions: Fields to group by (as in slice_costs). filters: Include-filters, {field: [values]}. exclusions: Exclude-filters, {field: [values]}. metric: "cost" (default) or another supported metric. granularity: "DAILY" or "MONTHLY". order_by: Sort field, defaults to the metric descending. limit: Max rows in the card. days: Look-back window in days (default 30). scope: "instance" (default) pins for this machine.

Examples: - "Pin this S3-by-region view to my dashboard" - "Save that as a card"

List the cost cards pinned to the dashboard: every saved view with its id, title, template, metric and dimensions, so you can re-run one with get_pinned_view(id) or remove one with unpin_view(id).

Examples: - "What views do I have pinned?" - "Show my saved cost cards"

Re-run a pinned view by id and return fresh cost data plus its rendered card. Read-only: nothing is modified, the saved definition is executed against current data.

Args: view_id: The pinned card's id, from list_pinned_views().

Examples: - "Refresh my S3 spend card" - "Re-run pinned view 2"

Remove a pinned cost card from the dashboard by id, so the dashboard stops tracking that saved view. The underlying saved view is not deleted, only unpinned; pin_view() puts it back.

Args: view_id: The pinned card's id, from list_pinned_views().

Examples: - "Unpin the S3 spend card from my dashboard" - "Remove pinned view 3"

Show everything nable can do, tailored to what you've connected.

Call this when the user asks "what can you do?", "what features do you have?", "what should I try first?", "show me what's available", or "help". Always call it right after a user connects their first account, so they see what just became possible. Pass detailed=True to also list the underlying tool names. Args: detailed: True returns the full capability list instead of the summary.

Examples: - "What can nable do?" - "List your capabilities"

Agent-driven onboarding: what is connected, what credentials are already on this machine, and the exact command to connect each remaining provider.

Call this when the user asks to connect a provider, says setup is incomplete, or asks what they are missing. Detected ambient credentials (gcloud login, env keys, ~/.modal.toml) mean the connect is ONE terminal command with no secrets involved; run it for the user or hand them the command.

Rules for the agent, and they are hard rules:

• NEVER ask the user to paste an API key or secret into the chat. For paste-a-key providers, have them run the setup command in their own terminal; it deep-links the key page and stores the key locally.

• Prefer the zero-secret paths: finops connect (batch-connects everything detected) and finops setup gcp / ambient AWS, where no secret ever passes through the conversation.

Examples: - "Connect my GCP costs" - "What providers am I missing?" - "Finish setting up nable"

Show the realized-savings dashboard: how much nable has recommended, how much has been acted on, and how much has been verified as actually saved.

Tracks the full lifecycle of every recommendation: open → acted on → verified (change confirmed in AWS/Azure/GCP) open → dismissed (won't fix)

Examples: - "How much have we saved from recommendations so far?" - "Show me our realized savings" - "Which recommendations have we actually acted on?" - "What's our total potential savings sitting open?"

Activate your nable Pro or Team license right here, no terminal, no restart.

Paste the license key from your receipt email (it starts with FINOPS-2-). nable validates it locally, stores it on this machine, and unlocks the paid features in this same session immediately. The key is verified offline with a public key bundled in nable; nothing about it is sent anywhere.

Examples: - "Activate my license FINOPS-2-..." - "I just paid for Pro, here's my key"

Args: license_key: Your license key from the receipt email (FINOPS-2-...).

Check which notification channels (Slack, Teams) are configured and active, returning each channel's status and what is missing when one is not set up. Use it to verify where anomaly alerts and digests will be delivered before relying on them.

Examples: - "Is Slack configured for alerts?" - "Where are cost alerts being sent?" - "Why did no alert reach Teams?"

Export a cost report as HTML (printable to PDF) and/or CSV. Saved to ~/.finops/exports/. No Claude Desktop required to open.

Args: title: Report title. Defaults to "Cloud Cost Report ". sections: Sections to include: cost_summary, services, anomalies, rightsizing, savings, budgets. Default: all. formats: ["html", "csv"]. Default: both. start_date: ISO date. Defaults to 30 days ago. end_date: ISO date. Defaults to today. open_file: Open HTML in browser after export (default True).

Examples: - "Export a cost report for this month" - "Give me a CSV export of anomalies and rightsizing" - "Make a weekly cost report for the team"

Runs the full cost audit and exports results to a CSV file.

Offer this automatically after run_full_cost_audit completes, or when the user says "export that", "save to CSV", "download these results", "export to spreadsheet", or similar.

output_path: optional full path for the CSV file. Defaults to ~/Downloads/nable-report-YYYY-MM-DD.csv

Returns the path where the file was saved and a summary. Args: output_path: Full path for the CSV. Defaults to ~/Downloads/nable-report-.csv. regions: AWS regions to scan. Defaults to all enabled regions. top_n: How many top results to return.

Examples: - "Export that audit to CSV" - "Save the findings as a spreadsheet"

Mark a savings recommendation as acted on (you've implemented the change). nable will then attempt to verify the change next time verify_savings() runs.

Args: recommendation_id: The ID from list_savings_recommendations() or get_savings_summary().

Examples: - "I resized that EC2 instance, mark recommendation 42 as done" - "We shut down the idle RDS, mark it acted on" - "Mark recommendation 7 as complete"

Dismiss a recommendation you've decided not to act on (won't fix, accepted risk, etc.). Dismissed recommendations won't appear in open potential savings.

Always pass the user's reason when they give one. It is how nable learns which recommendation types fit this environment. A business reason ("reserved for peak", "SLA-sensitive", "another team owns it") is recorded but kept OUT of the act-rate, so a valid "keep it" never trains a good recommendation type down. A quality reason ("the estimate is wrong") does count against that type. Pass the user's own words; nable categorizes them.

Args: recommendation_id: The ID from list_savings_recommendations(). reason: Why you're dismissing it, in the user's words (e.g. "reserved for burst traffic").

Examples: - "Dismiss recommendation 15, we need that instance for peak load" - "Mark recommendation 8 as won't fix"

Propose standing cost rules nable has inferred from what your team keeps rejecting.

When you dismiss the same CLASS of finding for the same business reason again and again (spot on prod, idle in the dr environment, a whole provider you don't optimize), nable notices and proposes one durable rule instead of nagging every time. Each proposal shows the evidence and the exact remember_cost_context() call that enacts it. Nothing is applied until you confirm one, so you stay in control.

Examples: - "What cost rules has nable figured out about how we work?" - "Turn my repeated dismissals into standing policies"