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

mcp-elasticache-ops

by ritojoao
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Node Cluster Slowlog

node_cluster_slowlog
Read-onlyIdempotent

Collects slow log entries from all shard primaries in an ElastiCache cluster to surface the slowest commands, per-command totals, and per-shard status for latency diagnosis.

Instructions

node_slowlog on every shard primary: the slowest entries overall labelled by shard, per-command totals and per-shard status. Arguments beyond the key are hidden unless include_args is 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": "node_cluster_slowlog"
  }
}

Input Schema

NameRequiredDescriptionDefault
countNoEntries to return overall
max_workersNoConcurrent shard probes
include_argsNoReturn full command arguments (may expose values)
per_node_timeoutNoSeconds to wait per node

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already cover the read-only, idempotent, non-destructive profile, so the description's job is to add semantics — and it does: it discloses the fan-out across shard primaries, that results are labelled by shard with per-command totals and per-shard status, and critically that command arguments are redacted unless include_args is set. It does not discuss partial shard failures or timeout behavior beyond what the schema states.

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?

Two tight sentences with no filler, and the scope plus return shape are front-loaded. The first sentence is densely packed with clause-like fragments, which slightly reduces readability but not efficiency.

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 a 100%-covered schema, four optional parameters and an output schema, the description only needs to explain aggregation behavior and result labelling, and it does. Redaction behavior and per-shard status are both called out, leaving little an agent would need to guess.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3, but the description adds real meaning for include_args: without it, arguments are hidden except the key, which tells the agent the default output is sanitized. The other three parameters (count, max_workers, per_node_timeout) are left entirely to the schema.

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 names a concrete operation and scope: it runs the slowlog against 'every shard primary' and returns the slowest entries labelled by shard, per-command totals and per-shard status. That is enough to distinguish it in spirit from the sibling node_slowlog (single node), though it never names that sibling explicitly.

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?

The cluster-wide scope implies when this tool is preferable to a per-node slowlog, but the guidance is only implicit. There is no explicit 'use this instead of node_slowlog when...' statement, no mention of cost/latency of probing all shards, and no exclusion criteria.

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