Atwork

Duplicate Sheet Page Or Folder

item_tree.duplicate

Copy a sheet (structure and rows), a page, or a folder with what is in it, into a space or folder. Ids come from workspace.structure.

Input Schema

Name	Required	Description
`pageId`	No
`sheetId`	No	The sheet to copy (give exactly one of sheetId, pageId, folderId)
`folderId`	No	A folder is copied, with the sheets and pages in it, within its own space
`toSpaceId`	Yes	The space the copy goes to
`toFolderId`	No	A folder of `toSpaceId`; omit for the top of the space

Output Schema

Name	Required	Description
`kind`	Yes
`name`	Yes	The name of what was copied
`location`	Yes	Where the copy sits
`sourceId`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedNov 4, 2026
- removedOutput schema / properties / location / properties / folderId / anyOf
```
Removed value: -[
-  {
-    "type": "number"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / location / properties / folderId / type
```
Added value: +[
+  "number",
+  "null"
+]
```
- removedOutput schema / properties / location / properties / folderName / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / location / properties / folderName / type
```
Added value: +[
+  "string",
+  "null"
+]
```
AddedOct 27, 2026

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare a non-read-only, non-destructive, non-idempotent, closed-world write. The description adds real behavioral context beyond that: exactly what content travels with the copy (sheet structure and rows, folder contents) and that ids must be sourced from workspace.structure. It omits naming/collision behavior for the new item, whether permissions are inherited, and whether repeated calls pile up duplicates.

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?

Two sentences, zero filler, with the operation and its resource scope front-loaded and the id-provenance caveat trailing as a short actionable note.

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 five parameters, four of them described in schema, and an output schema present, the description covers what is needed to select the tool and identify the source/destination concept. A line on duplicate naming or on move-vs-duplicate would make it complete.

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 80%, so the baseline is 3. The description only tells the agent where to obtain ids; it adds no meaning about the toSpaceId/toFolderId destination pair or the source-selector exclusivity beyond what the schema already documents.

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 states a specific verb (copy) plus the three resource types it accepts (sheet with structure and rows, page, folder with contents) and the destination (a space or folder). An agent can distinguish this from item_tree.move by the copy semantics, though the description never names that sibling explicitly.

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 by the enumeration of copiable resource types, and there is a useful prerequisite hint that ids come from workspace.structure. However, it gives no explicit when-to-use/when-not guidance, no mention of the alternative item_tree.move, and the exactly-one-of constraint on sheetId/pageId/folderId is left to the schema.

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

All Atwork 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.

Resources

Need Help?