View the current Redis connection, environment, database, allowed operations, and saved connections, or switch to another database or saved connection for the active MCP process.
查看或切换上下文。不带参数：返回当前连接、环境标识、库序号、该环境放行的操作类别、已保存连接列表。传 database：切换到指定库序号（范围取自实例的 databases 配置）。传 connection：切换到已保存的连接并重新建连。切换只会影响当前 MCP 进程，不会改变连接的环境标识。
| Name | Required | Description | Default |
|---|---|---|---|
| database | No | 要切换到的库序号，从 0 开始 | |
| connection | No | 要切换到的已保存连接名 |
Changes observed during successful MCP inspections.
v2.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses that switching is scoped to the current MCP process only, does not alter the connection's environment identifier, and that switching connection triggers a reconnect. It does not state permission requirements for switching or failure behavior for an out-of-range database index.
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?
Four short clauses, front-loaded with the no-argument behavior, then one clause per parameter, then a trailing constraint on scope. No filler and no repetition of schema text.
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?
No output schema exists, and the description compensates by enumerating what the inspection mode returns, plus the side-effect scope of switching. Remaining gaps are edge cases: combined parameters, invalid index handling, and whether subsequent redis_query calls inherit the new database.
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 100%, so baseline is 3, but the description adds real semantics: the database index range is bounded by the instance's databases configuration, and passing connection causes a reconnect rather than a lazy switch. It does not address what happens if both parameters are supplied.
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 concrete verb+resource: inspect or switch the Redis context, with an explicit breakdown of what the no-argument mode returns (current connection, environment id, db index, permitted operation categories, saved connections). It is clearly distinguishable from redis_query/redis_execute by content, though it never names those siblings to reinforce the contrast.
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?
It routes between the tool's own three modes (no args / database / connection) clearly, which is useful. But it gives no guidance on when an agent should call this instead of redis_query or redis_execute, or on whether switching is a prerequisite for those tools — usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.