Redis MCP Server

Official

by redis

Overview Schema Related Servers Score Discussions

Python

Hybrid

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool maps to a distinct Redis command or data structure operation, so an agent can clearly identify the appropriate tool for a given task. The few overlapping tools like scan_keys and scan_all_keys are explicitly differentiated by their partial vs. full result behavior.
Naming Consistency4/5
Tool names use lowercase with underscores and generally follow a verb_noun or Redis command style. Minor deviations like 'dbsize' or single-word commands ('set', 'get', 'type') are standard Redis command names and don't break the overall consistency.
Tool Count2/5
With 53 tools, the surface is very large and could overwhelm an agent. While Redis is broad, so many individual tools are excessive for a single MCP server, and many related operations could be grouped or parameterized.
Completeness4/5
The tool set covers the main Redis data structures (strings, hashes, lists, sets, sorted sets, streams, JSON) plus pub/sub, search, indexing, and server info. Missing operations like TTL/EXISTS/INCR or index deletion are minor gaps that can be worked around.
Average 3.6/5 across 49 of 53 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- 7 of 12 community issues answered or closed in the last 6 months
- 21 commits in the last 12 weeks
- Last stable release on August 5, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral disclosure burden. It mentions deletion but lacks key behavioral traits: whether the key must exist, if deletion is irreversible, error specifics (only 'error message' is vague), or side effects. The destructive nature is implied but not elaborated.
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 very concise, using only four lines to state purpose, parameters, and return. It is front-loaded with the action and well-structured with Args and Returns sections. However, the brevity sacrifices informative content.
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 (1 param, no annotations, output schema exists), the description adequately covers the basic operation and return type (confirmation or error). However, it does not address edge cases like non-existent keys or complex key types, and it does not explain the output structure beyond a string. Sibling tool complexity suggests more context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter 'key' with no description (0% schema coverage). The description merely repeats 'key (str): The key to delete,' adding no additional meaning about format, constraints, or valid values. It fails to enrich understanding 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 clearly states 'Delete a Redis key,' specifying the action and resource. The tool name 'delete' is generic, but naming it as a Redis key deletion helps distinguish it from sibling tools like 'hdel' or 'srem' that delete specific data structure elements. However, it does not explicitly differentiate from other delete operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools for different data structure deletions (e.g., hdel, lrem, zrem), the description should indicate that this tool is for top-level key deletion, not for fields or members. The absence of usage context hinders correct 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?
Without annotations, the description only mentions return type (string) but does not disclose side effects (none), error conditions, bounds behavior, or result format details. Minimal behavioral context.
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?
Very concise (two sentences) but lacks necessary detail. It is efficient but at the cost of clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of many sibling list tools, no output schema details, and no annotations, the description is incomplete. It fails to clarify Redis index conventions, error handling, or return format specifics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 3 parameters (name, start, stop) with 0% description coverage. The description does not explain the meaning of start/stop (e.g., inclusive/exclusive, indexing convention), leaving them ambiguous.
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 action ('Get elements'), resource ('Redis list'), and operation ('within a specific range'). It distinguishes from sibling tools like llen, lpop, lpush, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus other list operations (e.g., lrange vs. llen or lindex). No context about 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.
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 'destroy' without explaining side effects (e.g., whether pending messages are discarded), error handling (e.g., behavior on nonexistent group), or required permissions. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4 lines) and front-loaded with the core purpose. However, it could benefit from a structured format (e.g., bullet points) to improve readability for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature and the presence of sibling tools like xgroup_create and xreadgroup, the description lacks critical context about prerequisites, error states, and the return value structure. The output schema exists but is not explained beyond 'returns str', leaving the AI agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description restates parameter names and types from the schema ('key (str): The stream key.') without adding meaningful constraints, examples, or validation rules. Schema description coverage is 0%, so the description should compensate, but it fails to do so.
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 ('Destroy') and the resource ('a consumer group for a Redis stream'), making the tool's purpose immediately understandable. However, it does not elaborate on what 'destroy' entails or how it differs from other group operations like deleting the stream 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 on when to use this tool, prerequisites (e.g., group must exist), or alternatives. For example, it does not mention that xgroup_destroy is the inverse of xgroup_create, nor does it advise against destroying an in-use group.
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?
Cannot rely on annotations (none provided). Description lacks details on list empty behavior, blocking semantics, or side effects. Only bare operation stated.
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?
Single short sentence with no filler. However, it may be excessively terse, sacrificing necessary context for brevity.
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?
Output schema exists but is not detailed in the description. Lack of parameter explanation and behavioral edge cases makes it incomplete for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has one parameter 'name' with 0% description coverage. Description does not explain what 'name' refers to (e.g., the Redis key for the list). No added meaning beyond 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?
Clearly states the tool removes and returns the last element from a Redis list, using a specific verb and resource. This distinguishes it from siblings like lpop (first element) and rpush (add to end).
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 rpop versus alternatives (e.g., lpop for first element, lrange for peeking). No mention of prerequisites or context.
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 provided, so description carries full burden. It claims 'Delete' which implies destructiveness but does not mention idempotency, behavior on non-existent field, or exact return value (success/error is vague).
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?
Concise at 6 lines, front-loaded with purpose. However, it includes an 'Args' and 'Returns' section that are structured but not necessary if schema and output schema are present. No wasted words.
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 deletion tool, the description is adequate but lacks details on error handling, return format (e.g., integer count), and notes about field existence. The output schema is not used to provide return structure.
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?
Input schema has 0% description coverage. Description adds basic meaning: 'name' is Redis hash key, 'key' is field name. This clarifies but is minimal and expected.
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?
Clearly states it deletes a field from a Redis hash. The verb 'Delete' and resources 'field' and 'Redis hash' are specific. However, it does not explicitly differentiate from similar hash tools like hdel vs hdel (sibling named hset, hget), but the purpose is clear 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 versus alternatives (e.g., srem for sets). No mention of prerequisites like field existence or that this is for removing a single field, not the entire hash.
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 should fully disclose behavior. It states the action but does not explain side effects (e.g., whether entries are removed from history), required permissions, or error conditions beyond a generic error message. The return type is mentioned but not detailed.
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 structured as a docstring with clear sections (Args, Returns). It is concise, using minimal words to convey purpose. However, it could be slightly more compact by removing redundant mentions of argument types that are already in the schema.
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 moderate complexity (acknowledging stream entries) and the availability of an output schema (return type), the description covers the basic what and how. However, it lacks usage context, prerequisites (e.g., consumer group must exist), and behavioral details that would make it self-sufficient for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, meaning property descriptions are missing. The description's 'Args:' section merely repeats the parameter names and types without adding meaning (e.g., what each parameter represents, constraints, or format). This adds no value over the 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 tool's purpose: acknowledging entries processed by a consumer group, which is a specific verb+resource combination. It is distinct from sibling tools like xdel (delete) or xreadgroup (read), so the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as xdel or xreadgroup. Missing context like prerequisites (e.g., need to be a consumer group member) 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations; description only mentions success/error message. Lacks details on idempotency, effect if value not in set, or return value (actual SREM returns count).
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?
Concise and well-structured with clear Args and Returns sections. Front-loaded description is efficient.
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?
Lacks details on behavior for non-existent keys or values, and the return description is inaccurate (SREM returns integer, not just message). Output schema not utilized to clarify.
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 has 0% description coverage; description adds 'The Redis set key' and 'The value to remove' but does not fully clarify type constraints or valid inputs.
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?
Clear verb ('Remove') and resource ('value from a Redis set'). Differentiates from sibling tools like sadd (add) and smembers (list).
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 vs. alternatives (e.g., hdel for hashes, lrem for lists). No context for when not to use.
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 provided, and description only states it sets expiration and returns success/error. It does not disclose key behavioral traits: whether it works only on existing keys, overwrites existing TTL, or behavior for expired keys.
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?
Description is succinct with clear Args and Returns sections. Minor verbosity: blank line after first sentence not needed. Otherwise well-structured.
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 output schema exists and tool complexity is low, description covers core purpose and parameters. However, missing behavioral details (e.g., key existence handling, overwrite behavior) reduce completeness.
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?
Input schema has 0% coverage, so description compensates by defining both parameters: name as 'the Redis key' and expire_seconds as 'time in seconds after which the key should expire'. This is adequate but basic.
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?
Description clearly states the verb 'Set' and the resource 'Redis key' with the specific action 'expiration time'. This distinguishes it from sibling tools like 'set' or 'delete'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no prerequisites or when-not-to-use advice. It simply describes the operation without context.
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?
While it mentions 'remove' (destructive), it does not disclose behavior on empty lists, error cases, or blocking semantics. Annotations are absent, so the description bears the full burden but falls short.
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 with no extraneous words. It front-loads the action and resource, achieving high conciseness.
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 atomic Redis command, the description is adequate but lacks details about return values (implied) and edge cases. Given the presence of an output schema (not shown), the description could be more thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'name' is not explained in the description. With 0% schema description coverage, the agent must infer it as the Redis key; no type or format hints are provided beyond the 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 action ('Remove and return') and the target resource ('the first element from a Redis list'). It distinguishes itself from sibling tools like rpop (last element) and lpush (add to left).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as rpop or lrange. No context about use cases, prerequisites, or constraints like list emptiness.
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 disclose behavioral traits, but it only states the basic operation. It omits details such as whether the list is created if it doesn't exist, what happens on error, idempotency, or the return value (though an output schema may exist). The mutation implied by 'push' is the only behavioral hint.
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 that efficiently communicates the core action and optional parameter. No unnecessary words or redundancy, earning a high score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and a 0% schema coverage, the description is insufficiently complete. It lacks behavioral context like list creation behavior, error conditions, return value semantics (though output schema may help), and does not leverage sibling tool names to clarify usage boundaries.
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 0%, so the description should compensate. It adds meaning to 'value' (the element to push) and 'expire' (optional TTL), but does not explain 'name' (the list key) or the allowed data types for 'value' as defined in the schema. Partial coverage, leaving gaps.
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 action ('Push'), the resource ('a value onto the right of a Redis list'), and an optional feature ('set an expiration time'). It distinguishes this from the sibling tool 'lpush' by specifying 'right', and from other list operations by naming the verb 'push'.
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 rpush versus alternatives like lpush or other list commands. It does not mention prerequisites, when not to use it, or any specific context where this tool is more appropriate.
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?
No annotations provided, so description carries burden. It mentions returning an error message, hinting at error for non-set keys, but lacks details on behavior for missing keys or performance.
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?
Very concise, two sentences for core description plus args/returns. No wasted text, but could be slightly more structured.
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?
Simple tool with output schema present. Description covers return type (list or error). Sufficient for basic understanding.
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 0%, but description adds minimal gloss: 'The Redis set key.' This adds value beyond the schema's bare field name.
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 'Get all members of a Redis set,' identifying the action and resource. It distinguishes from siblings like 'sadd' and 'srem' by being a read operation.
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 over alternatives, no prerequisites or context for usage.
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?
The description omits important behavioral details: it states 'Add' but does not clarify that ZADD in Redis also updates the score if the member already exists. No side effects, permissions, or atomicity are discussed, and no annotations are present to offset the lack of 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 extremely concise, using a clear 'Args' and 'Returns' format. Every sentence serves a purpose, with no wasted words.
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?
While the description covers the basic operation, it lacks details about behavior when the member already exists (update vs. strict add). Given the tool's low complexity and no annotations, the description could be more complete to support correct invocation.
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 0% description coverage, so the description alone defines parameter semantics. It explains 'key' as the sorted set key, 'score' as the member's score, 'member' as the member to add, and 'expiration' as time in seconds. This adds valuable meaning beyond the bare schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Add' and the resource 'member to a Redis sorted set', making the tool's purpose evident. However, it does not explicitly differentiate from sibling tools like zrange or zrem, which also operate on sorted sets.
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 zrange or zrem. There is no mention of prerequisites or scenarios where the tool is appropriate or should be avoided.
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 fully carries transparency. It lacks disclosure of side effects (e.g., overwrites existing index?), idempotency, error conditions beyond a generic error message, or any destructive behavior. The return type is mentioned but insufficient.
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 relatively concise, starting with a clear purpose. The Args list is text-based but structured. Some repetition ('Unless specifically required' for three parameters) adds minor overhead but is instructional.
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 description lacks crucial context: prerequisites (e.g., Redis 8, existing data), behavior on re-run, permissions, or relationship with data population tools. An output schema exists, but completeness for a setup tool is insufficient given the complexity.
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 Args section in the description adds meaning beyond the input schema's titles and defaults, explaining each parameter's role and providing usage recommendations (e.g., using defaults unless required). Examples are given for distance_metric. Schema coverage is 0%, so description compensates well.
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 explicitly states 'Create a Redis 8 vector similarity index using HNSW on a Redis hash,' providing a specific verb and resource. It distinguishes from sibling tools like vector_search_hash and set_vector_in_hash by clearly indicating index creation.
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 explicit guidance on when to use this tool vs alternatives (e.g., before searches, when index doesn't exist). The description advises using default parameter values but does not explain prerequisites or exclusions.
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?
The description mentions 'or an error message' but does not clarify behavior for missing keys or nonexistent hashes. With no annotations, the description provides minimal but adequate transparency for a simple get 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 short and includes an Args/Returns section, but the Arg descriptions are essentially redundant with the schema. Still, it avoids unnecessary verbosity.
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 covers the core operation and mentions error handling, but given the complexity of Redis hash operations and the presence of many sibling tools, it could better explain edge cases or return formats.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only restates parameter names ('The Redis hash key', 'The field name inside the hash') without adding meaningful context beyond what the schema titles already provide.
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 ('Get') and clearly identifies the resource ('value of a field in a Redis hash'), which distinguishes it from siblings like hgetall or hset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as hset, hgetall, or hexists. The description lacks context for the agent to choose appropriately.
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?
The description implies a non-destructive read operation, but lacks explicit statements about side effects, error handling (e.g., if key does not exist), or permissions. Without annotations, some behavioral responsibility remains undeclared.
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?
A single, clear sentence. It is concise and front-loaded, but could be expanded slightly to include parameter context without losing brevity.
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 an output schema, the description is adequate but incomplete; it does not mention return value type (integer) or behavior when key is missing, which are important for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter 'name' has no description in the schema (0% coverage), and the tool description does not clarify that it represents the Redis key of the list. The parameter's purpose is inferable but not explicitly documented.
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 the length of a Redis list.' clearly states the action (get length) and resource (Redis list), effectively distinguishing it from sibling commands like lpush, lpop, lrange, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., llen vs. lrange for checking list size). The description provides no context for optimal usage or prerequisites.
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 mentions the subscription handle and return format but omits context on whether the command blocks, how messages are consumed, resource cleanup, or connection state changes, which are critical for a Redis subscription 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 concise and well-structured with a one-line summary, Args, and Returns sections. Every sentence adds meaningful information without redundancy.
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?
For a single-parameter tool with an output schema, the description covers the essential purpose, parameter semantics, and return format. However, it lacks guidance on usage context relative to sibling tools and does not elaborate on the lifecycle of the subscription handle, which is relevant in the Redis pub/sub context.
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 description provides a plain-language definition for the 'channel' parameter ('The Redis channel to subscribe to'), compensating for the complete lack of schema descriptions (0% coverage). This adds meaning beyond the schema's type-only definition.
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 ('Subscribe to a Redis channel') and the output ('reusable subscription handle'), distinguishing it from broader pub/sub operations. However, it does not explicitly contrast with the sibling 'psubscribe' tool, which is likely for pattern subscriptions.
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 over alternatives, such as 'psubscribe' or 'publish', nor are any exclusions or prerequisites mentioned. The description only states what the tool does.
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 cover behavioral aspects. It mentions that the tool returns 'information or an error message', but does not disclose side effects (e.g., no mutation), auth requirements, or rate limits. Given the lack of annotations, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the main purpose. The docstring style (Args, Returns) is clear but could be more concise by removing redundant formatting when the schema already exists.
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 retrieval tool with one parameter and an output schema, the description covers the basic action and parameter. However, it lacks behavioral details and does not explain the return value format beyond 'str', which is minimal.
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 parameter 'index_name' has schema coverage 0%, but the description gives a clear explanation: 'The name of the index to retrieve information about.' This adds context beyond the schema's title and type, covering its purpose meaningfully.
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 action ('Retrieve schema and information') and the resource ('specific Redis index'), and it references the underlying command 'FT.INFO'. This distinguishes it from sibling tools like 'get_indexes' which returns list of indexes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_indexes' or 'create_vector_index_hash'. It does not mention prerequisites (e.g., index must exist) or context for usage.
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?
No annotations; description mentions returns a dictionary or error but fails to specify behavior for missing keys or read-only nature (assumed).
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?
Concise with clear Args/Returns structure, though Args section redundantly repeats schema info.
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?
No output schema or annotations; description lacks edge cases (e.g., empty/non-existent key, size implications) and doesn't fully compensate for missing structured data.
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?
Only parameter 'name' is described as 'Redis hash key', adding clarity over schema with 0% description coverage, but no further details on format or constraints.
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?
Clearly states it gets all fields and values from a Redis hash, distinguishing it from hget and hset.
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 vs alternatives like hget for single fields or scan for large hashes.
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 given, so the description must disclose all behavioral traits. It only states that deletion occurs and returns a success/error message, but does not clarify behavior for root path deletion (e.g., whether it deletes the entire key) or error handling for missing paths.
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 concise, using a single-purpose statement followed by clear argument definitions. It could be slightly improved by integrating the returns into the main sentence, but overall it is well-structured and quick 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?
The description covers the basic purpose, parameters, and return type. However, it lacks details on edge cases (e.g., deleting at root, non-existent path) and does not leverage the existing output schema to provide more comprehensive information. It is minimally adequate for a simple tool.
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 coverage, the description adds meaningful explanations for both parameters: 'name' is the Redis key, and 'path' is the JSON path with a default of '$'. This provides context beyond the schema's type definitions.
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 'Delete', the resource 'JSON value', and the context 'from Redis at a given path'. This differentiates it from sibling tools like json_get (read) and json_set (write).
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 using 'delete' for the whole key or 'hdel' for hash fields. The description does not mention when not to use it or any dependencies.
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. It states the tool subscribes and returns a dict with subscription ID or error, but does not disclose whether it is blocking, how the subscription lifecycle works, or how to receive messages. This 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear one-sentence purpose followed by standard Args and Returns sections. Every sentence adds value with no redundancy.
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 subscription tool with an output schema, the description covers the basics and return value. However, it lacks context on how the subscription integrates with sibling tools (e.g., 'read_messages', 'unsubscribe') and omits behavioral details like blocking semantics, making it only partially complete.
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%, but the description includes an Args section explaining that 'pattern' is a Redis channel pattern to subscribe to. This adds semantic meaning beyond the schema's 'Pattern' label, though it provides no examples of pattern syntax.
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 'Subscribe to Redis channels using a pattern' with a specific verb and resource. It distinguishes from sibling 'subscribe' by emphasizing pattern-based subscription, but does not explicitly name the alternative for exact-channel subscription.
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 pattern-based subscriptions but provides no explicit when-to-use or when-not-to-use guidance. It does not mention alternatives like 'subscribe' for exact channels or how subscription relates to 'read_messages' or 'unsubscribe'.
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 full behavioral disclosure. It does not mention effects like channel creation, message size limits, or synchronous behavior. Only return type is vaguely stated.
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 very concise, using a clear docstring format with Args and Returns. Every sentence is necessary and no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description is incomplete. It lacks details on connection context, error handling, and whether channels are auto-created. The output schema may cover return values, but the description itself is sparse.
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%, but the description adds meaningful explanations: 'The Redis channel to publish to' and 'The message to send.' This supplements the schema's bare string types.
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 publishes a message to a Redis channel, specifying the action and resource. It distinguishes from sibling tools like 'subscribe' by focusing on publishing.
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 (e.g., 'set' or 'xadd'). No prerequisites or context are given.
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 disclose behavioral traits, but it only states the return value (True/False). It does not mention that storing a vector may overwrite an existing field (implied by the default field name), any permissions required, or side effects like data persistence or interaction with indexing tools.
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 concise with a clear one-line summary followed by structured Args and Returns sections. Each sentence serves a purpose, though the vector_field guidance could be slightly more succinct. Overall, it is well-organized 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?
The description covers the core parameters and return value but omits important context: storage format (e.g., JSON serialization), overwrite behavior, error conditions (e.g., non-existent hash), and interaction with vector search indexing. While adequate for basic use, it leaves gaps for an agent.
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. The Args section explains each parameter's purpose (e.g., 'name: The Redis hash key') and provides guidance (e.g., using default vector_field). This adds significant meaning beyond the schema's titles and types, though it lacks constraints like vector length or numeric precision.
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 explicitly states 'Store a vector as a field in a Redis hash,' which clearly identifies the action (store) and resource (Redis hash). This distinguishes it from sibling tools like 'hset' (generic hash set) and 'get_vector_from_hash' (retrieval), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'hset' or 'set.' It does not mention prerequisites, use cases, or scenarios where another tool would be more appropriate, leaving the agent without decision support.
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?
No annotations exist, so the description must carry the transparency burden. It mentions the return type (str or error message) and implies a read-only operation, but lacks details on behavior for missing keys, pagination, or the fact that xrange returns entries in a specific ID range.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with only three sentences plus the Args/Returns list. It is front-loaded with the main purpose, and every sentence adds value without redundancy.
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?
Despite the presence of an output schema, the description does not detail what the returned string looks like (e.g., format of entries). It also omits context like the requirement for a stream key to exist, or that xrange works with specific ID ranges. For a tool with two parameters and no nested objects, it is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description partially compensates by listing the two parameters and their types, but provides no additional semantics beyond the schema's type information. It does not explain the format of 'key' (e.g., stream key naming) or that 'count' limits the number of entries.
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 'Read entries from a Redis stream,' which is a specific verb-resource pair. It distinguishes from sibling tools like xadd, xreadgroup, and xdel, all of which have different operations on streams.
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 like xreadgroup or lrange. The description does not mention the typical use case of retrieving a range of entries by ID or the difference from consumer group reads.
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 must fully disclose behavior. It states the tool removes a member and returns a confirmation or error, but lacks details on side effects (e.g., whether the sorted set must exist, idempotency, or behavior when the member is absent). This is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a single sentence to state the purpose followed by structured parameter documentation. There is no fluff, and every sentence serves a clear purpose.
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 simple nature of the tool (2 parameters, no nested objects), the description covers the basics. However, it omits edge cases like missing keys or duplicate members. The return value is explained, but output schema exists, so less burden. Overall, it meets minimal requirements but could be more thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds minimal value beyond parameter names ('The sorted set key' and 'The member to remove'). It does not provide format, constraints, or example values, which would be helpful for correct invocation.
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 explicitly states 'Remove a member from a Redis sorted set,' which is a specific verb-resource combination. This clearly differentiates it from sibling tools like srem (set removal), hdel (hash deletion), and lrem (list removal), all of which operate on different data structures.
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 srem, hdel, or delete. The description only explains what the tool does, without contextual hints about scenarios where zrem is preferred.
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 disclose behavioral traits. It mentions optional expiration and return type (success/error message), but omits details like key creation if missing, overwrite behavior, idempotency, error conditions (e.g., non-hash key), or size limits. The disclosure 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise: a single-purpose sentence followed by a structured list of arguments. Every sentence adds value, and the format is front-loaded with the primary action. No unnecessary words or repetition.
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 and the presence of an output schema (true), the description covers the core action and parameters. However, it lacks usage context (when to choose this over siblings) and deeper behavioral details (error handling, atomicity). For a basic set operation, it is minimally adequate but not comprehensive.
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 explain parameters. It clearly defines 'name' as the Redis hash key, 'key' as the field name, 'value' as the value, and 'expire_seconds' as optional TTL. This adds meaning beyond the schema's type-only definitions, though examples or constraints are absent.
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 action: 'Set a field in a hash stored at key with an optional expiration time.' It specifies the resource (hash field) and includes a distinguishing feature (optional expiration). Among siblings like hget, hset, and hdel, this uniquely identifies setting a hash field.
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 lacks any guidance on when to use this tool versus alternatives such as set, json_set, or other hash operations. It does not mention prerequisites, side effects, or scenarios to avoid, leaving the agent without decision support.
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?
Discloses the core write operation and optional expiration, but does not mention return value (list length), error handling for non-list keys, or TTL unit. Without annotations, description carries full burden and is moderately transparent.
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?
Single sentence, 14 words, no redundancy. Front-loaded with core action and optional feature. Efficient.
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?
Tool has 3 parameters, no annotations, and output schema exists but description doesn't mention return value (list length). Lacks details like TTL units or effect on existing TTL. Adequate but incomplete for a simple tool.
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 0%, so description should add meaning. It explains 'value' as the data to push and 'expire' as optional TTL, but 'name' (the list key) is only implied. Partially compensates but not fully explicit for all 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?
Clearly states it pushes a value onto the left of a Redis list and optionally sets expiration, distinguishing it from rpush (right push) and other list operations. The verb 'push' and resource 'Redis list' are specific.
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 explicit guidance on when to use this tool vs alternatives like rpush, lset, or lpush with expire. Only implicit differentiation from sibling names. No when-not or alternative comparisons.
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?
The description states the return type (JSON string of indexes or error), but with no annotations, it misses details like read-only nature or side effects. It adds some value beyond the schema by describing the output.
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?
Two sentences with no wasted words: the purpose is front-loaded ('List of indexes in the Redis database'), and the return type is clearly stated.
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?
For a parameterless tool with an output schema, the description provides adequate context: what it does, what it returns. Could mention that it lists all indexes, but overall complete.
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?
With 0 parameters and 100% schema description coverage, baseline is 3. The description does not add parameter info as none exist, but it explains the return value which is part of the output 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 uses a specific verb 'List' and resource 'indexes in the Redis database', clearly distinguishing from siblings like get_index_info (specific index) and get_indexed_keys_number (count).
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 explicit guidance on when to use this tool vs alternatives. Siblings like get_index_info and get_indexed_keys_number exist, but the description does not mention them or specify scenarios.
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 provided, and the description does not disclose side effects, permissions, or rate limits. It implies a read operation but does not explicitly state safety or behavior beyond returning data.
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?
Extremely concise: one line for purpose, then args and returns. No wasted words, front-loaded with the key action.
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?
Adequate for a simple, one-parameter tool with no output schema. Covers inputs and returns, though listing all possible section values would improve completeness.
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 description explains the 'section' parameter with examples (default, memory, cpu), adding meaning beyond the schema's field name and type. Schema description coverage is 0%, so the description compensates adequately.
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?
Clearly states it gets Redis server information and statistics. The verb 'Get' and resource 'Redis server information' are specific, and it distinguishes from sibling tools like get (key-value) or dbsize (database size).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like type, get, or dbsize. No mention of 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Lacks disclosure of critical behavior: what happens if new_key already exists (overwrites in Redis). No mention of destructiveness or permissions. With no annotations, description should cover these.
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?
Three concise sentences for purpose, then structured Args and Returns. No wasted words, front-loaded with main action.
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?
Adequately covers purpose and return for a simple tool, but omits behavioral details (overwrite) that would make it fully self-contained. Output schema provided compensates partially.
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?
Adds meaning beyond the schema: explains old_key is current name, new_key is new name, and provides return structure. Schema had 0% description coverage, so this is valuable, though missing constraints like key existence.
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 renames a Redis key from old_key to new_key, with specific args and return format. It is not a tautology and distinguishes from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., copy, delete). No mention of prerequisites (key must exist) or when not to use (e.g., if new_key exists).
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 full burden for behavioral disclosure. It mentions it returns a list of matched documents or error, but lacks details on read-only nature, performance impacts, error conditions, or whether it modifies data. Basic functionality is covered but insufficient for a non-annotated tool.
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 structured with a summary line followed by docstring-style args and returns, which is clear but slightly verbose. The key action is front-loaded, but the docstring format adds extra lines that could be condensed for a more concise tooltip.
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 that there is an output schema (unseen but present), the description only needs to summarize return values, which it does. All 5 parameters are explained, and the tool's purpose is complete for a search operation. Minor omission: no mention of how vector_field relates to hash structure.
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?
Despite 0% schema description coverage, the description adds meaning by explaining each parameter's purpose and type (e.g., 'List of floats to use as the query vector', 'default index name'). It also clarifies optionality for return_fields. However, details like valid ranges for k or constraints on query_vector are missing.
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 it performs KNN vector similarity search using Redis 8+ on hash data structures, with a specific verb and resource. It distinguishes itself from siblings like hybrid_search which combines vector and text search, and search_redis_documents which is for full-text 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 for vector similarity search on Redis 8+ but does not explicitly state when to use this tool vs alternatives like hybrid_search or search_redis_documents. No when-not guidelines or exclusion criteria are provided, leaving the agent to infer context from sibling names.
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?
The description discloses the action (deletion) and return type (confirmation or error message). However, it lacks details on behavior when key or entry_id is missing, or any side effects. With no annotations, this is adequate but minimal.
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 very concise, with a clear first sentence defining the purpose, followed by a compact Args and Returns section. Every sentence is necessary and adds value.
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 simplicity of the tool (two required parameters, no output schema needed beyond return string), the description is complete enough. It explains the parameters and return value. Slight deduction for lack of edge-case 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 description includes brief parameter descriptions ('The stream key' and 'The ID of the entry to delete'), which adds meaning beyond the schema (which only has titles and types). Schema coverage is 0%, so the description partially compensates, but the descriptions are minimal.
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 deletes an entry from a Redis stream, using a specific verb and resource. It distinguishes itself from sibling delete tools like hdel, json_del, lrem, etc., which operate on different data structures.
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 explicit guidance on when to use this tool over alternatives. The description does not mention prerequisites, context, or contrast with other delete operations.
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 provided, so description carries full burden. It mentions creation but lacks disclosure of side effects, permissions, or constraints beyond parameter defaults (e.g., mkstream=true). Minimal behavioral insight.
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?
Core description is one clear sentence. The docstring-style parameter list is structured but slightly verbose for a tool description. Still well-organized and front-loaded.
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?
Covers parameters and return type. Missing details like prerequisites (stream existence handled by mkstream), error cases, or idempotency. Adequate for a simple create tool but with gaps.
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 description includes an 'Args' section that explains each parameter's role (key, group_name, start_id, mkstream), adding meaning beyond the schema titles. Schema coverage is 0% but description compensates well.
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 'Create a consumer group for a Redis stream' with a specific verb and resource. It distinguishes from sibling tool xgroup_destroy which destroys a group. Parameter list reinforces the purpose.
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?
No explicit guidance on when to use this tool versus alternatives like xreadgroup or xadd. The description implies usage for creating consumer groups but does not provide 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?
No annotations provided, so description carries full burden. Only states 'get a list' without detailing behavior such as whether it returns all clients, filtering capabilities, or authentication requirements.
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?
Single sentence, no extraneous information, efficient and 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?
No output schema, but for a simple list tool the description is minimally adequate. Lacks details on return format (e.g., list of strings vs objects) but sufficient given low complexity.
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?
No parameters exist; schema coverage is 100% (empty). Baseline for 0 parameters is 4 per rules, and description adds no param info (none 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?
Description uses specific verb 'Get' and resource 'list of connected clients', distinguishing it from sibling tools that operate on data (e.g., lrange, get) or server info (info).
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?
No explicit when-to-use or when-not-to-use guidance, but the simple nature of the tool (read-only, no parameters) makes context clear. No alternatives mentioned.
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?
Without annotations, the description carries the full burden. It implies a safe read operation but does not disclose any side effects, performance implications, or error cases. The behavior is universally understood but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no extraneous information. It is perfectly concise and front-loaded with the action and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description covers the essential purpose. It fully informs the agent of what the tool returns without needing additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100%. The description does not add parameter details, but none are needed. Baseline score 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 verb 'Get' and the resource 'number of keys stored in the Redis database', which is specific and distinct from sibling tools that deal with individual keys or other metrics.
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 like 'info' or 'scan_keys'. The tool is simple, but explicit usage context would improve selection.
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?
The description discloses the return type (a string) and the basic operation of retrieving the count of indexed keys. However, it does not mention any behavioral traits such as whether the index must exist, performance implications, or whether the count includes duplicate or pending keys. Given that no annotations are provided, the description carries the burden but remains minimally adequate.
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 compact and front-loaded with the purpose. It uses a docstring format that is clear, though the extra line breaks and indentation add minimal overhead. Each sentence serves a purpose, but it could be slightly more concise.
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?
For a simple count retrieval tool with a single parameter and an output schema, the description is complete. It covers the parameter and return type adequately. However, given the number of sibling tools, some guidance on usage context would enhance completeness.
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 description compensates for the lack of schema description coverage (0%) by explaining the index_name parameter: 'The name of the index to retrieve information about.' This adds meaning beyond the schema, though it could be more detailed about expected format or constraints.
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 'Retrieve the number of indexed keys by the index', specifying a specific verb and resource. It effectively distinguishes from sibling tools like get_index_info (which likely provides more details) and scan_all_keys (which lists keys).
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 like get_index_info or other index-related tools. The description lacks context on prerequisites or scenarios where this tool is preferred.
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?
No annotations provided, so description carries burden. It implies a read operation but doesn't explicitly state non-destructiveness or details like zero-based inclusive indices.
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 concise, front-loaded with purpose, and includes an Args list – no wasted sentences.
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?
Has output schema but still explains return type. Missing details like ordering (ascending) and index behavior, but sufficient for basic usage.
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 schema coverage 0%, description adds meaning by explaining each parameter: 'start' and 'end' as indices, 'with_scores' to include 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 states 'Retrieve a range of members from a Redis sorted set' with a specific verb and resource, distinguishing it from siblings like lrange for lists and xrange for streams.
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 explicit guidance on when to use this tool versus alternatives (e.g., zrevrange, zrangebyscore) or prerequisites.
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?
No annotations exist, so the description must convey behavioral traits. It discloses that the tool adds a value (mutation) and optionally sets expiration. However, it does not mention how duplicates are handled (e.g., idempotent for existing members) or any side effects like creating the set if absent.
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 very concise, using a clear docstring format with Args and Returns sections. Every sentence adds information without redundancy.
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?
Although not exhaustive (e.g., no error conditions), the description covers the core operation, parameters, and return type. Given the tool's simplicity and the presence of siblings for context, it is mostly complete.
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 0% description coverage, so the description compensates by explaining each parameter's meaning (name as key, value to add, expire_seconds as optional TTL). This adds essential value beyond the schema's type constraints.
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 action: 'Add a value to a Redis set with an optional expiration time.' It uses a specific verb (add) and resource (Redis set), and distinguishes from sibling set operations like srem (remove) or smembers (list).
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 when to use srem or smembers. The description lacks explicit context for tool selection.
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 mentions optional expiration and return type, but does not disclose whether the operation overwrites existing keys, creates new keys, or any side effects. Basic behavior is described, but important details are missing.
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 paragraph with clear sections: summary line, Args, Returns. It is front-loaded with the main purpose and contains no extraneous information. Every sentence is necessary and well-organized.
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 complexity (many siblings, no annotations), the description covers the basic operation but lacks details on usage differentiation and behavior like overwriting. The return type is simple and stated, but overall completeness is adequate but not thorough.
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 coverage is 0%, so the description must add value. The Args section clearly explains each parameter's type and optionality (e.g., value can be str, bytes, int, float, dict; expiration is optional). This adds meaning beyond the schema's anyOf definitions.
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 states 'Set a Redis string value with an optional expiration time,' which clearly identifies the tool's action and resource. It distinguishes itself from sibling tools like get, delete, hset, etc., by specifying the Redis string value operation.
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 does not explicitly provide when to use this tool versus alternatives. It implies usage for string values, but no exclusions or comparisons with siblings like hset or json_set are given. Usage context is 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavior. It states return type (str, bytes) and mentions error messages, but does not describe auth requirements, side effects (read-only), or failure conditions. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences that are front-loaded. Every word is essential, and the structure with Args/Returns is clear.
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?
For a simple get operation with an output schema present, the description covers input and output adequately. It lacks details on error conditions beyond 'error message' but is sufficient for a basic tool.
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 coverage is 0% (no parameter descriptions in schema), so the description compensates by stating 'key (str): The key to retrieve.' This adds meaning beyond the schema's type and required flag.
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 explicitly states 'Get a Redis string value' which clearly identifies the action and resource. This differentiates it from sibling tools like set, delete, or hget.
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 a key's value but lacks explicit guidance on when to use versus alternatives (e.g., hget for hashes, json_get for JSON). No when-not conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and discloses key behaviors: retrieval, binary blob conversion, return of a list of floats or error. It does not cover edge cases (missing key or field), but overall provides adequate transparency for a simple 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, using three sentences for purpose, parameters, and return. It avoids fluff and is easy to scan, though the Args section could be formatted more clearly.
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?
For a simple tool with no output schema, the description covers the essential: what it does, parameters, return type. It could mention that the hash must contain a vector stored by a companion tool, but is otherwise complete.
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 description adds meaning beyond the input schema by explaining that 'name' is the Redis hash key and 'vector_field' is the field name with a default. Since schema coverage is 0%, this is valuable context for correct usage.
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 purpose: 'Retrieve a vector from a Redis hash and convert it back from binary blob.' This includes a specific verb (Retrieve), resource (vector from Redis hash), and conversion action, distinguishing it from sibling tools like get, hget, or set_vector_in_hash.
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. It only mentions using the default field name unless specifically required, but does not explain context, prerequisites, or scenarios where other tools like hget or vector_search_hash 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries full burden. It mentions auto-conversion of value to JSON, optional expiration, and return type (success/error). However, it does not disclose behavior like overwriting existing path, atomicity, or error conditions beyond generic 'error message'. More specifics would improve transparency.
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?
Description is concise with clear 'Args' and 'Returns' sections, using few sentences without redundancy. Every sentence serves a purpose, and the structure is easy to parse.
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 presence of an output schema (implied), the description covers the tool's purpose, parameters, and return type. It could mention edge cases (e.g., non-existent key, invalid path) but overall sufficient for basic usage.
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%, but the description explains each parameter: name (Redis key), path (JSON path), value (JSON string/auto-converted), expire_seconds (optional). This adds essential meaning beyond the schema's type-only definitions.
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?
Description clearly states 'Set a JSON value in Redis at a given path with an optional expiration time.' It specifies the operation (set), resource (JSON in Redis), and key parameters (path, expiration). This distinguishes it from sibling tools like json_get, json_del, and set.
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?
No explicit guidance on when to use this tool vs alternatives (e.g., set for non-JSON, hset for hash fields). The context of Redis JSON operations is implied but not stated. A brief note on when to prefer this over other set tools would help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description explains removal behavior, count semantics (0=all, positive=from head, negative=from tail), and return value, but could mention that it modifies the list in place.
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?
Five lines with clean 'Args' and 'Returns' structure, no wasted words.
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?
Covers parameters and return value adequately; missing potential error cases (key not a list) but acceptable for a simple tool.
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 coverage is 0%, but description explains all three parameters with meaningful context (count semantics, element removal), compensating well.
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 'Remove elements from a Redis list' with a specific verb and resource, distinguishing it from siblings like lpop or rpop.
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 lrem over alternative list operations (lpop, rpop, etc.) 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral details. It only states that the subscription is closed and returns a dictionary or error message. It does not mention side effects, idempotency, whether other subscribers are affected, or what 'closed' means for subsequent messages—important gaps for a mutable pub/sub 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 compact and well-structured with a one-sentence purpose, an Args block, and a Returns block. Every sentence earns its place, is front-loaded, and contains no filler or redundancy.
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?
For a simple one-parameter tool, this description is largely sufficient: it covers the action, the parameter source, and the return type. The existing output schema can handle detailed return fields. It could be more complete by addressing edge cases or idempotency, but that is not critical given the tool's simplicity.
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 schema description coverage at 0%, the description compensates by explaining the parameter's provenance: 'The ID returned by subscribe() or psubscribe().' This adds essential meaning beyond the schema's bare 'Subscription Id' and is vital for correct invocation.
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 explicitly states the action with a clear verb and resource: 'Unsubscribe and close an existing pub/sub subscription.' This directly distinguishes it from sibling tools like subscribe, psubscribe, and publish, which are for creating or sending messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by specifying that subscription_id must be 'the ID returned by subscribe() or psubscribe().' This implies the tool should be used only after a subscription has been created, effectively giving prerequisite guidance. It does not enumerate explicit alternatives or exclusions, but for this simple tool the usage context is clear.
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?
No annotations provided, so description must carry full burden. It states basic action and return type but omits details like automatic key creation, maxlen behavior, or error scenarios.
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?
Description is extremely concise, with no wasted words, and uses a clear Args/Returns structure that is easy to parse.
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?
For a simple add operation, the description is largely complete given the output schema exists. It could further clarify stream creation behavior but covers essential usage.
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 adds meaningful explanations for all three parameters (key, fields, expiration), clarifying their roles beyond the schema types and titles.
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?
Description uses specific verb 'Add' and resource 'Redis stream', clearly distinguishing from sibling tools like xdel, xreadgroup, and xrange.
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?
Description provides basic usage context (optional expiration) but lacks explicit when-to-use guidelines or comparisons to alternative stream operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, so description carries full burden. Covers non-blocking vs blocking (with block_ms note), use of '>' for new messages, and return type. Lacks mention of consumer group semantics like message pending status, but overall good disclosure.
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?
Structured with summary, Args, and Returns sections. Not overly verbose but detailed parameter help adds length. Structure is clear, though could be slightly more concise if summary covered basic usage without exhaustive parameter list.
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?
With 6 parameters, no schema descriptions, no annotations, and an output schema, the description explains all inputs, return type, and key behaviors. Missing error details beyond generic message, but output schema likely covers structure. Sufficient for correct agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage; description fully documents all 6 parameters in Args, including defaults, types, and special behavior (e.g., block_ms 0 rejected, stream_id '>' for new). Compensates entirely for missing schema descriptions.
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?
Description clearly states 'Read entries from a Redis stream using a consumer group', specifying verb, resource, and method. Distinguishes from siblings like xrange (which reads without consumer groups) and other read commands.
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 explicit guidance on when to use this tool versus alternatives. Usage is implied by the description (consumer group scenario), but no exclusions or contrasts with siblings like xrange or xread are provided.
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?
No annotations are provided, so the description carries full burden. It states the return value (True/False) but does not disclose that the operation is read-only or error conditions (e.g., if the key does not exist). Minimal but adequate.
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 concise, front-loading the purpose, and uses a clear structure with Args and Returns sections. No extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no annotations and a simple input schema, the description fully covers the tool's behavior, including return type. No missing information for a basic 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?
Schema description coverage is 0%, but the description adds meaning by labeling 'name' as 'The Redis hash key' and 'key' as 'The field name inside the hash', providing context beyond the schema's type-only fields.
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 explicitly states 'Check if a field exists in a Redis hash', providing a clear verb and resource. It distinguishes from sibling tools like hget, hdel, and hset by focusing on existence checking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking existence within a hash, and the sibling context (e.g., hget, hdel) helps differentiate. However, it lacks explicit when-not or alternative guidance.
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?
No annotations provided, but the description mentions default path and that it returns an error message on failure. It lacks details on behavior if key missing or path invalid, and does not confirm idempotency 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using two sentences for the summary followed by a clear Args/Returns structure. Every sentence adds value, no redundant text.
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 presence of an output schema, the description adequately covers return values. However, it omits edge cases and potential errors beyond a generic error message, leaving room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds meaningful explanations for both parameters: 'name' as key, 'path' as JSON path with default. This fully compensates for the schema gap.
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 'Retrieve a JSON value from Redis at a given path,' specifying the action and resource. It distinguishes from siblings like json_del and json_set, which are for mutation.
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 reading JSON values but does not explicitly state when to use or avoid this tool, nor does it mention alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that 'none' is returned when the key does not exist, which is a key behavioral aspect. Since no annotations are provided, the description carries the full burden; it adequately covers the core behavior without contradictions. It does not mention side effects, but none are expected for a read-only type check.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using only two sentences plus a structured Args/Returns block. Every sentence provides essential information without redundancy or fluff. It is front-loaded and easy to parse.
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?
For a simple type-check tool, the description is contextually complete: it covers the purpose, the single parameter, and the return behavior. Given that the server has many sibling tools for other operations, this description allows an agent to confidently select and invoke the tool without ambiguity.
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 description for the 'key' parameter (0% coverage), but the tool description includes an 'Args' section that specifies the key's purpose. This compensates for the schema gap, providing sufficient semantic meaning for an agent to understand and correctly provide the parameter.
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 that the tool returns the string representation of the type of a value stored at a given key. This differentiates it from sibling tools like 'get' which return the value itself, and from type-checking or existence-checking commands.
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 when to use this tool (to check the type of a stored value) through its definition, but does not explicitly mention when not to use it or provide alternatives. Sibling tools exist for related tasks (e.g., 'get' for retrieving values), so guidance on differentiation would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: automatic cursor iteration, memory consumption warning, returns all results in memory. With no annotations, this provides sufficient transparency, though it omits details like rate limiting or auth requirements.
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?
Concise, front-loaded with purpose, includes a warning section, and uses clear sentence structure. Every part adds value without redundancy.
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?
Adequately covers the tool's operation and output (list of keys or error). With an output schema existing, the description doesn't need to detail return format. Could mention error scenarios or side effects, but overall complete.
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?
Adds meaning beyond the schema by stating defaults and roles (pattern to match, batch size per iteration). However, does not elaborate on valid pattern formats or limits, leaving some ambiguity given 0% schema description coverage.
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 specifies the tool scans and returns ALL keys matching a pattern using multiple SCAN iterations. It distinguishes itself from the sibling scan_keys (manual iteration) and KEYS command by highlighting automatic cursor handling and safety for large databases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises when to use (safer than KEYS*) and when not to (very large datasets). Suggests alternative scan_keys() with manual iteration for large-scale operations, referencing a sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 discloses that the tool returns a list of documentation results or an error dict, and implies a read-only operation. No side effects or destructive behavior are indicated, which is accurate for a search 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 front-loaded with the main purpose and includes a structured list of use cases. It is appropriately detailed without being verbose, though the bullet list could be slightly more concise.
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?
The description covers the tool's purpose, use cases, parameter description, and return type (with output schema present). It lacks detail on limits like max results or pagination, but is largely complete for a knowledge base search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. The Args section explains the 'question' parameter as 'The question about Redis concepts, data structures, features, or use cases', adding crucial semantic context beyond the schema's type-only definition.
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 explicitly states the tool searches Redis documentation and knowledge base, and lists specific use cases (e.g., Session Management, Caching, Rate Limiting). It clearly distinguishes from sibling tools which are all data manipulation operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'must be invoked every time the user wants to learn more' and enumerates use cases, providing clear context for when to use. It does not explicitly mention when not to use, but the sibling context makes it clear this is for learning vs. data operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description must cover behavior. Explains non-blocking, production-safe, partial results, count as hint, cursor iteration. No mention of limitations like memory, but sufficient.
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?
Well-structured with sections and warning. Some verbosity in example, but earns its place. Front-loaded with key info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all aspects: purpose, parameters, output format (split into fields), and iteration workflow. No gaps given output schema and complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has no property descriptions (0% coverage). Description adds meaningful details: pattern examples, count as hint, cursor usage. Fully compensates for schema gap.
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?
Description clearly states 'Scan keys in the Redis database using the SCAN command' and distinguishes from sibling 'scan_all_keys' by noting partial results. Verb and resource specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends using scan_all_keys for full results and shows iteration pattern. Does not mention non-usage scenarios but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details the hybrid search process (pre-filter then rank) and expected output (list with similarity score or error), but does not explicitly state that it is a read-only operation, though implied. No annotations are present to contradict.
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 concise and well-structured: an introductory sentence, explanation, examples, syntax link, and an Args list. Every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity, zero schema coverage, and presence of an output schema, the description covers usage, parameters, and return format adequately for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description includes an Args section that explains each parameter, provides defaults, and gives filter expression examples, adding significant meaning beyond the 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 tool performs a hybrid search combining Redis filter expression with KNN vector similarity, and distinguishes from pure vector search by noting that using '*' as filter equals vector_search_hash.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (for pre-filtering before vector search in production RAG) and provides filter expression examples, but does not explicitly state when to use alternatives like vector_search_hash.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 clarifies that this is a read operation ('Read'), explains timeout semantics ('Use 0 for non-blocking'), and notes the return type ('dictionary containing ... or an error message'). It does not explicitly state whether reading removes messages or requires an active subscription, but the 'pending' and 'existing subscription' phrasing provides useful 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 concise and well-structured with Args and Returns sections. Every sentence adds value; there is no fluff or repetition. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple, well-defined purpose with three parameters, all of which are thoroughly explained. The presence of an output schema reduces the need to document return values, but the description still mentions them. Including the prerequisite of an existing subscription and the optional parameters makes the description complete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/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 fully compensate. It does: each parameter is explained with meaningful detail (subscription_id source, timeout behavior, max_messages purpose). This goes well beyond the bare type/default information in the input 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 states a specific action ('Read pending pub/sub messages') on a specific resource ('existing subscription'), clearly distinguishing it from sibling tools like publish, subscribe, and psubscribe. The scope is well-defined: it reads messages for an existing subscription, not creating or managing subscriptions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies usage after a prior subscription by requiring 'subscription_id: The ID returned by subscribe() or psubscribe().' It explains the non-blocking option and message count limit. However, it does not explicitly state when to prefer this over other read-like tools (e.g., xreadgroup for streams), though the sibling list makes the pub/sub context clear.
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-redis MCP server](https://glama.ai/mcp/servers/redis/mcp-redis/badges/card.svg)](https://glama.ai/mcp/servers/redis/mcp-redis)

Score Badge

Copy to your README.md:

[![mcp-redis MCP server](https://glama.ai/mcp/servers/redis/mcp-redis/badges/score.svg)](https://glama.ai/mcp/servers/redis/mcp-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/redis/mcp-redis'

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