Add nable: local-first FinOps MCP for cloud and AI spend

[getnable]

Adds one component: cli-tool/components/mcps/devtools/nable.json.

Why this one. There is no cost or FinOps MCP in the catalog today. Cloud spend is a question people ask inside Claude Code constantly and currently have to leave for a console to answer.

What nable does. Answers cost questions across AWS, Azure, GCP, Kubernetes and 15+ SaaS and AI providers, detects anomalies against a rolling baseline, tracks LLM spend by model, and drafts the Terraform fix as a pull request a human reviews.

Config notes. Runs with uvx, matching the nine existing uvx components. No API key in the config, so no placeholder for users to fill: it reads the cloud credentials already on the machine, and they stay in the OS keyring. Propose-only, so it never changes cloud resources on its own.

Open source (Apache-2.0) at getnable/finopsmcp, on PyPI as finops-mcp. I did not touch components.json, since that is generated.

🤖 Generated with Claude Code

---

Summary by cubic

Adds nable as a new MCP component to provide local‑first FinOps for cloud and AI spend, filling the gap of no cost tooling in the catalog. Previously there was no FinOps MCP; now users can query spend, detect anomalies, and get Terraform fix proposals locally without modifying cloud resources.

• Area: components (cli-tool/components/); adds cli-tool/components/mcps/devtools/nable.json.
• Catalog: new component added; regenerate docs/components.json.
• Runtime: starts via uvx (entrypoint nable, PyPI finops-mcp); no API key in config; reads existing cloud credentials from the OS keyring; caches cost data locally; propose‑only (no resource changes).
• No new environment variables or secrets; no impact to existing components.

^{Written for commit d54b2c2. Summary will update on new commits.}

[github-actions]

👋 Thanks for contributing, @getnable!

This PR touches cli-tool/components/** and has been marked review-pending.

What happens next

1. 🤖 Automated security audit runs and posts results on this PR.
2. 👀 Maintainer review — a human reviewer validates the component with the component-reviewer agent (format, naming, security, clarity).
3. ✅ Merge — once approved, your PR is merged to main.
4. 📦 Catalog regeneration — the component catalog is rebuilt automatically.
5. 🚀 Live on aitmpl.com — your component appears on the website after deploy.

While you wait

• Check the Security Audit comment below for any issues to fix.
• Make sure your component follows the contribution guide.

This is an automated message. No action is required from you right now — a maintainer will review soon.

[greptile-apps]

Greptile Summary

Adds a local nable FinOps MCP descriptor that launches through uvx and advertises cloud, SaaS, and AI spend analysis.

• Adds the nable MCP under the devtools catalog category.
• Configures a local uvx nable process without environment placeholders.
• Does not update the generated dashboard catalogs required to expose the component in browsing and search.

Confidence Score: 4/5

The PR should not merge until the generated dashboard component artifacts are updated so users can discover the new MCP.

The descriptor itself follows the expected MCP JSON shape, but the dashboard reads committed generated catalogs that omit nable and are not committed by the scheduled regeneration workflow.

Files Needing Attention: cli-tool/components/mcps/devtools/nable.json and generated dashboard component catalogs

Important Files Changed

Filename	Overview
cli-tool/components/mcps/devtools/nable.json	Adds a structurally valid MCP descriptor, but its generated dashboard catalog entries are missing.

_{Reviews (1): Last reviewed commit: "Add nable: local-first FinOps MCP for cl..." | Re-trigger Greptile}

[greptile-apps]

Generated catalog omits nable

When this component is merged, the dashboard continues reading committed generated catalogs that contain no nable entry, causing the new MCP to remain absent from browsing and search; regenerate and commit the dashboard component artifacts with this source file.

Knowledge Base Used: Components Catalog (cli-tool/components)

[cubic-dev-ai]

1 issue found across 1 file

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="cli-tool/components/mcps/devtools/nable.json">

<violation number="1" location="cli-tool/components/mcps/devtools/nable.json:6">
P2: On machines whose default Python is <3.11 (Ubuntu 22.04 system Python, older pyenv setups), `uvx nable` does not start an MCP server: the `nable` shim detects the old interpreter and exits 1 after printing a stderr message. The package's own guidance and the repo's existing android-mcp.json pattern pin the interpreter, e.g. `uvx --python 3.12 nable`. Pin the interpreter in the args to make the server start reliably regardless of the machine's default Python.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

P2: On machines whose default Python is <3.11 (Ubuntu 22.04 system Python, older pyenv setups), uvx nable does not start an MCP server: the nable shim detects the old interpreter and exits 1 after printing a stderr message. The package's own guidance and the repo's existing android-mcp.json pattern pin the interpreter, e.g. uvx --python 3.12 nable. Pin the interpreter in the args to make the server start reliably regardless of the machine's default Python.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At cli-tool/components/mcps/devtools/nable.json, line 6:

<comment>On machines whose default Python is <3.11 (Ubuntu 22.04 system Python, older pyenv setups), `uvx nable` does not start an MCP server: the `nable` shim detects the old interpreter and exits 1 after printing a stderr message. The package's own guidance and the repo's existing android-mcp.json pattern pin the interpreter, e.g. `uvx --python 3.12 nable`. Pin the interpreter in the args to make the server start reliably regardless of the machine's default Python.</comment>

<file context>
@@ -0,0 +1,9 @@
+    "nable": {
+      "description": "Local-first FinOps server for cloud and AI spend. Answers cost questions across AWS, Azure, GCP, Kubernetes and 15+ SaaS and AI providers, detects anomalies against a rolling baseline, tracks LLM spend by model, and drafts the Terraform fix as a pull request a human reviews. Runs on your machine: credentials stay in your OS keyring and cost data caches in a local SQLite database. Propose-only, so it never changes your cloud on its own.",
+      "command": "uvx",
+      "args": ["nable"]
+    }
+  }
</file context>

Suggested change

	"args": ["nable"]
	"args": ["--python", "3.12", "nable"]

[getnable]

Good catch, and it was correct. I went to reply that this was already fixed, then ran it:

$ uvx --python 3.10 nable --version
  nable needs Python 3.11 or newer. This is Python 3.10.
  Run this instead: uvx --python 3.12 nable
exit 1

The root cause was not the config. The shim re-execs itself under a uv-managed interpreter rather than asking the user to retype the command, and that code was written weeks ago, merged, and tested. It never shipped. shim/pyproject.toml still declared a version already on PyPI, so there was nothing to publish it under. The published artifact had zero occurrences of the re-exec function; the repo had two.

Fixed at the source and published as nable 0.1.4. Same command, same machine, just now:

$ uvx --python 3.10 nable --version
  This is Python 3.10, and nable needs 3.11. Fetching Python 3.12 and continuing.
nable (finops-mcp) 0.8.213
exit 0

So I have left the config as uvx nable rather than pinning --python 3.12 in the args. Pinning would have fixed this entry; fixing the shim fixes it for everyone who installs any other way, and it keeps the config matching the command in the project's own docs. There is also a specific reason to be careful about pinning here: an earlier attempt to solve this by raising the shim's Python floor caused a worse failure, where the newest shim excluded itself on old interpreters and resolution fell back to a months-old release.

Also added a digest lock so this class of miss fails the test suite instead of reaching a reviewer: editing the shim source now breaks CI until the version is bumped, which is the point where you remember to tag it.

Thanks for the report. It surfaced a shipped-but-unpublished fix I would not have found otherwise.