Skip to main content
Glama
zb-ss

Servonaut

by zb-ss
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

cloudtrail_lookup_events

Look up AWS CloudTrail management events with filters for event name, username, and resource type to audit who changed what and from which source IP.

Instructions

Look up AWS CloudTrail management events with optional filters (event name, username, resource type). Filters are exact, case-sensitive matches and may be combined. Useful for auditing who changed what, and from which source IP.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
regionNoAWS region. Empty queries the configured default region (or all regions if unset).
accountNoAWS account label to act in; omit for the default account.
usernameNoFilter by the IAM username.
event_nameNoFilter by CloudTrail event name (e.g. 'RunInstances').
hours_backNoHow many hours back to search. 0 uses the configured default lookback.
max_resultsNoMaximum events to return (0 = unlimited, capped at 10000).
resource_typeNoFilter by resource type (e.g. 'AWS::EC2::Instance').

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.28.0
    • addedInput schema / properties / account
      Added value: +{
+  "description": "AWS account label to act in; omit for the default account.",
+  "type": "string"
+}
  2. Addedv2.24.0
  3. Removedv2.23.8
  4. First observedv1.0.0

TDQS

A3.6/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations, so the description carries the full burden. It does add genuinely useful behavior — filters are exact, case-sensitive matches and may be combined — which is not in the schema. However it omits read-only confirmation, result volume/pagination behavior, and any auth/permission notes, leaving gaps for a tool with zero annotation coverage.

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?

Two compact sentences that front-load the verb and resource, then the filter semantics and use case. Every clause carries information; nothing is padded, though it could be marginally tighter.

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?

There is no output schema or annotations, so the description must stand alone; it covers purpose, filter semantics, and a use case. The main remaining gap is the return shape and read-only nature, but for a filtered-lookup tool with 100% schema coverage on parameters this is largely complete.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description earns above baseline by adding semantics the schema lacks: the filter params (event_name, username, resource_type) are exact, case-sensitive, and combinable. It adds no extra meaning for region/account/hours_back/max_results, which the schema already documents.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: 'Look up AWS CloudTrail management events'. The resource (CloudTrail) is clearly distinct from the sibling CloudWatch log tools, so an agent can route without opening the schema. It stops short of explicitly contrasting with any sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Offers an implied use case ('useful for auditing who changed what, and from which source IP') but gives no when-to-use vs when-not guidance and never names an alternative (e.g. cloudwatch_get_log_events). The agent must infer that CloudTrail is the right source for audit trails.

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

Deploy Server

Other Tools