Skip to main content
Glama
Nextcloud MCP Server

Nextcloud MCP Server

by a-lagutov

delete

Remove specified files or folders by moving them to their owner's trash, where they can be restored later.

Instructions

Delete files or folders (they go to the trash bin of their owner; restore with restore_from_trash)

Input Schema

NameRequiredDescriptionDefault
pathsYesPaths to delete

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.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 behavioral burden and does disclose the critical trait: items go to the owner's trash bin and can be restored. The 'of their owner' detail is useful for shared content. It omits permission requirements, partial-failure behavior when deleting multiple paths, and whether trashed items still occupy space or appear in listings.

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?

One sentence, front-loaded with the action and target, with the recovery hint in parentheses. Zero waste and no redundancy with structured fields.

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

Completeness3/5

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

For a destructive mutation tool with no annotations and no output schema, the description covers the essential reversibility fact, which is the most important thing an agent needs. It leaves gaps on permission prerequisites, error/partial-failure semantics for multiple paths, and what the response contains.

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 100%, so the single 'paths' array parameter is already documented in the schema, and the description adds no format, relative-vs-absolute path rules, or multi-path semantics. Baseline 3 is appropriate when the schema does the heavy lifting.

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) and resource (files or folders), which disambiguates the generic tool name 'delete' from siblings like delete_share and clear_trash. It doesn't explicitly exclude those siblings, but the file/folder scoping does the work.

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?

Implies usage by naming restore_from_trash as the recovery path, which tells the agent the deletion is reversible. However, there is no explicit when-to-use vs clear_trash (permanent removal) or delete_share, and no guidance on required permissions or preconditions.

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