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

Annotations are absent, so the description carries the full burden. It transparently discloses that this is a read-only check ('Ask Redis's own ACL engine... ACL DRYRUN') and clarifies that the tool itself cannot execute those commands ('the tool surface itself can't send any of these either way'). This effectively communicates the non-destructive nature, which is essential given the risk of the commands listed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences and front-loads the core purpose and method. It wastes no words, though the second sentence could be slightly tighter. The expected outcome is clearly stated, making it efficient without being overly verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (no params, no output schema), the description covers the key aspects: purpose, method, and expected result. It mentions the `would_succeed` field, providing a hint about the return structure. While it doesn't detail the full response format, it's sufficient for an agent to understand the tool's role and avoid misuse.

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

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

The tool has zero parameters, so schema coverage is complete by default. The baseline for zero parameters is 4, and the description adds no parameter-specific information (as there is none to add). It appropriately focuses on behavior rather than parameter details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action: using Redis's ACL DRYRUN to check if a curated list of dangerous commands would succeed. It explicitly names the method (ACL DRYRUN) and the resource (Redis's ACL engine). This is distinct from all sibling tools, which are data-access commands, so there's no ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains what the tool does and even includes an expected outcome ('would_succeed should always be empty'), but it doesn't explicitly state when to use this tool versus alternatives. Since siblings are all read operations, the usage context is implied but not directly articulated, leaving some room for the agent to infer the appropriate scenario.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It implicitly indicates a read-only operation (returning a count without modifying state) and clarifies the scope ('current database'). However, it does not explicitly state that it is non‑destructive or that it has no side effects, nor does it mention potential errors (e.g., connection issues). For a trivial, read-only tool, this is acceptable but not overly transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, concise sentence that fully conveys the operation. No filler, no unnecessary detail, and the core meaning is front-loaded. This is an exemplary model of minimal yet complete description for a simple tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (no params, no output schema, no annotations), the description is complete. It states exactly what the tool returns (a count) and identifies the scope (current database). An agent has everything it needs to correctly invoke and interpret the result without additional context.

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

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

The tool has zero parameters, so the description adds no parameter semantics. Per the rubric, the baseline for 0 parameters is 4. The description appropriately omits any parameter discussion, as there is nothing to explain beyond the schema (which is empty).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Total number of keys in the current database' uses a precise resource ('keys in the current database') and clearly implies the operation of counting. It distinguishes itself from siblings like redis_get (retrieve value), redis_scan_keys (list keys), and redis_ttl (time-to-live) by focusing solely on the count, making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. However, the tool's simplicity (no parameters, no side effects) makes its usage self-evident for obtaining the database key count. The lack of explicit routing to alternatives is a minor gap, but not misleading.

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

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

With no annotations, the description carries full responsibility for behavioral disclosure. It states the main operation (counting existing keys) but omits details such as return type (integer count vs boolean), behavior on empty arrays, error handling, or whether the operation is read-only. Minimal transparency 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence with no filler. The description efficiently communicates the core functionality, front-loading the verb and subject. No unnecessary detail or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and no output schema, the description covers the essential behavior. 'Count' implies a numeric return, and 'currently exist' clarifies that non-existent keys are ignored. Lacks explicit notes on permissions or edge cases, but given the low complexity, the description is largely sufficient. Not perfect because it doesn't mention potential pitfalls like empty arrays or large key lists.

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

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

Schema description coverage is 0%, so the description must compensate. The phrase 'given keys' explicitly links the 'keys' parameter to the counting action, adding semantic meaning beyond the schema's type definition. However, it does not elaborate on format, limits, or edge cases, leaving some ambiguity. Adequate but not strong.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('count') and resource ('given keys'), clearly indicating it checks existence. Does not explicitly name alternative sibling tools, but the action is distinct enough from redis_mget or redis_get that an agent can likely infer the purpose. Missing explicit contrast with siblings prevents a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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. The description gives no context about when existence counting is preferable to retrieving values (redis_mget) or other key operations. An agent receives no direction on selecting this tool.

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

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

