Skip to main content
Glama
redis

Redis MCP Server

Official
by redis

zrange

Retrieve a range of members from a Redis sorted set by specifying start and end indexes. Optionally include scores for each member in the results.

Instructions

Retrieve a range of members from a Redis sorted set.

Args: key (str): The sorted set key. start (int): The starting index. end (int): The ending index. with_scores (bool, optional): Whether to include scores in the result.

Returns: str: The sorted set members in the given range or an error message.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
keyYes
startYes
endYes
with_scoresNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • The zrange tool handler: an async function decorated with @mcp.tool() that executes the Redis ZRANGE command to retrieve members from a sorted set, with optional scores, handling errors and formatting the response.
    @mcp.tool()
    async def zrange(key: str, start: int, end: int, with_scores: bool = False) -> str:
        """Retrieve a range of members from a Redis sorted set.
    
        Args:
            key (str): The sorted set key.
            start (int): The starting index.
            end (int): The ending index.
            with_scores (bool, optional): Whether to include scores in the result.
    
        Returns:
            str: The sorted set members in the given range or an error message.
        """
        try:
            r = RedisConnectionManager.get_connection()
            members = r.zrange(key, start, end, withscores=with_scores)
            return (
                str(members) if members else f"Sorted set {key} is empty or does not exist"
            )
        except RedisError as e:
            return f"Error retrieving sorted set {key}: {str(e)}"
  • The load_tools function imports all modules in src/tools, triggering the @mcp.tool() decorators to register tools including zrange from sorted_set.py.
    def load_tools():
        import src.tools as tools_pkg
    
        for _, module_name, _ in pkgutil.iter_modules(tools_pkg.__path__):
            importlib.import_module(f"src.tools.{module_name}")
    
    
    # Initialize FastMCP server
    mcp = FastMCP("Redis MCP Server", dependencies=["redis", "dotenv", "numpy", "aiohttp"])
    
    # Load tools
    load_tools()
Behavior2/5

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

No annotations are provided, so the description carries full burden. It mentions the return type ('str') and error handling, but lacks details on behavioral traits like whether the operation is read-only (implied by 'retrieve'), performance considerations, rate limits, or authentication needs. The description is minimal beyond basic function.

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 appropriately sized and front-loaded with the core purpose, followed by structured sections for args and returns. Every sentence earns its place, but the 'Returns' section could be more concise by integrating with the main description.

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 no annotations, 0% schema coverage, and an output schema exists (implied by 'Returns'), the description is moderately complete. It covers basic purpose and parameters but lacks behavioral context (e.g., read-only nature, error conditions) and doesn't fully explain parameter nuances or sibling differentiation, leaving gaps for a tool with 4 parameters.

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

Parameters4/5

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

Schema description coverage is 0%, so the description must compensate. It adds meaning by explaining each parameter's role (e.g., 'key' as the sorted set key, 'start' and 'end' as indices, 'with_scores' for including scores), which clarifies beyond the bare schema. However, it doesn't detail index semantics (e.g., inclusive/exclusive, negative indices) or default behavior for 'with_scores'.

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 specific action ('retrieve a range of members') and resource ('from a Redis sorted set'), distinguishing it from siblings like zadd (add), zrem (remove), or xrange (stream range). It precisely identifies the tool's function without being tautological.

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 for retrieving sorted set members by range, but provides no explicit guidance on when to use this tool versus alternatives like zrangebyscore (score-based range) or lrange (list range). It lacks context about prerequisites or exclusions, leaving usage inferred rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

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/redis/mcp-redis'

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