Provides tools for estimating AWS disaster recovery costs by reading spending data from AWS Cost Explorer and applying strategy-specific multipliers for backup/restore, pilot light, warm standby, and active/active.
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., "@AWS DR Cost Estimator MCP Server Compare all four DR strategies for my AWS account over the last 6 months."
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.
This sample is provided for demonstration and educational purposes only and is not intended for production use without additional security review and testing.
Plan your AWS disaster recovery (DR) budget conversationally. Ask your MCP-compatible assistant (Kiro, Cline, Claude, etc.) what it would cost to run DR under backup and restore, pilot light, warm standby, or active/active for your workload. Compare all four strategies side by side in one response.
The server reads your current spend from the AWS Cost Explorer API, applies DR cost multipliers derived from real customer engagements, and returns a budgetary estimate in seconds — with per-row confidence levels so you know where the estimate is well-grounded and where it needs further validation.
For the full methodology, see docs/methodology.md.
Add the server with one click.
Kiro | Cursor | VS Code |
|
|
Or paste this into your MCP client config manually:
{
"mcpServers": {
"dr-cost-estimator": {
"command": "uvx",
"args": ["--from", "git+https://github.com/aws-samples/sample-dr-cost-estimator-mcp.git", "dr-cost-estimator-mcp"],
"env": {
"FASTMCP_LOG_LEVEL": "WARNING",
"AWS_PROFILE": "your-aws-profile",
"AWS_REGION": "us-east-1"
}
}
}
}uvx fetches and runs the server from this repo with no clone or build needed.
Attach a policy granting ce:GetCostAndUsage to the IAM identity behind your AWS_PROFILE:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DRCostEstimatorCostExplorerRead",
"Effect": "Allow",
"Action": "ce:GetCostAndUsage",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestedRegion": "us-east-1"
}
}
}
]
}Cost Explorer doesn't support resource-level ARNs for GetCostAndUsage, so Resource must be *. The condition restricts calls to the us-east-1 endpoint (the only endpoint Cost Explorer uses). For additional controls, consider SCPs or aws:PrincipalTag conditions.
"Compare all four DR strategies for my AWS account over the last 6 months."That's it.
Related MCP server: AWS Billing MCP Server
"Compare all four DR strategies for my AWS account over the last 6 months and show me estimated costs."
"Using my prod AWS profile, analyze warm standby DR cost for the last 3 months."
"For AWS accounts 111122223333 and 444455556666, analyze pilot light DR cost over the last 3 months."
"Estimate DR costs for the workload tagged Project=checkout across all my accounts."
"Compare DR strategies for resources tagged app=payments or app=ledger in production (env=prod)."
"What would warm standby cost if we keep 30% warm capacity?"
Three tools: list_dr_strategies, compare_dr_strategies, analyze_dr_strategy
Four DR strategies: backup/restore, pilot light, warm standby, active/active
Live Cost Explorer input averaged over 1-24 complete months, optionally scoped by linked accounts or cost allocation tags
Usage-type-aware multipliers for RDS, OpenSearch, and Elastic Load Balancing (compute vs. storage vs. backup get separate multipliers)
Dollar-weighted confidence showing what fraction of spend has high-confidence vs. default-fallback multipliers
Per-row rationale with confidence level and plain-language explanation
Per-workload estimates via tags (tag_filters parameter)
Tunable warm-standby capacity (0.1-1.0) to match your RTO requirements
For detailed parameters, response shapes, and example calls, see docs/tool_reference.md.
The DR cost multipliers live in JSON files under dr_cost_estimator_mcp/core/data/; edit them directly in your clone. For a readable rendering of every shipped multiplier with its rationale, see docs/multiplier_reference.md (generated from the data files). For guidance on tuning multipliers for your portfolio, see docs/methodology.md.
Symptom | Fix |
Server doesn't appear in tool list | Restart your MCP client after config changes. Set |
| Check parameter ranges: |
| Verify |
Empty estimates (no error) | All line items matched the skip list (tax, refunds, support, Savings Plans). This is expected when there's no estimable spend. |
Numbers differ from Cost Explorer console | The tools use |
The server is read-only: ce:GetCostAndUsage is the only AWS API call. It cannot create, modify, or delete any resource. No data is written to disk; all output goes to stderr.
Methodology — multiplier tiers, assumptions, worked examples, customization guidance
Tool Reference — parameters, response shapes, example calls
Multiplier Reference — every shipped multiplier with rationale (generated)
This project is licensed under the MIT-0 License. See the LICENSE file for details.
Analyze DR cost for a single strategy using live Cost Explorer data.
| Name | Required | Description | Default |
|---|---|---|---|
| top_n | No | Top-N rollup size. Ignored when include_all_services is true. | |
| region | No | Optional AWS region for the boto3 session. Cost Explorer is accessed via us-east-1. | |
| profile | No | Optional AWS named profile. Defaults to the boto3 credential chain. | |
| strategy | Yes | DR strategy id. One of 'backup_restore', 'pilot_light', 'warm_standby', 'active_active'. | |
| months_back | No | Number of complete months of Cost Explorer history to average across (1-24). | |
| tag_filters | No | Optional cost-allocation-tag scope mapping a tag key to accepted values, e.g. {"Project": ["checkout", "payments"], "Environment": ["prod"]}. Keys are ANDed; values within a key are ORed. Scopes the estimate to a tagged workload instead of the whole account/portfolio. Tag keys must be activated as cost allocation tags; untagged resources are excluded from the estimate. | |
| linked_account_ids | No | Optional list of 12-digit AWS account ids to restrict the query to. | |
| include_all_services | No | When true, skip the Top-N rollup. | |
| warm_standby_capacity | No | Fraction of primary compute capacity kept warm in the DR region for the warm_standby strategy (0.1-1.0, default 0.5). Rescales fleet-shaped compute services (EC2, EBS, ECS, EMR) only; databases, storage, and control-plane fees are unaffected. |
| Name | Required | Description |
|---|---|---|
| error | No | Populated only when ``success`` is False. |
| totals | No | Portfolio totals across ``estimates``. Null on error. |
| success | Yes | True when the call succeeded. False indicates ``error`` is populated. |
| summary | No | Plain-text 2-4 sentence summary of the analysis. Empty string on error. |
| strategy | No | Strategy id the analysis was produced for. Null on error. |
| warnings | No | Non-fatal warnings, for example when the summary generator fell back to its literal placeholder string. |
| estimates | No | Portfolio-level per-service rows. Includes the synthetic Top-N rollup row when the input contains more than ``top_n`` DR-eligible services and ``include_all_services`` is false. |
| per_account | No | Per-account sections with per-service detail. For single-account inputs contains exactly one entry whose totals reconcile with the portfolio totals within rounding tolerance. |
| top_n_rollup | No | Transparent summary of services rolled into the 'Other Services' row. Null when no rollup occurred or when ``include_all_services`` is true. |
| strategy_label | No | Human-readable strategy label. Null on error. |
| confidence_summary | No | Dollar-weighted confidence summary across the portfolio. Null on error. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the key behavioral trait of using 'live Cost Explorer data', implying real-time AWS access. However, it omits other useful details like whether the operation is read-only, any rate-limit considerations, or the nature of the output (covered by output schema).
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 a single, front-loaded sentence that immediately states the action and scope. No wasted words, highly concise and effective.
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 is minimal but sufficient given a rich input schema and an existing output schema. It clearly communicates the purpose and data source. A slight gap is that it doesn't hint at what 'analyze' produces (e.g., cost breakdown, average), but the output schema covers return values, so completeness is good.
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?
Schema description coverage is 100%, and the parameter descriptions in the schema are detailed (e.g., tag_filters scoping, warm_standby_capacity rescaling). The tool description itself adds no additional parameter meaning beyond the schema, which is acceptable given high coverage.
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 analyzes DR cost for a single strategy using live Cost Explorer data, with a specific verb ('Analyze') and resource ('DR cost for a single strategy'). It explicitly distinguishes from sibling tools like compare_dr_strategies by limiting to a single strategy.
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 phrase 'for a single strategy' provides clear usage context, implying this should be used when analyzing one strategy rather than comparing. However, it does not explicitly mention alternatives like compare_dr_strategies for multi-strategy comparison, though sibling names make the distinction apparent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare DR cost across all four strategies using live Cost Explorer data.
| Name | Required | Description | Default |
|---|---|---|---|
| top_n | No | Top-N rollup size. Ignored when include_all_services is true. | |
| region | No | Optional AWS region for the boto3 session. Cost Explorer is accessed via us-east-1. | |
| profile | No | Optional AWS named profile. Defaults to the boto3 credential chain. | |
| months_back | No | Number of complete months of Cost Explorer history to average across (1-24). | |
| tag_filters | No | Optional cost-allocation-tag scope mapping a tag key to accepted values, e.g. {"Project": ["checkout", "payments"], "Environment": ["prod"]}. Keys are ANDed; values within a key are ORed. Scopes the estimate to a tagged workload instead of the whole account/portfolio. Tag keys must be activated as cost allocation tags; untagged resources are excluded from the estimate. | |
| linked_account_ids | No | Optional list of 12-digit AWS account ids to restrict the query to. | |
| include_all_services | No | When true, skip the Top-N rollup. | |
| warm_standby_capacity | No | Fraction of primary compute capacity kept warm in the DR region for the warm_standby strategy (0.1-1.0, default 0.5). Rescales fleet-shaped compute services (EC2, EBS, ECS, EMR) only; databases, storage, and control-plane fees are unaffected. |
| Name | Required | Description |
|---|---|---|
| error | No | Populated only when ``success`` is False. |
| success | Yes | True when the call succeeded. False indicates ``error`` is populated. |
| summary | No | Plain-text 2-4 sentence summary of the comparison. Empty string on error. |
| warnings | No | Non-fatal warnings, for example when the summary generator fell back to its literal placeholder string. |
| top_services | No | Portfolio-wide top-N services list, with current cost and per-strategy DR additional cost on each row. |
| confidence_summary | No | Dollar-weighted confidence summary across the portfolio. Null on error. |
| per_account_totals | No | Per-account totals list with one row per account. For single-account inputs this list contains exactly one entry whose totals reconcile with the portfolio totals within rounding tolerance. |
| total_current_cost | No | Sum of current_cost across all returned services, in USD. |
| per_strategy_totals | No | Portfolio-wide totals keyed by strategy id for the four supported strategies. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It mentions using 'live Cost Explorer data' (source and recency) but does not state whether the operation is read-only, what permissions are needed, or any side effects. This is a significant gap for a tool that queries live data.
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 a single, concise sentence that front-loads the essential action and scope, with no wasted words.
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 has 8 parameters and an output schema, the description is minimal but covers the core purpose. However, it lacks context about tool usage in workflows and behavioral details, making it thin for a tool of this complexity.
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?
Schema description coverage is 100%, so the schema already documents all 8 parameters thoroughly. The description itself adds no parameter-specific information, so it meets the baseline of 3.
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 the specific verb 'Compare' with a clear resource ('DR cost across all four strategies') and distinguishes from sibling tools like list_dr_strategies and analyze_dr_strategy by focusing on comparing all strategies.
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 use case (comparing DR costs) but does not explicitly mention when to use it versus alternatives such as analyzing a single strategy or listing strategies. It provides clear context but no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the four supported DR strategies with labels and descriptions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| error | No | Populated only when ``success`` is False. |
| success | No | True when the call succeeded. False indicates ``error`` is populated. |
| strategies | No | Supported DR strategies in canonical order. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly indicates a read-only listing operation, and the mention of 'four supported' strategies adds a specific behavioral detail. There is no hidden or destructive behavior, but the description could be slightly more explicit about the lack of side effects.
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 a single, compact sentence that conveys the essential information without any wasted words. Every part of the sentence contributes meaning.
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 with no parameters and an output schema present, so the description's mention of the four strategies and their labels/descriptions is sufficient. It is complete for the tool's intended use.
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 tool has zero parameters, so the baseline is 4. The description does not need to explain parameters, and the empty input schema confirms there is nothing 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 action ('List') and the resource ('DR strategies'), and specifies that it returns exactly four items with labels and descriptions. This distinguishes it from sibling tools like 'compare_dr_strategies' and 'analyze_dr_strategy', which imply different operations.
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 context for when to use the tool (to get the list of supported strategies), but does not explicitly mention alternatives or when not to use it. The implied usage is adequate for a simple list tool, but there is no direct comparison with sibling tools.
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.0analyze_dr_strategycompare_dr_strategieslist_dr_strategiesEach tool has a distinct purpose: listing strategies, comparing all strategies, and analyzing a single strategy. The scope difference between compare and analyze is clear, so there is minimal risk of misselection.
All tool names follow a verb_noun pattern with snake_case, using 'dr_strategy' as the core noun. The only variation is singular vs plural, which is semantically appropriate and does not break the overall consistency.
With 3 tools, the server is tightly scoped to its purpose of DR cost estimation. Each tool covers an essential operation (list, compare, analyze) without redundancy or unnecessary bloat.
The tool set covers the full read-only lifecycle of DR strategy costing: discovering available strategies, comparing all, and drilling into a single strategy. No obvious CRUD or analysis gaps exist for the stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Create AWS cost estimates and shareable AWS Pricing Calculator URLs.
Cloud cost + FinOps knowledge for AI agents: AWS/Azure/GCP optimisation, AI spend, waste playbooks.
AWS Cost Explorer cost, forecast, and anomaly reporting through user-connected IAM credentials.
Query cloud, AI and SaaS spend across 25+ providers: costs, budgets, anomalies, unit economics.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/aws-samples/sample-dr-cost-estimator-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
