Skip to main content
Glama

cloudwatch-get_metric_statistics

Retrieve CloudWatch metric statistics to monitor AWS resources like EC2, RDS, and Lambda functions with customizable time ranges, dimensions, and statistical calculations.

Instructions

Retrieve CloudWatch metric statistics with full configurability for monitoring AWS resources.

This tool fetches time-series data points for CloudWatch metrics, supporting custom statistics,
dimensions, and time ranges. Essential for monitoring EC2 instances, RDS databases, Lambda functions,
and other AWS services.

**Required Parameters:**
- profile_name (str): AWS profile name from ~/.aws/credentials
- region (str): AWS region (e.g., 'us-east-1', 'eu-west-1')
- metric_name (str): CloudWatch metric name (e.g., 'CPUUtilization', 'NetworkIn', 'DatabaseConnections')
- namespace (str): AWS service namespace (e.g., 'AWS/EC2', 'AWS/RDS', 'AWS/Lambda')
- start_time (str): Start time in ISO 8601 format (e.g., '2024-01-01T00:00:00Z')
- end_time (str): End time in ISO 8601 format (e.g., '2024-01-02T00:00:00Z')
- period (int): Data point interval in seconds (60, 300, 3600, etc. - must align with metric resolution)

**Optional Parameters:**
- statistics (List[str]): Standard statistics to calculate. Default: ['Average']
  Options: 'Average', 'Sum', 'SampleCount', 'Maximum', 'Minimum'
  Example: ['Average', 'Maximum'] for CPU utilization trends

- extended_statistics (List[str]): Percentile statistics for detailed analysis
  Format: 'p{percentile}' (e.g., 'p99', 'p95', 'p90', 'p50')
  Example: ['p99', 'p95'] for latency analysis

- dimensions (List[Dict[str, str]]): Filter metrics by specific resource attributes
  Common dimension examples:
  * EC2: [{'Name': 'InstanceId', 'Value': 'i-1234567890abcdef0'}]
  * RDS: [{'Name': 'DBInstanceIdentifier', 'Value': 'mydb-instance'}]
  * Lambda: [{'Name': 'FunctionName', 'Value': 'my-function'}]
  * ELB: [{'Name': 'LoadBalancerName', 'Value': 'my-load-balancer'}]

- unit (str): Expected unit of measurement for validation
  Common units: 'Seconds', 'Percent', 'Count', 'Bytes', 'Bits/Second'

**Common Use Cases:**
1. Monitor EC2 CPU: namespace='AWS/EC2', metric_name='CPUUtilization', statistics=['Average', 'Maximum']
2. Track RDS connections: namespace='AWS/RDS', metric_name='DatabaseConnections', statistics=['Average']
3. Lambda duration analysis: namespace='AWS/Lambda', metric_name='Duration', extended_statistics=['p99', 'p95']
4. ELB response times: namespace='AWS/ELB', metric_name='Latency', extended_statistics=['p95', 'p99']

**Time Range Guidelines:**
- For high-resolution metrics: Use 60-second periods, max 3 hours of data
- For standard metrics: Use 300-second periods, up to 15 days of data
- For long-term analysis: Use 3600-second periods, up to 455 days of data

Returns detailed metric data points with timestamps, values, and units for analysis and alerting.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
profile_nameYes
regionYes
metric_nameYes
namespaceYes
start_timeYes
end_timeYes
periodYes
statisticsNo
extended_statisticsNo
dimensionsNo
unitNo
Behavior4/5

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 effectively describes what the tool does (fetches time-series data), includes practical constraints ('Time Range Guidelines' with period/data duration relationships), and specifies the return format ('detailed metric data points with timestamps, values, and units'). It doesn't mention authentication requirements beyond profile_name, rate limits, or error handling, but covers core behavior well.

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 description is well-structured with clear sections (purpose, required/optional parameters, use cases, guidelines) and uses bullet points effectively. While comprehensive, it's appropriately sized for an 11-parameter tool with no schema descriptions. Some sections like the detailed dimension examples could be slightly condensed, but overall it's front-loaded with key information and avoids redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex tool with 11 parameters, 0% schema coverage, no annotations, and no output schema, the description provides excellent coverage of inputs, behavior, and usage context. It explains what the tool returns and includes practical constraints. The main gap is the lack of explicit error handling or rate limit information, but given the comprehensive parameter documentation and behavioral context, it's nearly complete.

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

Parameters5/5

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

Given 0% schema description coverage, the description fully compensates by providing comprehensive parameter documentation. It clearly distinguishes required vs. optional parameters, explains each parameter's purpose with examples and formatting guidelines (e.g., ISO 8601 for timestamps, p99 format for extended_statistics), and includes practical examples for dimensions across different AWS services. This adds substantial value beyond the bare schema.

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?

The description clearly states the tool's purpose with specific verbs ('retrieve', 'fetches') and resources ('CloudWatch metric statistics', 'time-series data points'), and distinguishes it from sibling tools by focusing on CloudWatch metrics rather than EC2, RDS, or S3 operations. The opening sentence provides a concise summary of functionality.

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?

The description provides clear context for when to use this tool ('essential for monitoring EC2 instances, RDS databases, Lambda functions, and other AWS services') and includes 'Common Use Cases' with specific examples. However, it doesn't explicitly state when NOT to use it or name alternative tools for similar monitoring tasks, though the sibling list suggests other AWS services.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Havoc24k/aws-sa-tools-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server