With no annotations, the description carries the full burden. It discloses the key behavioral trait of returning null for non-existent keys, which is critical for an agent to handle results. It also implicitly indicates a read-only operation (no side effects mentioned). While it doesn't cover error conditions or permissions, for a simple GET operation this is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, compact sentence that front-loads the core action and includes the important null-return behavior. No redundancy or unnecessary details. Perfectly sized for the tool's simplicity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple get operation with only one parameter and no output schema, the description covers the essential information: what it does and what it returns when the key is missing. It lacks alternative routing guidance but that is covered under usage guidelines. The tool is simple enough that an agent can call it correctly with this description.

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

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

Schema description coverage is 0%, so the description must compensate. The description says 'by key' but adds no meaningful semantics beyond the schema's 'key' property. It does not explain key format, naming conventions, or provide any example. For a single parameter, the description adds minimal value beyond restating the parameter name.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Get a string value by key') and the resource (string value). It distinguishes itself from siblings like redis_mget (multiple keys) and redis_type (type check) by specifying single-key string retrieval. The mention of returning null for missing keys adds clarity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for single-key retrieval but does not explicitly contrast with alternatives like redis_mget or mention when not to use it. There is no explicit guidance on when to choose this over sibling tools, though the wording 'by key' implies a single key context.

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

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

Since no annotations are provided, the description carries the full burden of behavioral disclosure. It simply states 'Get one field from a hash' and does not disclose what happens if the field or key does not exist (e.g., returns nil), whether the operation is read-only, or any error conditions. The description adds no behavioral context beyond the obvious read action, leaving important aspects ambiguous.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, using a single sentence, which is positive for front-loading. However, it lacks any structure or elaboration—no prerequisites, no examples, no explicit parameter roles. It is appropriately short but sacrifices clarity and utility in the process, making it borderline under-specified rather than efficiently concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (2 params, no output schema, no annotations), the description still omits critical context such as return values (nil if field missing), behavior on missing keys, or any error semantics. An agent could call this tool without knowing what to expect, making it incomplete for a reliable invocation.

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

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

The schema has 0% description coverage, and the description provides no additional meaning for the two parameters, key and field. It does not explain that 'key' refers to the hash name and 'field' to the specific field within that hash. The description adds nothing beyond the parameter names already present in the schema, so an agent cannot infer the exact purpose of each parameter from the tool definition alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb ('Get') and specific resource ('one field from a hash'), which tells the agent exactly what it does. It doesn't explicitly differentiate from siblings like redis_hscan (which scans fields) or redis_get (which retrieves whole values), but the phrase 'one field' makes the intent unambiguous enough for a basic read operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 that it is for retrieving a single hash field specifically, nor does it note when to prefer redis_hscan (for multiple fields) or redis_get (for non-hash values). The agent is left to infer from the name and description alone, which may cause mis-selection.

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

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

With no annotations, the description carries full behavioral disclosure. It explicitly reveals the paginated nature, cursor mechanics, and the rationale (non-blocking). It does not mention the exact return structure (e.g., alternating field/value pairs) or that it is read-only, but these are partially implied by the operation name. The added pagination contract goes beyond the schema, which only has key and cursor.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no filler. The primary purpose is front-loaded, and the pagination guidance is concise and immediately actionable. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 2-parameter tool with no output schema and no annotations, the description covers the essential usage pattern (cursor loop) and the reason for pagination. However, it omits the response format (field-value pairs, the structure of each page) and does not state that it only works on hash keys. An agent might need this to correctly parse results, making the description slightly incomplete.

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

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

