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

mcp-elasticache-ops

by ritojoao
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Aws Security Audit

aws_security_audit
Read-onlyIdempotent

Audits ElastiCache fleet security from existing Describe data, reporting findings by severity and category (transit, at rest, auth, ACL, network, snapshots, patching) plus a per-resource pass/fail matrix.

Instructions

Fleet hardening roll-up from existing Describe data (no new IAM), Redis and Memcached. Findings first: counts by severity, findings by category (transit, at rest, auth, ACL, network, snapshots, patching) naming the resource, then a pass/fail matrix capped to top. A denied call is a note, partial=true.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "aws_security_audit"
  }
}

Input Schema

NameRequiredDescriptionDefault
topNoRows of the per-resource pass/fail matrix
regionNoAWS region; defaults to AWS_REGION

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 read-only, idempotent, non-destructive, open-world. The description adds genuinely new behavior: it uses only existing Describe data so no new IAM is granted, findings are emitted before the matrix, and a denied call degrades to a note with partial=true rather than failing. That partial-failure semantics is real value beyond the annotations.

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, with the headline output ('Findings first') stated up front and supporting details after. The telegraphic style ('no new IAM', 'a denied call is a note') reads tersely but each clause carries information.

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 read-only audit tool with an output schema and full parameter documentation, the description supplies ordering, the top cap, the absence of new IAM grants, and partial-result semantics. An agent could call this correctly from the definition alone; only the sibling-routing question is left unspoken.

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 coverage is 100%, so the two parameters are already documented. The description adds only that `top` caps the pass/fail matrix rows, which is mild elaboration over the schema's own text; `region` is not addressed in the description at all. Baseline 3 applies when the schema carries the load.

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?

Names a specific deliverable (fleet hardening roll-up) and its scope (Redis and Memcached, existing Describe data), plus the finding categories inventoried. It does not explicitly differentiate itself from the numerous sibling audit tools (aws_backup_audit, aws_replication_group_audit, etc.), but the resource-and-purpose statement is clear enough to identify the tool.

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 by 'fleet hardening roll-up' — the agent can infer this is the broad posture audit rather than a single-domain one — but there is no explicit when-to-use, when-not-to-use, or pointer to a sibling. A reader must infer the routing from the phrase 'fleet'.

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