Skip to main content
Glama

delete_object

Delete one object by id or multiple objects by ids from an Inkboard board file or the live board; bound connectors stay but become detached.

Instructions

Deletes an object, or several with ids (connectors that were bound to them remain, detached). Give id or ids.

Input Schema

NameRequiredDescriptionDefault
idNo
idsNoSeveral objects to delete at once (result: `deleted` is then a list).
pageNoPage: number (from 1) or name. Defaults to the first.
pathNoPath of the board file (.inkboard; .inkboard.json and .tableau.json also accepted). Optional when the application is open: the tool then acts live on the displayed board (undoable with Ctrl+Z).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It usefully discloses a non-obvious side effect — connectors bound to deleted objects remain but detached — which is real behavioral value. However, it says nothing about irreversibility, whether deletion is undoable, permission requirements, or rate limits, leaving the most consequential traits unstated.

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?

Two short sentences, front-loaded with the action and immediately followed by the batch variant and its side effect. Little waste; only the trailing 'Give `id` or `ids`' is mildly redundant with the opening.

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

Completeness4/5

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

For a destructive tool with no annotations and no output schema, the description covers the essential call mechanics (target selection, batch limits implied by schema, connector side effect). The notable gap is the absence of any statement about reversibility or confirmation, which matters most for a delete operation.

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

Parameters3/5

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

Schema coverage is 75%, so `ids`, `page`, and `path` are already documented in the schema. The description restates the `id`/`ids` choice and adds the connector-detachment consequence, but adds nothing about `page` or `path` beyond what the schema says. Baseline 3 is appropriate.

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

Purpose4/5

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

The description gives a specific verb and resource ('Deletes an object') and distinguishes the single-target form from the bulk form via `ids`. No sibling tool deletes objects, so differentiation is inherent, but the wording is clear and unambiguous.

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

Usage Guidelines3/5

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

The use condition is implicit in 'Give `id` or `ids`' — an agent learns which parameter form to pick, but there's no statement about when deletion is appropriate, prerequisites, or what to do instead (e.g., update_object) when removal is not wanted. Adequate but thin.

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