redis-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.3.1
Disambiguation5/5
Each tool has a clearly distinct purpose: scanning keys, inspecting single key metadata, reading values, running generic commands, health check, slow log, and advisor. No overlap.
Naming Consistency5/5
All tool names follow the consistent pattern redis_<action>, using descriptive nouns (scan, key_info, get, command, health, slowlog, advisor). No mixing of conventions.
Tool Count5/5
7 tools is well-scoped for a Redis diagnostic and data access server. Each tool earns its place, covering essential operations without bloat.
Completeness4/5
Covers key read operations, scanning, health, and diagnostics. Write operations (set, delete) are available via redis_command with write gate, but a dedicated write tool is missing, making coverage not fully explicit.
Average 4.6/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 17 commits in the last 12 weeks
- Last stable release on August 23, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds extensive behavioral detail about the specific metrics and data sources (INFO, DBSIZE, SLOWLOG), which goes beyond annotations and provides transparency about what the tool accesses.
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?
The description is a single well-structured paragraph that front-loads the key metrics. It is concise given the amount of information, though it could be slightly more scannable with lists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description thoroughly explains what will be returned. The single parameter is fully documented in schema. The tool is simple and the description covers all necessary context for selection and invocation.
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 baseline is 3. The description mentions slow commands in context but does not add new meaning to the 'slowlogLimit' parameter beyond the schema's description. No additional value provided.
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 clearly states the tool provides a health snapshot from INFO, DBSIZE, and SLOWLOG, listing specific metrics like server version, memory, clients, ops/sec, keyspace, persistence, replication, and recent slow commands. It distinguishes itself from siblings like redis_slowlog by being a rolled-up summary.
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?
The description explicitly says 'Use as a connection sanity check and the first stop in 'why is Redis slow / using so much memory?' triage,' providing clear when-to-use guidance. It does not explicitly exclude alternatives like redis_advisor, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, non-destructive behavior. The description adds significant behavioral context beyond annotations: it explains the sampling method (SCAN), the four categories (big_keys, missing_ttls, eviction_pressure, fork_latency_risk), and the thresholds used. It also clarifies that findings are over the sample, not the whole keyspace. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured paragraph that front-loads the core purpose and then lists the four categories with clear explanations. Every sentence adds value, and there is no redundant or filler text. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 7 parameters (all with defaults and descriptions in schema) and no output schema, the description provides a complete picture: it explains what the tool returns (four categories with severity and fixes), how it works (sampling), and safety considerations. It covers all essential aspects for an agent to understand and use the tool correctly.
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 the baseline is 3. The description does not re-explain each parameter but provides high-level mapping between parameters and categories (e.g., sampleSize affects key sampling). This adds some context but does not significantly enhance understanding beyond the schema's own descriptions.
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 clearly states the tool's purpose as a 'Rolled-up Redis health lint pass' that returns four categories of findings with severity and actionable fixes. It uses specific verbs ('returns') and resource ('health lint findings'), and distinguishes itself from sibling tools like redis_scan or redis_key_info by providing a comprehensive health assessment in one call.
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?
The description provides explicit context for safe usage: 'Keys are sampled via SCAN (never KEYS), so it is safe on a large production instance.' It implies comprehensiveness but does not explicitly state when not to use it or name alternatives. The sibling tools suggest more specific purposes, but the description itself lacks explicit guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly, idempotent, non-destructive), the description explains TTL semantics, encoding examples, and memory usage via MEMORY USAGE command. It fully discloses what the tool returns and its non-value-reading nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with front-loaded purpose, followed by return details and usage advice. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter and no output schema, the description covers all essential aspects: what is returned, TTL meaning, safe inspection, and use case. No gaps remain.
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 already describes 'key' as 'The key to inspect' with 100% coverage. The description adds no new parameter-specific details (e.g., format, patterns), only behavioral context. Baseline score of 3 is appropriate.
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 clearly states the tool inspects a single key's metadata (type, TTL, encoding, memory, idle time) without reading its value. It distinguishes from sibling redis_get by explicitly recommending use before retrieval.
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?
Explicitly recommends using before redis_get to avoid pulling large values, and to spot big keys/missing TTLs. While it doesn't enumerate all alternatives, the guidance is strong and context-specific.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds value by explaining the data source (slowlog), configuration (slowlog-log-slower-than), and that reset is not exposed. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each informative. Front-loaded with the core purpose. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description explains the fields of each entry. Covers the configuration, why to use it, and what is not exposed. Complete for a simple tool with one parameter.
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?
Input schema has one parameter (limit) with full description, default, min, max. The description does not add meaning beyond the schema but provides context about the log content. Schema coverage is 100%, baseline 3.
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 clearly states it returns recent entries from the Redis slow log, specifying fields (command, execution time, timestamp, client address). It distinguishes itself from other tools by claiming it's the fastest way to find specific slow commands.
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?
Explicitly says it's the fastest way to find slow commands, implying its primary use case. Mentions that SLOWLOG RESET is intentionally not exposed, indicating a limitation. However, it does not compare to sibling tools like redis_advisor or redis_command.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, etc. The description adds critical behavioral details: byte-windowing at REDIS_MAX_VALUE_BYTES, truncation indication, collection caps with limit defaults, and type-specific shape mentions. No contradiction with 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?
The description is a single, well-structured sentence that front-loads the purpose. It is slightly verbose due to listing all types, but each part earns its place. Could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description fully covers return shapes for all types, edge cases (truncation, defaults), and safety (read-only). Context signals show simple parameters, and the description handles the complexity well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. The description adds meaning to 'limit' (default REDIS_MAX_KEYS=1000, windowing) and explains how 'key' is used without extra detail. It enriches the schema's minimal descriptions.
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 clearly states the tool reads a key's value and dispatches by type. It distinguishes from siblings like redis_scan (scan keys) and redis_key_info (key info) by specifying type-aware reading.
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?
The description implies usage for reading any key's value without knowing the type, and notes it's always read-only. It does not explicitly list when not to use or compare to siblings, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, idempotent, etc.), the description reveals critical behaviors: SCAN yields event loop between batches, duplicate removal within a call, possible reappearance across resumed scans, default max keys, and the truncated flag. This fully informs the agent of the tool's safety and pagination model.
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?
The description is a single paragraph but well-organized: starts with the primary purpose, then details pagination, pattern, and type filtering. Every sentence adds value, though a slightly more structured format (e.g., bullet points) could improve scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (cursor-based iteration, safety guarantees, multiple optional parameters) and the absence of an output schema, the description is remarkably complete. It explains return fields (truncated, cursor), pagination semantics, and production safety, leaving no critical gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 4 parameters are fully documented in the schema (100% coverage), but the description adds substantial value: explains cursor-based pagination, default count and its safety implications, pattern matching syntax, and the type filter enum. This goes beyond the schema's basic descriptions.
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 clearly states it enumerates keys with cursor-based SCAN, explicitly contrasting with the O(N) KEYS command and highlighting safety for production. This distinguishes it from sibling tools like redis_get or redis_key_info.
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?
The description provides clear usage context: use for safe key enumeration, especially on production with many keys. It explains how to resume scans with cursor and mentions optional pattern/type filtering. While not explicitly listing when not to use it, the sibling tools are sufficiently different.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant context beyond annotations: it details that read-only commands always run, mutating commands require a flag, and arbitrary commands are never exposed. It explains the safety gate is a curated allowlist, which is crucial for safe usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph but packs essential information efficiently: purpose, behavioral rules, and usage guidance. Every sentence contributes value, and the structure is logical and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of Redis command execution with safety gates and no output schema, the description covers all necessary aspects: allowed/disallowed commands, prerequisites, and alternatives. It is complete for an agent to use correctly.
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. The description adds meaning by noting that for multi-word commands the subcommand is the first arg, which clarifies the 'args' parameter usage beyond the schema description.
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 clearly states 'Run a single Redis command through the safety gate,' specifying what the tool does. It distinguishes from siblings by noting that typed tools (redis_get, redis_scan, redis_key_info) are preferred where they exist, and that KEYS should use redis_scan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use (commands without a dedicated tool) and when not to (prefer typed tools, KEYS via redis_scan). It also provides conditions for mutating commands (ALLOW_WRITES=1) and lists blocked commands, giving clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![redis-mcp MCP server](https://glama.ai/mcp/servers/YawLabs/redis-mcp/badges/card.svg)](https://glama.ai/mcp/servers/YawLabs/redis-mcp)

Score Badge

Copy to your README.md:

[![redis-mcp MCP server](https://glama.ai/mcp/servers/YawLabs/redis-mcp/badges/score.svg)](https://glama.ai/mcp/servers/YawLabs/redis-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/YawLabs/redis-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server