Schema coverage is 0%, so the description must compensate. It explains the cursor parameter well: 'Pass the returned cursor back in as `cursor` to continue; 0 means done,' adding dynamic semantics that the schema alone does not convey. The key parameter is obvious from the context of a hash operation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it returns 'One HSCAN page of a hash's fields,' specifying the operation (HSCAN), the resource (hash fields), and the pagination behavior. It distinguishes itself from siblings like redis_hget (single field) and redis_get (whole key) by its focus on paged iteration.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the pagination loop ('Pass the returned cursor back in as `cursor` to continue; 0 means done') and gives a concrete reason to choose this over HGETALL ('can block a shared Redis server'). It implies usage for iterating large hashes without blocking, though it does not explicitly name alternative tools like redis_hget for single-field access.

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

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

With no annotations, the description fully carries the behavioral burden and delivers: it discloses the 1000-element cap, defines that an omitted stop means 'as many as fit within the cap starting at start', and instructs how to continue pagination via the `truncated` flag with an advanced start. This is rich, actionable behavioral detail.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with zero fluff: the first delivers the core purpose and cap, the second explains the omitted-stop semantics and pagination mechanism. The most critical information (cap and continuation) is front-loaded, and every clause contributes essential guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the key operational details for a paginated list range read: behavior, cap, and continuation logic. The absence of an output schema means the description should clarify the return shape; it mentions `truncated` but not the structure of the returned items or error behaviors. For a simple read operation, this is fairly complete but not exhaustive.

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

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

Given the schema has 0% description coverage, the description compensates by explaining the behavior of `stop` (omitted means cap-based) and the `truncated` flag for continuation. However, it does not explicitly clarify that `start` and `stop` are inclusive zero-based indices, nor does it describe the `key` parameter beyond its obvious role. It adds partial but meaningful parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'A range of list elements' which clearly indicates the operation retrieves a range from a list, and the context of sibling Redis tools disambiguates it. However, it uses a noun phrase rather than an explicit verb phrase like 'Retrieve a range of elements from a Redis list', so the action is implied rather than stated directly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for list range retrieval via 'range of list elements' but provides no explicit guidance on when to use this tool versus siblings like redis_hget or redis_zrange. It also omits any exclusions or alternative tool recommendations, so the selection context is only inferred from the tool name and sibling set.

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

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

No annotations are provided, so the description carries full behavioral burden. It indicates a read operation ('Get') and the return structure, but does not disclose behavior on missing keys (e.g., omission or null), permission requirements, or error handling. For a read tool, this is a meaningful gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, efficient sentence that front-loads the core purpose and return format. There is zero waste, and every word contributes to understanding the operation. It is appropriately concise for a simple tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read operation with one parameter and no output schema, the description conveys the basic contract (fetch multiple values, return as mapping). However, it omits details like missing-key behavior, type restrictions (though it says 'string values'), and any permission implications. It is adequate but not fully comprehensive.

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

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

Schema coverage is 0%, and the description hardly explains the 'keys' parameter beyond what the schema already shows. It does not clarify that keys are Redis keys, what constitutes a valid key, or that the values retrieved are strings (though 'string values' hints at the value type). The description adds little to parameter interpretation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Get'), a specific resource ('multiple string values'), and the return format ('as {key: value}'). This clearly distinguishes it from siblings like redis_get (which fetches a single value) and other type-specific tools. The purpose is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no explicit guidance on when to use this tool versus alternatives. It implies a batch operation by saying 'multiple', but it does not state that redis_get should be used for single keys, nor does it mention any other exclusions or prerequisites. An agent must infer usage context.

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

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

With no annotations, the description must disclose behavior, and it does: it guarantees non-blocking (unlike KEYS) and details the cursor-based pagination contract. It does not describe the exact return format (e.g., an array of keys plus a cursor) or any error conditions, but those are partially inferable from the pagination instructions. This is sufficient coverage for a straightforward read-only operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences, front-loaded with the core purpose and then the critical safety caveat and pagination detail. Every phrase adds value, and there is no filler or redundant restating of the tool name. It is exemplary in structure and economy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no output schema and no annotations, this description is quite complete: it covers purpose, safety (non-blocking), and the cursor mechanics needed to iterate. It does not mention the return shape (list of keys + cursor) or possible edge cases like empty results, but those are minor omissions for a scanning tool. The essential information for correct invocation is present.

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

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

