Redis MCP

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no ambiguity, as they are organized by Redis data types (hash, list, set, string, zset) and operations (get, set, delete, etc.), plus connection and backup utilities. The naming explicitly indicates the target resource and action, making misselection unlikely.
Naming Consistency5/5
The tool names follow a highly consistent verb_noun pattern throughout, such as hash_get, list_lpush, string_set, and backup_create. All tools use snake_case with no deviations, making the naming predictable and easy to understand.
Tool Count3/5
With 34 tools, the count is borderline high for a Redis server, as it includes comprehensive coverage of data types and operations but may feel heavy compared to typical MCP servers (usually 3-15 tools). However, it is reasonable given Redis's feature-rich nature.
Completeness5/5
The tool set provides complete CRUD/lifecycle coverage for Redis operations, including connection management, data manipulation for all major types (hash, list, set, string, zset), key operations, and backup/restore. There are no obvious gaps, ensuring agents can handle full workflows without dead ends.
Average 2.6/5 across 34 of 34 tools scored. Lowest: 1.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI 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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description reveals nothing about whether this is a read or write operation, what permissions are required, whether it's destructive, how errors are handled, or what the return format looks like. For a tool with three required parameters and no output schema, this is a critical gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise (only four Chinese characters), this is a case of under-specification rather than effective brevity. The description is too short to be helpful - it doesn't earn its place by providing necessary context. A single sentence with slightly more detail would be far more valuable than this minimal phrase.
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 that this tool has 3 required parameters, no annotations, and no output schema, the description is completely inadequate. It doesn't explain what the tool returns, what system it operates on (Redis is implied by sibling tools but not stated), or any behavioral characteristics. The agent would need to guess about the tool's purpose and behavior based on minimal information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage with clear parameter documentation in Chinese ('列表键名', '起始索引', '结束索引'). The description adds no additional meaning beyond what the schema already provides. According to the scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no parameter information in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取列表范围' (Get list range) is a tautology that essentially restates the tool name 'list_range' in Chinese. It doesn't specify what type of list, what system it operates on, or what 'range' means in this context. While it implies retrieving a subset of a list, it lacks the specificity needed to distinguish this tool from sibling tools like 'list_lpop', 'list_lpush', or 'zset_range'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. It doesn't mention prerequisites, appropriate contexts, or comparisons to sibling tools like 'list_lpop' (which removes from the left) or 'zset_range' (which operates on sorted sets). Without any usage context, an agent would struggle to select this tool appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. '删除键' only states the action without any information about permissions required, whether deletion is permanent, what happens to associated data, error conditions, or response format. For a destructive operation with zero annotation coverage, this is critically insufficient.
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 at just two characters ('删除键'), with zero wasted words. It's front-loaded with the core action. While this conciseness comes at the expense of completeness, as a standalone attribute the description is maximally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive deletion tool with no annotations and no output schema, the description is completely inadequate. It doesn't explain what 'key' refers to in this context (Redis key? Database key?), doesn't mention the permanence of deletion, doesn't describe error handling, and provides no information about return values or side effects. Given the complexity and risk of a deletion operation, this description leaves critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'keys' well-documented in the schema as accepting either a string key name or array of key names. The description adds no additional parameter information beyond what's already in the schema. With complete schema coverage, the baseline score of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '删除键' (delete key) is a tautology that essentially restates the tool name 'key_delete' in Chinese. While it does specify the verb 'delete' and resource 'key', it doesn't distinguish this tool from sibling tools like 'key_delete_pattern' or 'hash_del' which also delete keys or hash fields. The purpose is clear at a basic level but lacks differentiation from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. There are multiple sibling tools that perform deletion operations (key_delete_pattern, hash_del, set_remove, zset_remove, db_flush), but the description doesn't indicate this tool's specific scope or when it's appropriate versus those alternatives. No context, prerequisites, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description '获取键信息' only states the action without revealing any behavioral traits such as whether it's read-only, what permissions are required, what happens if the key doesn't exist, response format, or error conditions. For a tool with no annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just three Chinese characters ('获取键信息'), which is front-loaded and wastes no words. However, it's overly terse to the point of under-specification, lacking necessary details. While efficient, it sacrifices clarity for brevity, so it doesn't earn the highest score.
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 complexity of Redis key operations and the lack of annotations and output schema, the description is incomplete. It doesn't explain what information is returned (e.g., value, metadata, type), how it differs from other key-related tools, or any behavioral aspects. For a tool in a rich sibling set with no structured support, the description fails to provide sufficient 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?
The input schema has 100% description coverage, with the parameter 'key' documented as '键名' (key name) in the schema. The description doesn't add any meaning beyond this, such as examples, constraints, or usage notes. With high schema coverage, the baseline score is 3, as the schema adequately documents the parameter without extra value from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取键信息' (Get key information) is a tautology that essentially restates the tool name 'key_info' in Chinese. While it indicates the tool retrieves information about a key, it doesn't specify what type of information (metadata, value, type, etc.) or distinguish it from sibling tools like key_type, key_ttl, or key_search that also provide information about keys. The purpose is vague and lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. With sibling tools like key_type (returns key type), key_ttl (returns time-to-live), key_search (finds keys by pattern), and string_get (gets string value), there's no indication of what makes this tool unique or appropriate for specific scenarios. No context, exclusions, or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 but fails completely. It doesn't indicate that this is a destructive operation (removes elements from the list), what happens when the list is empty, whether it's atomic, or what the return value might be. For a mutation tool with zero annotation coverage, this is critically inadequate.
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 at just four Chinese characters. While this represents severe under-specification, it's not verbose or poorly structured—it's front-loaded with the core concept (left pop list) without unnecessary words. Every character earns its place, though that place is minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a destructive list operation with no annotations, no output schema, and a sparse description, the description is completely inadequate. It doesn't explain what the tool returns, how errors are handled, or the behavioral implications of popping elements. For a tool that modifies data, this level of documentation is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('key' and 'count') documented in the schema. The description adds no additional semantic information about parameters beyond what's already in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '左侧弹出列表' (left pop list) is a tautology that restates the tool name 'list_lpop' in Chinese. It doesn't specify what resource it operates on (Redis lists) or what 'pop' means in this context (removing and returning elements). While it hints at a list operation, it lacks the specificity needed for clear understanding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. It doesn't mention sibling tools like 'list_rpop' (right pop), 'list_range' (view without removal), or 'list_lpush' (left push), nor does it explain the typical use cases for left-pop operations in Redis (e.g., queue processing).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure but offers none. It doesn't indicate whether this is a read-only operation (likely, but not stated), what happens if the key doesn't exist (returns null/error?), whether there are authentication requirements, rate limits, or performance characteristics. The description provides zero behavioral context beyond the basic action implied by 'get'.
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 at just four Chinese characters ('获取字符串值'). While this represents severe under-specification for other dimensions, from a pure conciseness perspective it's maximally efficient with zero wasted words. Every character directly contributes to stating the core action, though it fails to provide necessary context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a Redis string retrieval operation (which requires understanding of Redis data types, error handling, and system context), the description is completely inadequate. With no annotations, no output schema, and a minimal description that doesn't even mention Redis or differentiate from sibling tools, this leaves the agent with insufficient information to use the tool correctly. The description fails to provide the minimal context needed for a database operation 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?
The input schema has 100% description coverage with the parameter 'key' clearly documented as '键名' (key name). The description adds no additional parameter information beyond what the schema already provides. According to scoring rules, when schema_description_coverage is high (>80%), the baseline score is 3 even with no parameter information in the description, which applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取字符串值' (Get string value) is a tautology that essentially restates the tool name 'string_get' in Chinese. It doesn't specify what resource this operates on (Redis string keys), what system it interacts with, or how it differs from sibling tools like 'hash_get' or 'string_mget'. While the verb '获取' (get) is clear, the purpose remains vague without context about the underlying data store.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance about when to use this tool versus alternatives. It doesn't mention that this is for retrieving string values from Redis (as inferred from sibling tools), nor does it differentiate it from similar tools like 'hash_get' (for hash fields), 'string_mget' (for multiple strings), or 'key_type' (for checking data type). There's no indication of prerequisites, error conditions, or appropriate contexts for 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. '弹出' (pop) implies a destructive operation that removes elements, but the description doesn't specify whether elements are returned, what happens when the list is empty, whether this is atomic, or any performance characteristics. It provides minimal behavioral context beyond the basic operation name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (4 Chinese characters) but under-specified rather than efficiently informative. While it doesn't waste words, it fails to provide the minimal necessary context for understanding the tool's purpose and behavior. The single phrase doesn't constitute a properly structured description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive list operation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (the popped elements), error conditions (e.g., non-existent key, wrong data type), or how it differs from similar tools. The context signals show this is part of a Redis toolset, but the description doesn't leverage that 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?
The input schema has 100% description coverage with clear Chinese descriptions for both parameters ('列表键名' for key, '弹出数量（可选）' for count). The tool description adds no additional parameter information beyond what's already in the schema. With complete schema coverage, the baseline score of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '右侧弹出列表' (right-side pop list) is a tautology that restates the tool name 'list_rpop' in Chinese. It doesn't specify what resource is being operated on (Redis list), what 'pop' means in this context (removing and returning elements), or how this differs from sibling tools like 'list_lpop' (left-side pop). The purpose is vague without additional context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. It doesn't mention when to choose 'list_rpop' over 'list_lpop' (for right-side vs left-side operations), 'list_range' (for reading without removal), or other list manipulation tools. There's no indication of prerequisites, error conditions, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. '递减数值' implies a mutation operation that decreases a numeric value, but it doesn't specify that this operates on Redis string keys, requires Redis connection (implied by sibling tools), affects atomic decrement behavior, or what happens on errors (e.g., if the key doesn't exist or isn't numeric). For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two characters ('递减数值'), which is efficient and front-loaded. However, it's arguably under-specified rather than optimally concise, as it lacks necessary context for a mutation tool. Still, it avoids redundancy and wastes no words, earning a high score 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?
Given the tool's complexity (a mutation operation on Redis strings), lack of annotations, and no output schema, the description is incomplete. It doesn't explain the return value (e.g., the new decremented value), error conditions, or dependencies like Redis connectivity. While the schema covers parameters well, the overall context for safe and correct usage is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for both parameters: 'key' as the key name and 'decrement' as the decrement value (optional, default 1). The description adds no additional meaning beyond the schema, such as examples or constraints (e.g., decrement must be numeric). Since the schema does the heavy lifting, the baseline score of 3 is appropriate, but no extra credit is given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '递减数值' (decrement value) is a tautology that essentially restates the tool name 'string_decr' (string decrement). While it indicates the general action of decreasing a value, it doesn't specify what resource is being decremented (a string value in Redis), nor does it distinguish this tool from its sibling 'string_incr' (string increment) beyond the opposite direction. The purpose is vague rather than specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. It doesn't mention prerequisites (e.g., the key must exist in Redis), when not to use it (e.g., for non-numeric strings), or direct alternatives like 'string_incr' for incrementing. Without any context, the agent must infer usage from the tool name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. '设置字符串键值' implies a write/mutation operation, but it doesn't disclose any behavioral traits: no mention of permissions needed, whether it overwrites existing keys, what happens on success/failure, rate limits, or side effects. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single phrase ('设置字符串键值'), which is extremely concise and front-loaded. However, this brevity comes at the cost of being under-specified—it lacks necessary detail for a mutation tool. While efficient, it doesn't fully earn its place by providing adequate guidance.
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 (a mutation operation with no annotations and no output schema), the description is incomplete. It doesn't explain what the tool returns, error conditions, or how it differs from siblings. For a tool that modifies data in a system with many similar alternatives, more context is needed to ensure correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with all parameters ('key', 'value', 'expireSeconds') documented in Chinese. The description adds no additional meaning beyond what the schema provides—it doesn't explain parameter interactions, constraints, or examples. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '设置字符串键值' (sets string key-value) is a tautology that essentially restates the tool name 'string_set' in Chinese. While it indicates the tool sets something, it doesn't specify what resource it operates on (Redis string type) or distinguish it from similar sibling tools like 'hash_set' or 'string_mset'. The purpose is vague rather than specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. There are multiple sibling tools for setting values (e.g., 'hash_set', 'string_mset', 'set_add'), but the description doesn't mention any context, prerequisites, or exclusions. An agent would have no basis for choosing this tool over others.
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. '设置哈希字段' implies a write/mutation operation but doesn't disclose any behavioral traits: no information about permissions required, whether the operation is idempotent, what happens if the key doesn't exist (creates new hash?), error conditions, or performance characteristics. The description provides only the most basic functional indication without 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just four Chinese characters. While it's arguably too brief for adequate tool documentation, it contains zero wasted words and is front-loaded with the core function. Every character serves the purpose of stating the tool's basic action, making it maximally efficient within its limited scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what the tool returns, what errors might occur, or important behavioral aspects. Given the complexity of a write operation to a Redis hash and the lack of structured metadata, the description should provide more context about the operation's effects and results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all three parameters (key, field, value) having clear descriptions in Chinese. The tool description adds no additional parameter semantics beyond what's already in the schema. According to scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no parameter information in the description, which applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '设置哈希字段' (sets hash field) is a tautology that essentially restates the tool name 'hash_set' in Chinese. It doesn't specify what resource is being modified (Redis hash data structure) or provide any meaningful distinction from sibling tools like hash_mset or string_set. While it indicates a write operation, it lacks specificity about what exactly is being set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. With multiple sibling tools for data manipulation (hash_mset, string_set, set_add, etc.), there's no indication of when hash_set is appropriate versus hash_mset for multiple fields, or when to use hash operations versus string operations. No prerequisites, constraints, or comparison context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read-only operation ('获取' means get/fetch), but doesn't disclose behavioral traits such as error handling (e.g., if the key doesn't exist), performance characteristics, or any side effects. This is inadequate for a tool with no annotation coverage.
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 a single phrase, '获取键类型', which is front-loaded and wastes no words. However, this conciseness comes at the cost of clarity and completeness, but purely on brevity and structure, it earns full marks.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., string, list, hash types), error conditions, or how it fits within the Redis context implied by sibling tools. For a tool with no structured data support, this minimal description is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'key' documented as '键名' (key name). The description adds no additional meaning beyond this, such as format examples or constraints. Given the high schema coverage, a baseline score of 3 is appropriate as the schema handles the parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取键类型' (Get key type) restates the tool name 'key_type' in Chinese, making it a tautology. It doesn't specify what resource it operates on (e.g., Redis keys) or distinguish it from sibling tools like key_info or key_search, which also deal with key metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 siblings like key_info (which might return more comprehensive key details) and key_search (for finding keys), the description offers no context on selection criteria or prerequisites 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?
No annotations are provided, so the description carries full burden for behavioral disclosure. '查找匹配的键' (Find matching keys) implies a read-only search operation, but doesn't specify what 'matching' entails beyond the pattern parameter, whether results are paginated, if it returns metadata or just keys, or any performance/rate limit considerations. For a tool with no annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just four Chinese characters, making it front-loaded and waste-free. However, this conciseness comes at the cost of being under-specified for a tool that needs to distinguish itself from multiple siblings. While efficient, it may be too brief for adequate context.
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 complexity of operating in a Redis key environment with 30+ sibling tools, no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., list of keys, count, metadata), how it differs from similar tools like 'key_delete_pattern', or any behavioral constraints. The minimal description fails to provide sufficient context for effective tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with the parameter 'pattern' fully documented in the schema as supporting wildcards (* ? []). The description adds no additional parameter semantics beyond what the schema provides. With high schema coverage, the baseline score of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '查找匹配的键' (Find matching keys) is a tautology that essentially restates the tool name 'key_search' in Chinese. It specifies the verb '查找' (find/search) and resource '键' (keys), but doesn't distinguish this tool from sibling tools like 'key_delete_pattern' or 'key_info' that also operate on keys. The purpose is clear at a basic level but lacks differentiation from alternatives.
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. With sibling tools like 'key_delete_pattern' (which also uses patterns) and 'key_info' (which provides key details), there's no indication whether this tool is for discovery, validation, or other purposes. No context about prerequisites, alternatives, or exclusions is mentioned.
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 but provides minimal behavioral insight. It states the action ('connect') but doesn't disclose traits like whether this establishes a persistent session, requires authentication, has rate limits, or what happens on failure (e.g., error handling). For a connection tool with zero annotation coverage, this leaves critical behavioral aspects undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence ('连接到 Redis 服务器') that is front-loaded and wastes no words. However, it is overly concise to the point of under-specification, missing necessary context for a connection tool. It earns a 4 for brevity but loses points for lacking depth.
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 complexity of a connection tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the connection enables (e.g., subsequent operations), return values, error conditions, or persistence. For a foundational tool in a Redis server context, this leaves significant gaps in understanding its role and 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?
Schema description coverage is 100%, so the schema fully documents all 6 parameters (host, port, username, password, db, tls). The description adds no parameter-specific information beyond what's in the schema, such as default values or format examples. Baseline 3 is appropriate when the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '连接到 Redis 服务器' (Connect to Redis server) states the basic action but is vague about what this connection enables. It distinguishes from siblings like 'disconnect_redis' but doesn't clarify if this establishes a persistent session or just validates credentials. The purpose is clear at a high level but lacks specificity about the connection's scope or outcome.
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 doesn't mention prerequisites (e.g., must be called before other Redis operations), exclusions, or how it relates to sibling tools like 'disconnect_redis'. The description implies a one-time setup but offers no explicit usage 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 are provided, so the description carries the full burden of behavioral disclosure. It states the action (delete) but doesn't describe what happens on success/failure, whether it's idempotent, error conditions, or performance implications. For a destructive operation with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient phrase ('删除哈希字段') that directly states the action. It's front-loaded with no wasted words, though it could benefit from slightly more detail given the tool's complexity. The structure is minimal but effective.
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, lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like what happens if fields don't exist, return values, or error handling. For a delete operation in a Redis context, more context is needed to guide safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for both parameters (key and fields). The description doesn't add any meaning beyond what the schema provides, such as examples or constraints. However, since the schema fully documents the parameters, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '删除哈希字段' (delete hash fields) clearly states the verb (delete) and resource (hash fields), but it's somewhat vague about the exact operation. It doesn't specify that this deletes fields from a Redis hash data structure, nor does it distinguish it from sibling tools like key_delete or hash_getall. The purpose is understandable but lacks specificity.
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. It doesn't mention prerequisites (e.g., requiring a Redis connection via connect_redis), when not to use it, or how it differs from similar tools like key_delete (which deletes entire keys) or hash_* operations. This leaves the agent with little context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('获取所有哈希字段') but doesn't describe return format, error conditions, performance implications, or side effects. For a read operation with no annotation coverage, this leaves significant gaps in understanding how the tool behaves beyond its basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single phrase ('获取所有哈希字段'), which is concise and front-loaded with the core action. However, it lacks structure and could benefit from additional context to improve clarity without becoming verbose. It earns its place but is minimalistic.
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 complexity of a tool that retrieves all fields from a hash (likely from a data store like Redis, inferred from sibling tools), the description is incomplete. No output schema exists, so the description should explain return values, but it doesn't. With no annotations and minimal description, it fails to provide enough context for effective use, especially compared to richer sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the parameter 'key' clearly documented as '哈希键名' (hash key name). The description doesn't add any meaning beyond what the schema provides, such as examples or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the schema adequately handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取所有哈希字段' (Get all hash fields) states the basic action but is vague about scope and format. It mentions the resource (hash fields) but doesn't specify whether this returns keys, values, or both, or how the data is structured. It distinguishes from siblings like hash_get (single field) but not clearly from hash_mset or other hash 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 siblings like hash_get (for single fields), hash_mset (for setting multiple), and hash_del (for deletion), the description lacks context on appropriate use cases, prerequisites, or exclusions. It implies usage for retrieving all fields but doesn't specify conditions or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('设置键过期时间') but doesn't describe key behaviors such as whether it overwrites existing expiration, returns a confirmation, requires specific permissions, or has side effects (e.g., error if key doesn't exist). This leaves significant gaps for an agent to understand how the tool operates beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence ('设置键过期时间') that directly states the purpose without unnecessary words. It's appropriately sized for a simple tool, though it could be more informative. There's no waste, but it's borderline under-specified rather than concise.
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 (a mutation operation with no annotations and no output schema), the description is incomplete. It doesn't explain what happens on success or failure, return values, or error conditions. For a tool that modifies data in a Redis-like context, more detail is needed to guide an agent effectively, especially without annotations to cover behavioral aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear parameter descriptions ('键名' for key, '过期时间（秒）' for seconds). The description adds no additional meaning beyond what the schema provides, such as explaining parameter interactions or constraints. Since schema coverage is high, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '设置键过期时间' (Set key expiration time) clearly states the action (set expiration) and target (key), but it's vague about the specific mechanism or context. It doesn't distinguish this tool from sibling tools like key_ttl (which retrieves expiration) or key_delete (which removes keys), leaving ambiguity about its exact role in the Redis-like toolset.
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. For example, it doesn't clarify if this is for setting a new expiration, updating an existing one, or how it differs from key_ttl (which checks expiration) or key_delete (which removes keys immediately). The description lacks context about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the action without behavioral details. It doesn't disclose that this is a mutation operation (implied by 'push'), potential side effects (e.g., list creation if key doesn't exist), error conditions, or performance characteristics. The description adds minimal context beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with a single phrase, but this brevity leads to under-specification rather than efficient communication. While front-loaded, it lacks necessary detail for a tool with mutation behavior and sibling alternatives.
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?
Inadequate for a mutation tool with no annotations and no output schema. The description doesn't explain return values (e.g., new list length), error cases, or how it differs from list_rpush. Given the complexity of list operations and rich sibling toolset, more context is needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear parameter documentation in Chinese. The description adds no additional meaning about parameters beyond what the schema provides (e.g., no examples or constraints). Baseline score of 3 is appropriate since the schema adequately defines key and values parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '左侧推入列表' (left-push to list) states the action and target resource, but is vague about what exactly is being pushed and lacks differentiation from sibling tools like list_rpush (right-push). It doesn't specify it's for Redis lists or mention the tool's role in a data structure context.
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 list_rpush or list_lpop. The description doesn't provide context about left-push semantics (e.g., adding to the head of the list) or prerequisites, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. '移除' (remove) implies a destructive mutation, but the description doesn't specify whether this operation is reversible, what happens if members don't exist (e.g., silent ignore or error), or any side effects like returning the number of removed members. It lacks details on permissions, rate limits, or error conditions, which are critical for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single phrase '移除集合成员', which is very concise and front-loaded with the core action. There's no wasted text, but it might be overly terse, risking under-specification. It earns a 4 for efficiency, though it could benefit from slightly more context without losing 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 the complexity (a destructive mutation tool with no annotations and no output schema), the description is incomplete. It doesn't explain what the tool returns (e.g., number of removed members, success status, or error messages), behavioral traits like idempotency, or how it interacts with sibling tools. For a mutation operation, this leaves significant gaps for an AI agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for both parameters: 'key' as the set key name and 'members' as the member(s) to remove. The description adds no additional meaning beyond what the schema provides (e.g., no examples, format details, or constraints). With high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '移除集合成员' (remove set members) clearly states the verb 'remove' and the resource 'set members', which is specific. However, it doesn't distinguish this tool from sibling tools like 'zset_remove' (which removes from sorted sets) or 'hash_del' (which removes from hashes), leaving ambiguity about when to use this specific set removal tool versus others.
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. It doesn't mention prerequisites (e.g., the set must exist), exclusions (e.g., not for removing from other data types like hashes or lists), or refer to sibling tools like 'set_add' for adding members or 'set_members' for listing them. Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states '获取' (get), implying a read-only operation, but doesn't clarify if it's safe, what happens if the key doesn't exist, or any rate limits. The description lacks details on return format (e.g., list of values, scores if withScores is true) or error conditions, which is insufficient for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single phrase '获取有序集合范围', which is concise and front-loaded. It wastes no words, but it may be overly brief, risking under-specification. However, given the schema provides details, this conciseness is efficient, though it could benefit from slightly more context without becoming verbose.
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, no output schema, and a tool with 4 parameters (3 required), the description is incomplete. It doesn't explain the return values, error handling, or behavioral traits like read-only nature. For a data retrieval tool in a Redis context with siblings like zset_add, more context is needed to ensure the agent can use it correctly without guesswork.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for all parameters (key, start, stop, withScores). The description adds no meaning beyond the schema, as it doesn't explain parameter interactions (e.g., start and stop are indices, withScores affects output). With high schema coverage, the baseline score is 3, as the description doesn't compensate but doesn't detract either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取有序集合范围' (Get sorted set range) states the verb '获取' (get) and resource '有序集合范围' (sorted set range), which is clear but vague. It doesn't specify what 'range' means (e.g., by index, score, or lexicographic order) or distinguish it from sibling tools like zset_add or zset_remove. The purpose is understandable but lacks specificity for precise tool selection.
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. It doesn't mention sibling tools like zset_add for adding elements or zset_remove for removing them, nor does it explain prerequisites such as requiring an existing sorted set key. Usage is implied by the name but not explicitly stated, leaving gaps for an AI agent to infer 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 are provided, so the description carries full burden. It doesn't disclose behavioral traits such as whether this is a read-only operation (implied by 'get' but not explicit), error handling (e.g., if key/field doesn't exist), performance characteristics, or authentication needs. The description is minimal and adds little beyond the basic action.
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 phrase ('获取哈希字段') that is extremely concise and front-loaded with the core action. There is zero waste or redundancy, making it efficient for quick scanning, though this conciseness comes at the cost of detail.
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 (simple read operation), lack of annotations, and no output schema, the description is incomplete. It doesn't explain return values, error cases, or dependencies (e.g., requires Redis connection as hinted by siblings). For a tool with 2 parameters and no structured safety hints, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('key' and 'field') documented in the schema. The description adds no additional meaning beyond what the schema provides (e.g., no examples, format details, or constraints). Baseline is 3 since the schema does the heavy lifting, but the description doesn't compensate or enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取哈希字段' (Get hash field) states the basic action but is vague about scope and resource. It specifies a verb ('获取' - get) and resource type ('哈希字段' - hash field), but doesn't distinguish from siblings like hash_getall (gets all fields) or clarify what type of hash structure this operates on. The purpose is understandable but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention siblings like hash_getall (for all fields) or string_get (for non-hash values), nor does it specify prerequisites like requiring a Redis connection (implied by sibling tools but not stated). Usage is implied from the name alone.
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 but provides minimal behavioral insight. It implies a write operation ('设置' means set), but doesn't disclose whether this overwrites existing fields, creates new ones, requires the hash to exist, has atomicity guarantees, or returns any confirmation. For a mutation tool with zero annotation coverage, this is inadequate.
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, efficient phrase ('批量设置哈希字段') with zero wasted words. It's appropriately sized for a simple tool and front-loads the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens on success/failure, return values, or side effects. Given the complexity of batch operations and lack of structured safety hints, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear parameter documentation in Chinese. The description adds no additional meaning beyond the schema, which already defines 'key' as hash key name and 'fieldValues' as array of field-value pairs. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '批量设置哈希字段' (batch set hash fields) states the action (set) and target (hash fields), but is vague about scope and lacks sibling differentiation. It doesn't specify whether this creates new fields, updates existing ones, or both, nor does it distinguish from hash_set (single field set) or other data structure tools like string_mset.
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 doesn't mention hash_set for single-field operations, hash_getall for reading, or other batch operations like string_mset. There's no context about prerequisites, error conditions, or performance implications.
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 burden. It states the action ('right push list') but doesn't disclose behavioral traits such as whether it modifies data in-place, requires authentication, has rate limits, or what happens on errors (e.g., if the key doesn't exist). This is inadequate for a mutation tool with zero annotation coverage.
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 with a single phrase '右侧推入列表', which is front-loaded and wastes no words. Every part earns its place by conveying the core action, though it lacks detail.
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, no output schema, and a mutation tool (implied by 'push'), the description is incomplete. It doesn't cover behavioral aspects, return values, or error handling, making it insufficient for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents parameters (key and values). The description adds no meaning beyond the schema, as it doesn't explain parameter usage or constraints. Baseline 3 is appropriate since the schema does the heavy lifting, but no extra value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '右侧推入列表' (right push list) indicates a Redis RPUSH operation but is vague. It specifies the verb 'push' and resource 'list' but lacks details on what 'right push' means operationally. It doesn't distinguish from siblings like list_lpush (left push), leaving ambiguity about directionality.
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. It doesn't mention sibling tools like list_lpush for left-side operations or list_rpop for popping, nor does it specify prerequisites like requiring a Redis connection (implied by context but not stated). Usage is implied by the name only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. '递增数值' implies a mutation operation (incrementing), but it doesn't specify whether this requires write permissions, what happens if the key doesn't exist (e.g., creates it or errors), or if it's atomic/thread-safe. It also doesn't describe the return value (e.g., new value after increment). For a mutation tool with zero annotation coverage, this is a significant gap in 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two characters ('递增数值'), which efficiently conveys the core action. It's front-loaded with no wasted words, making it easy to parse quickly. However, this conciseness comes at the cost of completeness, but for this dimension alone, it's perfectly sized.
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 complexity (a mutation tool with no annotations and no output schema), the description is incomplete. It doesn't explain what the tool increments (e.g., a string value in Redis), behavioral traits like error handling or atomicity, or the return value. With siblings like 'string_decr' and 'string_get', more context is needed to distinguish usage. The description fails to compensate for the lack of structured data, making it inadequate for effective tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for both parameters: 'key' as '键名' (key name) and 'increment' as '增量值（可选，默认为 1）' (increment value, optional, defaults to 1). The description adds no additional meaning beyond what the schema provides, such as examples or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the schema adequately documents parameters without extra help from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '递增数值' (increment numerical value) states a clear verb ('increment') and resource ('numerical value'), but it's vague about what exactly is being incremented. It doesn't specify this is for string values in a key-value store or distinguish it from sibling tools like 'string_decr' (decrement) or 'string_set' (set value). The purpose is understandable but lacks specificity and sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'string_decr' for decrementing, 'string_set' for setting values directly, or 'string_get' for retrieving values. There's no context about prerequisites (e.g., needing a connected Redis instance) or typical use cases, leaving the agent with no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. '设置' (set) implies a write/mutation operation, but the description doesn't disclose critical traits like whether this overwrites existing values, requires specific permissions, has rate limits, or what happens on failure. This is inadequate for a mutation tool with zero annotation coverage.
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 just four characters ('批量设置键值'), which efficiently conveys the core action. There's no wasted text, and it's front-loaded with the essential verb and object, making it easy to parse quickly.
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 complexity of a batch write operation, no annotations, and no output schema, the description is incomplete. It lacks information on behavioral traits, error handling, return values, and differentiation from siblings. This is insufficient for safe and effective tool invocation in a multi-tool environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'keyValues' clearly documented as an array of key-value objects. The description adds no additional meaning beyond what the schema provides, such as explaining key constraints or value formatting. With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '批量设置键值' (batch set key-values) states the tool's general purpose as a batch write operation, but it's vague about what resource it operates on. It doesn't specify that this is for Redis string operations or distinguish it from sibling tools like hash_mset or string_set, leaving ambiguity about its exact scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With sibling tools like string_set (single set), hash_mset (hash batch set), and string_mget (batch get), the description doesn't indicate whether this is for strings specifically, when batch operations are preferred, or any prerequisites for 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 are provided, so the description carries the full burden of behavioral disclosure. It states the action ('add') which implies a write/mutation operation, but doesn't cover critical traits: whether it overwrites existing members, requires authentication, has rate limits, or what happens on success/failure. For a mutation tool with zero annotation coverage, this is a significant gap in 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 a single, efficient sentence ('添加有序集合成员') that directly states the tool's purpose without waste. It's appropriately sized and front-loaded, making it easy to parse quickly.
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 complexity (a mutation tool for sorted sets with 2 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't address behavioral aspects like idempotency, error handling, or return values, leaving gaps that could hinder an AI agent's correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('key' and 'members') well-documented in the schema. The description doesn't add any meaning beyond what the schema provides—it doesn't explain parameter interactions, constraints, or examples. Baseline is 3 since the schema does the heavy lifting, but no extra value is added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '添加有序集合成员' (add sorted set members) clearly states the verb (add) and resource (sorted set members), which is specific. However, it doesn't distinguish this tool from sibling tools like 'zset_range' or 'zset_remove' that also operate on sorted sets, nor does it mention the scoring aspect that defines sorted sets. The purpose is understandable but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are no mentions of prerequisites (e.g., connection state), exclusions, or comparisons to similar tools like 'set_add' for unordered sets or 'zset_remove' for deletion. Usage is implied by the action but without explicit 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 are provided, so the description carries full burden. '创建' implies a write operation that likely modifies system state, but it doesn't disclose critical behaviors: whether it locks the database, requires admin permissions, has rate limits, or what happens on failure. For a backup tool with zero annotation coverage, this is inadequate.
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, efficient phrase in Chinese that directly states the tool's purpose. There's zero wasted text, and it's appropriately sized for a simple backup creation tool. It's front-loaded with the core action.
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, no output schema, and a backup creation tool (which implies system mutation and potential side effects), the description is incomplete. It doesn't explain what the tool returns, error conditions, or behavioral constraints. The agent lacks sufficient context to use this tool safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all 4 parameters documented in the schema. The description adds no parameter-specific information beyond the tool's general purpose. According to rules, when coverage is high (>80%), baseline is 3 even with no param info in description.
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 '创建 Redis 数据备份' clearly states the action (create) and resource (Redis data backup) in Chinese. It distinguishes from sibling tools like backup_restore by specifying creation rather than restoration. However, it doesn't specify what type of backup (full/incremental) or format, keeping it at 4 rather than 5.
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. It doesn't mention prerequisites (e.g., Redis connection), compare with other backup methods, or specify scenarios like before maintenance. With sibling tools like connect_redis available, this lack of context is a significant gap.
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 burden. '恢复 Redis 数据' implies a write/mutation operation, but it doesn't disclose critical behaviors: whether it overwrites existing data, requires specific permissions, has side effects (e.g., downtime), or error handling. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese ('从备份恢复 Redis 数据'), which directly states the purpose without waste. It's appropriately sized and front-loaded, earning full marks 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 complexity (a mutation tool restoring data), no annotations, no output schema, and incomplete behavioral disclosure, the description is inadequate. It should cover more: what happens to existing data, success/error responses, or dependencies (e.g., needing a backup file). The current description leaves too many gaps for safe use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (filename, path, flushBeforeRestore) with descriptions. The tool description adds no additional meaning beyond the schema, such as format examples or constraints. Baseline 3 is appropriate when schema does the heavy lifting.
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 '从备份恢复 Redis 数据' clearly states the action (恢复/restore) and resource (Redis 数据/Redis data). It distinguishes from siblings like backup_create (create vs restore) but doesn't specify scope like which database or cluster, keeping it at 4 rather than 5.
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. It doesn't mention prerequisites (e.g., need for existing backup files, connection state), exclusions, or comparisons with siblings like db_flush or key operations. The description alone implies usage but lacks actionable 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 are provided, so the description carries the full burden of behavioral disclosure. It states '批量删除匹配的键' (batch delete matching keys), implying a destructive mutation operation, but doesn't mention critical aspects like irreversible deletion, performance impact on large datasets, permissions required, or error handling. For a destructive tool with zero annotation coverage, this is a significant gap in 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 a single phrase '批量删除匹配的键', which is front-loaded and wastes no words. Every part of the phrase contributes essential meaning: '批量' (batch), '删除' (delete), '匹配的' (matching), and '键' (keys), making it efficient and well-structured.
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 (deletion), lack of annotations, no output schema, and multiple sibling tools, the description is incomplete. It doesn't address safety concerns, return values, or differentiation from similar tools like 'key_delete'. For a batch deletion tool in a Redis context with many alternatives, more context is needed to guide the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'pattern' parameter documented as supporting wildcards (* ? []). The description adds no additional parameter semantics beyond what the schema provides, such as examples or constraints on pattern usage. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '批量删除匹配的键' clearly states the action (delete) and resource (keys) in Chinese, meaning 'batch delete matching keys'. It specifies the batch nature and matching criteria, which distinguishes it from the sibling tool 'key_delete' (likely for single-key deletion). However, it doesn't explicitly mention Redis or the data store context, which could slightly reduce specificity.
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 'key_delete' (for single keys), 'db_flush' (for all keys), or 'key_search' (for finding keys without deletion). It lacks context about prerequisites, risks, or typical scenarios for pattern-based deletion, leaving the agent with minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the action ('获取' - get) but doesn't disclose behavioral traits: it doesn't specify what happens if the key doesn't exist (e.g., returns -2), if it has no expiration (returns -1), or if there are permission/connection issues. For a read operation with zero annotation coverage, this leaves critical gaps in understanding how the tool behaves in edge cases.
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, efficient phrase ('获取键过期时间') with zero waste. It's front-loaded and appropriately sized for a simple tool, avoiding unnecessary elaboration. Every word contributes directly to the purpose without redundancy.
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 simplicity (1 parameter, 100% schema coverage) but lack of annotations and output schema, the description is incomplete. It doesn't explain return values (e.g., TTL in seconds, -1 for no expiry, -2 for non-existent key), error conditions, or dependencies like requiring Redis connectivity. For a tool that interacts with a data store, more context is needed despite the minimal parameter set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the 'key' parameter is documented as '键名' - key name), so the baseline is 3. The description adds no additional meaning beyond the schema—it doesn't explain key naming conventions, allowed characters, or that this refers to a Redis key. It relies entirely on the schema for parameter documentation.
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 '获取键过期时间' (Get key expiration time) clearly states the verb ('获取' - get) and resource ('键过期时间' - key expiration time). It distinguishes from siblings like key_delete (deletes keys), key_expire (sets expiration), and key_info (gets general key info) by focusing specifically on expiration time retrieval. However, it doesn't explicitly mention this is for Redis keys, though context suggests it.
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. It doesn't mention when to use key_ttl versus key_info (which might include TTL) or key_expire (which sets TTL), nor does it specify prerequisites like requiring an active Redis connection. The agent must infer usage from the name and sibling tools alone.
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 burden. It states the action ('add') but lacks behavioral details: it doesn't specify if duplicates are allowed, if the set is created if missing, error conditions, or performance implications. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient phrase ('添加集合成员') that front-loads the core action. There is no wasted verbiage, making it highly concise and well-structured for quick comprehension.
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 is a mutation operation (adding to a set) with no annotations and no output schema, the description is incomplete. It lacks details on behavior (e.g., idempotency, creation on missing key), error handling, or return values, leaving the agent with insufficient context for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for 'key' (集合键名 - set key name) and 'members' (要添加的成员或成员数组 - members or array of members to add). The description doesn't add meaning beyond the schema (e.g., format examples or constraints), so it meets the baseline of 3.
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 '添加集合成员' (add set members) clearly states the verb 'add' and the resource 'set members', making the purpose immediately understandable. It distinguishes from siblings like 'set_members' (read) and 'set_remove' (delete), though it doesn't explicitly mention the 'set' data structure context beyond the tool name.
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 doesn't mention prerequisites (e.g., the set must exist), when not to use it (e.g., for removing members), or direct alternatives like 'set_remove' for deletion. The agent must infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('获取' - get) but doesn't describe what happens if the key doesn't exist, whether it's a read-only operation, potential performance impacts for large sets, or the return format. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient phrase ('获取集合所有成员') that directly states the purpose without unnecessary words. It's appropriately sized and front-loaded, with every word contributing to clarity. No waste or redundancy is present.
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 complexity (a read operation on a set data structure), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what is returned (e.g., list of members, error handling), behavioral traits, or usage context. For a tool with no structured support, more detail is needed to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the parameter 'key' documented as '集合键名' (set key name). The description doesn't add any meaning beyond this, such as examples or constraints. According to the rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.
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 '获取集合所有成员' (Get all members of a set) clearly states the verb ('获取' - get) and resource ('集合所有成员' - all members of a set). It's specific about retrieving all members rather than a subset. However, it doesn't explicitly distinguish from sibling tools like 'set_add' or 'set_remove', which is why it doesn't reach a perfect score.
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. It doesn't mention prerequisites (e.g., the set must exist), exclusions (e.g., not for other data types), or compare to siblings like 'key_search' for broader searches. Usage is implied by the purpose but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states '批量获取键值' (batch get key-values), which implies a read-only operation, but doesn't specify whether it's atomic, what happens with missing keys, error handling, or performance characteristics. For a tool with zero annotation coverage, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single phrase '批量获取键值', which is extremely concise and front-loaded with the core action. Every word earns its place by specifying batch operation and resource, with no wasted text. It's appropriately sized for a simple retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool that likely returns multiple values. It doesn't explain the return format (e.g., array, map, error handling for missing keys), which is critical for an agent to process results. For a batch operation with zero structured metadata, more context is needed.
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 implies batch retrieval but doesn't add meaning beyond the input schema, which has 100% coverage. The schema documents 'keys' as an array of strings, and the description's '批量' (batch) aligns with this but provides no additional details on constraints, formats, or examples. With high schema coverage, the baseline 3 is appropriate.
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 (获取/get) and resource (键值/key-values) in Chinese, translating to 'batch get key-values'. It's specific about the batch operation, though it doesn't explicitly differentiate from its sibling 'string_get' which likely handles single keys. The purpose is clear but lacks explicit sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention the sibling 'string_get' for single-key operations or other retrieval tools like 'hash_get', leaving the agent to infer usage from the name alone. No context or exclusions are provided.
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 but offers minimal behavioral context. It implies a destructive operation (remove) but doesn't disclose whether it's idempotent (safe for non-existent members), returns the number of removed members, or has side effects. For a mutation tool, this is inadequate 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 a single, efficient phrase in Chinese with zero wasted words. It's front-loaded with the core action and resource, making it immediately understandable for its intended audience.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens on success/failure, return values, or error handling. Given the context of sibling Redis tools, more operational context is needed for safe use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear parameter descriptions in Chinese. The description adds no additional meaning beyond the schema (e.g., no examples of member formats or key naming conventions). Baseline 3 is appropriate as the schema adequately documents parameters.
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 '移除有序集合成员' (remove sorted set members) clearly states the action (remove) and target resource (sorted set members). It distinguishes from sibling tools like zset_add (add) and zset_range (query), but doesn't specify it's for Redis zsets versus other data structures, which slightly limits differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an active Redis connection via connect_redis), error conditions (e.g., if key doesn't exist), or comparison to similar tools like set_remove (for unordered sets) or key_delete (for entire keys).
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 burden. It states the action ('flush') but doesn't disclose critical behavioral traits: whether this is destructive (likely yes), irreversible, requires specific permissions, affects all data types, or has side effects like performance impact. The description is minimal and lacks necessary operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient phrase ('清空当前数据库') that directly states the tool's purpose with zero wasted words. It's appropriately sized and front-loaded, making it easy to parse quickly.
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 high complexity (destructive database operation) and lack of annotations or output schema, the description is incomplete. It doesn't address safety, consequences, return values, or error conditions, leaving significant gaps for an AI agent to understand and use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%. With no parameters to document, the description doesn't need to add parameter semantics beyond the schema. A baseline score of 4 is appropriate as the schema fully covers the parameter aspect.
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 '清空当前数据库' (Flush the current database) clearly states the action (flush) and target resource (current database). It's specific enough to understand the core function, though it doesn't explicitly differentiate from sibling tools like key_delete_pattern or backup_create that might also affect data removal.
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 siblings like key_delete_pattern (pattern-based deletion) and backup_create (data preservation), the description lacks context on appropriate use cases, prerequisites, or warnings about 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 carries the full burden. It states the action ('断开连接') but doesn't disclose behavioral traits such as whether this closes all connections, requires specific permissions, has side effects on other operations, or what happens if no connection exists. This is a significant gap for a tool that likely involves network/state changes.
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, efficient sentence in Chinese ('断开与 Redis 服务器的连接'), which directly conveys the purpose without any waste. It's appropriately sized and front-loaded for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of disconnecting from a server (likely involving state changes), no annotations, no output schema, and 0 parameters, the description is incomplete. It lacks details on behavior, return values, or error conditions, making it inadequate for safe and effective use by an AI 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?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here, but it also doesn't compensate for any gaps since there are none. Baseline is 4 for zero parameters.
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 ('断开连接' meaning 'disconnect') and the target resource ('Redis 服务器' meaning 'Redis server'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'connect_redis' beyond the obvious opposite action, missing explicit comparison.
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 or prerequisites. While it's implied to be used after connecting to Redis (given the sibling 'connect_redis'), there's no explicit mention of context, exclusions, or dependencies.
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:

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

Score Badge

Copy to your README.md:

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

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

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