Aws Metrics

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds real value beyond them by describing output ordering ('Findings first, then min/avg/max/latest') and flagging that include_series is token heavy. It still omits cost/rate-limit behavior and how missing data or empty periods are handled, so it stays at a 3.

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

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

Two dense sentences with no filler; the metric taxonomy is front-loaded and the output-shape/cost caveat follows. The long parenthetical metric list is informative but slightly heavy, which keeps it from a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be spelled out, and annotations cover the safety profile. However, with 9 parameters and only 56% schema description coverage, the description should clarify node_id, serverless, and cluster-vs-group targeting to be fully sufficient for correct invocation.

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

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

Schema coverage is 56%, above the low-coverage threshold, and the schema itself documents region, metrics, period_seconds, cache_cluster_id and replication_group_id. The description reinforces metrics and include_series but says nothing about node_id, serverless, minutes, or the interaction between cache_cluster_id and replication_group_id, leaving the undocumented half of the parameters unexplained.

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

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

The description names the exact data source (CloudWatch AWS/ElastiCache metrics) and enumerates the metric families per engine (Redis/Valkey vs Memcached), so an agent knows precisely what it retrieves. It does not explicitly distinguish itself from siblings like aws_cache_clusters or aws_triage, leaving that comparison implicit.

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

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

Usage is implied rather than stated: the metric lists suggest performance investigation, and 'raw series only with include_series=true' gives a concrete cost tradeoff for one flag. There is no explicit when-to-use versus alternatives (e.g. inventory tools or triage) and no exclusion criteria, so the agent must infer routing.

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