Given the schema has 0% description coverage, the description fully compensates by explaining both parameters: 'pattern' as a glob pattern and 'cursor' with its significance (returned cursor, 0 means done). It also implies defaults indirectly (starter cursor of 0). This leaves no ambiguity for an agent about how to supply the parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool fetches one SCAN page of keys matching a glob pattern, with a specific verb and resource. It implies the tool is for top-level keys rather than hash or set fields, but it does not explicitly differentiate from sibling commands like redis_hscan or redis_sscan. The purpose is unambiguous and the reference to KEYS helps distinguish it from an unsafe alternative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly advises using this tool instead of KEYS to avoid blocking the server, providing a clear when-not-to-use directive. It also explains how to paginate by passing the returned cursor back and that 0 indicates completion. However, it does not state when to prefer this over other SCAN variants like hscan or sscan, which is a minor gap given the sibling list.

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

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

With no annotations provided, the description carries the burden of disclosing behavior. It clearly explains pagination (one page at a time), cursor continuation, termination when cursor is 0, and sorted ordering. It implies a read-only operation (SSCAN is a scan, not a write), but doesn't mention error semantics, time complexity, or potential cost for large sets. The reference to 'the same reason HGETALL is avoided above' adds context but relies on external information.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the core purpose and pagination details. There is no wasted text; every clause contributes to understanding what the tool does and how to use it. The structure is clear and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (paginated scan) and lack of an output schema, the description covers the essential mechanics: purpose, pagination, and continuation. It mentions the reason for pagination (avoiding SMEMBERS/HGETALL) which adds rationale. It doesn't describe the exact return structure, but the cursor mention implies the response includes a cursor and members, enough for an agent to iterate. Overall, it's reasonably complete for safe invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It explicitly explains the cursor parameter ('Pass the returned cursor back in as `cursor` to continue; 0 means done'), which is the key semantic. It also implies that `key` is the set key via 'set's members'. While `key` isn't elaborated further, the inference is straightforward. The description adds meaningful value beyond parameter names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific operation: 'One SSCAN page of a set's members, sorted.' It identifies the resource (a Redis set) and the action (paginated scan), and explicitly contrasts with SMEMBERS to show what it is not. This distinguishes it from siblings like redis_hscan (for hashes) and redis_scan_keys (for key patterns).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description indicates this is the paginated alternative to a single SMEMBERS call, implicitly suggesting it for large sets or when full retrieval is unwanted. It also mentions the continuation pattern via cursor. However, it doesn't explicitly state when not to use it or compare to other scanning tools beyond SMEMBERS, leaving some room for interpretation.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does explain the return value semantics (-1 for no expiry, -2 for missing key), which is valuable. However, it does not explicitly state that the operation is read-only or non-destructive, nor does it mention any error conditions or permissions. Given the simplicity of a TTL check, this is adequate but not comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is exceptionally concise—two short sentences that immediately convey the core purpose and the critical return-value special cases. There is no filler or redundancy; every word serves a purpose. The main function is front-loaded, and the clarifying value definitions are placed right after. This is a model of efficiency.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and no output schema, the description covers the essential behaviors: what it returns and the special sentinel values. It does not discuss error handling, but that is likely covered by the general Redis connection context. The description is nearly complete for its scope, though it could explicitly note that it is a read-only operation.

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

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

