Tokenrip

Copy artifact

artifact_fork

Fork a readable non-table artifact (artifactId: its current version) or one version by its own id (versionId), as POST /v0/forks. The copy lands in the source's workspace when you can write there (with why); a workspace file you read only by its public link lands standalone in your own account (no why); a standalone source lands standalone. folder files it: a folder id, or a slug (in the workspace the copy lands in, else in team, else your personal folders).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "artifact_fork"
  }
}

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. Not needed for a copy that lands in your own account. At most 300 characters.
`team`	No	With a folder slug: the team the folder belongs to.
`title`	No	The copy's title (default: the source's).
`folder`	No	The folder to file the copy in: an id, or a slug (in the workspace the copy lands in, else in team, else your personal folders).
`versionId`	No	One version to copy, by its own id (it names its artifact). Not with artifactId.
`artifactId`	No	The artifact to copy (its current version): its id, alias or page URL. Not with versionId.

Output Schema

Name	Required	Description	Default
`artifact`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 12, 2026
- removedOutput schema / properties / artifact / properties / audience
```
Removed value: -{
-  "enum": [
-    "internal",
-    "shared"
-  ],
-  "type": "string"
-}
```

Changed5 schema fields changedOct 27, 2026

addedOutput schema / properties / artifact / properties / alias

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}

addedOutput schema / properties / artifact / properties / folder

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": false,
+      "properties": {
+        "id": {
+          "format": "uuid",
+          "pattern": "^([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)$",
+          "type": "string"
+        },
+        "slug": {
+          "type": "string"
+        },
+        "teamSlug": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "id",
+        "slug"
+      ],
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}

addedOutput schema / properties / artifact / properties / rawUrl

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}

addedOutput schema / properties / artifact / properties / title

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}

changedOutput schema / properties / artifact / required

Previous value: -[
-  "id",
-  "url",
-  "type",
-  "currentVersionId"
-]New value: +[
+  "id",
+  "url",
+  "rawUrl",
+  "type",
+  "currentVersionId",
+  "alias",
+  "title",
+  "folder"
+]

First observedOct 23, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Annotations only say readOnly=false, destructive=false, idempotent=false, openWorld=true; the description adds genuine behavior: the copy's destination depends on write access, workspace writes require a one-sentence 'why' while account-local copies do not, and folder slugs resolve in a defined priority (workspace, then team, then personal). That is real context the annotations do not carry. It stops short of describing failure modes or what happens with a table artifact.

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 purpose is front-loaded and the text is dense, but the final sentence ('folder files it: a folder id, or a slug...') is awkwardly phrased and duplicates the folder parameter's schema description word-for-word, so it does not earn its place. Structure is one long run-on rather than clearly separated clauses.

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?

With an output schema, full schema coverage, and annotations present, the description covers the main agent-facing unknowns: destination logic and the 'why' requirement. It leaves minor gaps such as behavior when the source is a table or unreadable, and confirmation of the non-idempotent nature.

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 the schema already documents why, folder, team, title, artifactId, and versionId — including the artifactId/versionId mutual exclusion. The description largely restates that (including the folder slug resolution order verbatim), so baseline 3 is right.

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 ('Fork') and resource (artifact), plus the key scope limits: readable, non-table, and either the current version via artifactId or a single version via versionId. It is clear what the tool does, but it never names a sibling (e.g., artifact_get or artifact_version_diff) to sharpen the boundary.

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?

Usage is implied through landing-destination rules ('lands in the source's workspace when you can write there', 'a standalone source lands standalone'), which tells the agent when a 'why' is needed. However, there is no explicit when-to-use-this vs. a sibling tool, nor any stated exclusion beyond 'non-table'.

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.