Billtrim: AWS bill savings

Find savings in an AWS bill

analyze_aws_bill

Read-onlyIdempotent

Find savings in an AWS bill export. Give it the text of a Cost Explorer CSV or an AWS Cost and Usage Report CSV and it returns a ranked list of likely waste (NAT gateway traffic, idle resources, oversized or old-generation volumes and instances, cross-AZ and internet data transfer, Savings Plan sizing), each with a monthly dollar range, the arithmetic, the console and CLI steps, how to verify first, the risk and how to roll back. Deterministic rules, no account access, nothing stored. Findings are suggestions: verify before deleting anything.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "csv": "<csv>"
    },
    "name": "analyze_aws_bill"
  }
}

Input Schema

Name	Required	Description	Default
`csv`	Yes	The text of the CSV file, header row included, up to 2 MB. For a bigger file, group by Service, Usage Type and Region in Cost Explorer first.
`format`	No	ce-csv (Cost Explorer), cur-csv (Cost and Usage Report) or auto to detect it.	auto
`max_findings`	No	How many ranked findings to return.
`min_monthly_savings_usd`	No	Drop findings whose top-end monthly saving is below this many US dollars.

Output Schema

Name	Required	Description	Default
`notes`	No
`format`	No
`source`	No
`web_url`	Yes
`findings`	Yes
`returned`	Yes
`period_end`	No
`total_cost`	No
`granularity`	No
`savings_low`	No
`period_start`	No
`savings_high`	No
`finding_count`	Yes
`engine_version`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 11, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, destructiveHint=false, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavior: the analysis is rule-based and deterministic, requires no account access, stores nothing, and each finding carries arithmetic, console/CLI remediation, verification steps, risk and rollback guidance. Minor deduction because it restates some of what the output schema already declares.

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 purpose and input requirement are front-loaded in the first two sentences, and the final sentence is a useful caution rather than filler. The middle sentence is a long parenthesized enumeration that is dense but each item conveys real output content, so little is wasted.

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?

With annotations, a fully described four-parameter schema and an output schema all present, the description fills the remaining gaps: what inputs are accepted, that processing is local and deterministic, and that results are advisory. Nothing an agent needs in order to decide to call this tool and interpret its output is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so every parameter — csv, format, max_findings, min_monthly_savings_usd — is already documented with types, defaults and bounds. The description only mentions the CSV input generally and adds no syntax, size or detection semantics beyond what the schema provides, which is the expected baseline.

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 and resource — find savings in an AWS bill export — and names the accepted inputs (Cost Explorer CSV or Cost and Usage Report CSV) plus the nature of the return (ranked list of likely waste categories). It is clearly distinguishable from the sibling explain_aws_usage_type, which by name alone explains a usage type rather than analyzing a whole bill.

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?

"Give it the text of a Cost Explorer CSV or an AWS Cost and Usage Report CSV" sets a clear precondition for invocation, and "Findings are suggestions: verify before deleting anything" frames how to act on results. It does not explicitly state when to prefer the sibling tool or what inputs are unsuitable, so it stops short of full when/when-not guidance.

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

All Billtrim: AWS bill savings tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?