Analyzes Terraform projects to identify AWS services and provide pre-deployment cost estimates and insights.
Click on "Deploy 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 Pricing MCP Server estimate cost of t3.medium EC2 in us-east-1"
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.
MCP server for generating upfront AWS service cost estimates and providing cost insights
Important Note: This server provides estimated pricing based on AWS pricing APIs and web pages. These estimates are for pre-deployment planning purposes and do not reflect the actual expenses of deployed cloud services.
Get detailed breakdown of your AWS costs by service, region and tier
Understand how costs are distributed across various services
Provide pre-deployment cost estimates for infrastructure planning
Support for analyzing both CDK and Terraform projects to identify AWS services
Ask questions about your AWS costs in plain English, no complex query languages required
Get instant answers fetched from pricing webpage and AWS Pricing API, for questions related to AWS services
Retrieve estimated pricing information before actual cloud service deployment
Generate comprehensive cost estimates based on your IaC implementation
Get cost optimization recommendations for potential cloud infrastructure
Provide upfront pricing analysis to support informed decision-making
Related MCP server: cloudscope-mcp
Install uv from Astral or the GitHub README
Install Python using uv python install 3.10
Set up AWS credentials with access to AWS services
You need an AWS account with appropriate permissions
Configure AWS credentials with aws configure or environment variables
Ensure your IAM role/user has permissions to access AWS Pricing API
Configure the MCP server in your MCP client configuration (e.g., for Amazon Q Developer CLI, edit ~/.aws/amazonq/mcp.json):
{
"mcpServers": {
"awslabs.aws-pricing-mcp-server": {
"command": "uvx",
"args": ["awslabs.aws-pricing-mcp-server@latest"],
"env": {
"FASTMCP_LOG_LEVEL": "ERROR",
"AWS_PROFILE": "your-aws-profile"
},
"disabled": false,
"autoApprove": []
}
}
}or docker after a successful docker build -t awslabs/aws-pricing-mcp-server .:
# fictitious `.env` file with AWS temporary credentials
AWS_ACCESS_KEY_ID=ASIAIOSFODNN7EXAMPLE
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
AWS_SESSION_TOKEN=AQoEXAMPLEH4aoAH0gNCAPy...truncated...zrkuWJOgQs8IZZaIv2BXIa2R4Olgk {
"mcpServers": {
"awslabs.aws-pricing-mcp-server": {
"command": "docker",
"args": [
"run",
"--rm",
"--interactive",
"--env",
"FASTMCP_LOG_LEVEL=ERROR",
"--env-file",
"/full/path/to/file/above/.env",
"awslabs/aws-pricing-mcp-server:latest"
],
"env": {},
"disabled": false,
"autoApprove": []
}
}
}NOTE: Your credentials will need to be kept refreshed from your host
The MCP server uses the AWS profile specified in the AWS_PROFILE environment variable. If not provided, it defaults to the "default" profile in your AWS configuration file.
"env": {
"AWS_PROFILE": "your-aws-profile"
}Make sure the AWS profile has permissions to access the AWS Pricing API. The MCP server creates a boto3 session using the specified profile to authenticate with AWS services. Your AWS IAM credentials remain on your local machine and are strictly used for accessing AWS services.
Analyze a CDK project to identify AWS services used. This tool dynamically extracts service information from CDK constructs without relying on hardcoded service mappings.
| Name | Required | Description | Default |
|---|---|---|---|
| project_path | Yes | Path to the project directory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It adds a useful non-obvious detail: 'dynamically extracts service information from CDK constructs without relying on hardcoded service mappings.' This explains internal behavior. However, it does not disclose potential side effects (e.g., read-only vs. file modifications), output format, or prerequisites needed for analysis.
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 states the core purpose, and the second adds a relevant technical detail. It is front-loaded, concise, and contains no redundant or filler content.
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 simple one-parameter tool, the description provides enough to select the tool and know what it does. However, it omits the return value/output format (e.g., list of service names) and any side effects or dependencies. Given the absence of annotations and an output schema, a bit more context would complete the picture.
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 coverage is 100% with project_path described as 'Path to the project directory.' The tool description does not add any additional parameter semantics beyond what the schema already provides, so the baseline of 3 is appropriate.
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's purpose: 'Analyze a CDK project to identify AWS services used.' It uses a specific verb ('analyze') with a specific resource ('CDK project') and an explicit outcome. It also distinguishes itself from the sibling analyze_terraform_project by specifying CDK, making the tool's scope unambiguous.
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 usage for CDK projects, and the second sentence explains the method (dynamic extraction from CDK constructs), giving context. However, it does not explicitly mention when not to use this tool or name alternatives like analyze_terraform_project. The guidance is clear but relies on the sibling name to infer the Terraform alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze a Terraform project to identify AWS services used. This tool dynamically extracts service information from Terraform resource declarations.
| Name | Required | Description | Default |
|---|---|---|---|
| project_path | Yes | Path to the project directory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds the fact that extraction is 'dynamic' but does not reveal important traits such as whether the tool is read-only, requires a local Terraform installation, accesses cloud APIs, or has limitations. This leaves significant gaps about side effects and operational behavior.
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 long, front-loaded with the primary action, and contains no redundant filler. Every sentence contributes meaningful information about the tool's purpose and method.
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 has moderate complexity with one parameter and no output schema. The description captures the core purpose but omits details about expected output format, error scenarios, or operational requirements. It is minimally viable but not fully complete for a tool that processes user-supplied project paths.
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% for the single parameter ('Path to the project directory'). The description does not add details about parameter semantics beyond what the schema already provides, but it also does not conflict with or duplicate schema information. Baseline 3 is appropriate.
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 a specific verb ('Analyze') and resource ('Terraform project') with a defined goal ('identify AWS services used'). It distinguishes itself from the sibling tool 'analyze_cdk_project' by explicitly targeting Terraform rather than CDK.
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 explains what the tool does but does not explicitly state when to use it versus alternatives. There is no mention of exclusions, prerequisites, or comparison with 'analyze_cdk_project' or other siblings. Usage context is only implied by the tool's purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a detailed cost analysis report based on pricing data for one or more AWS services.
This tool requires AWS pricing data and provides options for adding detailed cost information.
IMPORTANT REQUIREMENTS:
ALWAYS include detailed unit pricing information (e.g., "$0.0008 per 1K input tokens")
ALWAYS show calculation breakdowns (unit price × usage = total cost)
ALWAYS specify the pricing model (e.g., "ON DEMAND")
ALWAYS list all assumptions and exclusions explicitly
Output Format Options:
'markdown' (default): Generates a well-formatted markdown report
'csv': Generates a CSV format report with sections for service information, unit pricing, cost calculations, etc.
Example usage:
{
// Required parameters
"pricing_data": {
// This should contain pricing data retrieved from get_pricing
"status": "success",
"service_name": "bedrock",
"data": "... pricing information ...",
"message": "Retrieved pricing for bedrock from AWS Pricing url"
},
"service_name": "Amazon Bedrock",
// Core parameters (commonly used)
"related_services": ["Lambda", "S3"],
"pricing_model": "ON DEMAND",
"assumptions": [
"Standard ON DEMAND pricing model",
"No caching or optimization applied",
"Average request size of 4KB"
],
"exclusions": [
"Data transfer costs between regions",
"Custom model training costs",
"Development and maintenance costs"
],
"output_file": "cost_analysis_report.md", // or "cost_analysis_report.csv" for CSV format
"format": "markdown", // or "csv" for CSV format
// Advanced parameter for complex scenarios
"detailed_cost_data": {
"services": {
"Amazon Bedrock Foundation Models": {
"usage": "Processing 1M input tokens and 500K output tokens with Claude 3.5 Haiku",
"estimated_cost": "$80.00",
"free_tier_info": "No free tier for Bedrock foundation models",
"unit_pricing": {
"input_tokens": "$0.0008 per 1K tokens",
"output_tokens": "$0.0016 per 1K tokens"
},
"usage_quantities": {
"input_tokens": "1,000,000 tokens",
"output_tokens": "500,000 tokens"
},
"calculation_details": "$0.0008/1K × 1,000K input tokens + $0.0016/1K × 500K output tokens = $80.00"
},
"AWS Lambda": {
"usage": "6,000 requests per month with 512 MB memory",
"estimated_cost": "$0.38",
"free_tier_info": "First 12 months: 1M requests/month free",
"unit_pricing": {
"requests": "$0.20 per 1M requests",
"compute": "$0.0000166667 per GB-second"
},
"usage_quantities": {
"requests": "6,000 requests",
"compute": "6,000 requests × 1s × 0.5GB = 3,000 GB-seconds"
},
"calculation_details": "$0.20/1M × 0.006M requests + $0.0000166667 × 3,000 GB-seconds = $0.38"
}
}
},
// Recommendations parameter - can be provided directly or generated
"recommendations": {
"immediate": [
"Optimize prompt engineering to reduce token usage for Claude 3.5 Haiku",
"Configure Knowledge Base OCUs based on actual query patterns",
"Implement response caching for common queries to reduce token usage"
],
"best_practices": [
"Monitor OCU utilization metrics and adjust capacity as needed",
"Use prompt caching for repeated context across API calls",
"Consider provisioned throughput for predictable workloads"
]
}
}| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Output format ("markdown" or "csv") | markdown |
| exclusions | No | List of items excluded from cost analysis | |
| assumptions | No | List of assumptions for cost analysis | |
| output_file | No | Path to save the report file | |
| pricing_data | Yes | Raw pricing data from AWS pricing tools | |
| service_name | Yes | Name of the AWS service | |
| pricing_model | No | Pricing model (e.g., "ON DEMAND", "Reserved") | ON DEMAND |
| recommendations | No | Direct recommendations or guidance for generation | |
| related_services | No | List of related AWS services | |
| detailed_cost_data | No | Detailed cost information for complex scenarios |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosure. It does reveal important behaviors: generates markdown/CSV output, mandates inclusion of unit pricing, calculations, pricing model, and assumptions/exclusions. However, it does not explain how the report is returned (file write vs. string output), what happens with invalid pricing_data, or any side effects. This leaves gaps in understanding the tool's runtime behavior.
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 well-structured with headings and bullet points, but it is quite lengthy, especially the example JSON. While informative, it could be more concise by trimming redundant statements like 'This tool requires AWS pricing data' since it is already implied by the first sentence and example. The example is valuable but adds bulk.
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 complexity (10 params, nested objects) and lack of output schema, the description does not fully clarify the return format or behavior when output_file is not provided. It describes the report structure in general terms but leaves ambiguity about whether the tool returns the report as a string or saves to a file. More explicit mention of output delivery would improve completeness.
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?
Although schema description coverage is 100%, the description adds significant value through extensive example usage. It shows the exact structure for pricing_data, detailed_cost_data, and recommendations, which goes far beyond the schema's minimal descriptions. This is crucial for correctly constructing complex nested parameters.
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 generates a detailed cost analysis report for AWS services, which is a specific action on a specific resource. It distinguishes itself from sibling tools like get_pricing (raw data retrieval) and analyze_cdk_project/analyze_terraform_project (infrastructure analysis) by focusing on report generation from pricing data.
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 notes that the tool 'requires AWS pricing data', implying it should be used after get_pricing, but does not explicitly state when to use this tool versus alternatives or provide exclusion criteria. The example shows pricing_data from get_pricing, giving implicit context, but lacks a direct 'use this when...' statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get architecture patterns for Amazon Bedrock applications, including component relationships and cost considerations
| Name | Required | Description | Default |
|---|---|---|---|
| ctx | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. 'Get' clearly implies a read-only operation, and the content scope is specified. However, it does not disclose potential caveats, authentication requirements, rate limits, or output structure. For a simple retrieval tool, this is acceptable but minimal.
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?
A single, well-structured sentence communicates purpose and scope in 13 words. It is front-loaded with the main action and includes necessary detail without 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?
Given the tool's low complexity (no parameters, no output schema), the description adequately conveys what the tool returns: architecture patterns with component relationships and cost considerations. It is sufficient for an agent to know what to expect, though it could offer more detail on how the returned patterns are structured.
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 effectively zero user-facing parameters (only the internal Context injection), so the baseline is 4. The description does not need to explain parameters, and the schema already documents the optional context. No additional parameter semantics are required.
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 verb ('Get') and resource ('architecture patterns for Amazon Bedrock applications'), and adds specific scope ('including component relationships and cost considerations'). It distinguishes from sibling tools like analyze_cdk_project and get_pricing by focusing on Bedrock architecture patterns.
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 no guidance on when to use this tool versus alternatives. It does not mention sibling tools or any selection criteria, leaving the agent to infer usage solely from the name and the generic 'Get' phrasing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed pricing information from AWS Price List API with optional filters.
Service codes for API often differ from web URLs.
(e.g., use "AmazonES" for OpenSearch, not "AmazonOpenSearchService").
List of service codes can be found with `curl 'https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/index.json' | jq -r '.offers| .[] | .offerCode'`
IMPORTANT GUIDELINES:
- When retrieving foundation model pricing, always use the latest models for comparison
- For database compatibility with services, only include confirmed supported databases
- Providing less information is better than giving incorrect information
**TOOL PURPOSE:**
Retrieve AWS pricing data for various analysis needs: cost optimization, regional comparisons, compliance reporting, budget planning, or general pricing research.
**YOUR APPROACH:**
Follow a systematic discovery workflow to ensure accurate, complete results regardless of your specific use case.
**MANDATORY WORKFLOW - ALWAYS FOLLOW:**
**Step 1: Build Precise Filters**
```python
# FOR COST OPTIMIZATION: Create matrix of ALL minimum qualifying combinations
filters = {
"filters": [
{"Field": "memory", "Value": "8 GiB", "Type": "TERM_MATCH"},
{"Field": "instanceType", "Value": "m5.large", "Type": "TERM_MATCH"}
]
}
```
**Step 2: Execute Query**
```python
pricing = get_pricing('AmazonEC2', 'us-east-1', filters)
```
**COMMON USE CASES:**
**Cost Optimization (CRITICAL):**
- Build complete cross-product matrix of ALL qualifying attribute combinations
- Test every combination systematically: example: (min_memory × qualifying_storage × other_attributes)
- Start with minimum thresholds, test ALL possibilities - don't stop at first match
- Compare prices to find most cost-effective solution
- Prove optimality: Verify no cheaper option exists within requirements
**Regional Comparison:**
- Use identical filters across different regions
- Compare same instance types between us-east-1 vs eu-west-1
- Analyze pricing variations for capacity planning
**Compliance/Reporting:**
- Retrieve pricing for specific instance families or configurations
- Generate cost reports for budget planning
- Document pricing for procurement processes
**Research/Analysis:**
- Compare pricing across different service tiers
- Analyze cost implications of different configurations
- Investigate pricing patterns for forecasting
**CRITICAL REQUIREMENTS:**
- **USE SPECIFIC FILTERS**: Large services (EC2, RDS) require 2-3 filters minimum
- **VERIFY EXISTENCE**: Ensure all filter values exist in the service before querying
- **FOR "CHEAPEST" QUERIES**: Build complete matrix, test ALL qualifying combinations, prove optimality
**CONTEXT AND CONSTRAINTS:**
- **CURRENT PRICING ONLY:** Use get_price_list_file for historical data
- **NO SAVINGS PLANS/SPOT:** Only On-Demand and Reserved Instance pricing
- **REGION AUTO-FILTER:** 'region' parameter creates regionCode filter automatically
**REQUIRED INPUTS:**
- `service_code`: (e.g., 'AmazonEC2', 'AmazonS3')
- `region`: AWS region (e.g., 'us-east-1')
- `filters`: Built using discovered values (MANDATORY for large services)
- `max_allowed_characters`: Response limit (default: 100,000)
**ANTI-PATTERNS - AVOID THESE:**
❌ Using broad queries without specific filters on large services
❌ Assuming attribute values exist across different services/regions
❌ **Stopping at first qualifying option when seeking cheapest price**
❌ **Testing only "obvious" instance sizes - smaller may be cheaper**
**EXAMPLE USE CASES:**
**1. Cost Optimization Example:**
```python
# Find cheapest option meeting requirements
qualifying_memory = [m for m in memory_options if meets_requirement(m, "≥8GB")]
# Test combinations starting with minimum qualifying specs
```
**2. Regional Comparison Example:**
```python
# Compare same configuration across regions
filters = {"filters": [{"Field": "instanceType", "Value": "m5.large", "Type": "TERM_MATCH"}]}
us_pricing = get_pricing('AmazonEC2', 'us-east-1', filters)
eu_pricing = get_pricing('AmazonEC2', 'eu-west-1', filters)
```
**3. Research/Analysis Example:**
```python
# Compare different memory tiers for same instance family
memory_tiers = ["4 GiB", "8 GiB", "16 GiB"]
for memory in memory_tiers:
filters = {"filters": [{"Field": "memory", "Value": memory, "Type": "TERM_MATCH"}]}
pricing = get_pricing('AmazonEC2', 'us-east-1', filters)
```
**FILTERING STRATEGY:**
- **Large Services (EC2, RDS)**: ALWAYS use 2-3 specific filters to prevent 200+ record responses
- **Small Services**: May work with single filter or no filters
- **Multi-Region Analysis**: Use identical filters across regions for accurate comparison
- **Requirement-Based**: Systematically discover ALL options meeting criteria
- **Cost Optimization**: Start with minimum qualifying thresholds, use minimum-threshold filtering, test all qualifying combinations
**SUCCESS CRITERIA:**
✅ Applied appropriate filters for the service size
✅ For cost optimization: tested all qualifying combinations and proved optimality
| Name | Required | Description | Default |
|---|---|---|---|
| region | Yes | AWS region (e.g., "us-east-1", "us-west-2", "eu-west-1") | |
| filters | No | Optional filters for pricing queries | |
| service_code | Yes | AWS service code (e.g., "AmazonEC2", "AmazonS3", "AmazonES") |
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 discloses that only current pricing is available, the region parameter auto-creates a regionCode filter, large services require 2-3 filters to avoid 200+ record responses, and there is a default max_allowed_characters limit. However, it does not describe the response format or error behavior, leaving some gaps for a tool with no 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 well-structured with headings, code blocks, bullet lists, and front-loaded purpose. However, it is verbose and repeats cost-optimization strategies multiple times, which could be condensed. The organization helps an agent navigate the content, but conciseness suffers from 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?
Given no output schema, the description could explicitly state the return format, but it thoroughly covers service discovery, filter construction, constraints, and use cases. The extensive workflow and examples provide sufficient context for correct invocation. Missing auth, error handling, and exact response structure are minor gaps for this API-oriented tool.
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 coverage is 100%, but the description adds substantial value: it explains service code discrepancies (e.g., 'AmazonES' vs 'AmazonOpenSearchService'), region auto-filter behavior, and the mandatory filter requirements for large services. Extensive code examples show exact filter structures and parameter usage, exceeding the schema baseline.
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 'Get detailed pricing information from AWS Price List API with optional filters', a clear verb+resource statement. It further defines the purpose as retrieving AWS pricing data for cost optimization, regional comparisons, compliance reporting, and research, distinguishing it from sibling analysis and reporting 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 explicit when-to-use guidance: use get_price_list_file for historical data, avoid savings plans/spot pricing, and apply specific filters for large services. It includes anti-patterns, success criteria, and detailed use-case examples, giving the agent clear direction on when and how to invoke the tool.
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.
v1.0.1analyze_cdk_projectanalyze_terraform_projectgenerate_cost_reportget_bedrock_patternsget_pricingScored across 5 tools
Each tool has a clearly distinct purpose: analyzing CDK vs Terraform projects, retrieving pricing data, retrieving Bedrock patterns, and generating cost reports. No two tools overlap in function.
All tools follow a consistent verb_noun naming pattern: analyze_cdk_project, analyze_terraform_project, get_pricing, get_bedrock_patterns, generate_cost_report. The verbs are descriptive and parallel where appropriate.
With 5 tools, the server is well-scoped for its purpose of AWS pricing and cost analysis. Each tool covers a distinct step in the workflow, and the count is within the ideal range.
Core workflow is covered: analyze IaC projects, get pricing, generate reports. However, the get_pricing description references a get_price_list_file tool for historical data that does not exist in this server, creating a minor gap. Service code discovery also relies on external commands rather than a built-in tool.
Hosted MCP server for AWS cloud spend: service breakdowns, anomalies, savings and forecasts.
Hosted MCP server for LLM cost estimation, model comparison, and budget-aware routing.
Cloudflare Workers MCP server: ai-cost-optimizer
MCP server for querying and analyzing data from ad platforms, analytics tools, and spreadsheets
