Skip to main content
Glama
Sign In
mcp-elasticache-ops

mcp-elasticache-ops

by ritojoao
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Aws Parameter Drift

aws_parameter_drift
Read-onlyIdempotent

Compare two AWS ElastiCache parameter groups to identify modified values that differ, listing only changed parameters and flagging family mismatch warnings.

Instructions

DescribeCacheParameters on two groups: only parameters whose values differ and that someone modified (default-only differences are counted, not listed), plus family mismatch warnings.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "group_a": "<group_a>",
      "group_b": "<group_b>"
    },
    "name": "aws_parameter_drift"
  }
}

Input Schema

NameRequiredDescriptionDefault
regionNoAWS region; defaults to AWS_REGION
group_aYesFirst cache parameter group name (e.g. production)
group_bYesSecond cache parameter group name (e.g. staging)

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

A3.7/5.0
Behavior4/5

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. Beyond that, the description adds real behavioral detail: only modified parameters with differing values are listed, default-only differences are counted but not enumerated, and family mismatch warnings are surfaced. It does not discuss pagination or limits, but the core result semantics are disclosed.

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?

It is a single dense sentence with no filler, and the key filtering rule comes early. The parenthetical about default-only differences is slightly cryptic and could be phrased more plainly, but nothing is redundant.

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?

An output schema exists, so return structure need not be explained, and the description focuses on what differentiates the result set (modified-only listing, default-only counts, family mismatch warnings). For a three-parameter, read-only comparison tool that is close to complete; only explicit sibling routing is missing.

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%, with region, group_a and group_b all documented inline, so the schema carries the parameter burden. The description confirms that the two group parameters are the comparison inputs but adds no format, naming convention, or edge-case detail (e.g. cross-family behavior) beyond the schema. Baseline 3 is appropriate.

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?

The description states a specific operation (DescribeCacheParameters comparison) over a specific resource (two cache parameter groups) and specifies the output shape: only differing, human-modified parameters plus family mismatch warnings. It is distinguishable from sibling tools like aws_parameters and aws_parameter_groups by virtue of being a two-group diff, though it never names an alternative explicitly and leads with API jargon rather than a plain verb.

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?

Usage is implied rather than stated: comparing group_a against group_b to find drift. There is no explicit when-to-use framing, no when-not conditions, and no reference to the sibling tools (aws_parameters, aws_parameter_groups) that an agent might confuse this with. The agent must infer the comparison scenario from the wording.

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