AWS Health MCP Server
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LOG_LEVEL | No | Logging level (DEBUG, INFO, WARNING) | INFO |
| AWS_REGION | No | Region (Health API is us-east-1 only) | us-east-1 |
| AWS_PROFILE | No | AWS credentials profile | |
| HEALTH_API_TIMEOUT | No | API timeout in seconds | 30 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_service_healthA | Get current AWS service health events. Returns active and upcoming AWS health events with descriptions and timelines. Example prompts:
|
| get_affected_entitiesA | Get affected entities for all open AWS health events. Shows resources impacted by active health events, grouped by event and status. Example prompts:
|
| get_service_eventsB | Get health events for a specific AWS service. Args: service: The AWS service name (e.g., 'EC2', 'RDS', 'LAMBDA'). Case insensitive. Example prompts:
|
| get_completed_eventsA | Get completed/closed health events. Args: service: Optional. The AWS service name to filter by. Case insensitive. Example prompts:
|
| get_scheduled_changesA | Get all scheduled changes/maintenance events across AWS services. Returns upcoming maintenance windows, planned updates, and infrastructure improvements. Example prompts:
|
| get_org_health_eventsA | Get health events across your AWS Organization. If no arguments are provided, returns all active org health events. Args: service: Optional. The AWS service name to filter by. Case insensitive. account_id: Optional. The AWS account ID to filter events for. status: Optional. 'active' (default) or 'closed'. Example prompts:
|
| get_org_service_healthB | Get current AWS service health events across your organization. Provides a comprehensive overview of active health events across all accounts in your AWS Organization. Example prompts:
|
| get_org_affected_entitiesA | Get affected entities for AWS health events across your organization. Args: account_id: Optional. The AWS account ID to filter events for. event_arn: Optional. The ARN of a specific event to get details for. Example prompts:
|
| get_org_service_eventsA | Get health events for a specific AWS service across your organization. Args: service: The AWS service name (e.g., 'EC2', 'RDS', 'LAMBDA'). Case insensitive. Example prompts:
|
| get_org_account_eventsA | Get health events for a specific AWS account in your organization. Args: account_id: The 12-digit AWS account ID. Example prompts:
|
| get_org_scheduled_changesA | Get scheduled changes/maintenance events across your AWS Organization. Returns upcoming maintenance affecting accounts in your organization. Example prompts:
|
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 11 tools
The org-prefixed mirror set is a coherent pattern, but several pairs overlap heavily: get_service_health vs get_service_events (both return current event data for a service), and get_org_account_events vs get_org_health_events (the latter already filters by account_id). Descriptions help somewhat but the 'health' vs 'events' distinction is subtle enough to cause misselection.
Every tool follows a strict get_<scope>_<resource> snake_case pattern with a consistent 'org' prefix to mark organization-wide variants. Naming is fully predictable and readable.
11 tools is within a reasonable range, but roughly half are org-scope duplicates of single-account tools, so the effective unique surface is smaller than the count suggests.
Covers active/upcoming events, per-service and per-account queries, scheduled changes, affected entities, and completed history across both single-account and org scopes. A dedicated get-event-by-ARN details tool is missing but not a hard blocker.