Skip to main content
Glama

Delete Table

delete_table
Destructive

Removes a table and all its contents from a Word document using the table's index position. Includes auto-backup and validation, and refuses open files.

Instructions

Delete a whole table and its contents. table_index is the 0-based position among body-level tables in document order, as reported by list_elements(type='tables') or get_document_view; nested tables are removed with their host table. To clear cell values while keeping the grid, use set_cells instead. Auto-backup: prev/anchor slots in .ks4w-backups (backup=False skips rotation only); atomic validated save. Refuses documents open in Word.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
backupNo
file_pathYes
table_indexYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.2.1

TDQS

A4.9/5.0
Behavior5/5

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

Even though destructiveHint=true already signals mutation, the description adds substantial behavioral context: nested tables are removed with the host table, auto-backup behavior is described, saves are atomic and validated, and documents open in Word are refused. There is no contradiction with the 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?

Three dense sentences with no filler. The core action is front-loaded, followed by index lookup guidance, the alternative, backup behavior, and a failure condition. Every sentence contributes useful information.

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 destructive tool with annotations and an output schema, the description covers the key parameter semantics, alternative routing, backup behavior, and an important failure mode. Nothing essential for correct invocation is missing.

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 description coverage is 0%, so the description must compensate. It fully explains table_index semantics and gives backup-related behavior, but file_path is only implicit from its name and the backup=False behavior ('skips rotation only') is somewhat terse.

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 precise verb and resource: it deletes a whole table and its contents. It also scopes the target to body-level tables and explains nested-table behavior, making it clearly distinguishable from siblings like set_cells and delete_element.

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 tells the agent when not to use it ('To clear cell values while keeping the grid, use set_cells instead') and states a failure condition ('Refuses documents open in Word'). It also explains how to obtain table_index via list_elements or get_document_view, which is concrete, actionable guidance.

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