Skip to main content
Glama
getnable

nable (finops-mcp)

by getnable
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Check AI budget

check_ai_budget
Read-onlyIdempotent

Check remaining AI budget headroom and get an ok, warn, or over verdict before starting an expensive agent run. Pass an estimated token count to test if the next task would exceed the cap.

Instructions

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, a recommendation, and headroom: dollars left under this session's cap, and dollars or tokens left under the monthly budget. 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. session_id defaults to the calling session.

Input Schema

NameRequiredDescriptionDefault
session_idNo
estimated_next_tokensNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.12.0
    • addedInput schema / properties / session_id
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Session Id"
+}
  2. Addedv0.8.213

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare read-only/idempotent/non-destructive; the description goes further by declaring 'Advice only, it never blocks' — a critical behavioral trait no annotation conveys — and by pre-describing the return payload (verdict, reason, recommendation, headroom). It also discloses that session_id resolves to the calling session, removing a silent-default surprise.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the one-line purpose, then progressively more detail; each sentence carries distinct information (timing, return shape, non-blocking nature, param usage). The opening rhetorical question is slightly padded but functions as a memorable framing line.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, yet the description enumerates the return fields (verdict states, reason, recommendation, headroom) and explains the cap semantics, so an agent knows what comes back without probing. Only two optional params and both are addressed, making this complete for its complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must carry the parameter load, and it largely does: estimated_next_tokens is given a concrete purpose and session_id is explained as defaulting to the calling session. What's missing is any guidance on magnitude/units for estimated_next_tokens or when to override session_id.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb plus resource ('check ... AI budget') in the first line and pins the scope to this session's cap and the monthly budget. That scope distinguishes it from cost-oriented siblings such as get_cost_summary and estimate_change_cost, which concern cloud spend rather than agent token budget.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit invocation timing: 'Call this before an expensive run,' plus a conditional use for estimated_next_tokens ('to test whether the next task would tip a token budget over'). It also sets expectations on what to do with the result ('relay the verdict and let the human decide'), but never names a sibling or says when not to call it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools