Skip to main content
Glama

Delete Space Items Tool

delete-space-items
Destructive

Use this when the user wants to delete one or more Space pages, documents, folders, or external links from a Space. Destructive state-changing action: deletes the selected items directly after the MCP client authorizes the call, including items that may be publicly visible in a public Space. Requires numeric space_id and item_ids from list-space-documents.

Input Schema

NameRequiredDescriptionDefault
item_idsYesSpace item IDs to delete.
space_idYesNumeric Space ID containing the items that should be deleted.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and openWorldHint=true, so the safety profile is covered structurally. The description adds genuine context beyond that: deletion happens directly after MCP client authorization, and it can affect items publicly visible in a public Space. It omits whether deletion is reversible or recoverable.

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?

Three tight sentences with the destructive warning and the item types front-loaded; the prerequisite sentence closes it cleanly. No filler, though it is slightly denser than it needs to be.

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?

With no output schema, the description is the only source of return/side-effect information, and it adequately covers the destructive nature, authorization requirement, and parameter provenance. A brief note on reversibility would close the remaining gap.

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 100%, so the baseline is 3. The description goes beyond the schema by tying item_ids to their source (list-space-documents) and confirming space_id is numeric, giving the agent a workflow hook the schema alone does not provide.

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?

States a specific verb (delete) plus the resource classes it handles (Space pages, documents, folders, external links) and scopes them to a Space. This distinguishes it from delete-space (whole space) and delete-space-document (single document), though it doesn't name those siblings explicitly.

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?

Opens with an explicit trigger ("Use this when the user wants to delete one or more...") and tells the agent where the required IDs come from (list-space-documents). No explicit when-not statement or named alternative, which keeps it just below a 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.