AWS Labs CloudTrail MCP Server

Overview

AWS Labs CloudTrail MCP Server is a local stdio Model Context Protocol server for querying AWS CloudTrail Event History and CloudTrail Lake data. It is intended for security investigations, compliance auditing, operational troubleshooting, user activity analysis, API call tracking, and CloudTrail Lake analytics.

Install and launch

The README documents a Python/uvx installation path. The default MCP client launch is:

{
  "mcpServers": {
    "awslabs.cloudtrail-mcp-server": {
      "autoApprove": [],
      "disabled": false,
      "command": "uvx",
      "args": ["awslabs.cloudtrail-mcp-server@latest"],
      "env": {
        "AWS_PROFILE": "",
        "FASTMCP_LOG_LEVEL": "ERROR"
      },
      "transportType": "stdio"
    }
  }
}

The package is published on PyPI as awslabs.cloudtrail-mcp-server; the reviewed PyPI/source distribution version is 0.0.15. The package entrypoint awslabs.cloudtrail-mcp-server calls mcp.run() with default transport, and tests assert no explicit transport override is passed.

Docker option

The README also documents an optional local Docker image path with docker build and docker run flags. This submission has only a uvx package target, so Docker build/run flags are documented as a separate installation option and are not included in packages[].packageArguments for the uvx target.

Configuration

The server uses boto3 to create CloudTrail clients for the region requested by each tool call. Source review found direct use of AWS_PROFILE; when it is present, the server creates boto3.Session(profile_name=AWS_PROFILE, region_name=region), otherwise it creates boto3.Session(region_name=region) and relies on the default boto3 credential chain.

The README requires AWS credentials with CloudTrail permissions, configured through aws configure or environment variables. FASTMCP_LOG_LEVEL=ERROR is documented in the MCP client launch configuration.

Tools

The server registers five MCP tools:

• lookup_events: looks up CloudTrail Event History records from the last 90 days with optional time range, attribute filter, pagination token, max results, and region.
• lake_query: starts a CloudTrail Lake SQL query. It supports Trino-compatible SELECT queries and can wait for completion or return a query ID immediately.
• list_event_data_stores: lists CloudTrail Lake Event Data Stores and can include detailed event selector metadata.
• get_query_status: checks CloudTrail Lake query status.
• get_query_results: retrieves completed CloudTrail Lake query results with pagination.

Required IAM permissions

The README lists these IAM permissions:

• cloudtrail:LookupEvents
• cloudtrail:ListEventDataStores
• cloudtrail:GetEventDataStore
• cloudtrail:StartQuery
• cloudtrail:DescribeQuery
• cloudtrail:GetQueryResults

Prerequisites

• AWS account with CloudTrail enabled. Event History is enabled by default; CloudTrail Lake must be enabled for SQL queries.
• Local execution on the same host as the LLM client.
• AWS credentials with the required CloudTrail permissions.
• uv and Python 3.10+ for the uvx package path.
• Docker only if using the optional local Docker image path.

Limitations and security notes

CloudTrail Event History lookup only covers the last 90 days of management events. CloudTrail Lake SQL requires a valid Event Data Store ID in the FROM clause, supports Trino-compatible SELECT statements, and does not support INSERT, UPDATE, DELETE, CREATE, DROP, other DDL/DML operations, or CTEs. The lake_query implementation waits up to 300 seconds when wait_for_completion is true. Tool result pagination requires callers to reuse the same lookup parameters with returned pagination tokens. The README says this server can only be run locally on the same host as the LLM client. All CloudTrail API access uses the AWS credentials available to boto3, so users should apply least-privilege IAM permissions.