Skip to main content
Glama
Sign In

TransformPipe

by io.github.raudarlabs
OverviewDiscussionsAdmin

Delete a folder

tp_delete_folder
DestructiveIdempotent

Deletes a folder from the user's TransformPipe account. Use it when the user asks to delete or remove a folder. By default the folder alone is removed and its documents and subfolders move up one level, to its parent folder or the top level. With with_documents: true, every document in the folder and its subfolders is permanently deleted as well. A shared folder's link stops working. Deletion cannot be undone. confirm: true is required on every call and is set after the user has named the folder and agreed to delete it; without it nothing is deleted and the response describes what the folder contains and what would happen to it.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "folder": "<folder>",
      "confirm": "<confirm>"
    },
    "name": "tp_delete_folder"
  }
}

Input Schema

NameRequiredDescriptionDefault
folderYesThe folder: an id from tp_list_folders, or a path from the top such as "Devart AI/Home".
confirmYesSet true after the user has asked for this folder to be deleted — and, with `with_documents`, its documents.
with_documentsNoAlso move every document in the folder and its subfolders to the Trash, where they are kept 14 days. Default false: they move up one level.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, yet the description still earns its place by spelling out the default reparenting behavior, the shared-link breakage, the irreversibility, and what happens when confirm is omitted. One blemish: it says documents are 'permanently deleted' with `with_documents: true`, while the schema says they go to the Trash for 14 days, so the severity the agent communicates to the user may be overstated.

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?

Front-loaded with purpose and trigger, then default behavior, then the destructive variant, then the confirm gate; nearly every sentence adds a distinct fact. It runs slightly long, and the 'permanently deleted' phrasing creates a small detour the agent must reconcile with the schema.

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, three-parameter tool with no output schema, it covers irreversibility, side effects on documents and shares, and the response when confirm is absent. The only real gap is the inconsistent fate of documents between the description text and the schema.

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, but the description adds workflow meaning the schema does not: the ordering of `confirm` relative to the user's agreement, and the consequence of the default `with_documents` value on folder structure.

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?

Opens with a specific verb and resource ('Deletes a folder from the user's TransformPipe account'), which clearly separates it from tp_delete_document and tp_update_folder without needing to open those schemas.

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?

States the triggering intent ('when the user asks to delete or remove a folder') and layers on a real precondition: the user must have named the folder and agreed before `confirm: true` is sent. It does not name a sibling alternative, but for a destructive delete there is no obvious substitute tool to route to.

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

All TransformPipe toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources