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

mcp-elasticache-ops

by ritojoao
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Node Keyspace Sample

node_keyspace_sample
Read-onlyIdempotent

Samples Redis/Valkey keyspace metadata on one ElastiCache node using bounded SCAN to identify big, hot, cold, TTL, and prefix-level patterns without reading values.

Instructions

Big keys, hot (LFU) or cold keys, type mix, TTL coverage, per-prefix bytes from a bounded SCAN. Metadata only, never values. partial=true at max_seconds. Cluster mode: this node only (see node_cluster_keyspace_sample). include_access adds the idle-key share; include_sizes flags large collections.

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": "node_keyspace_sample"
  }
}

Input Schema

NameRequiredDescriptionDefault
topNo
matchNoSCAN MATCH glob, e.g. 'session:*'
pause_msNoSleep between SCAN batches
scan_countNoSCAN COUNT hint
max_secondsNoWall-clock budget; returns partial=true when exceeded
sample_sizeNoMax keys to inspect
top_prefixesNoKey prefixes to report
include_sizesNoAdd a collections block: key prefixes whose collections exceed size_threshold elements
include_accessNoAdd an access block: share of sampled keys idle over 7 days (OBJECT IDLETIME) or with a cold LFU counter (OBJECT FREQ), with an eviction-risk hint
size_thresholdNoElement count above which a collection is flagged

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds real behavior beyond them: metadata only, never values (privacy guarantee), a partial=true outcome when the wall-clock budget is hit, this-node-only scope in cluster mode, and what the optional blocks contribute. It stops short of stating scan cost or server-load implications of the SCAN/pause_ms loop.

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?

Dense, front-loaded, and every clause carries content — outputs first, then safety, then the partial-result caveat, then scope, then flags. The telegraphic comma-list style ('Big keys, hot (LFU) or cold keys, type mix...') is slightly clipped but wastes no words.

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?

With 10 optional parameters, an output schema, and full annotations, the description supplies what structured data cannot: what is reported, that keys are sampled rather than exhaustively scanned, the partial-result condition, and node vs cluster scope. Only the tuning relationship among the sampling knobs is left implicit.

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 90%, so the schema already documents top, match, scan_count, sample_size, size_threshold and the two include_* flags. The description only restates the include_access/include_sizes effects and leaves the interplay of sample_size, scan_count and max_seconds unexplained; 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?

The description names the concrete outputs — big keys, hot (LFU)/cold keys, type mix, TTL coverage, per-prefix bytes — and the mechanism (a bounded SCAN). It also explicitly disambiguates from the sibling: 'Cluster mode: this node only (see node_cluster_keyspace_sample)'. An agent can choose this tool over node_cluster_keyspace_sample without opening a 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?

It gives a clear routing rule for the cluster-wide alternative and signals when the optional blocks matter ('include_access adds the idle-key share; include_sizes flags large collections'). It does not explicitly say when to prefer this over other keyspace-adjacent siblings (e.g. hot-slot or memory tools), so no exclusion guidance beyond the one named alternative.

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