Skip to main content
Glama
KitchenSink4AI

io.github.nometalalchemist/kitchensink4xl

Enable Tools

enable_tools
Idempotent

Activate optional Excel tool packs mid-session to add design, I/O, or computation capabilities. Specify packs or 'everything' to expand your session's toolkit.

Instructions

Enable optional tool packs mid-session (sessions start lite). Idempotent; reports tokens added. packs = names below or ['everything']; disable_tools reverses it. Refuses under KS4XL_PACK_POLICY=locked. Task map: conditional formatting, data validation, named styles, images, charts, advanced table ops, named ranges -> design; page layout, headers/footers, protection, comments, whole-file export, external links, VBA, pivot and connection info -> io; recalculate, real pivots, PDF, render, convert, encrypt, autofit, sparklines, goal seek -> com. Packs:

  • design (~4.3k): workbook design and rich features: named cell styles, format painter, style-bloat audit, conditional formatting, data validation, images, charts (create/list/delete), advanced table lifecycle (columns, totals, resize, banding), and named ranges (define, scope, LAMBDA, cleanup)

  • io (~3.0k): page layout and print, headers/footers, advisory protection, legacy comments, multi-sheet export, and the read-side inspectors: external links, VBA, existing pivots, data connections

  • com (~3.1k): drives a private hidden Excel instance (Windows + Excel required): real pivot tables, fidelity recalculation, goal seek, PDF export, sheet render to image, format conversion, real encryption, sparklines, true autofit, opens-clean validation, and honest status; never touches your open Excel session

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

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

Annotations already cover idempotency and non-destructiveness; the description adds beyond that: it 'reports tokens added', 'Refuses under KS4XL_PACK_POLICY=locked', is reversible by disable_tools, and for the com pack guarantees 'never touches your open Excel session'. These are valuable behavioral disclosures not present in annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded with a summary, but it is quite long and contains some duplication (task map entries repeat features listed in each pack's description). It is not wastefully verbose, but not as tight as it could be.

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 tool with one simple array parameter and no output schema, the description covers the essential points: what packs exist, what each pack includes, the 'everything' option, the policy refusal, required platform for com, and the return behavior (reports tokens added). No critical information is missing.

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?

Schema coverage is 0%, so the description carries the full burden. It defines the valid pack values (design, io, com), the 'everything' alias, approximate token costs, and a task map that tells the agent which pack name to put in the array. This fully compensates for the schema's silence.

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 clear verb+resource: 'Enable optional tool packs mid-session,' explaining that sessions start lite. It distinguishes this from sibling disable_tools by naming it as the reverse operation, and the list of pack names and task map further clarify scope.

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

Usage Guidelines5/5

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

It explicitly says when to use it: when optional tool packs are needed because sessions start lite. It names disable_tools as the alternative and provides a task-to-pack mapping (e.g., 'conditional formatting ... -> design') to guide pack selection, plus a policy condition that will cause refusal.

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