Skip to main content
Glama
zb-ss

Servonaut

by zb-ss
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

cloudwatch_get_log_events

Fetch recent Amazon CloudWatch log events for a log group within a chosen time window, optionally filter patterns, aggregate by client IP/status/URI, or return only counts.

Instructions

Fetch recent events from a CloudWatch log group within the last N hours, with an optional filter pattern. Set group_by (clientIp|status|uri) to get a server-side ranked summary (top_n, default 20) instead of raw lines — avoids dumping huge log pulls. summary_only returns just the event count.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
top_nNoWhen group_by is set, how many top entries to return (0 = default 20).
regionNoAWS region (optional).
accountNoAWS account label to act in; omit for the default account.
group_byNoAggregate the events by this structured field and return a ranked summary.
client_ipNoConvenience: build the structured WAF/ALB selector { $.httpRequest.clientIp = "x" } for this IP. Overrides filter_pattern.
log_groupYesCloudWatch log group name.
hours_backNoHow many hours back to search.
max_eventsNoMaximum events to return (0 = unlimited, capped at 50000).
summary_onlyNoReturn only the event count, not raw lines.
filter_patternNoCloudWatch Logs filter pattern (optional). A bare literal (an IP, a path) is auto-quoted so it matches reliably; JSON/space-delimited patterns are passed through untouched.

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

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral burden, and it does disclose that aggregation is server-side, that group_by trades raw lines for a ranked summary, and that summary_only returns a count. It omits read-only framing, throttling/limits, and return format, but adds genuine behavioral context beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, front-loaded with the core action, then the aggregation mode, then the count-only mode. No filler; every clause conveys callable behavior.

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?

For a 10-parameter tool with no output schema and no annotations, the description covers the main sources of complexity (group_by mode, summary_only, filter behavior) so an agent can call it correctly. Minor gaps remain on ranking/return-shape expectations, but the annotation-free safety profile is implicitly read-only.

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

Parameters3/5

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

Schema description coverage is 100%, so every parameter is already documented in the schema. The description reinforces group_by, top_n default, and summary_only but adds little semantic detail (e.g., no ranking semantics) beyond what the schema states. Baseline 3 applies.

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

Purpose5/5

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

States a specific verb and resource ('Fetch recent events from a CloudWatch log group') and further distinguishes its three modes (raw lines, server-side ranked summary, count-only). An agent can tell this apart from cloudwatch_list_log_groups or get_logs without opening the schema.

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

Usage Guidelines4/5

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

Gives clear conditional guidance: set group_by to get a ranked summary 'instead of raw lines — avoids dumping huge log pulls,' and summary_only for just a count. It explains when to pick each mode but names no sibling alternative and gives no explicit when-not.

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