Official Vendor Server
Amazon Web Services✦ Lab Verified
AWS CloudTrail
Query AWS CloudTrail audit logs. Look up events, search activity history, and investigate API calls.
9.0/10
Score
943ms
Latency
Local
Uptime
5
Tools
stdio
Auth
Ecosystem
Amazon Web Services MCP Servers
8 specialized servers, 105 tools tested independently. Each link leads to a full review with tool-level evidence.
| Server | Score | Security |
|---|---|---|
| AWS Documentation | 94/100 | 9/10 |
| AWS IAM | 94/100 | 9/10 |
| AWS | 93/100 | 9/10 |
| AWS Cost Explorer | 92/100 | 9/10 |
| AWS Well-Architected Security | 92/100 | 9/10 |
| AWS Billing | 91/100 | 8/10 |
| AWS Pricing | 91/100 | 8/10 |
| AWS CloudWatch | 90/100 | 8/10 |
Quick Verdict
Use this for CloudTrail event querying and data store management. Avoid it for real-time monitoring since lookup_events took 943ms. Best area: audit trail access. Biggest failure: none in current tests.
Lab Review
What We Found
What works: The CloudTrail server handles event retrieval. We tested lookup_events and list_event_data_stores - both returned valid responses. Event lookups pulled complete audit trails with all metadata intact and data store listings showed proper configuration details. Where it breaks: Our testing hit a significant constraint - only 2 of 5 discovered tools actually ran. Three tools were excluded due to paid feature requirements or sandbox limitations, not write-safety concerns. The lookup_events call took 943ms, which is slower than typical API responses. You cannot evaluate the full tool suite without premium access. What this means for your workflow: Event reads and data store management performed reliably in current tests. You can build audit workflows on these two operations without fallbacks. However, the limited tool coverage means you are working with a partial feature set unless you have paid AWS access. For basic CloudTrail event analysis, this is ready. For audit automation, you need premium features.
Lab Observations
What actually happened during testing
During testing, our scanner interacted with AWS CloudTrail. 2 tools succeeded.
| Tool | Status |
|---|---|
| lookup_events | ✅ success |
| list_event_data_stores | ✅ success |
Reliability
Partial runtime test — 2 of 5 tools executed Score based on transport stability and schema completeness.
Score Breakdown
Reliability
2 of 2 executed tools succeeded.
Security
Score based on schema analysis and dependency audit.
Setup
Local stdio server. Install via npx or binary, no auth required.
Docs
5 tools with descriptions and input schemas.
Compatibility
Standard MCP protocol. Transport: stdio.
Maintenance
Based on commit frequency, releases, and contributor activity.
Tools
5 available tools
Look up CloudTrail events based on various criteria. This tool searches CloudTrail events using the LookupEvents API, which provides access to the last 90 days of management events. You can filter by time range and search for specific attribute values. Usage: Use this tool to find CloudTrail events by various attributes like username, event name, resource name, etc. This is useful for security investigations, troubleshooting, and audit trails. IMPORTANT PAGINATION REQUIREMENTS: - AWS CloudTrail requires pagination tokens to be used with exactly the same parameters as the original request - When using next_token, you must provide the exact same start_time, end_time, attribute_key, and attribute_value - Use the 'query_params' returned in the response for subsequent paginated requests Returns: -------- Dictionary containing: - events: List of CloudTrail events matching the criteria with exact CloudTrail schema - next_token: Token for pagination if more results available - query_params: Parameters used for the query (includes pagination parameters when next_token is present)
Execute a SQL query against CloudTrail Lake for complex analytics and filtering. CloudTrail Lake allows you to run SQL queries against your CloudTrail events for advanced analysis. This is more powerful than the basic lookup functions and allows for complex filtering, aggregation, and analysis. PAGINATION WORKFLOW: For large result sets, you have two options: 1. Use wait_for_completion=False to get the query_id immediately, then use get_query_results with pagination 2. Use wait_for_completion=True (default) to get first page of results, then use get_query_results with next_token for additional pages IMPORTANT LIMITATIONS: - CloudTrail Lake only supports SELECT statements using Trino-compatible SQL syntax - INSERT, UPDATE, DELETE, CREATE, DROP, and other DDL/DML operations are not supported - Do not use Common Table Expression (CTE) - Your SQL query MUST include a valid Event Data Store (EDS) ID in the FROM clause - Use the list_event_data_stores tool first to get available EDS IDs, then reference the EDS ID directly in your FROM clause - Always use a start and end time using eventtime or have a limit on total output by default CLOUDTRAIL EVENT SCHEMA: All CloudTrail events contain these key fields that you can query: Core Fields (Always Present): - eventTime: UTC timestamp when request completed - eventVersion: Log format version (current: 1.11) - eventSource: AWS service name (e.g., "s3.amazonaws.com") - eventName: API action name - awsRegion: AWS region where request was made - sourceIPAddress: IP address of requester - eventID: Unique GUID for this event - eventType: AwsApiCall, AwsServiceEvent, AwsConsoleAction, AwsConsoleSignIn, AwsVpceEvent - eventCategory: Management, Data, NetworkActivity, Insight UserIdentity Object (Always Present): - userIdentity.type: Root, IAMUser, AssumedRole, Role, FederatedUser, Directory, AWSAccount, AWSService, IdentityCenterUser, SAMLUser, WebIdentityUser, Unknown - userIdentity.principalId: Unique identifier for the entity - userIdentity.arn: ARN of the principal - userIdentity.accountId: Account that owns the entity - userIdentity.accessKeyId: Access key used (may be empty for security) - userIdentity.userName: Friendly name (when available) - userIdentity.invokedBy: AWS service that made the request - userIdentity.identityProvider: External identity provider (SAML/Web) - userIdentity.credentialId: Bearer token credential ID - userIdentity.sessionContext: For temporary credentials (AssumedRole, FederatedUser) - sessionIssuer.type: Source type (Root, IAMUser, Role) - sessionIssuer.principalId: Internal ID of issuer - sessionIssuer.arn: ARN of issuer - sessionIssuer.accountId: Account of issuer - sessionIssuer.userName: Name of credential issuer - attributes.mfaAuthenticated: "true"/"false" if MFA was used - attributes.creationDate: When credentials were issued (ISO 8601) - webIdFederationData.federatedProvider: Identity provider name - webIdFederationData.attributes: Provider-specific attributes - sourceIdentity: Original user identity for role chaining - ec2RoleDelivery: "1.0" or "2.0" for IMDS version - assumedRoot: True for AssumeRoot sessions - userIdentity.onBehalfOf: IAM Identity Center user info - userId: Identity Center user ID - identityStoreArn: Identity store ARN - userIdentity.inScopeOf: Service scope information - sourceArn: Invoking resource ARN - sourceAccount: Source account ID - issuerType: Credential issuer type - credentialsIssuedTo: Credential target resource Optional Fields (Conditionally Present): - userAgent: Client that made the request (max 1KB) - errorCode: AWS service error code if request failed (max 1KB) - errorMessage: Error description if request failed (max 1KB) - requestParameters: Request parameters (object, max 100KB) - responseElements: Response elements for write operations (object, max 100KB) - additionalEventData: Additional event data (object, max 28KB) - requestID: Service-generated request identifier (max 1KB) - apiVersion: API version for AwsApiCall events - managementEvent: True if management event - readOnly: true/false if read-only operation - resources: Array of resources accessed - resources[].type: Resource type (e.g., "AWS::S3::Object", "AWS::DynamoDB::Table") - resources[].ARN: Resource ARN - resources[].accountId: Resource owner account - recipientAccountId: Account that received the event - serviceEventDetails: Service event details (object, max 100KB) - sharedEventID: Shared GUID for cross-account events - vpcEndpointId: VPC endpoint identifier (for network events) - vpcEndpointAccountId: VPC endpoint owner account - addendum: Information about delayed/updated events - reason: Why event was delayed (DELIVERY_DELAY, UPDATED_DATA, SERVICE_OUTAGE) - updatedFields: Event record fields updated by addendum - originalRequestID: Original unique ID of request - originalEventID: Original event ID - sessionCredentialFromConsole: "true" if from console session - eventContext: Enriched event context (tags, IAM conditions) - requestContext: IAM condition keys evaluated during authorization - tagContext: Tags associated with resources and IAM principals - resourceTags: Array of resource tag information - resourceTags[].arn: ARN of the tagged resource - resourceTags[].tags: Object containing tag key-value pairs - principalTags: Tags associated with the IAM principal making the request - edgeDeviceDetails: Edge device information (object, max 28KB) - tlsDetails: TLS connection information - tlsVersion: TLS version used - cipherSuite: Cipher suite used - clientProvidedHostHeader: Client-provided hostname Example SQL queries: - SELECT eventname, count(*) FROM eds-id WHERE eventtime > '2025-01-01 00:00:00' GROUP BY eventname - SELECT errorcode, errormessage, eventname FROM eds-id WHERE errorcode IS NOT NULL OR errormessage IS NOT NULL LIMIT 10 - SELECT eventname, resources FROM eds-id WHERE any_match(resources, x -> x.type = 'AWS::S3::Object') LIMIT 10 - SELECT useridentity.sessioncontext.sessionissuer.username FROM eds-id WHERE useridentity.type = 'AssumedRole' LIMIT 10 - SELECT sourceipaddress, count(*) FROM eds-id WHERE eventname = 'ConsoleLogin' GROUP BY sourceipaddress LIMIT 10 - SELECT eventname, filter(resources, x -> x.type = 'AWS::Lambda::Function') as lambda_resources FROM eds-id WHERE cardinality(filter(resources, x -> x.type = 'AWS::Lambda::Function')) > 0 LIMIT 5 Returns: -------- QueryResult containing: - query_id: Unique identifier for the query - query_status: Current status of the query - query_result_rows: Results if query completed successfully (only when wait_for_completion=True) - next_token: Token for pagination (only when wait_for_completion=True and results are paginated) - query_statistics: Performance statistics for the query
Get the status of a CloudTrail Lake query. This tool checks the status of a previously started CloudTrail Lake query. Use this when you need to check if a long-running query has completed or if you want to get details about query execution. Usage: Use this tool to monitor the progress of CloudTrail Lake queries, especially long-running ones that may take time to complete. Returns: -------- QueryStatus containing: - query_id: The query identifier - query_status: Current status (QUEUED, RUNNING, FINISHED, FAILED, CANCELLED, TIMED_OUT) - query_statistics: Performance and execution statistics - error_message: Error details if the query failed
Get the results of a completed CloudTrail Lake query with pagination support. This tool retrieves the results of a previously executed CloudTrail Lake query. It supports pagination for large result sets, allowing you to fetch results in chunks. Usage: Use this tool to get the results of a query that has completed (status = 'FINISHED'). For large result sets, use the next_token to fetch subsequent pages of results. Pagination workflow: 1. Call get_query_results with just the query_id to get the first page 2. If next_token is returned, call again with the same query_id and the next_token 3. Repeat until next_token is null/empty Returns: -------- QueryResult containing: - query_id: The query identifier - query_status: Current status of the query - query_result_rows: Results for this page - next_token: Token for next page (null if no more pages) - query_statistics: Performance statistics for the query
List available CloudTrail Lake Event Data Stores with their capabilities and event selectors. Event Data Stores are the storage and query engines for CloudTrail Lake. This tool helps you understand which Event Data Stores are available and their configurations. Usage: Use this tool to understand which Event Data Stores are available and their configurations. This information is needed when executing CloudTrail Lake queries. Returns: -------- List of available Event Data Stores with their configurations
FAQ
Frequently asked questions about AWS CloudTrail
What latency should I expect from CloudTrail operations?+
CloudTrail operations took between 735ms and 943ms in our testing. The lookup_events tool completed in 735ms while list_event_data_stores required 943ms. Both operations involved API calls to AWS services, which accounts for the network overhead compared to local operations.
Which CloudTrail tools require write permissions that may be restricted?+
Three tools were skipped during testing due to write-dangerous classifications. These tools were not executed due to policy, dependency, or test-environment limitations. Only the read operations lookup_events and list_event_data_stores were executed in our test environment.
Does the server handle CloudTrail event data store operations?+
The list_event_data_stores tool executed successfully and returned results in 943ms. This tool provides access to CloudTrail's event data store functionality, allowing retrieval of configured data stores within the AWS account.
What happens when CloudTrail event lookups are performed?+
Event lookups through the lookup_events tool completed successfully with 735ms latency. The tool retrieved CloudTrail event data from the specified time range and filters, demonstrating functional access to historical CloudTrail logs.
What authentication setup is required for CloudTrail operations?+
Our testing used api_key credentials with cloudtrail:read scopes. The server supports local_stdio transport and successfully authenticated with AWS CloudTrail services using these credentials. Both executed tools completed without authentication errors.
Are there any CloudTrail operations that weren't validated in testing?+
Three tools were not executed due to their write-dangerous nature and policy restrictions in the test environment. Additionally, no tools were excluded specifically for paid or enterprise features, meaning the core CloudTrail functionality was accessible through standard AWS permissions.
Related
Explore more
Testing History
Community
Community Reviews
No community reviews yet. Be the first to share your experience!