Loading ToolBench
An MCP server providing AI agents secure, read-only access to AWS Cost Explorer.
This is a well-structured AWS Cost Explorer MCP server with clear, domain-specific tool definitions. All 7 tools have explicit schemas and substantive descriptions that guide LLM selection. Naming follows verb_noun convention consistently. However, there are gaps in parameter documentation, output schema formalization, and error handling guidance that prevent a higher score. The server demonstrates good intent but lacks the polish expected at 80+.
Retrieve raw AWS cost and usage data for a specific date range. Returns daily or monthly unblended cost time series. Best for seeing exact spend over time. For period-over-period comparison, use get_cost_comparison instead. For breakdown by service, use get_cost_by_service.
Retrieve cost anomalies detected by AWS Cost Anomaly Detection service. Shows unexpected spend spikes with root cause analysis including affected service, expected vs actual spend, and impact assessment. Use this when investigating unusual charges, unexpected bill increases, or when asked 'why did my costs spike?' Note: requires Cost Anomaly Detection monitors to be configured in the AWS console.
Break down AWS costs by service (EC2, S3, Lambda, RDS, etc.) for a date range. Returns services ranked by spend with percentage of total. Use this when you need to identify which AWS services are driving costs or answer questions like 'what am I spending the most on?'
Break down AWS costs by a specific cost allocation tag such as Environment, Team, Project, or any custom tag. Returns cost per tag value ranked by spend. Use this when asked about costs per team, per environment (prod vs dev), per project, or any tag-based cost allocation. The user must specify which tag key to group by. Note: cost allocation tags must be activated in the AWS Billing console for them to appear in Cost Explorer data.
Output schemas not documented. Tools describe their return data in narrative descriptions but lack formal JSON Schema output definitions. LLMs cannot reliably plan downstream calls or extract fields without seeing the return type structure.
Parameter constraints under-specified in schema. Date range parameters (e.g., 'days_back' in get_cost_anomalies) lack min/max bounds in JSON Schema; descriptions mention '1-365' but schema does not encode this. LLMs may pass invalid values.
Parameter descriptions are terse and lack usage guidance. Many descriptions are single sentences (e.g., 'The cost allocation tag key to group by...') without examples, common values, or dependencies. Compare to baseline of ~72 chars average, most are under 40.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 8 | - | v1 |
Compare AWS costs between two time periods with automatic change analysis. Defaults to comparing current month-to-date vs the same number of days in the previous month. Identifies which services, regions, or linked accounts drove the biggest cost changes, sorted by impact. This is the best tool for answering 'why did my bill go up?', 'how does this month compare to last month?', or 'what changed in my AWS spending?' The group_by parameter lets you slice the comparison by service, region, or linked account.
Forecast future AWS spending for the next N days using AWS's built-in ML-based predictions. Returns predicted total spend with 80% confidence interval and period-by-period breakdown. Use this when asked about expected future costs, budget projections, or 'how much will I spend next month?'
Get EC2 rightsizing recommendations showing over-provisioned or idle instances with specific instance type change suggestions and estimated monthly savings. Use this when asked about cost optimization, reducing AWS spend, finding waste, or right-sizing infrastructure. Recommendations are based on CloudWatch utilization metrics over the specified lookback period.
Date parameter format descriptions are minimal. 'Start date (YYYY-MM-DD)' repeats the label without explaining why format matters, whether past dates are supported, or validation rules. Richer guidance like 'ISO 8601 format. Must be within last 2 years; default to start of current month if omitted.' would improve usability.
No error recovery guidance. Error handling in the source (e.g., src/tools/get-cost-and-usage.ts) returns errors with messages ('AWS API Error: ...') but does not guide LLM recovery. Should specify: Is this retryable? Should the user check their AWS configuration? Are there prerequisites?
Limited parameter validation rules documented. Numeric parameters (days, days_back) and enum parameters (granularity, lookback_period) should explicitly state constraints in descriptions. LLMs cannot reliably infer 'days' must be 1-365 without explicit text.