Skip to main content
Glama

Delete item

nextcloud_delete_item
Destructive

Deletes a specified Nextcloud item by path, enabling you to remove files or resources through the MCP server.

Instructions

Alias for delete_resource to support MCP server action.

Input Schema

NameRequiredDescriptionDefault
pathYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.3.4

TDQS

C2/5.0
Behavior2/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=true, so the safety profile is covered by structured data. The description adds nothing beyond the alias fact – no statement about irreversibility, confirmation requirements, or what happens when path does not exist.

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

Conciseness3/5

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

It is a single short, front-loaded sentence with no padding, so structurally fine. However, the one sentence spent on alias metadata does not earn its place against the missing explanation of what gets deleted and what path means.

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

Completeness2/5

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

This is a destructive operation with no output schema and an entirely undocumented parameter, so the description carries most of the burden – yet it covers neither the affected resource type nor the path format nor error behavior. The alias note is the only useful content.

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

Parameters1/5

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

There is a single required path parameter with 0% schema description coverage, so the description must explain its format and semantics. It says nothing at all about path – not whether it is root-relative, URL-encoded, or whether it addresses files versus folders.

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

Purpose2/5

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

The description only says it is an alias for delete_resource; it does not state what an "item" is (file, folder, share, calendar, contact) or what resource domain it operates on. A reader can infer deletion from the name and the alias pointer, but the description itself adds no scope beyond the title.

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

Usage Guidelines2/5

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

Naming delete_resource does tell the agent the two calls are functionally equivalent, which is faint routing value. But there is no guidance on when to prefer delete_item over the direct delete_resource sibling, nor any prerequisites or exclusions.

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