Disable Tools

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

Beyond the idempotentHint annotation, the description explicitly states that already-disabled packs are reported rather than erroring. It also explains that presentation files are untouched and that the tool reports approximate token cost removed and remaining active surface, adding meaningful 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?

The description is compact and front-loaded: purpose, accepted inputs, idempotence, side-effect scope, and output are each covered in separate efficient sentences with no filler.

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 single-parameter tool with only one required argument, the description combines with the annotations and output schema to cover everything needed: what the tool does, what values the parameter accepts, non-destructive behavior, idempotence, and what it reports.

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 only a generic array of strings, but the description compensates by defining valid values: pack names from enable_tools or the special value 'everything.' It does not list example pack names, but enough meaning is added for correct invocation.

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?

Description states a specific verb and resource: 'Switch pack tools back off to shrink the tool surface.' It clearly positions this as the inverse of enable_tools, and adds that the lite core always stays on, distinguishing it from sibling tools.

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 names enable_tools as the counterpart and clarifies that it accepts the same pack names or 'everything.' It implies use for shrinking the tool surface, though it does not explicitly state when not to use it or name alternative tools beyond enable_tools.

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