Skip to main content
Glama
KitchenSink4AI

io.github.nometalalchemist/kitchensink4xl

by KitchenSink4AI
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Disable Tools

disable_tools
Idempotent

Reclaim context by disabling previously enabled tool packs for this session. Specify packs or 'everything' to free up tokens while keeping the core active.

Instructions

Disable previously enabled tool packs for this session and reclaim their context; the lite core always stays on. Idempotent. The result reports the packs just disabled, the approximate tokens removed, and the remaining surface. packs takes the same names as enable_tools (its description carries the menu) or ['everything']. Calling a tool from a disabled pack does not dead-end: the refusal names the owning pack and the exact enable_tools call to turn it back on. Refuses when the host pins the surface with KS4XL_PACK_POLICY=locked.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
packsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.2.0
    • changedOutput schema / (root)
      Previous value: -{
-  "additionalProperties": true,
-  "type": "object"
-}New value: +null
  2. First observedv1.0.0

TDQS

A4.7/5.0
Behavior5/5

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

The description goes well beyond annotations: it explains idempotency, that the lite core always stays on, what the result reports, the refusal format for disabled tool calls, and the KS4XL_PACK_POLICY=locked refusal condition. This is rich behavioral disclosure beyond the idempotentHint and destructiveHint annotations.

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 dense but every sentence earns its place: purpose, idempotency, result contents, parameter semantics, failure behavior, and policy restriction are all relevant. It is front-loaded with the core purpose and expands into needed details in a logical order.

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

Completeness5/5

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

For a one-parameter, no-output-schema tool, the description is remarkably complete. It covers what happens, what is returned, how to reference packs, how failures behave, and when the tool refuses. No crucial behavior is left unexplained.

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?

Schema coverage is 0%, so the description must carry the parameter meaning. It does: packs accepts the same names as enable_tools or the special value ['everything'], and it points to the sibling's description for the menu. This compensates well for the bare schema.

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

Purpose5/5

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

The description opens with a specific verb and resource: 'Disable previously enabled tool packs for this session and reclaim their context.' It clearly distinguishes this from sibling tools, especially enable_tools, by defining the opposite action and scope.

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

Usage Guidelines4/5

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

The description gives strong contextual usage guidance: it targets previously enabled packs, names enable_tools as the counterpart for re-enabling, and explains the refusal behavior when a disabled tool is called. It does not explicitly state 'use this when you want to free context' but the purpose implies it clearly.

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

Deploy Server

Other Tools