lookup_events is the fast path once you have a username or an API name, and it reaches back 90 days over management events. Anything aggregate — how often, by whom, in what order — becomes a Lake query, which runs asynchronously: start it, check the status, then page the results out. Every tool reads; none of them can change the account being examined.
A read-only server over AWS CloudTrail. It looks up account activity events by attribute, and runs SQL against CloudTrail Lake for the aggregate questions a lookup cannot answer.
- Events looked up by attribute — username, event name, resource name and more — across the last 90 days of management events, with a time range and paging — lookup_events
- SQL over CloudTrail Lake in Trino-compatible syntax, for filtering and aggregation across stored events — lake_query
- A running query's status checked, so a long one can be started and picked up later — get_query_status
- Completed query results retrieved page by page for large result sets — get_query_results
- The Event Data Stores available, with their capabilities and event selectors — list_event_data_stores
An AWS account with CloudTrail. Event History is on by default; CloudTrail Lake has to be enabled separately before the SQL tools have anything to query. Configure credentials with aws configure or environment variables, and grant cloudtrail:LookupEvents, ListEventDataStores, GetEventDataStore, StartQuery, DescribeQuery and GetQueryResults. Install uv, install Python with uv python install 3.10, and run awslabs.cloudtrail-mcp-server through uvx — it runs on the same host as the client.
One command — uvx awslabs.cloudtrail-mcp-server@latest