mcp-server-redis

Server Quality Checklist

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

Latest release: v1.0.1
Disambiguation2/5
Several tools overlap significantly: set_data/create_key/update_data all manipulate key values, and delete_data/drop_key are essentially the same. The distinction between get_data, get_key_info, and exists_key may also confuse agents.
Naming Consistency3/5
Most tools follow a verb_noun snake_case pattern, but the inconsistent use of 'data' vs 'key' for the same resource (e.g., set_data vs create_key, delete_data vs drop_key) breaks a predictable convention.
Tool Count3/5
With 18 tools, the server is on the heavier side. While many are justified for Redis management, there is enough redundancy that the count feels slightly bloated.
Completeness4/5
The toolset covers core Redis CRUD, key lifecycle (rename, TTL), server info, and maintenance operations. Minor gaps like batch operations or type-specific commands exist, but they are not critical for basic usage.
Average 3.2/5 across 18 of 18 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/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 does not mention read-only nature, authentication requirements, pagination behavior, output format, or any side effects. The description is entirely silent on behavioral traits.
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 short, which is concise, but it under-specifies the tool's purpose and behavior. While it is not verbose, the lack of context means it does not fully earn its place as a useful description.
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 has no output schema, no annotations, and only a terse description, it is severely incomplete. It fails to explain what operation logs are, what the limit/offset parameters mean in context, or what the returned data looks like. The description is inadequate for a tool with even minimal complexity.
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% for both parameters (limit and offset) with clear default values. The description adds no extra semantic meaning beyond the schema, but the baseline is 3 because the schema covers the parameters adequately.
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 uses a specific verb and resource ('Get operation logs'), clearly indicating it retrieves operation logs. It distinguishes itself from sibling tools like get_data or get_database_stats by focusing on logs rather than data or metrics, though it does not elaborate on what operation logs are.
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. There is no mention of prerequisites, typical use cases, or exclusions. This is a bare statement with no contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 disclosure. It does not reveal whether the operation is read-only, what fields of 'detailed information' are returned (e.g., type, TTL, encoding), or any permissions required. This is insufficient for a tool with no structured safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence—and the key detail is front-loaded. However, it is under-specification rather than efficient conciseness, earning a 4 instead of a 5 because it omits necessary qualifiers.
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 simple tool with one parameter and no output schema, the description should clarify what 'detailed information' means and how it differs from get_data. Given the large sibling set and no annotations, the description is incomplete for reliable selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the only parameter 'key' with a description ('Redis key to get info for'), achieving 100% coverage. The tool description adds no further semantic detail, so the baseline score of 3 applies; the schema already documents what the parameter is.
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 uses a specific verb ('get') and a resource ('key'), but 'detailed information' is vague and does not distinguish this tool from siblings like get_data (which likely retrieves values) or get_redis_info (which retrieves server info). It states what it does but not what 'information' entails.
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. The sibling tools (get_data, exists_key, list_keys) indicate related but distinct operations, yet the description offers no exclusions or comparisons to help an agent choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 only states the core operation and does not mention potential side effects (e.g., overwriting existing keys), default types or TTL, required permissions, or whether the operation is reversible. This is a significant gap for a mutating operation.
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 concise sentence with no wasted words. It is front-loaded with the action and resource, making it immediately clear what the tool does.
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?
Despite the schema being complete, the description lacks contextual information that an agent needs: no mention of return values, error conditions, default behaviors, or use cases. For a tool with four parameters and no output schema or annotations, this is under-specified.
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 covers all four parameters with descriptions, so the baseline is 3. The tool description 'Create a new key' adds no additional meaning beyond the schema, but does not need to since the schema already explains each parameter.
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 ('Create a new key') and the resource ('in Redis'), which is specific and unambiguous. However, it does not differentiate from sibling tools like set_data or update_data, which may also create or modify keys, so it lacks explicit sibling differentiation.
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 such as set_data or update_data. There are no mentions of prerequisites, typical scenarios, or situations where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden. It states the core destructive action ('delete') but omits details like permanence, idempotency, or what happens to associated data. No extra context is provided 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It is appropriately concise for a simple delete operation.
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?
The tool is simple, but the description lacks information about return values, error handling, or behavior when the key does not exist. With no output schema or annotations, the agent is left without full context for using this tool 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?
The schema covers the sole parameter 'key' with a relevant description ('Redis key to delete'). Since schema coverage is 100%, the description adds no additional semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete data by key from Redis' clearly states the action (delete) and the target (data by key). It is specific about the tool's function, but does not differentiate it from the sibling tool 'drop_key', which may overlap in purpose.
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 such as 'drop_key' or 'update_data'. There is no mention of prerequisites, permissions, or typical scenarios for deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It only says 'Set/insert' without detailing overwrite behavior, TTL effects, error handling, or return values. This is a significant gap 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no waste, but it also omits crucial details. It is appropriately brief for a simple tool, though slightly redundant with 'Set/insert'.
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?
The tool has 4 parameters and no output schema or annotations. The description does not explain return values, overwrite semantics, or how the 'type' parameter affects behavior, making it insufficient for reliable tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with meaningful descriptions for key, ttl, type, and value. The description adds no additional parameter context, but the schema fully documents them, so baseline of 3 applies.
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 states a clear action ('Set/insert') and target ('data for a key in Redis'), establishing it as a write operation for Redis keys. It lacks explicit differentiation from sibling 'update_data', but the action and resource are specific enough.
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 vs alternatives like update_data or create_key. The description only restates the operation without context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 implies a mutating operation, but does not clarify whether it creates a key if absent, how it interacts with existing TTL, or what response is returned. Significant gaps remain for a write operation.
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, concise sentence with no redundant wording. It front-loads the primary action and resource, achieving high efficiency at the cost of detail that other dimensions evaluate.
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?
As a mutation tool with no annotations and no output schema, the description is too minimal. It fails to explain edge cases (e.g., updating a non-existent key), TTL semantics, or return behavior, making it inadequate for an agent to fully anticipate the tool's runtime behavior.
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 already describes all three parameters (key, value, ttl) with 100% coverage. The description adds no additional semantic detail beyond what the schema provides, so it meets the baseline for high schema coverage but does not enhance 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 ('Update existing data') and the resource ('a key in Redis'), giving a specific verb and object. However, it does not distinguish itself from the sibling tool 'set_data', which may perform a similar operation, so it lacks explicit differentiation.
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?
There is no guidance on when to use this tool versus alternatives like 'set_data', 'create_key', or 'delete_data'. The description gives no context about preconditions (e.g., key must exist) or scenarios that favor this tool, so usage is ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. 'Delete a key' implies destructiveness, but the description does not warn about irreversibility, required permissions, behavior for non-existent keys, or side effects (e.g., TTL cleanup). This is a significant gap 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, focused sentence that front-loads the verb and resource. There is no wasted wording or redundancy. It is appropriately minimal for a one-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema), and the description gives a basic understanding of the operation. However, without annotations or output schema, the agent lacks information about return values, error handling, or idempotency. This is the minimum viable level but leaves clear gaps.
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 already provides a 100% description for the 'key' parameter, so the description adds no new meaning. The parameter is fully documented in the schema, meeting the baseline for high coverage without requiring extra detail.
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 (Delete) and the resource (a key in Redis), making the tool's purpose immediately obvious. However, it does not explicitly differentiate from sibling tools like delete_data or rename_key, so it doesn't fully meet the highest bar for 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 gives no guidance on when to use this tool versus alternatives such as delete_data, rename_key, or set_data. There is no mention of prerequisites, exceptions, or situations where a different tool would be more appropriate, leaving the agent to infer usage solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 only says 'Get', implying a read-only operation, but does not disclose what statistics are returned, whether additional permissions are required, or any other behavioral traits such as rate limits or response format. This minimal description 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 short sentence that immediately states what the tool does. It is concise, free of filler, and easy to parse. No unnecessary words or repetition.
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?
With no output schema and no annotations, the description is the only source of information about what the tool returns and how it behaves. 'Get Redis database statistics' is too vague to be complete—it does not specify which statistics, the format, or how it relates to siblings like get_memory_info. For a tool with no parameters and an unknown output, this description leaves too much to the imagination.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is empty and there is nothing for the description to clarify about parameter meaning. The description adds no param-level information, but none is needed. A baseline of 4 is appropriate for a parameter-less tool.
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 uses a specific verb ('Get') and identifies a clear resource ('Redis database statistics'). It is unambiguous and matches the tool name, but it does not differentiate from sibling tools like get_redis_info or get_memory_info, which could also return statistics. It clearly states what the tool does, though without distinguishing 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 the many sibling tools. There is no mention of use cases, exclusions, or alternatives. The only implied usage is that it retrieves database statistics, but this is not made explicit or compared with other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. 'Get Redis server information' implies a safe read-only operation, but it does not mention what data is returned, whether sensitive information is exposed, or any rate limits/auth requirements. This is a minimal disclosure.
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 with no wasted words. It conveys the essential purpose immediately, which is appropriate for a zero-parameter tool.
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?
Despite the low complexity, the description is incomplete because it does not specify the contents of 'server information'. With no output schema, the agent is left guessing about return values. It could at least mention likely fields (e.g., version, uptime, memory). The sibling tools further create ambiguity about exact scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, making the schema complete and the parameter semantics irrelevant. The baseline of 4 applies because no parameter documentation is needed; the description adds no param details but none are required.
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 tool's action (Get) and resource (Redis server information). However, it does not distinguish from sibling tools like get_database_stats or get_memory_info, which also return server-related data. It is specific enough for a simple read operation but lacks scope detail.
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 sibling tools. The description gives no context on scenarios, prerequisites, or alternatives, leaving the agent without differentiation cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 only states the action, without explaining side effects like overwriting an existing TTL, whether the TTL must be positive, or error conditions. This is insufficient for a mutating operation.
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, concise sentence with no irrelevant information. It is appropriately sized for the simple operation it describes.
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 state-changing tool with no annotations and no output schema, the description is under-specified. It lacks context about side effects, success/failure behavior, or how TTL interacts with existing key data. More behavioral context is needed for an agent to use it 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?
Schema description coverage is 100%, with both parameters (key and ttl) having clear descriptions. The tool description itself adds no additional parameter semantics beyond what the schema already provides, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set') and resource ('time to live for a key'), clearly stating the tool's function. It is unambiguous and distinct from sibling tools like remove_ttl or get_key_info, though it doesn't explicitly differentiate them.
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 gives no explicit guidance on when to use this tool versus alternatives. There is no mention of prerequisites, alternatives, or exclusion criteria. The usage is implied only by the tool's name and basic description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description alone must disclose behavioral traits. It only states 'list Redis keys' and implies read-only operation, but does not mention pagination behavior, performance implications, return format, or the glob style of pattern matching. The schema hints at offset/limit, but the description adds no risk or side-effect 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 sentence with no filler: 'List Redis keys with optional pattern matching'. It is front-loaded with the main action and a key option, making it concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool, the description covers the core purpose and the schema handles parameter meanings. However, without an output schema or annotations, the return format, pagination default behavior, and possible performance caveats are not disclosed. It is minimally viable but leaves some gaps for an agent.
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 already provides complete descriptions and defaults for all three parameters (limit, offset, pattern), giving 100% coverage. The description only mentions 'optional pattern matching', which adds no value beyond the schema. Baseline 3 is appropriate because the schema carries the semantic load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'list' with a clear resource ('Redis keys') and notes optional pattern matching. This distinguishes it from sibling tools like get_data or exists_key, which operate on individual keys rather than enumerating them.
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 when-to-use guidance is provided. The description does not mention scenarios where list_keys is preferred over alternatives like get_data or exists_key, nor does it explain exclusion conditions. The usage is implied by the name but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the core operation (removes TTL) but does not disclose what happens if the key does not exist or has no TTL, whether the operation is destructive to the key's value, or what the return value/response is. For a mutating operation, 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, concise sentence that is front-loaded with the action. It contains no filler or redundant information, earning its place effectively. Brevity is appropriate for such a simple operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description covers the basic purpose but lacks important contextual details such as return behavior, error conditions, or interaction with TTL semantics. It is minimally complete but leaves open questions that an agent might need answered, especially without annotations.
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 for the single parameter 'key' is complete: 'Redis key to remove TTL from'. Since schema coverage is 100%, the description adds no additional meaning beyond what the schema already provides. The baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Remove time to live from a key'. It uses a specific verb (remove) and resource (key), and the concept of TTL is unambiguous. This distinguishes it from siblings like set_ttl (which adds TTL) and delete_data (which removes the key itself).
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 about when to use this tool versus alternatives. There is no mention of prerequisites (e.g., key must exist, must already have a TTL) or scenarios where this is preferred over set_ttl or drop_key. The only implied usage is derived from the name and description, but no explicit context or exclusions are offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states the operation is 'get', implying read-only, but does not disclose behavior such as what is returned for a missing key, whether it returns metadata or just the value, or any permissions required. For a simple get, this is adequate but lacks explicit detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It is appropriately sized for the simplicity of the tool, though it could benefit from a bit more context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema), the description is minimally viable but lacks explicit mention of return behavior or how it differs from related sibling tools. It is adequate for a trivial get operation but leaves room for clarification.
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 already fully documents the 'key' parameter at 100% coverage, so the description adds no extra meaning beyond what the schema provides. The mention of 'by key' is redundant with the schema's 'Redis key to get data from'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get data by key from Redis' clearly states the action (get) and the resource (data by key from Redis), distinguishing it from sibling tools like exists_key and get_key_info. The verb and resource are 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?
No guidance is provided about when to use this tool versus its siblings. The description does not mention alternatives, exclusions, or conditions under which get_data is preferred over exists_key, get_key_info, or other related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states the action 'rename' without revealing critical behavior such as whether an existing newKey is overwritten, what happens if oldKey does not exist, or any side effects. This is a significant gap for a mutation operation.
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?
A single sentence that is front-loaded and directly states the operation. Every word earns its place, and there is no redundant or extraneous content.
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 output schema and no annotations, this description is too sparse. It omits important contextual information like overwrite semantics, error conditions, and return behavior, which an agent would need to invoke the tool correctly and anticipate consequences.
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 both oldKey and newKey clearly described as current and new key names. The description itself adds no additional parameter meaning beyond what the schema already provides, so 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Rename a key in Redis' uses a specific verb and resource, clearly distinguishing this tool from siblings like set_data, delete_data, or create_key. The purpose is immediately unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a key needs renaming, but it does not explicitly state when to choose this tool over alternatives or mention any exclusions. There is no sibling that renames keys, so the use case is reasonably clear, but guidance is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 only states the purpose ('Get Redis memory usage information') and implies a read operation, but does not mention return format, required permissions, or 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.
Conciseness5/5
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 with the action and resource, making it immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal and does not explain the output structure or details of what 'memory usage information' includes, especially since there is no output schema. However, the tool's simplicity (no parameters) makes the description minimally viable, though it could be more explicit about return contents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. There is no parameter meaning to add beyond the empty schema, and the description does not need to elaborate on parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb+resource: 'Get Redis memory usage information'. It distinguishes itself from sibling tools like get_redis_info (which likely covers broader Redis info) and get_database_stats by focusing specifically on memory.
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 compared to alternatives. Sibling tools like get_redis_info and get_database_stats exist, but the description does not indicate which to choose for memory-specific queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Absent annotations, the description carries the burden of explaining behavior. It clearly indicates a read-only existence check, but does not disclose the return format (e.g., boolean true/false) or behavior on missing keys. The core operation is clear, but some behavioral details are omitted.
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, concise sentence with no unnecessary words. It directly states the tool's action and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature (one parameter, no output schema), the description is mostly sufficient. However, since there is no output schema, mentioning the return value (e.g., 'returns true if key exists, false otherwise') would enhance completeness, but its absence is not critical for a straightforward existence check.
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 parameter 'key' is fully described in the schema ('Redis key to check') with 100% coverage. The tool description adds no additional meaning beyond what the schema already provides, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Check if a key exists in Redis' uses a specific verb ('Check') and resource ('key exists'), clearly stating the tool's purpose. It is distinct from siblings like get_data or get_key_info, which imply retrieval rather than a boolean existence test.
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 such as get_key_info or get_data. The description simply states what it does without contextual clues for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 only says 'Test Redis connection' without revealing whether the operation is read-only, any side effects, or what a successful or failed test returns.
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 four words long, directly expressing the tool's purpose with zero filler. Every word earns its place and the structure is optimally compact.
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?
Despite the tool's simplicity, it lacks an output schema and annotations, so the description should explain the return value or outcome of the connection test. It does not, leaving the agent without critical information on how to interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% trivially. The description has nothing to add beyond the empty schema, so the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action (Test) and a resource (Redis connection). This distinguishes it from sibling tools like get_data or delete_data, which operate on data rather than the connection itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for verifying connectivity but provides no explicit guidance on when to use it versus alternatives, such as get_redis_info for server diagnostics. The usage context is left to the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Check Redis permissions' without stating whether this is a read-only operation, what the return format is, whether authentication or specific permissions are required, or any side effects. The agent cannot determine what happens when invoking this tool beyond the vague concept of checking.
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 sentence that is front-loaded with the verb 'Check' and immediately states the resource and scope. It contains no redundant words or filler, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 but lacks a description of the return value or behavior. It also does not provide guidance on when to use this tool relative to the extensive sibling list, or mention any side effects. A more complete description would state that it returns the user's permissions for the listed operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so there is nothing to describe. The operations listed in the description are not parameters but define the scope of the check. A baseline of 4 is appropriate because the description adds no parameter information (as none exist), and no further semantic explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Check' and the resource 'Redis permissions', and specifies the exact operations it covers (insert, update, delete, create, drop). This distinguishes it from sibling tools like get_data or set_data, which perform data operations rather than permission checks. It is specific, direct, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool should be used to verify permissions before performing mutation operations such as set_data, delete_data, create_key, or drop_key. However, it does not explicitly state when to use it versus alternatives, nor does it mention any exclusions or prerequisites. The usage context is left to the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

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

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