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

mcp-elasticache-ops

by ritojoao
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Aws Upgrade Plan

aws_upgrade_plan
Read-onlyIdempotent

Run an engine upgrade pre-flight check for an ElastiCache replication group to get a go or no-go verdict with blockers and caveats before changing versions.

Instructions

Engine upgrade pre-flight, verdict first: go or no-go plus blockers (version path, Redis to Valkey, parameter group family, status, failover, snapshot freshness), then caveats (ACL/TLS, quirks, service updates, window). An unreadable gate blocks. Describe calls only.

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": {
      "replication_group_id": "<replication_group_id>"
    },
    "name": "aws_upgrade_plan"
  }
}

Input Schema

NameRequiredDescriptionDefault
regionNoAWS region; defaults to AWS_REGION
target_engineNoDefault: the current engine
target_versionNoExact or major.minor prefix; default newest
replication_group_idYesReplicationGroupId to check
snapshot_max_age_hoursNoNewest snapshot must be younger

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 cover the read-only/idempotent/undestructive profile, so the bar is lower, and the description adds real behavioral detail: output is verdict-first with blockers, then caveats, and 'an unreadable gate blocks' documents a fail-closed rule an agent would not otherwise know. 'Describe calls only' also confirms no mutation side effects. It still doesn't note credential/permission needs or latency, keeping it below a 5.

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?

Very compact and front-loaded — verdict, then blockers, then caveats, matching the reported output order. The bulleted parenthetical lists are efficient, though the fragment style ('An unreadable gate blocks. Describe calls only.') is terse to the point of being slightly cryptic.

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?

The tool performs many checks, and the description enumerates them (version path, engine migration, parameter group family, status, failover, snapshot freshness) plus failure semantics, while an output schema exists so return structure need not be explained. It is largely complete; only the meaning of 'describe calls only' and any permission prerequisites remain unexplained.

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 region, target_engine, target_version, replication_group_id and snapshot_max_age_hours are already documented in the schema. The description references the concepts behind them (version path, Redis-to-Valkey, snapshot freshness) but adds no syntax, defaults, or edge-case meaning beyond the schema; baseline 3 applies.

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 task — an engine upgrade pre-flight for a replication group that returns a go/no-go verdict plus blockers — which is clearly distinct from sibling read tools like aws_engine_versions or aws_failover_readiness. It stops short of a clean verb+resource sentence, using telegraphic phrasing ('Engine upgrade pre-flight, verdict first'), but an agent can tell what it does.

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?

'Pre-flight' implies you run this before an actual engine upgrade, and the enumerated checks hint at what it covers, but no alternatives are named (e.g., when to use aws_engine_versions or aws_failover_readiness instead) and there is no explicit when-not guidance. Usage is implied rather than stated.

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