Provides tools for connecting to any Redis instance and executing a wide range of Redis commands, including string, hash, list, set, and sorted set operations, as well as key management and database administration.
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 Server get the value of key 'user:123'"
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.
A Model Context Protocol (MCP) server for Redis. Connect to any Redis instance and execute queries through AI assistants.
🔌 Connect to any Redis instance - Local or remote, with authentication and TLS support
🛠️ 30+ Built-in Tools - Complete Redis operations including strings, hashes, lists, sets, sorted sets
🔒 Command Blacklist - Block dangerous commands (FLUSHALL, SHUTDOWN, etc.)
💾 Connection Management - Save and switch between multiple Redis connections
🌐 Web UI - Browser-based management interface
🔐 Password Encryption - AES-256-GCM encryption for saved passwords
Related MCP server: Redis MCP Server
git clone https://github.com/minivv/redis-mcp-server.git
cd redis-mcp-servernpm install
npm run buildAdd to your Claude Desktop, Cursor, or other MCP client configuration:
{
"mcpServers": {
"redis-mcp-server": {
"type": "stdio",
"command": "node",
"args": [
"/your/path/to/redis-mcp-server/build/index.js"
],
"env": {
"MCP_OPEN_BROWSER": "false",
"REDIS_HOST": "127.0.0.1",
"REDIS_PORT": "6379",
"REDIS_PASSWORD": "",
"REDIS_DB": "0"
}
}
}
}⚠️ 注意: 请将
args中的路径/your/path/to/redis-mcp-server/build/index.js改为你本机实际的项目路径，例如/Users/yourname/projects/redis-mcp-server/build/index.js。
Variable | Default | Description |
|
| Redis host |
|
| Redis port |
| - | Redis password |
|
| Database number (0-15) |
| - | Redis username (for ACL) |
|
| Use TLS connection |
|
| Web UI port |
|
| Auto-open browser on start |
Tool | Description |
| Get current Redis connection details |
| List all saved Redis connections |
| Save a Redis connection configuration |
| Switch to a saved Redis connection |
| Delete a saved Redis connection |
| Test a Redis connection by sending PING |
Tool | Description |
| Execute any Redis command (with blacklist check) |
| Execute read-only Redis commands only |
Tool | Description |
| List keys matching a pattern |
| Get detailed information about a key |
| Delete one or more keys |
| Rename a key |
| Set expiration time for a key |
| Get remaining TTL for a key |
Tool | Description |
| Get the value of a string key |
| Set the value of a string key (with optional TTL) |
Tool | Description |
| Get all or specific fields of a hash |
| Set fields in a hash |
Tool | Description |
| Get elements from a list by range |
| Push elements to a list (left or right) |
Tool | Description |
| Get all members of a set |
| Add members to a set |
Tool | Description |
| Get members from a sorted set |
| Add members with scores to a sorted set |
Tool | Description |
| Select a Redis database (0-15) |
| Get the number of keys in the current database |
| Get Redis server information |
Tool | Description |
| Get the current command blacklist configuration |
| Update the command blacklist configuration |
| Reset command blacklist to default patterns |
By default, the following commands are blocked:
FLUSHALL - Flush all databases
FLUSHDB - Flush current database
SHUTDOWN - Shutdown Redis server
DEBUG SEGFAULT - Debug segfault
CONFIG SET - Change Redis config
CONFIG REWRITE - Rewrite Redis config
SLAVEOF - Set replication
REPLICAOF - Set replication
CLUSTER * - Cluster commands
RESET - Reset connection
You can customize the blacklist through the Web UI or using the update_command_blacklist tool.
The Web UI provides a browser-based interface for:
Managing Redis connections
Testing connections
Managing the command blacklist
Testing commands against the blacklist
Access it at http://localhost:3457 (default port).
All configuration is stored in ~/.redis-mcp/:
connections.json - Saved connections
command-blacklist.json - Command blacklist rules
.key - Encryption key for passwords
Passwords are encrypted using AES-256-GCM
Dangerous commands are blocked by default
The encryption key is stored with restricted permissions (0600)
MIT
Add members to a set.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| members | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description is too brief to disclose any behavioral traits. Does not mention what happens if key doesn't exist (creates set), duplicate handling, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Under-specification: only 4 words, sacrificing clarity for brevity. Should include more context within a short space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 required parameters, no output schema, and no annotations, the description is completely inadequate. Lacks detail on behavior, constraints, and differentiation from siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and description adds no meaning beyond parameter names. Does not explain that 'key' is the set key or that 'members' are the elements to add.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add members to a set' which indicates the verb and resource. It distinguishes from sibling 'add_sorted_set' implicitly, though not explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like add_sorted_set. Does not mention conditions or best practices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add members with scores to a sorted set.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| members | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does not mention whether existing members are overwritten, if the key must already exist, or any permissions needed. For a mutation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear, and concise sentence. No unnecessary words or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool modifies a sorted set, it lacks context on side effects (e.g., updating existing members), return value (though no output schema), and error conditions. The description is too minimal for an agent to use effectively without additional knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description adds little beyond the schema: it mentions 'scores' but does not explain the structure of 'members' or the role of 'key'. It fails to compensate for the lack of description in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add'), the resource ('sorted set'), and the data ('members with scores'). It distinguishes from sibling tools like 'add_set' (which adds to a set without scores) and 'get_sorted_set' (retrieval).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, such as when to use 'add_set' or 'run_redis_query'. No mention of prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a saved Redis connection.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It states it deletes a connection but does not mention irreversibility, confirmation prompts, or impact on active connections.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise, but it is too brief to be fully helpful. Every word earns its place but crucial details are missing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with no output schema and minimal parameter info, the description should at least indicate that the deletion is permanent or confirm it removes from saved list. It lacks completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should explain the 'name' parameter. It only repeats 'name' without clarifying it refers to the saved connection identifier, adding no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete) and the resource (saved Redis connection), distinguishing it from sibling tools like save_connection and test_connection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (e.g., delete_key) or any prerequisites (e.g., connection must exist, cannot undo).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete one or more keys.
| Name | Required | Description | Default |
|---|---|---|---|
| keys | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides no behavioral disclosures beyond the fact of deletion. No annotations exist to compensate. Critical details like irreversibility, permissions needed, or effects on related data are omitted, which is essential for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but lacks necessary detail. While concise in length, it fails to provide enough information to guide correct usage, making it under-specified rather than efficiently succinct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and a single parameter lacking description, the description is highly incomplete. It does not explain return values, error conditions, limitations, or behavior with non-existent keys.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'keys' with no description. The tool description does not add any meaning beyond the schema, leaving the parameter's purpose and constraints entirely implicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete one or more keys' clearly states the action and resource, making the purpose understandable. However, it does not differentiate from sibling tools like rename_key or set_ttl, which also operate on keys.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 such as rename_key or other deletion tools. The description lacks context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute any Redis command. For dangerous commands (FLUSHALL, SHUTDOWN, etc.), the command blacklist will be checked.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | Redis command to execute (e.g., 'GET key', 'HSET hash field value') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions a command blacklist check for dangerous commands (e.g., FLUSHALL, SHUTDOWN), adding some behavioral context. However, it does not disclose potential side effects, success/failure behavior, or that arbitrary commands can be destructive, which is critical given no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no extraneous content. The first sentence states the core purpose, and the second adds an important qualification. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool executes arbitrary Redis commands (high complexity) and has no output schema, the description is insufficient. It omits information about return values, error handling, and the full range of behavioral traits, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter description already provides an example. The tool description adds no additional semantic value for the parameter beyond what is in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Execute any Redis command,' clearly indicating the verb and resource. However, it does not differentiate from the sibling tool 'run_redis_query,' which likely serves a similar purpose, leaving ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like 'run_redis_query' or other command-specific tools. The description implies general use but lacks explicit when-not-to-use or alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current command blacklist configuration.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose any behavioral traits such as authentication requirements, side effects, or rate limits. For a read operation, it could at least indicate it is non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence of 6 words with no extraneous information. It is appropriately front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero parameters, no output schema), the description adequately states the purpose. However, a bit more detail on what the configuration includes would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the description cannot add meaning beyond the schema. Per guidelines, 0 parameters grants a baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and clearly identifies the resource 'command blacklist configuration'. It effectively distinguishes from sibling tools like reset_command_blacklist and update_command_blacklist, which perform different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when wanting to view the current blacklist, but it does not explicitly provide when-to-use guidance or mention alternatives. The context from sibling tools partially fills the gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current Redis connection details.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose prerequisites (e.g., required active connection) or behavior if connection is unavailable. Minimal transparency beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, zero wasted words, front-loaded with key action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a param-free tool, but fails to specify what 'connection details' include (e.g., host, port, auth). Could cause confusion with get_server_info.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is 100%. Description adds no parameter info, but baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Get' and resource 'current Redis connection details', clearly distinguishing from sibling tools like test_connection or use_connection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (e.g., get_server_info, test_connection). Agent must infer context from tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the number of keys in the current database.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully convey behavioral traits. It implies a read-only operation but fails to specify return format, potential performance impact for large databases, or dependency on a selected connection and database.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence. It is appropriately short for a simple tool, though it could include additional context without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is the sole source of information. It lacks details on return value (e.g., integer), the meaning of 'current database', and any side effects or prerequisites, leaving gaps for safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is 100%. The description adds no parameter information, which is acceptable since none exist. Baseline score 4 for no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves the number of keys in the current database, using a specific verb and resource. However, it does not differentiate from sibling tools like list_keys or get_key_info, which serve related but distinct purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. For instance, it is not mentioned that this tool is appropriate for monitoring database size, while list_keys would be used for key enumeration.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all fields and values of a hash, or specific fields.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| fields | No | Specific fields to get (optional, returns all if empty) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fails to disclose behavioral traits such as error handling (e.g., if key is not a hash), return format, performance implications, or side effects. It only states basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence) but overly terse, lacking necessary details. It is appropriately front-loaded but sacrifices completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is incomplete. It does not describe return values, error cases, or prerequisites, leaving the agent with insufficient information for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (only 'fields' described). The description adds minimal value beyond the schema; it does not explain the 'key' parameter or provide additional semantic context for either parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves hash fields and values, and distinguishes from sibling tools like get_set or get_string by specifying the data type 'hash' and the ability to get specific fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 get_key_info or when to use specific fields vs all. The description does not provide usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about a key: type, TTL, encoding, and value.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Key name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It only lists the information returned but fails to mention whether the tool is read-only (likely true), safe to call repeatedly, or if it has any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It efficiently communicates the core purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no output schema), the description is adequate for basic understanding. However, it doesn't specify the return format or whether the value can be large, which would be helpful for an agent invoking it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (the single parameter 'key' is described as 'Key name'). The description adds no additional detail beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get information') and the resource ('a key'), and explicitly lists the attributes returned (type, TTL, encoding, value). It effectively distinguishes from sibling tools that focus on specific data structures or operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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_string', 'get_hash', 'get_ttl', or 'list_keys'. It does not specify prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get elements from a list by range.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| stop | No | Stop index (default: -1, means end) | |
| start | No | Start index (default: 0) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose whether the tool is read-only, requires authentication, or how it handles edge cases (e.g., out-of-bounds indices). Only states it gets elements by range.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no redundancy. It is concise but still conveys core purpose. However, it might be too terse given the complexity of parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 3 parameters, no output schema, and no annotations, the description is insufficient. It omits return format, edge cases, and behavior details, leaving the agent guessing about how to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% (2 of 3 parameters described). The description adds 'by range' which loosely refers to start and stop, but does not clarify indices inclusivity/exclusivity or default behavior. Key parameter lacks description entirely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 'elements from a list' with method 'by range'. However, it does not explicitly distinguish from siblings like get_set or get_sorted_set, which also retrieve elements from collections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., get_string, get_set), no prerequisites or exclusions. The description implies usage for list ranges but does not clarify context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Redis server information (memory, clients, stats, etc.).
| Name | Required | Description | Default |
|---|---|---|---|
| section | No | Specific section (optional): server, memory, clients, stats, etc. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It indicates the tool returns information (read-only behavior) but does not disclose any potential side effects, authentication needs, or rate limits. The description is somewhat transparent but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is front-loaded and efficiently conveys the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description is adequate. It explains what the tool does and hints at the possible sections. However, it could be more explicit about the return format or behavior, but overall it meets needs given the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description repeats the examples from the schema (server, memory, clients, stats). It adds marginal value by contextualizing the parameter as targeting 'Redis server information'. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get Redis server information' with examples of sections like memory, clients, stats. It uses a specific verb and resource, and it distinguishes from sibling tools that target specific data types or operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving server info but does not explicitly state when to use this over alternatives, nor does it provide context on when not to use it. No exclusions or comparisons are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all members of a set.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read operation ('get all members'), but with no annotations and no details on what happens if the key doesn't exist or if the set is empty. Basic transparency but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (6 words) and front-loaded. However, it sacrifices informativeness; a bit more context would improve it without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter, no output schema, no annotations, and many sibling tools, the description lacks essential context such as return format, error behavior, or the nature of the set data structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (key parameter has no description). The tool description does not add any meaning to the 'key' parameter beyond its name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 'a set', distinguishing it from siblings like 'get_sorted_set', 'get_hash', etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., when to use get_set vs get_sorted_set). No context on prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get members from a sorted set by score range or rank.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| stop | No | Stop rank (default: -1) | |
| start | No | Start rank (default: 0) | |
| reverse | No | Reverse order | |
| withScores | No | Include scores |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions retrieval by score range or rank but does not explain the meaning of start/stop (ranks), default direction, or inclusion of scores. Without annotations, these gaps are critical for an agent to use the tool correctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is clear and not verbose. However, it could be improved by front-loading the most critical details. It earns its place but is slightly under-informative for a tool with no annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, no output schema), the description is incomplete. It does not explain the relationship between start/stop and rank versus score, nor what is returned (members with scores?). Sibling tools are many, but context about this tool's specific scenario is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (80%), but the description adds no additional meaning beyond the schema fields. It vaguely refers to 'score range or rank' without clarifying how parameters relate. Baseline 3 is appropriate since the schema largely explains parameters, but the tool description offers no extra semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Get), resource (members from a sorted set), and method (by score range or rank). This distinguishes it from sibling tools like get_set (regular set) and add_sorted_set (adding). However, it could be more explicit about the dual retrieval methods (score vs rank).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 get_set for regular sets or list_keys for general key listing. The description does not specify prerequisites, limitations, or context where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the value of a string key.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose behavior such as what is returned, error handling for missing keys, or any side effects. With no annotations, the description fails to convey that this is a safe read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, which is concise, but it sacrifices informative content. It is not verbose, but it could be more useful without adding many words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the domain (many sibling tools, no output schema), the description is insufficient. It does not explain the behavior in the context of Redis key-value operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning the description adds no meaning beyond the schema. The single 'key' parameter is merely restated, providing no additional context or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('string key'), distinguishing it from siblings like get_set or set_string. It 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.
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 (e.g., get_set, get_hash). It does not mention that it only works for string keys or what happens if the key is of a different type.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get remaining TTL for a key.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose behavior beyond the basic function. It fails to mention what happens on missing keys (e.g., return -2), result format, or safety traits. This is a significant gap for a tool with zero annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (5 words) with no unnecessary content. However, extreme conciseness borders on under-specification, hence not a perfect 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is incomplete. It omits details about return values (e.g., TTL in seconds, -1 for no expiry, -2 for missing key) and does not cover edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'key' has no schema description, and the tool description provides no additional meaning (e.g., format, validity, or constraints). With 0% schema coverage, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Get) and the resource (remaining TTL for a key), making the tool's purpose understandable. However, it does not differentiate from sibling tools like get_key_info which may also return TTL.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (e.g., get_key_info for more context). There are no mentions of prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List keys matching a pattern. Use '*' for all keys. Be careful with large databases.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Max number of keys to return (default: 100) | |
| pattern | No | Pattern to match (default: '*') | * |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It warns about large databases, indicating potential performance issues, but does not disclose other behaviors like return format or side effects. The warning adds some transparency but is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise, two sentences. First sentence states purpose, second warns about large databases. No unnecessary words. Front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with two parameters and no output schema, the description covers the essential purpose and a key caveat. It does not explain the return value, but the pattern and count parameters are self-explanatory. Slightly incomplete but adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described. The description merely restates the pattern default ('*'), adding no new semantic meaning beyond the schema. Baseline 3 is appropriate as the schema already defines the parameters clearly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists keys matching a pattern, using a specific verb and resource. It distinguishes from sibling tools like get_key_info or get_string which retrieve values rather than list keys.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (e.g., get_key_info, execute_command). Only a caution about large databases, which implies potential performance impact but does not provide explicit when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all saved Redis connections.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states what it does without disclosing any behavioral traits (e.g., whether it requires an active connection, returns IDs or names, or has any side effects).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key verb and resource, no unnecessary words. Highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (no parameters, no output schema), the description is minimally adequate but lacks detail on what the list contains (e.g., names, IDs, connection strings).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. The description adds no param information, but with zero parameters the baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and resource 'saved connections' with scope 'all', clearly distinguishing it from sibling tools like save_connection, delete_connection, and use_connection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. With 29 sibling tools, explicit context for when to list saved connections vs. other operations is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Push elements to a list (left or right).
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| values | Yes | ||
| direction | No | right |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It mentions direction but omits key behaviors: auto-creation of list if key missing, return value (list length after push), and that it modifies in place. This is insufficient 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and concise. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is too minimal. It does not explain the return value, error conditions, or default behavior (e.g., direction default is right). For a 3-parameter tool, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description should compensate. It adds no parameter-specific details beyond what is in the schema (e.g., what key represents, that values are strings to push, direction enum). The description does not improve understanding of parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (push) and the resource (list), and specifies the direction option (left or right). This distinguishes it from sibling tools like add_set or get_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for list operations but does not explicitly state when to use this tool over alternatives like add_set or run_redis_query. No context on prerequisites or use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rename a key.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| newKey | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It fails to disclose critical behaviors: whether the operation is atomic, what happens if the new key already exists, or any failure conditions. The description is silent on all behavioral aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. It lacks essential information and does not follow a structure that front-loads useful details. Every sentence is present but uninformative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, annotations, and the presence of many sibling tools, the description is woefully incomplete. It does not explain return values, side effects, or how it fits into the broader toolset. A mutation tool requires far more detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% with no parameter descriptions. The description adds zero semantic value beyond the parameter names 'key' and 'newKey'. It does not clarify allowed formats, constraints, or relationships between parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Rename a key' is a tautology. It restates the tool name without specifying what kind of key (e.g., Redis key) or adding any distinguishing context. Among sibling tools like 'delete_key' or 'set_string', there is no differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool instead of alternatives like deleting and re-creating a key, or how it interacts with other operations. No when/why context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reset command blacklist to default patterns.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry full weight. It states the tool resets to defaults but does not disclose whether this action is irreversible, requires special permissions, or has any side effects. The minimal description leaves significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that conveys the core purpose without unnecessary words. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description is minimally adequate. However, it does not explain what 'default patterns' are, nor does it clarify the tool's effect in the context of command blacklisting. Adding a sentence about the outcome or typical use would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100%. With no parameters to document, the description appropriately does not add parameter-specific information. Baseline score of 4 for no-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resets the command blacklist to default patterns. The verb 'reset' is specific and distinguishes from sibling tools like 'get_command_blacklist' (retrieval) and 'update_command_blacklist' (custom modification).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when reverting to defaults but lacks explicit guidance on when to use this tool versus alternatives. No exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute read-only Redis commands (GET, HGET, LRANGE, SMEMBERS, etc.). Returns the result.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | Read-only Redis command |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states read-only nature and return of result, but lacks details on error handling, authentication, rate limits, or what happens with invalid commands.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences that front-load action and examples. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool, the description covers the primary purpose and examples. However, it omits details about the result format, error cases, and command blacklisting (e.g., sibling tool get_command_blacklist), leaving gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage for the single parameter, but the description adds concrete examples of valid commands (GET, HGET, etc.), providing additional semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Execute read-only Redis commands' with specific examples (GET, HGET, LRANGE, SMEMBERS) and states the return behavior. It distinguishes clearly from sibling write tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly marks the tool as read-only and provides examples, guiding the agent to use it for read queries. However, it does not explicitly state when not to use it or reference alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a Redis connection configuration.
| Name | Required | Description | Default |
|---|---|---|---|
| db | No | Database number | |
| tls | No | Use TLS | |
| host | Yes | Redis host | |
| name | Yes | Connection name | |
| port | No | Redis port | |
| password | No | Redis password (optional) | |
| username | No | Redis username (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description only states 'Save a Redis connection configuration' without details on whether it overwrites, validates, or persists, leaving behavioral traits unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise, but overly brief. While no wasted words, the single sentence lacks structure and fails to include important context that would fit in a slightly expanded description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters and no output schema, the description fails to explain what 'saving' entails (e.g., overwrite behavior, return value, validation). Incomplete for a writing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions; the tool description adds minimal semantic value beyond restating the verb and resource. Baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Save' and the resource 'Redis connection configuration', distinguishing it from siblings like test_connection or delete_connection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use save_connection versus alternatives like test_connection, use_connection, or get_connection_info. Lacks context on prerequisites or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Select a Redis database (0-15).
| Name | Required | Description | Default |
|---|---|---|---|
| db | Yes | Database number (0-15) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It merely states 'select' without disclosing behavioral details such as side effects on subsequent commands, return values, or whether an active connection is required. This is insufficient for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the key information. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and the simplicity of the tool, the description is minimal. It lacks context on prerequisites, state changes, or side effects, which is important for a tool that modifies the state of a connection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description adds no extra meaning beyond what the schema already provides ('Database number (0-15)'). Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Select', the resource 'Redis database', and specifies the range '0-15'. It is distinct from sibling tools which mostly deal with Redis commands, keys, connections, and data structures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not specify when to use this tool versus alternatives like 'use_connection' or 'test_connection'. The context is implied but no explicit guidance on prerequisites or exclusions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set fields in a hash.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| data | Yes | Object with field-value pairs |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral traits. It does not mention that setting fields is destructive (overwrites existing), whether the hash is created if absent, or any side effects. This is insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence with no redundancy. It is appropriately concise, though perhaps too terse for completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 should explain whether fields are merged or replaced, behavior on non-existent keys, and return value. It only provides minimal surface information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only 'data' described in schema). The description 'Set fields in a hash.' adds no parameter meaning beyond what's in the schema. For a 2-parameter tool, this is inadequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set fields in a hash.' clearly states the action and resource, distinguishing it from sibling tools like 'set_string' or 'add_set'. It is not a tautology, but could be more specific by mentioning Redis context or that it updates existing hash fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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_string' or 'add_set'. The description lacks any context for selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the value of a string key. Optionally set expiration.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| ttl | No | Expiration in seconds (optional) | |
| value | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description should disclose more about behavior. It mentions setting a value and optional expiration but does not state if it overwrites existing keys or fails on non-string types. Minimal but adequate for a simple operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence without unnecessary words. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple set operation with optional TTL, the description is mostly complete. It lacks mention of behavior on existing keys or response format, but given no output schema and sibling tools, it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% (only ttl described). The description adds context for key and value as string key and value, but does not explain format or constraints. Baseline 3 due to low coverage, but the description only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'string key', with an optional expiration. It distinguishes well from sibling tools like set_hash or add_set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., when to use set_hash or push_list). The description implicitly suggests it's for string keys but provides no explicit selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set expiration time for a key.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| seconds | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Does not disclose behavioral traits beyond setting expiration, such as behavior for missing keys, overriding existing TTL, or allowed values for seconds.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise but under-specified; lacks necessary information for the agent to use the tool correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 zero parameter descriptions, the description is inadequate for the complexity of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should explain parameters but does not. No mention of 'key' or 'seconds' meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action (Set expiration time) and resource (key). It distinguishes from siblings like get_ttl and other key operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives, such as delete_key or set_string with expiration. Missing prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test a Redis connection by sending PING.
| Name | Required | Description | Default |
|---|---|---|---|
| db | No | ||
| tls | No | ||
| host | No | ||
| port | No | ||
| password | No | ||
| username | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions sending PING (read-only behavior) but does not disclose error handling, side effects, or whether an existing connection is required. It lacks transparency beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. While it lacks structure for parameter details, it efficiently conveys the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 undocumented parameters, no output schema, and no annotations, the description is severely incomplete. The agent cannot determine what to provide as input, what the output looks like (e.g., success/fail response), or how this tool fits with connection life-cycle siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description fails to explain any of the 6 parameters (host, port, password, etc.). The agent has no guidance on how to construct the connection details from the parameters, making it unclear what values are expected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: test a Redis connection by sending PING. It uses specific verb+resource and distinguishes from siblings like use_connection or get_connection_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (testing a connection) but provides no explicit guidance on when to use it vs. alternatives like use_connection or get_connection_info, nor any prerequisites or when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update the command blacklist configuration.
| Name | Required | Description | Default |
|---|---|---|---|
| enabled | No | ||
| patterns | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of behavioral disclosure. It only states 'Update the command blacklist configuration' without explaining the nature of the update (e.g., whether it replaces the entire configuration, merges changes, or has side effects). This lack of detail leaves agents uncertain about 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence with no wasted words. It is front-loaded with the most important information (verb and resource). However, its brevity sacrifices explanatory depth.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with two parameters and no output schema, the description is too minimal. It does not explain the scope of the update (e.g., whether it affects all settings or specific ones), the return value, or any side effects. The tool's context suggests a configuration management function, but the description fails to provide a complete picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, meaning the description must compensate. However, it provides no explanation of the 'enabled' and 'patterns' parameters beyond their names. While the names are somewhat self-explanatory, the description does not add any meaning about how they are used or interact, which is insufficient given the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Update') and resource ('command blacklist configuration'), making the tool's purpose reasonably clear. However, it does not differentiate from sibling tools like 'reset_command_blacklist' or 'get_command_blacklist', which could cause confusion about the specific scope of the update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not indicate when to use this tool over alternatives (e.g., when to update vs. reset), nor does it mention any prerequisites or context for using the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Switch to a saved Redis connection.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must provide behavioral details. It only states the action but omits consequences (e.g., closing previous connection, what happens if the name is invalid, session state changes). For a state-mutating tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence), but it lacks structure and critical details. While brevity is valued, it sacrifices clarity. It could list the prerequisite (saved connections) in a front-loaded manner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, no output schema), the description should still explain the effect on the session, error handling, and relationship to other tools. It fails to provide enough context for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to the 'name' parameter. It does not clarify that 'name' must match a saved connection identifier or that it is case-sensitive. The agent is left to infer from the tool name alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Switch to') and the resource ('saved Redis connection'). It distinguishes from siblings like test_connection and delete_connection by focusing on selecting an existing connection. However, it could be improved by explicitly noting that the connection becomes active for subsequent operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. For example, it doesn't mention that list_saved_connections should be used first to get available names, or that test_connection can verify connectivity. Without this, an agent might use it without proper context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools have distinct purposes, but there is overlap between get_key_info and specific getters (get_string, get_hash, etc.) as well as between execute_command and run_redis_query. This could cause an agent to select the wrong tool.
All tool names follow a consistent verb_noun pattern with lowercase and underscores. The verbs appropriately reflect Redis command conventions (add for sets, set for strings/hashes, push for lists). Very consistent.
With 30 tools, the server is over-scoped. While each tool corresponds to a specific Redis operation, there is redundancy (e.g., get_key_info vs get_string) and the count exceeds 25, which is considered too many for a coherent set.
The tool set covers basic Redis operations for major data types and connection management, but lacks commonly used operations like INCR, EXISTS, APPEND, and advanced data structures. However, the presence of execute_command allows agents to fill gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
MCP server for AI dialogue using various LLM models via AceDataCloud
Talk to your public-facing AI from any MCP client — Claude, ChatGPT, Cursor, Cline, Windsurf.
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/minivv/redis-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
