The server provides read-only tools to analyze AWS cloud costs, identify waste, explain billing changes, and generate fix suggestions without making any changes. It uses actual negotiated rates.
what_is_wasting_money: Identifies avoidable spend with evidence, fixes, blast radius, and risk assessment. Supports optional S3 billing export (CUR) for per-resource detail.
what_was_not_examined: Reveals unexamined portions of the bill, ordered by spend, to show coverage gaps.
what_changed: Compares completed billing periods to explain growth, service-level cost drivers, and spending spikes (excludes in-progress months).
free_tier_status: Reports Free Tier usage and remaining allowances, highlighting charges from exceeding free limits.
show_fix: Generates a diff (for Infrastructure-as-Code) or AWS CLI command (for unmanaged resources) to fix a specific finding; changes are never applied automatically.
capabilities: Describes the server's read-only nature and limitations.
Detects when Amazon DynamoDB usage exceeds its free allowance, calculates the resulting charges, and provides recommendations to reduce usage and avoid unnecessary costs.
Prices Terraform plans using your actual AWS rates, evaluates the cost impact of infrastructure changes, and can generate mergeable fixes for cost findings in your working copy.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@cloudlens what's wasting money in my AWS account?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Cloud cost findings priced at your negotiated rates, reconciled to your actual invoice, and delivered as changes you can merge.
Runs on your machine. Reads your bill and your code. Sends nothing anywhere.
cloudlens check --profile your-aws-profileAbout $210.44 a month.
$141.26 a month looks avoidable (67% of the bill).
$137.39/month — Client VPN endpoint billed continuously with nobody connecting
Why: 4,656 endpoint-hours billed, with 0.0 connection-hours
Do: Delete the endpoint, or disassociate its subnets.
Risk if wrong: A VPN kept for break-glass access is unused by design.
$3.23/month — Amazon DynamoDB is just over its free allowance
Why: 24,056 unit-hours billed against a free allowance of 18,600
Do: Reduce to 18,600 or below and the charge disappears entirely.That is the whole product. Everything below is optional depth.
Or ask an agent instead of running a command — see Use it from Claude.
Three things this does that the others do not.
It knows what you actually pay. The AWS Price List API is documented as "for informational purposes only". Every tool that prices findings from it — including the pre-deploy estimators — is wrong for any customer with an enterprise discount, commonly by 20–40%, always in the direction of overstating. cloudlens derives your real rate card from your own bill:
Rate card 4 rates derived from your own billing data (4 measured)
Observed discount off public pricing: 16.0% — pricing findings at list price
would overstate savings by roughly this much.It refuses to publish numbers that don't tie out. Every run reconciles computed spend against your real invoice. If it doesn't match, you get the discrepancy instead of a savings figure.
┏━━━━━━━━━┳━━━━━━━━━━┳━━━━━━━━━┳━━━━━━━━┳━━━━━━━━━━┓
┃ Period ┃ Computed ┃ Invoice ┃ Delta ┃ ┃
┡━━━━━━━━━╇━━━━━━━━━━╇━━━━━━━━━╇━━━━━━━━╇━━━━━━━━━━┩
│ 2026-07 │ $253.46 │ $253.46 │ +0.00% │ ties out │
└─────────┴──────────┴─────────┴────────┴──────────┘It proves savings against history rather than projecting them.
"Had this been applied at the start of 2026-06, your actual invoices for 2026-06 and 2026-07 would have been $27.22 and $27.22 lower — computed against your own line items."
Related MCP server: AWS FinOps MCP Server
Nothing to install:
uvx --from cloudlens-mcp cloudlens check --profile prod(--from names the package, cloudlens names the command inside it. Bare
uvx cloudlens-mcp starts the MCP server instead, which is the other half.)
Or clone it, to run the tests or work on it:
git clone <repo> && cd cloudlens
uv sync --extra dev # or: pip install -e ".[dev]"
uv run cloudlens demo
uv run pytestPython 3.11+. Six dependencies: duckdb, boto3, rich, typer, openpyxl, mcp. The lockfile is committed, so installs are reproducible.
Source access is a hard ask on a first engagement, so everything here comes from the bill alone. No CloudWatch, no agent, no describe permission.
cloudlens scan --cur s3://bucket/prefix/ --invoices invoices.json
cloudlens trends --cur s3://bucket/prefix/
cloudlens profile --cur s3://bucket/prefix/An hourly CUR is a time series, not a ledger — so the weekly rhythm of every resource is already in it:
i-0uatworker billed 1,464h · active 405h · 72% idle · $55.34
00 06 12 18
Sun ························
Mon ·········█████████······
Fri ·········█████████······
Sat ························cloudlens findings --cur s3://... --repo . --invoices invoices.json --detail
cloudlens report --cur s3://... --repo . --out report.xlsx
cloudlens fix --cur s3://... --repo . --id gp2-to-gp3-001 --writeAttribution resolves ownership through a ten-rung ladder — code first, because git history outlives CloudTrail's 90-day window:
Attribution 92.4% of $1,091.56 traced to an owner
│ 1 │ infrastructure as code │ $433.84 │ 53.2% │
│ 3 │ AWS-generated tag │ $302.40 │ 37.1% │
│ — │ no owner found │ $38.64 │ 4.7% │cloudlens ci --cur s3://... --plan tfplan.json --repo . \
--max-monthly-increase 500Posts a PR comment nothing else can produce — the cost of the change at your rates, plus existing waste attached to the code being touched.
| Run this first on someone else's account. What the credential can and cannot see |
| Every account you can reach, ranked by what is avoidable |
| Record today, so a later |
| Start here. What is wasting money, in plain English |
| Rate card and reconciliation |
| What changed, what spiked, weekly usage rhythm |
| Who owns what; ask a human; record the answer |
| Waste, priced and citing AWS best practices |
| LLM cost defects in source — unbounded loops, uncapped prompts |
| Findings as mergeable diffs |
| Price a Terraform plan, comment on the PR |
| Six-sheet spreadsheet for finance |
docs/FIRST-RUN.md is the page to send them — four
commands from an empty laptop, including installing uv and pointing it at an
account.
Run this first, on any account that is not your own:
uvx --from cloudlens-mcp cloudlens doctor --profile theirsIt checks the credential against every call the tool makes and says what each permission buys. This matters because cloudlens degrades quietly — a missing permission makes one analyser return nothing, which reads exactly like that analyser finding nothing, so a half-blind report looks like a clean account.
docs/iam-readonly-role.json grants exactly the
18 actions it needs and denies everything else by NotAction, so the grant
and the guarantee are the same list. Every action is a read; there is no
mutating AWS call anywhere in the codebase.
The minimum to get any answer at all is ce:GetCostAndUsage plus
cloudwatch:ListMetrics and cloudwatch:GetMetricStatistics. Everything else
adds findings rather than enabling the tool.
Two ways, both read-only.
MCP server. Copy .mcp.json.example to .mcp.json:
{
"mcpServers": {
"cloudlens": {
"command": "uvx",
"args": ["cloudlens-mcp@latest"],
"env": { "AWS_PROFILE": "your-readonly-profile" }
}
}
}Nothing to clone and nothing to install. uvx fetches the package, builds
a throwaway environment and runs it. The CLI is the same package, asked for by
command name:
uvx --from cloudlens-mcp cloudlens check --profile prodReplace @latest with ==0.8.0 when you want a pinned version.
Six tools: what_is_wasting_money, what_was_not_examined, what_changed,
free_tier_status, show_fix, capabilities.
Skill. One command, which also has nothing to clone:
uvx --from cloudlens-mcp cloudlens installIt writes the skill to ~/.claude/skills/cloudlens/ and prints the MCP entry
to paste. --skills-dir puts it elsewhere, --mcp-config .mcp.json writes the
entry rather than printing it.
The skill teaches an agent how to read the output — which confidence tiers can
be added together, why a short findings list needs the coverage number beside
it, and always to relay the failure case before recommending a deletion. The
MCP server carries the essentials in its own instructions, which arrive over
the wire, so the two agree by construction: the skill ships inside the package
next to the server that describes it.
AWS's Agent Toolkit needs aws:CalledViaAWSMCP deny policies so an agent
cannot do more through MCP than the human should, because that toolkit can call
anything.
This needs none. There is no mutating AWS call anywhere in the codebase — the
tool names contain no verbs, show_fix returns a diff for you to review rather
than applying it, and the only file ever written goes into your own working
copy. There is no privilege to escalate, so there is nothing to fence off. Ask
the capabilities tool and it will say so itself.
The credential is the AWS profile already on the machine. Nothing new is issued, nothing is stored, and nothing leaves the host.
Minimum is read on one S3 prefix. See docs/SETUP.md; for client engagements see docs/MULTI_CLIENT.md and the self-expiring onboarding stack.
No write action, anywhere. fix --write edits your local working copy so you
can review it with git diff; it never calls a mutating AWS API.
Deliberate, and the reason to trust the numbers it does give:
Won't price from a public price list when it has never seen that usage
type in your account. It says unpriced and explains why.
Won't claim a saving it can't replay against your real line items. Those say "estimate rather than a replay of history."
Won't report a resource as idle because it emits no activity data. Absence of evidence is not evidence of idleness.
Won't tell you to schedule something with no stopped state.
Won't reformat your Terraform to change one attribute.
Won't apply anything. You merge.
Confidence is stated on every figure — measured, derived or bounded — and
never summed into one optimistic headline.
253 tests. Full pipeline works end to end.
Validated against synthetic data only. The fixture plants findings with known values and computes ground truth independently of the code under test, so the logic and arithmetic are sound. What that cannot prove is that a real AWS bill matches the assumptions — the reconciliation tolerance (0.5%), the Terraform-type-to-usage-type mapping, and the flow-log field casing are all calibrated against data I wrote.
Running it against one real CUR is the highest-value next step, and the fastest way to find out which assumptions are wrong.
What this server can and cannot do.
Worth asking before granting access: the answer is short because the tool is read-only by construction rather than by policy.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explicitly states the tool is read-only 'by construction rather than by policy' and that the answer is short, which covers key safety and behavior aspects. The output schema handles return format details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no waste. It front-loads the purpose and adds a brief, relevant behavioral note, earning a perfect score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description adequately covers purpose and read-only nature. It could slightly expand on what 'can and cannot do' encompasses (e.g., server-level limitations vs tool-level), but overall it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the baseline for this dimension is 4. The description adds no parameter-related meaning, which is appropriate since there are no parameters to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports what the server can and cannot do, which distinguishes it from sibling tools focused on specific analyses. However, it lacks an explicit verb like 'Lists' or 'Returns,' relying on a noun phrase, so it's clear but not maximally specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. The note about asking before granting access addresses authorization rather than usage context, leaving the agent to infer that this is a read-only capability check.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free Tier allowances and how close this account is to each.
Not in the bill, so a charge sitting just over an allowance is invisible without it — and the saving there is the whole charge.
| Name | Required | Description | Default |
|---|---|---|---|
| profile | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It implies a read-only status check by its name and phrasing, and adds useful context about the tool's purpose in revealing charges that are otherwise unnoticed. However, it does not explicitly confirm safety, discuss permissions, or mention any limitations or edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core purpose in the first sentence. The second sentence adds motivational context rather than redundant detail, so it earns its place. It is not overly verbose or repetitive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (1 optional param, no required params) and an output schema exists, so the description need not detail return values. However, the unexplained 'profile' parameter and lack of explicit behavioral notes leave gaps. It is adequate but not fully complete for an agent to use without guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one optional 'profile' parameter with 0% description coverage, and the description does not mention the parameter at all. Since the description fails to compensate for the complete lack of schema documentation for this parameter, it provides no added meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports free tier allowances and current account proximity to each limit, which is specific enough to distinguish from siblings like what_is_wasting_money or capabilities. However, it lacks an explicit verb like 'get' or 'list' and does not directly contrast with sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a concrete scenario ('Not in the bill, so a charge sitting just over an allowance is invisible without it') that explains when this tool is valuable. It gives clear context for use, though it does not explicitly name alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate the change for one finding, as a diff or a command.
Nothing is applied. The caller reviews and merges. Terraform edits are returned as a unified diff against the declaring file; resources not in code get the equivalent AWS CLI command instead.
| Name | Required | Description | Default |
|---|---|---|---|
| cur | No | ||
| repo | Yes | ||
| profile | No | ||
| finding_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing side effects. It explicitly says 'Nothing is applied' and differentiates output by resource type (unified diff for Terraform, AWS CLI command otherwise). This is critical behavioral transparency for a tool that might otherwise be assumed to apply changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: three sentences, front-loaded with the purpose, then two sentences of essential behavior. Every sentence adds value, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality, safety profile, and output format, and an output schema exists. However, with 4 parameters and 0% schema coverage, leaving parameters unexplained creates a significant gap for an agent trying to invoke the tool correctly. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description provides no explanation of the parameters. It does not mention finding_id, repo, cur, or profile semantics, leaving the agent to guess their meanings. The description fails to compensate for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Generate the change for one finding', a specific verb-object pair that clearly identifies the tool's function. The output form ('as a diff or a command') and the scope ('one finding') further refine the purpose, distinguishing it from sibling tools that analyze waste or changes rather than produce fixes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states 'Nothing is applied. The caller reviews and merges,' which makes the intended use case clear: generate a proposed change for human review. However, it does not explicitly contrast this with alternatives or state when not to use it, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain a bill that moved: growth, the services driving it, and spikes.
Compares complete billing periods only. A month still running is not comparable to a finished one, and reporting it as a decline would be the calendar rather than the bill.
| Name | Required | Description | Default |
|---|---|---|---|
| cur | No | ||
| profile | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure, and it does provide a key behavioral constraint: only complete billing periods are compared, and it explains the rationale (avoiding calendar artifacts). It does not cover every trait (e.g., permissions, rate limits), but the given nuance is valuable and non-obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first front-loads the purpose, the second adds a necessary caveat about complete periods. Every sentence earns its place, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema likely covers return values, but the description lacks parameter semantics and any guidance on when to use this tool versus siblings like what_is_wasting_money. It provides the core purpose and a key limitation, but the operational context is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters ('cur', 'profile') with no descriptions (0% coverage), and the description does not mention them at all. The general purpose hints at what they might mean (current period, billing profile), but the agent is left guessing, and the description does not compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Explain') and resource ('a bill that moved'), and explicitly lists the key outputs (growth, services driving it, spikes). This clearly distinguishes it from sibling tools like what_is_wasting_money, which focus on waste rather than change analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a clear usage context (explaining bill changes) and provides an explicit when-not-to-use rule ('Compares complete billing periods only... a month still running is not comparable'). It does not explicitly name alternative tools, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find avoidable cloud spend on an AWS account.
Start here. Returns what the account costs, what looks avoidable, and for each finding the evidence, the fix, the blast radius and what breaks if the finding is wrong.
profile: AWS profile name. Uses the default credential chain if omitted. cur: Billing export location (s3://... ). Omit to use Cost Explorer, which needs no setup but gives no per-resource detail. repo: Local repo path, to resolve ownership and AI cost defects.
| Name | Required | Description | Default |
|---|---|---|---|
| cur | No | ||
| repo | No | ||
| profile | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosure. It openly states what the tool returns (evidence, fix, blast radius, and consequences of false findings), which goes beyond a generic 'find' description. It also mentions credential behavior and the Cost Explorer fallback. It does not disclose performance characteristics or side effects, but for a read-oriented analysis tool, it is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured, and front-loaded. It uses a clear summary line, a 'Start here' instruction, and a compact parameter list. No wasted words; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and the existence of an output schema, the description covers the core aspects: purpose, parameters, and key tradeoffs. It explains why to use Cost Explorer versus CUR and what the findings include. It could optionally mention expected runtime or AWS permissions, but given the output schema and clear context, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters (profile, cur, repo) are explicitly explained in the description, with default behaviors and tradeoffs. The schema has zero descriptions, so this fully compensates. profile gets credential-chain context, cur gets the s3 URI and the Cost Explorer alternative, repo gets its purpose. This exceeds what the schema alone provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Find avoidable cloud spend on an AWS account.' It clearly outlines what is returned (cost, avoidable items, evidence, fix, blast radius, what breaks), and the phrase 'Start here' establishes its role as the entry-point tool. This distinguishes it from siblings like what_was_not_examined or what_changed, which target narrower subtopics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear directive to use this tool first ('Start here.') and explains when to use or omit each parameter: omitting cur uses Cost Explorer (no setup, but no per-resource detail), repo has a specific purpose. However, it does not explicitly compare against sibling tools or state when NOT to use it, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show which spend no rule looks at.
A report with three findings reads identically whether it inspected 95% of the bill or 5%. This is the denominator: every dollar is either flagged, checked and clean, or never examined. The unexamined list is ordered largest first.
| Name | Required | Description | Default |
|---|---|---|---|
| cur | No | ||
| profile | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses meaningful behavioral details beyond the tool name: it explains that spend is classified into three states and that the unexamined list is ordered largest first. Since no annotations are provided, this added context helps set expectations, though it still does not explicitly mention read-only status or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is intentionally brief, front-loading the core purpose in the first line and then providing the rationale and ordering detail in two supporting sentences. Every sentence adds value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description captures the tool's purpose and one key behavioral trait (ordering), but it omits any explanation of the optional parameters and does not offer comparative usage guidance with sibling tools. Since an output schema exists, return values need not be described, but the missing parameter semantics and absence of when-to-use guidance leave the description only partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema includes two optional parameters ('cur' and 'profile') with no descriptions (0% coverage), and the tool description does not mention or explain either parameter. This leaves the agent without any hint of their meaning or effect, a substantial gap that the description fails to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'show' and a clear resource 'spend no rule looks at', effectively distinguishing it from sibling tools like what_is_wasting_money or what_changed. It further explains the denominator concept, reinforcing the purpose and making the tool's intent unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by explaining that every dollar is either flagged, checked and clean, or never examined, clarifying the tool's role in identifying what wasn't reviewed. However, it does not explicitly state when to use this tool over alternatives or when not to use it, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.3capabilitiesfree_tier_statusshow_fixwhat_changedwhat_is_wasting_moneywhat_was_not_examinedEach tool addresses a distinct aspect of cloud cost analysis: waste detection, coverage, changes, free tier, fix generation, and server capabilities. No two tools overlap in purpose.
Tool names mix 'what_' question-style prefixes (what_is_wasting_money, what_was_not_examined, what_changed) with noun phrases (free_tier_status, capabilities) and one verb phrase (show_fix), creating inconsistent naming conventions.
Six tools is well-scoped for a cost analysis server, covering the full workflow without redundancy or bloat.
The tool set provides a complete cost analysis lifecycle: identify waste, examine coverage, analyze changes, check free tier, and generate fixes. No obvious gaps within the read-only scope.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Cloud cost visibility and savings recommendations grounded in your actual AWS, GCP and Azure bill.
Query cloud, AI and SaaS spend across 25+ providers: costs, budgets, anomalies, unit economics.
Lowers your AWS bill by helping you clean up and optimize your setup
FinOps MCP: query allocated, correlated cloud and AI cost across AWS, GCP, Azure and Snowflake.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Rishabhusesit/cloudlens'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
