Tokenrip

Update folder

folder_update

DestructiveIdempotent

Give any folder a new slug (newSlug), or set any folder's history (how many earlier versions its files' whole-file updates keep; null follows the workspace; a workspace folder's by its editors), one per call: folder is its id (any kind: personal, team or workspace), or its slug: in workspaceId when given, else in team, else one of your personal folders. The workspace is the folder's own. A workspace folder's change needs why; expectedWorkspaceRevision is optional: send the folder's workspace_revision to refuse (CONFLICT) if it changed since.

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>"
    },
    "name": "folder_update"
  }
}

Input Schema

Name	Required	Description
`why`	No	Required for workspace items: one sentence on what the person is trying to accomplish, in their terms, not a description of this edit. Every workspace write takes one; sessions and summaries record themselves from it. At most 300 characters.
`team`	No	With a folder slug: the team (slug or id) it belongs to.
`folder`	Yes	The folder: its id (any kind), or its slug: in workspaceId when given, else in team, else one of your personal folders.
`history`	No	How many earlier versions whole-file updates of the files in it keep: off, all, or a number from 1 to 100; null follows the workspace (default off). A file's own setting wins. Takes effect at each file's next write; deletes nothing now.
`newSlug`	No	The folder's new slug.
`workspaceId`	No	With a folder slug: the workspace it is in (its id or its slug).
`expectedWorkspaceRevision`	No	Optional, a workspace folder's: refuse (CONFLICT) if the folder changed since this workspace_revision.

Output Schema

Name	Required	Description	Default
`folder`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 12, 2026

removedInput schema / properties / audience

Removed value: -{
-  "description": "A workspace folder's new audience: internal or shared (sharing shows the folder to external members; its files keep theirs).",
-  "enum": [
-    "internal",
-    "shared"
-  ],
-  "type": "string"
-}

removedOutput schema / properties / folder / properties / audience

Removed value: -{
-  "enum": [
-    "internal",
-    "shared"
-  ],
-  "type": "string"
-}

Changed3 schema fields changedOct 27, 2026

addedInput schema / properties / history

Added value: +{
+  "anyOf": [
+    {
+      "anyOf": [
+        {
+          "enum": [
+            "off",
+            "all"
+          ],
+          "type": "string"
+        },
+        {
+          "maximum": 100,
+          "minimum": 1,
+          "type": "integer"
+        }
+      ]
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "How many earlier versions whole-file updates of the files in it keep: off, all, or a number from 1 to 100; null follows the workspace (default off). A file's own setting wins. Takes effect at each file's next write; deletes nothing now."
+}

addedOutput schema / properties / folder / properties / history

Added value: +{
+  "anyOf": [
+    {
+      "anyOf": [
+        {
+          "enum": [
+            "off",
+            "all"
+          ],
+          "type": "string"
+        },
+        {
+          "maximum": 100,
+          "minimum": 1,
+          "type": "integer"
+        }
+      ]
+    },
+    {
+      "type": "null"
+    }
+  ]
+}

changedOutput schema / properties / folder / required

Previous value: -[
-  "id",
-  "slug",
-  "owner_id",
-  "team_id",
-  "artifact_count",
-  "created_at",
-  "updated_at"
-]New value: +[
+  "id",
+  "slug",
+  "owner_id",
+  "team_id",
+  "artifact_count",
+  "history",
+  "created_at",
+  "updated_at"
+]

Changed5 schema fields changedOct 24, 2026

changedInput schema / properties / workspaceId / description

Previous value: -"With a folder slug: the workspace it is in."New value: +"With a folder slug: the workspace it is in (its id or its slug)."

removedInput schema / properties / workspaceId / format
```
Removed value: -"uuid"
```
addedInput schema / properties / workspaceId / maxLength
```
Added value: +64
```
addedInput schema / properties / workspaceId / minLength
```
Added value: +1
```

removedInput schema / properties / workspaceId / pattern

Removed value: -"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"

First observedOct 23, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already flag destructiveHint=true and idempotentHint=true, and the description adds valuable nuance: the history change 'Takes effect at each file's next write; deletes nothing now', plus optimistic-concurrency behavior (CONFLICT when workspace_revision has moved). It also discloses the mandatory 'why' for workspace writes. What it omits is what happens to the old slug (redirects? links break?), which matters for a destructive rename.

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?

The content is dense and useful, but it is delivered as one sprawling run-on sentence with parenthetical nesting and colon-separated clauses, which makes the two operation modes hard to parse on first read. Nothing is wasted, but the structure is not front-loaded: the two capabilities should be enumerated before the folder-resolution rules.

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 7-parameter mutation tool it covers both operations, folder resolution across personal/team/workspace, the required 'why', and concurrency semantics; an output schema exists so return values need no explanation. The remaining gap is what a slug change does to existing references and whether the old slug keeps working, which an agent would reasonably want to know before invoking a destructive rename.

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 every parameter is already documented in the schema, and much of the description's parameter text (resolution order for 'folder', history's off/all/number scale) restates it. The one genuinely additive clarifications are 'The workspace is the folder's own' for workspaceId and the inheritance note for history, but the schema already covers most of this. Baseline 3 is appropriate.

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?

The description names the exact mutations: renaming a folder's slug (newSlug) and setting the folder's history retention, plus the scope 'any folder... any kind: personal, team or workspace'. That is specific verb+resource and goes beyond the title 'Update folder'. It does not explicitly contrast with siblings like workspace_update or folder_create, so it falls short of a 5.

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?

It states the key operational constraint ('one per call') and gives the resolution rules for locating the folder (id, or slug in workspaceId, else team, else personal). It also states when 'why' is required ('A workspace folder's change needs why') and what expectedWorkspaceRevision is for. It never names an alternative tool or says when not to use this one, so no exclusion guidance.

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

All Tokenrip tools Inspect

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.