Schema description coverage is 0%, so the description must compensate for the sparse schema. The description references 'a key' in the first sentence, which implicitly ties to the `key` parameter, but it adds no additional detail about the parameter's format, constraints, or behavior. The schema already specifies the parameter as a string, so the description provides only minimal semantic enhancement.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: it returns the time-to-live in seconds for a key, with explicit meanings for -1 and -2. Though it does not explicitly use a verb like 'returns', the intent is unambiguous. It is distinct from sibling tools like redis_get or redis_type because it focuses specifically on TTL semantics.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives such as redis_exists or redis_type. There is no mention of situations where TTL checks are preferred, nor any exclusions or prerequisites. The description implies its use for checking expiry but does not give explicit selection criteria.

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

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 'Report' which implies a read-only operation, but does not specify the return value for a nonexistent key (Redis returns 'none'), nor does it mention whether it errors or how it handles empty keys. For an agent, knowing that missing keys return 'none' (not an error) is important to handle gracefully. The description is minimal and does not surface these edge-case behaviors, hence a low score.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence that names the exact action and resource with a list of possible types. Every word earns its place; there is zero waste. The structure clearly leads with the verb and resource, making it immediately scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity—one parameter, no output schema, no annotations—the description is mostly adequate but fails to mention the return value for missing keys, which is a key behavior an agent would need. It also does not state that it is a read-only operation explicitly, but that is implied. For a low-complexity tool, the missing edge-case detail leaves it slightly incomplete.

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

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

The schema has no description for the 'key' parameter (coverage 0%), so the description must compensate. The description says 'a key's' which maps 'key' to the parameter, but adds no additional meaning beyond the parameter name. The name is self-explanatory, but the description does not clarify the expected format (e.g., full key path, raw key string) or any constraints. Since the parameter is obvious and there is only one, a 3 is fair.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific action ('Report') on a specific resource ('a key's Redis type'), and enumerates the possible types (string/hash/list/set/zset/...). This distinguishes it from sibling tools like redis_get (retrieve value) and redis_exists (check existence). The purpose is unambiguous and immediately differentiated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage: use this tool to determine the type of a key before performing type-specific operations. However, it does not explicitly state when to use this tool versus alternatives (e.g., when you need the actual value use redis_get, when checking existence use redis_exists). The context is clear enough for a simple tool, but no explicit exclusions or alternative routing are provided. A 3 is appropriate for implicit guidance without explicit when-not-to-use.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It discloses two significant behaviors: a 1000-member cap per call and a pagination convention consistent with redis_lrange. This helps an agent understand limits and iteration. However, it does not mention that this is a read-only operation, error conditions, or return format, which are minor but notable gaps given no annotation support.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, two short sentences, with the core purpose and key constraint (capped at 1000) front-loaded. The pagination reference is in the second sentence. No unnecessary words or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description provides the core purpose and a key limit, but lacks essential parameter semantics and return format details. Since there is no output schema and no annotations, the description alone does not fully equip an agent to use the tool correctly, especially for optional parameters like with_scores. It is adequate for a simple range operation but not complete for a tool with these gaps.

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

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

The input schema provides no descriptions for parameters, and the tool description does not compensate. 'Key', 'start', 'stop', and 'with_scores' are named, but the description does not explain their semantics (e.g., zero-indexing, defaults, meaning of null stop, or output format when with_scores is true). The vague phrase 'same pagination convention as redis_lrange' hints at start/stop behavior but does not explicitly define it. With 0% schema coverage, this is insufficient for an agent to correctly construct arguments without prior knowledge.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the resource as a sorted-set and the operation as retrieving a range of members. It distinguishes from list ranges (redis_lrange) by explicitly saying 'sorted-set', and the cap and pagination note adds specificity. However, it does not explicitly state the verb 'return' or 'fetch', so it is slightly less direct, but still clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for sorted sets (via the term 'sorted-set') but does not explicitly state when to use this tool over alternatives like redis_lrange (for lists) or redis_sscan (for scanning). The reference to 'same pagination convention as redis_lrange' hints at similarity but does not provide exclusion guidance. Usage is mainly implied by the resource type.

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