Skip to main content
Glama
chaandannn

nable (finops-mcp)

optimize_ai_spend

Analyze your AI/LLM spend and get a ranked, dollar-quantified plan to cut costs across OpenAI, Anthropic, AWS Bedrock, Azure OpenAI, and Vertex.

Instructions

Ranked, dollar-quantified plan to cut your AI/LLM bill, across OpenAI, Anthropic, AWS Bedrock, Azure OpenAI, and Vertex.

This is the OpenRouter question answered as analysis, not a proxy: the cheapest way to get the same output. It decomposes spend into its real driver (model choice vs token size vs request volume) and returns the levers ranked by monthly dollars saved:

  • Model routing: move lower-complexity calls to a cheaper sibling model (priced from real input/output ratios, not a guessed percentage)

  • Prompt caching: raise your Anthropic cache hit rate so repeated input bills at ~10% of price

  • Output reduction: trim verbose responses (output is the pricier side)

  • Error reduction: stop paying for failed requests

  • Model consolidation: collapse model sprawl into clear tiers

Only levers with a grounded basis carry a savings number; governance levers are listed without inflating the headline. Output-trim savings are skipped for any model that already has a routing recommendation, so nothing is counted twice. nable never sits in your request path; it reads, ranks, and can open the PR.

Args: days: Lookback window in days (default 30). Savings are normalized to a 30-day month.

Examples: - "How do I cut our AI bill?" - "Where is the waste in our LLM spend?" - "What's the cheapest way to run the same workloads?" - "Optimize our token and model costs."

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
daysNo
Behavior4/5

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

The description explains it is an analysis (not a proxy), does not sit in the request path, and lists levers with precautions against double-counting. It adds context beyond the lack of annotations, though it omits potential limitations or data dependencies.

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?

The description is well-structured with an introduction, bulleted levers, edge-case notes, and examples. It is slightly verbose but front-loaded with the purpose. Could be trimmed while retaining clarity.

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

Completeness4/5

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

Given the tool's complexity and lack of output schema, the description explains the output as ranked and quantified, and lists levers with constraints. However, it does not specify the exact output format or structure.

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

Parameters5/5

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

The sole parameter 'days' has no description in the schema (0% coverage). The description adds full meaning: 'Lookback window in days (default 30). Savings are normalized to a 30-day month.' Examples further clarify usage.

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?

The description clearly states it provides a 'ranked, dollar-quantified plan to cut your AI/LLM bill' across specific providers, distinguishing it from sibling tools that report costs or monitor spend. The verb 'optimize' and resource 'AI spend' are explicit.

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

Usage Guidelines3/5

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

The description implies usage for cost reduction via example questions, but does not explicitly state when to use this tool versus alternatives like get_llm_costs or forecast_llm_costs. No exclusions or when-not-to-use guidance is provided.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/chaandannn/finopsmcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server