Finopsmcp vs Azure FinOps MCP Server

estimate_change_cost

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". Examples: - "What would this change cost per month?" - "Preflight the cost of this terraform plan"

connect_gcp

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"

list_connected_providers

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?"

check_ai_budget

Advisory gate: before a big task, is the agent about to blow its AI budget? Call this before an expensive run. Returns a verdict (ok / warn / over), the reason, and a recommendation. Advice only, it never blocks; relay the verdict and let the human decide. Pass estimated_next_tokens to test whether the next task would tip a token budget over.

check_action_policy

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". Examples: - "Is this apply within policy?" - "Check this change against our cost guardrails"

what_can_nable_do

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. Examples: - "What can nable do?" - "List your capabilities"

nable_setup_status

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?"