A
licenseNot graded
qualityF
maintenanceProvides access to Redis databases. This server enables LLMs to interact with Redis key-value stores through a set of standardized tools.
175
30
MIT
Redis MCP Server
by farhankaz
The Redis MCP Server provides a Model Context Protocol interface for interacting with a Redis database, enabling operations across multiple data types:
Hash operations: Set multiple fields (
hmset), get a specific field (hget), or retrieve all fields and values (hgetall)Key operations: Scan keys matching a pattern (
scan) and delete keys (del)String operations: Set values with optional NX/PX conditions (
set) and retrieve values (get)Sorted set operations: Add members with scores (
zadd), get ranges by index (zrange) or score (zrangebyscore), and remove members (zrem)Set operations: Add members (
sadd) and retrieve all members (smembers)
Provides access to Redis database operations through a Model Context Protocol (MCP) server. Includes tools for various Redis commands such as HMSET, HGET, HGETALL, SCAN, SET, GET, DEL, ZADD, ZRANGE, ZRANGEBYSCORE, ZREM, SADD, and SMEMBERS.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Redis MCP Serverget the value for key 'user:session:12345'"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Redis MCP Server
A Model Context Protocol (MCP) server that provides access to Redis database operations.
Project Structure
src/
├── interfaces/
│ └── types.ts # Shared TypeScript interfaces and types
├── tools/
│ ├── base_tool.ts # Abstract base class for Redis tools
│ ├── tool_registry.ts # Registry managing all available Redis tools
│ ├── hmset_tool.ts # HMSET Redis operation
│ ├── hget_tool.ts # HGET Redis operation
│ ├── hgetall_tool.ts # HGETALL Redis operation
│ ├── scan_tool.ts # SCAN Redis operation
│ ├── set_tool.ts # SET Redis operation
│ ├── get_tool.ts # GET Redis operation
│ ├── del_tool.ts # DEL Redis operation
│ ├── zadd_tool.ts # ZADD Redis operation
│ ├── zrange_tool.ts # ZRANGE Redis operation
│ ├── zrangebyscore_tool.ts # ZRANGEBYSCORE Redis operation
│ └── zrem_tool.ts # ZREM Redis operation
└── redis_server.ts # Main server implementationRelated MCP server: Redis MCP
Available Tools
Tool | Type | Description | Input Schema |
hmset | Hash Command | Set multiple hash fields to multiple values |
|
hget | Hash Command | Get the value of a hash field |
|
hgetall | Hash Command | Get all fields and values in a hash |
|
scan | Key Command | Scan Redis keys matching a pattern |
|
set | String Command | Set string value with optional NX and PX options |
|
get | String Command | Get string value |
|
del | Key Command | Delete a key |
|
zadd | Sorted Set Command | Add one or more members to a sorted set |
|
zrange | Sorted Set Command | Return a range of members from a sorted set by index |
|
zrangebyscore | Sorted Set Command | Return members from a sorted set with scores between min and max |
|
zrem | Sorted Set Command | Remove one or more members from a sorted set |
|
sadd | Set Command | Add one or more members to a set |
|
smembers | Set Command | Get all members in a set |
|
Usage
Configure in your MCP client (e.g., Claude Desktop, Cline):
{
"mcpServers": {
"redis": {
"command": "npx",
"args": ["redis-mcp", "--redis-host", "localhost", "--redis-port", "6379"],
"disabled": false
}
}
}Command Line Arguments
--redis-host: Redis server host (default: localhost)--redis-port: Redis server port (default: 6379)
Installing via Smithery
To install Redis Server for Claude Desktop automatically via Smithery:
npx -y @smithery/cli install redis-mcp --client claudeDevelopment
To add a new Redis tool:
Create a new tool class in
src/tools/extendingRedisToolDefine the tool's interface in
src/interfaces/types.tsRegister the tool in
src/tools/tool_registry.ts
Example tool implementation:
export class MyTool extends RedisTool {
name = 'mytool';
description = 'Description of what the tool does';
inputSchema = {
type: 'object',
properties: {
// Define input parameters
},
required: ['requiredParam']
};
validateArgs(args: unknown): args is MyToolArgs {
// Implement argument validation
}
async execute(args: unknown, client: RedisClientType): Promise<ToolResponse> {
// Implement tool logic
}
}Running evals
The evals package loads an mcp client that then runs the index.ts file, so there is no need to rebuild between tests. You can load environment variables by prefixing the npx command. Full documentation can be found here.
OPENAI_API_KEY=your-key npx mcp-eval src/evals/evals.ts src/tools/zrangebyscore_tool.tsLicense
Available Tools
13 toolsdelC
Delete a key
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Key to delete |
TDQS
C2.7/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Delete' implies a destructive mutation, but it doesn't disclose if deletion is permanent, requires specific permissions, has side effects (e.g., cascading deletions), or rate limits. This leaves significant behavioral gaps for a tool named 'del'.
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 extremely concise at three words ('Delete a key'), front-loading the core action with zero wasted words. It efficiently communicates the essential purpose without unnecessary elaboration, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's name ('del') suggests a destructive operation, lack of annotations, no output schema, and multiple sibling tools, the description is incomplete. It doesn't clarify the tool's scope (e.g., Redis key deletion), behavioral traits, or differentiation from siblings, leaving too much ambiguity for safe and effective use.
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%, with the parameter 'key' documented as 'Key to delete' in the schema. The description adds no additional meaning beyond this, such as key format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate as the schema handles the parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a key' states a clear verb ('Delete') and resource ('a key'), making the basic purpose understandable. However, it doesn't specify what type of key (e.g., Redis key, configuration key) or distinguish it from sibling tools like 'zrem' or 'hdel' (if they existed), leaving some ambiguity about the exact scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'zrem' (remove from sorted set) and 'hdel' (delete hash field), it's unclear if 'del' is for general key deletion or specific contexts. No prerequisites, exclusions, or comparative usage hints are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getD
Get string value
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Key to get |
TDQS
D1.7/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. 'Get string value' reveals nothing about error handling (e.g., what happens if key doesn't exist), performance characteristics, side effects, authentication requirements, or rate limits. This leaves the agent with insufficient information to predict the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words, but this brevity comes at the cost of being under-specified rather than efficiently informative. While front-loaded, it fails to provide necessary context that would help an agent use the tool effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's apparent simplicity (1 parameter, no output schema), the description is still inadequate. It doesn't explain what system the key belongs to, what format the returned string might have, or how this tool relates to its many siblings. Without annotations or output schema, the description should provide more complete operational context.
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%, with the single parameter 'key' clearly documented as 'Key to get'. The description adds no additional parameter semantics beyond what the schema already provides. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no parameter information in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get string value' is a tautology that essentially restates the tool name 'get' with minimal added meaning. While it specifies 'string value' as the return type, it doesn't clearly identify what resource is being retrieved (e.g., from a key-value store, cache, or database) or distinguish this tool from its many siblings like 'hget', 'hgetall', or 'set'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools like 'hget' (hash get), 'hgetall' (get all hash fields), 'scan' (iterate keys), and 'set' (store value), there's no indication of when this simple key-based retrieval is appropriate versus more specialized operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hgetC
Get the value of a hash field
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| field | Yes | Field to get | |
| key | Yes | Hash key |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While 'Get' implies a read operation, it doesn't specify whether this requires authentication, has rate limits, returns errors for missing fields, or provides any details about the return format. The description is minimal and lacks important operational context.
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, efficient sentence that communicates the core purpose without any wasted words. It's appropriately sized for a simple retrieval operation and gets straight to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what type of value is returned, how errors are handled, or provide any context about the data store or typical use cases. Given the sibling tools suggest this is part of a key-value or hash storage system, more context would be helpful.
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?
The input schema has 100% description coverage, with both parameters clearly documented as 'Field to get' and 'Hash key'. The description doesn't add any meaningful semantic context beyond what's already in the schema, such as explaining the relationship between key and field or providing examples of valid values.
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 clearly states the verb 'Get' and the resource 'value of a hash field', making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from sibling tools like 'get' or 'hgetall', which might also retrieve values from the same data store.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'get', 'hgetall', and 'scan' available, there's no indication whether this is for specific hash structures, when to prefer it over other retrieval methods, or any prerequisites for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hgetallC
Get all the fields and values in a hash
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Hash key |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action but lacks details on error behavior (e.g., what happens if the key doesn't exist or isn't a hash), return format (e.g., whether it's a list, map, or raw data), or performance implications (e.g., memory usage for large hashes). This leaves significant gaps for an agent to understand the tool's behavior.
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, clear sentence with no wasted words. It is front-loaded with the core action and resource, making it easy to parse quickly. Every part of the sentence contributes directly to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for a tool that retrieves data. It doesn't explain what the return value looks like (e.g., a dictionary of field-value pairs), error conditions, or how it differs from similar tools like 'hget'. For a read operation with no structured output documentation, this leaves the agent with insufficient context.
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?
The input schema has 100% description coverage, with the 'key' parameter clearly documented as 'Hash key'. The description adds no additional semantic context beyond this, such as examples of valid keys or constraints. Since the schema does the heavy lifting, the baseline score of 3 is appropriate.
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 clearly states the action ('Get all') and the resource ('fields and values in a hash'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'hget' (which gets a single field) or 'get' (which gets a string value), leaving some ambiguity about when to choose this specific tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'hget' for single-field retrieval or 'scan' for iterative scanning, nor does it specify prerequisites such as the hash's existence or error handling for missing keys.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hmsetC
Set multiple hash fields to multiple values
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| fields | Yes | Field-value pairs to set | |
| key | Yes | Hash key |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the action is to 'set' values, implying a write/mutation operation, but doesn't disclose behavioral traits like whether it overwrites existing fields, requires specific permissions, has side effects, or how errors are handled. The description is minimal and lacks critical context for a mutation tool.
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, efficient sentence with zero waste. It's front-loaded with the core purpose and 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a mutation tool with 2 parameters, the description is incomplete. It lacks information on return values, error handling, permissions, or how it interacts with sibling tools. The high schema coverage helps, but the description doesn't compensate for missing behavioral context.
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 schema already documents both parameters ('key' as hash key and 'fields' as field-value pairs). The description adds no additional meaning beyond what the schema provides, such as examples, constraints, or usage notes. Baseline 3 is appropriate when schema does the heavy lifting.
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 clearly states the action ('Set multiple hash fields to multiple values') and identifies the resource (hash fields/values). It distinguishes from basic 'set' by specifying multiple fields, but doesn't explicitly differentiate from other hash operations like hget or hgetall among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'set' (for single values) or other hash operations. The description implies it's for hash data structures but doesn't specify prerequisites, constraints, or when to choose this over other hash tools like hgetall for reading.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
saddC
Add one or more members to a set
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Set key | |
| members | Yes | Members to add to the set |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Add') but doesn't clarify whether this is an idempotent operation (Redis's SADD adds only new members), what happens on errors, or if there are rate limits or authentication requirements. This leaves significant gaps in understanding the tool's behavior beyond the basic action.
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 extremely concise—a single sentence that directly states the tool's function without any fluff. It's front-loaded with the core action and efficiently includes the detail about handling 'one or more members'. Every word earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is insufficient for a mutation tool like 'sadd'. It doesn't explain return values (e.g., in Redis, SADD returns the number of new members added), error conditions, or side effects. For a tool that modifies data, more context is needed to use it effectively and safely.
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?
The input schema has 100% description coverage, with clear documentation for both parameters ('key' as the set key and 'members' as an array of strings to add). The description adds no additional semantic information beyond what the schema already provides, such as format examples or constraints. However, since schema coverage is high, the baseline score of 3 is appropriate.
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 clearly states the action ('Add') and resource ('members to a set'), making the purpose immediately understandable. It specifies that it can handle 'one or more members', which adds useful detail. However, it doesn't explicitly differentiate from sibling tools like 'zadd' (which adds to sorted sets) or 'set' (which sets a key-value pair), leaving some ambiguity in the Redis context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. In a Redis server with multiple set-related tools like 'smembers' (to retrieve set members) and 'zadd' (for sorted sets), there's no indication of when 'sadd' is appropriate versus other options, nor any mention of prerequisites or constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scanC
Scan Redis keys matching a pattern
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of keys to return per iteration (optional) | |
| pattern | Yes | Pattern to match (e.g., "user:*" or "schedule:*") |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions scanning keys matching a pattern but omits critical details like whether this is a read-only operation, potential performance impacts on Redis, iteration mechanics (implied by 'per iteration' in schema but not explained), or output format. This leaves significant gaps in understanding the tool's behavior.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it easy to parse quickly while conveying the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for a tool with potential complexity (e.g., iterative scanning in Redis). It fails to explain behavioral aspects like safety, performance, or result format, which are crucial for an agent to use it effectively. The high schema coverage doesn't compensate for these missing contextual elements.
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?
The schema description coverage is 100%, with clear descriptions for both parameters ('pattern' and 'count'). The description adds minimal value beyond the schema, as it only reiterates the pattern matching concept without providing additional context like examples of complex patterns or advice on 'count' usage. This meets the baseline for high schema coverage.
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 clearly states the action ('Scan') and the resource ('Redis keys matching a pattern'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'get' or 'smembers', which might retrieve specific keys or set members, but the scanning functionality is distinct enough for basic clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get' for single keys or 'smembers' for set members. It lacks context about scenarios where pattern-based scanning is appropriate, such as bulk operations or key discovery, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
setC
Set string value with optional NX (only if not exists) and PX (expiry in milliseconds) options
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Key to set | |
| nx | No | Only set if key does not exist | |
| px | No | Set expiry in milliseconds | |
| value | Yes | Value to set |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that setting can be conditional (NX) and include expiry (PX), which adds some context. However, it fails to describe critical behaviors such as whether this overwrites existing values by default, what happens on expiry, error conditions, or response format. For a mutation tool with zero annotation coverage, this is a significant gap.
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, efficient sentence that front-loads the core action ('Set string value') and briefly mentions optional features. There is no wasted language, and it's appropriately sized for the tool's complexity, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool with no annotations and no output schema, the description is incomplete. It lacks information on behavioral traits (e.g., default overwrite behavior, error handling), usage guidelines compared to siblings, and expected return values. While concise, it doesn't provide enough context for an agent to use the tool effectively without additional assumptions.
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%, meaning all parameters are documented in the schema. The description adds minimal value by naming NX and PX options but doesn't provide additional semantics beyond what the schema already states (e.g., NX means 'only set if key does not exist'). Since the schema does the heavy lifting, the baseline score of 3 is appropriate.
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 clearly states the verb ('Set') and resource ('string value'), making the purpose understandable. It also mentions optional NX and PX options, which adds specificity. However, it doesn't explicitly differentiate from sibling tools like 'hmset' or 'zadd' that also set values in different data structures, leaving room for ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions optional NX and PX options but doesn't explain scenarios where these are beneficial or when to choose this over other setting tools like 'hmset' for hashes or 'zadd' for sorted sets. This lack of context makes it harder for an agent to select the right tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
smembersC
Get all members in a set
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Set key |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. While 'Get' implies a read operation, it doesn't disclose behavioral traits like whether this returns all members at once (potentially memory-intensive for large sets), error conditions (e.g., if key doesn't exist), or performance characteristics. The description is minimal and lacks operational context.
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, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool that retrieves data. It doesn't explain what 'members' are (e.g., strings, values), the return format (e.g., list, array), or error handling. For a read operation with minimal structured data, more context is needed to guide the agent effectively.
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%, with the parameter 'key' clearly documented as 'Set key'. The description adds no additional meaning beyond what the schema provides, such as explaining what constitutes a valid key format or examples. Baseline 3 is appropriate since the schema does the heavy lifting.
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 clearly states the verb ('Get') and resource ('all members in a set'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'zrange' or 'hgetall' which also retrieve collections, missing an opportunity to clarify this is specifically for Redis set operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With siblings like 'zrange' (for sorted sets) and 'hgetall' (for hashes), the description doesn't indicate this is for Redis set data structures specifically, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
zaddC
Add one or more members to a sorted set
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Sorted set key | |
| members | Yes | Array of score-value pairs to add |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Add') but does not cover critical aspects like whether this is a mutation (implied but not explicit), error conditions (e.g., if key is not a sorted set), or performance implications (e.g., handling of duplicates). This leaves significant gaps in understanding the tool's behavior.
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, direct sentence that efficiently conveys the core functionality without any wasted words. It is front-loaded with the essential action and resource, making it highly concise and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool with no annotations and no output schema, the description is insufficient. It lacks details on return values, error handling, and behavioral nuances (e.g., how duplicates are handled), leaving the agent with incomplete context for reliable tool 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?
The schema description coverage is 100%, with clear documentation for 'key' and 'members' parameters. The description adds no additional semantic context beyond what the schema provides, such as examples or edge cases, so it meets the baseline for adequate but unenhanced parameter understanding.
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 clearly states the action ('Add') and resource ('one or more members to a sorted set'), making the purpose immediately understandable. However, it does not explicitly differentiate from sibling tools like 'sadd' (which adds to a set) or 'zrem' (which removes from a sorted set), which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'sadd' for sets or 'zrem' for removal from sorted sets. It also lacks context on prerequisites, such as whether the key must exist or if it creates a new sorted set, leaving the agent with minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
zrangeC
Return a range of members from a sorted set by index
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Sorted set key | |
| start | Yes | Start index (0-based) | |
| stop | Yes | Stop index (inclusive) | |
| withScores | No | Include scores in output |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic operation. It doesn't disclose important behavioral traits such as whether this is read-only or has side effects, error conditions, performance characteristics, or what the output format looks like (especially given no output schema).
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, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded, with every word earning its place in conveying the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool with 4 parameters that performs data retrieval. It doesn't explain return values, error handling, or behavioral constraints, leaving significant gaps for the agent to understand how to use it effectively.
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 schema already documents all parameters thoroughly. The description adds no additional meaning beyond what's in the schema (e.g., it doesn't explain index semantics or score inclusion implications), meeting the baseline for high schema coverage.
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 clearly states the action ('return a range of members') and resource ('from a sorted set by index'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'zrangebyscore' which also returns ranges but by score rather than index, missing full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'zrangebyscore' or 'smembers'. It lacks context about appropriate use cases, prerequisites, or exclusions, leaving the agent to infer usage from the name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
zrangebyscoreC
Return members from a sorted set with scores between min and max
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Sorted set key | |
| max | Yes | Maximum score | |
| min | Yes | Minimum score | |
| withScores | No | Include scores in output |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral context. It doesn't disclose whether this is a read-only operation, what happens if the key doesn't exist, how scores are compared (inclusive/exclusive), or the return format. The description states the basic function but lacks critical operational details.
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, efficient sentence that states the core functionality without unnecessary words. It's front-loaded with the main purpose and contains zero redundant information. Every word earns its place in this compact description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a Redis sorted set operation with 4 parameters and no annotations or output schema, the description is insufficient. It doesn't explain the return format (members only or with scores), error behavior, score boundary semantics, or how this differs from similar tools. The agent lacks critical context for proper tool 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 description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema - it mentions 'min' and 'max' but provides no extra context about their interpretation or the 'withScores' option. Baseline 3 is appropriate when schema does the heavy lifting.
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 clearly states the action ('return members') and resource ('from a sorted set') with the specific condition ('with scores between min and max'). It distinguishes from siblings like 'zrange' (which uses index ranges) and 'zadd' (which adds members), but doesn't explicitly mention these distinctions. The purpose is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'zrange' (for index-based retrieval) or 'scan' (for pattern matching). It doesn't mention prerequisites, error conditions, or typical use cases. The agent must infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
zremC
Remove one or more members from a sorted set
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Sorted set key | |
| members | Yes | Array of members to remove |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Remove') but doesn't clarify whether this is destructive, what happens if members don't exist, if it returns a count, or any side effects. For a mutation tool with zero annotation coverage, this is a significant gap.
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, efficient sentence that directly states the tool's function without any fluff or redundancy. It's front-loaded with the core action and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., number of members removed), error behaviors, or interaction with other tools, leaving critical gaps for agent usage.
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 schema already documents both parameters ('key' and 'members') adequately. The description adds no additional semantic context beyond what the schema provides, such as format examples or constraints, meeting the baseline for high schema coverage.
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 clearly states the action ('Remove') and target ('one or more members from a sorted set'), which is specific and unambiguous. It doesn't explicitly differentiate from sibling tools like 'del' or 'sadd', but the mention of 'sorted set' provides some implicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'del' (for general keys) or 'sadd' (for set operations). It lacks context about prerequisites, error conditions, or typical use cases, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
B3/5.0
Disambiguation4/5
Most tools have clearly distinct purposes targeting different Redis data types and operations, with minimal overlap. However, 'get' and 'set' for strings versus 'hget' and 'hmset' for hashes follow similar patterns but are differentiated by the 'h' prefix, which could cause minor confusion for agents unfamiliar with Redis naming conventions.
Naming Consistency5/5
The tool names are highly consistent, following Redis command conventions with lowercase, concise verb-based names (e.g., 'get', 'set', 'del', 'sadd', 'zadd'). All tools adhere to this pattern without mixing styles, making them predictable and easy to interpret.
Tool Count5/5
With 13 tools, this server is well-scoped for Redis operations, covering key data types (strings, hashes, sets, sorted sets) and essential commands. The count is appropriate, providing a focused set without being overwhelming or too sparse for the domain.
Completeness4/5
The tool set offers strong coverage for core Redis operations, including CRUD-like actions for multiple data types and scanning. Minor gaps exist, such as missing list operations (e.g., 'lpush', 'lrange') and transaction commands, but agents can still handle many common workflows effectively.
Maintenance
ActivityInactive
ResponsivenessSyncing
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Read-only MCP tools for AI agent discovery, structured resources, and NIULAI information.
Hosted MCP server for AI-driven data ops. Create apps, manage schemas, and CRUD structured data.
Your org's AI agents, tasks, runs, search, and brain files as MCP tools and resources.
Governed data discovery, exact queries, decisions, simulations, and runtime utilities over MCP.
Related MCP Servers
- AlicenseBqualityDmaintenanceEnables AI assistants to perform comprehensive Redis database operations including managing strings, hashes, lists, sets, sorted sets, TTL management, and data backup/restore. Supports secure connections and provides batch operations for efficient Redis interaction through natural language.34162MIT
- AlicenseBqualityDmaintenanceProvides comprehensive Redis database operations supporting all major data types (strings, lists, sets, hashes, sorted sets) with full CRUD functionality through natural language commands.915MIT
- AlicenseAqualityDmaintenanceEnables AI agents to manage and search data in Redis using natural language. Supports hashes, lists, sets, sorted sets, streams, JSON, and vector search.44MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/farhankaz/redis-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server