Skip to main content
Glama
redis

Redis MCP Server

Official
by redis

vector_search_hash

Find similar vectors stored in Redis hash structures using K-nearest neighbor search to retrieve relevant documents based on vector similarity.

Instructions

Perform a KNN vector similarity search using Redis 8 or later version on vectors stored in hash data structures.

Args: query_vector: List of floats to use as the query vector. index_name: Name of the Redis index. Unless specifically specified, use the default index name. vector_field: Name of the indexed vector field. Unless specifically required, use the default field name k: Number of nearest neighbors to return. return_fields: List of fields to return (optional).

Returns: A list of matched documents or an error message.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
query_vectorYes
index_nameNovector_index
vector_fieldNovector
kNo
return_fieldsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • The core handler function for the 'vector_search_hash' MCP tool. It performs KNN vector similarity search on Redis hashes using HNSW index. Decorated with @mcp.tool() for automatic registration.
    @mcp.tool()
    async def vector_search_hash(
        query_vector: List[float],
        index_name: str = "vector_index",
        vector_field: str = "vector",
        k: int = 5,
        return_fields: Optional[List[str]] = None,
    ) -> Union[List[Dict[str, Any]], str]:
        """
        Perform a KNN vector similarity search using Redis 8 or later version on vectors stored in hash data structures.
    
        Args:
            query_vector: List of floats to use as the query vector.
            index_name: Name of the Redis index. Unless specifically specified, use the default index name.
            vector_field: Name of the indexed vector field. Unless specifically required, use the default field name
            k: Number of nearest neighbors to return.
            return_fields: List of fields to return (optional).
    
        Returns:
            A list of matched documents or an error message.
        """
        try:
            r = RedisConnectionManager.get_connection()
    
            # Convert query vector to float32 binary blob
            vector_blob = np.array(query_vector, dtype=np.float32).tobytes()
    
            # Build the KNN query
            base_query = f"*=>[KNN {k} @{vector_field} $vec_param AS score]"
            query = (
                Query(base_query)
                .sort_by("score")
                .paging(0, k)
                .return_fields("id", "score", *return_fields or [])
                .dialect(2)
            )
    
            # Perform the search with vector parameter
            results = r.ft(index_name).search(
                query, query_params={"vec_param": vector_blob}
            )
    
            # Format and return the results
            return [doc.__dict__ for doc in results.docs]
        except RedisError as e:
            return f"Error performing vector search on index '{index_name}': {str(e)}"
  • The @mcp.tool() decorator registers the vector_search_hash function as an MCP tool.
    @mcp.tool()
  • Function signature provides the input schema (parameters with types and defaults) and output type for the tool.
    async def vector_search_hash(
        query_vector: List[float],
        index_name: str = "vector_index",
        vector_field: str = "vector",
        k: int = 5,
        return_fields: Optional[List[str]] = None,
    ) -> Union[List[Dict[str, Any]], str]:
Behavior3/5

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

With no annotations provided, the description carries full burden. It discloses the technology constraint (Redis 8+) and search behavior (KNN similarity), but doesn't mention performance characteristics, error conditions, authentication requirements, or rate limits. The description adds basic operational context but lacks comprehensive behavioral disclosure for a search operation.

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 well-structured with a clear purpose statement followed by parameter explanations in a consistent format. It's appropriately sized for a 5-parameter tool, though the 'Args:' and 'Returns:' sections could be more integrated with the main description. Every sentence adds value with no redundant information.

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 tool's complexity (vector search with 5 parameters), no annotations, and the presence of an output schema, the description provides good coverage. It explains the operation, all parameters, and return behavior. The output schema handles return value details, so the description appropriately focuses on operational context rather than duplicating structured data.

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?

With 0% schema description coverage, the description must compensate. It provides clear semantic explanations for all 5 parameters beyond their schema definitions, explaining what each parameter represents (e.g., 'List of floats to use as the query vector', 'Number of nearest neighbors to return') and offering usage guidance for defaults. This adds substantial value over the bare schema.

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 ('Perform a KNN vector similarity search'), technology ('using Redis 8 or later'), and data structure ('vectors stored in hash data structures'). It distinguishes itself from sibling tools like 'search_redis_documents' by specifying vector-based search on hash structures rather than general document search.

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 context through technology requirements (Redis 8+) and data structure (hash), but doesn't explicitly state when to use this tool versus alternatives like 'search_redis_documents' or 'get_vector_from_hash'. It provides default values guidance but lacks explicit 'when-not-to-use' scenarios or comparison with sibling tools.

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