Skip to main content
Glama
Sign In

ThreadPage

by page.thread
OverviewDiscussionsAdmin

Remove a folder, keep its contents

delete_folder_container
DestructiveIdempotent

Remove only the Folder: it goes to Trash, and the Threads and Folders it held move up to its parent, unchanged. To trash the Folder with everything in it, use trash_folder. Needs Can edit and organize; expected_revision is not compared. A Folder holding Threads needs the person's yes: your client may ask them, else it answers confirmation_required — ask, then send the same call with confirm. Answers a receipt; restore_folder brings back the Folder alone.

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": {
      "operation_id": "<operation_id>",
      "folder_id": "<folder_id>",
      "expected_revision": "<expected_revision>"
    },
    "name": "delete_folder_container"
  }
}

Input Schema

NameRequiredDescriptionDefault
confirmNoOnly after a confirmation_required answer and the person's yes: its details.confirm. Omit it otherwise.
folder_idYesA Folder's id, from list_folders or list_threads.
operation_idYesA new UUID for each write. After a lost answer, send the identical call with the same one, or check get_operation before writing again.
expected_revisionYesIts revision from list_threads, get_thread, list_folders or get_note (not a content_revision); not compared.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / expected_revision / description
      Previous value: -"The revision you last read for it."New value: +"Its revision from list_threads, get_thread, list_folders or get_note (not a content_revision); not compared."
  2. First observed

TDQS

A4.2/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the mutation profile is known. The description goes beyond them by disclosing that the Folder goes to Trash (recoverable), that contents move up to the parent unchanged, that expected_revision is not compared, and that a receipt is returned. It does not contradict destructiveHint — the container itself is removed — but it could have been clearer about whether the trashed Folder can be restored with its original children, which it only implies via 'restore_folder brings back the Folder alone'.

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 the distinguishing behavior and free of filler; every clause conveys a distinct fact (trash vs delete, permission, confirm flow, receipt, restore scope). It is dense and semicolon-chained, which slightly hurts scanability for an agent parsing it quickly.

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

Completeness5/5

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

For a destructive, confirmation-gated mutation with no output schema, the description covers safety profile, prerequisites, the escalation path, retry guidance, the fact that a receipt is returned, and the sibling restore operation. Nothing an agent needs in order to call it correctly or recover from an error is missing.

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 description coverage is 100%, so all four parameters are already documented, and the description's notes on 'expected_revision is not compared' and the confirm handshake largely restate what the schema fields say. It adds modest value by framing confirm as a round-trip triggered by a confirmation_required answer, but does not explain operation_id retry semantics beyond what the schema states. 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.

Purpose5/5

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

States a specific verb and resource ('Remove only the Folder') plus the crucial semantic twist that its Threads and Folders reparent rather than being destroyed. It explicitly contrasts with trash_folder, so an agent can distinguish the two sibling operations without opening either schema.

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

Usage Guidelines5/5

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

Gives explicit when-to-use ('remove only the Folder') versus when-not ('To trash the Folder with everything in it, use trash_folder'), names the alternative tool, and states the required permission ('Needs Can edit and organize'). The confirmation escalation path ('ask, then send the same call with confirm') is spelled out rather than inferred.

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

All ThreadPage 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