Enable Toolset

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

The description mentions a side effect (sends a tools/list_changed notification) and notes that clients ignoring it can still call hidden tools directly, which is transparent. However, the annotation readOnlyHint: true directly contradicts the tool's mutation behavior (enabling is a state-changing operation). This inconsistency significantly undermines transparency, as an agent might incorrectly assume the tool has no side effects. The contradiction is severe enough to warrant a score of 1.

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 concise, consisting of two sentences that cover the action, the mechanism, and the side effect. It is well-structured, with the core purpose first, followed by usage detail and a note about notifications. There is no unnecessary fluff, making it easy for an agent to parse quickly.

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 tool has a single parameter and no output schema, so the description doesn't need to explain return values. It provides the essential context: what the tool does, how to pass the argument, and what side effects (notification) occur. It could be slightly more explicit about the expected response (e.g., whether it returns a success indicator), but given the simplicity of the tool, the information is largely sufficient.

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 fully describes the single parameter 'names' as a comma-separated list of toolset slugs, which is clear and complete. The description repeats this information and adds a cross-reference to list_toolsets, but doesn't provide additional semantic depth beyond the schema. Since schema coverage is 100%, the baseline of 3 is appropriate; the description adds no extra value to the parameter explanation.

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 purpose: enabling one or more toolsets for the session so their tools appear in tools/list. It uses a specific verb ('Enable') and names the resource (toolsets), which is distinct from the sibling tool list_toolsets that merely lists available toolsets. The description also provides a direct reference to list_toolsets for finding slugs, removing any ambiguity about what the tool does.

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 when to use the tool: to activate toolsets so their tools become available in the session. It implicitly indicates that the tool is the action counterpart to list_toolsets, guiding the user to first list toolsets and then enable the desired ones. However, it doesn't explicitly state prerequisites (e.g., that the tool must be called before using tools from the enabled toolset) or mention that this is the only way to enable toolsets, but the context is clear enough.

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