Skip to main content
Glama
KitchenSink4AI

io.github.nometalalchemist/kitchensink4xl

by KitchenSink4AI
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Local

disable_tools

Disable enabled tool packs for the current session and reclaim context tokens while keeping the lite core active. It reports the packs disabled, tokens freed, and remaining surface, with re-enable instructions if a disabled tool is called.

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.8/5.0
Behavior5/5

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

Discloses idempotency, the result content (disabled packs, tokens removed, remaining surface), the non-dead-end behavior when calling a disabled tool, and the refusal under KS4XL_PACK_POLICY=locked. This goes well beyond the sparse readOnlyHint=false annotation and fully describes what will happen.

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?

Four dense sentences with no wasted words. The primary action and effect are front-loaded, and the cross-reference to enable_tools keeps the description lean while preserving necessary detail.

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?

Given the minimal input schema, no output schema, and sparse annotations, the description covers the action, parameter vocabulary, return value, failure modes, and idempotency. The full pack menu is intentionally delegated to enable_tools, which is appropriate.

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

Parameters5/5

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

With schema coverage at 0% and no enum values, the description must compensate for the 'packs' parameter. It does so by saying packs takes the same names as enable_tools or ['everything'], giving the agent concrete value guidance. This exceeds the baseline for undocumented params.

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 states a specific verb and resource: 'Disable previously enabled tool packs for this session and reclaim their context.' It clearly distinguishes this from enable_tools and other siblings by focusing on disabling and context reclamation rather than any other operation.

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 explains how to specify packs via enable_tools' naming convention and the 'everything' special value, and it notes the locked-policy refusal condition. It doesn't explicitly contrast with alternatives because it is the only disabling tool, but the usage context is clear.

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

Install Server

Other Tools