Atwork

Update Page

page.update

DestructiveIdempotent

Rename a page, change its icon, set or clear its cover, author or date, or move it to another space or folder. Only what you name changes; edit the page's content with page.edit.

Input Schema

Name	Required	Description
`date`	No	The page's date, `YYYY-MM-DD`; null removes it
`icon`	No
`name`	No
`cover`	No	A built-in cover, `atw:1` to `atw:6`; null removes it
`pageId`	Yes
`authorId`	No	Employee id (from `member.read`) shown as the page's author; null removes it
`toSpaceId`	No	Move the page to this space
`toFolderId`	No	Move the page into this folder (of `toSpaceId`, or of the page's own space when that is absent)

Output Schema

Name	Required	Description
`name`	Yes
`pageId`	Yes
`changed`	Yes
`location`	Yes	Where the page sits

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 5, 2026

addedInput schema / properties / authorId

Added value: +{
+  "anyOf": [
+    {
+      "maxLength": 64,
+      "minLength": 1,
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Employee id (from `member.read`) shown as the page's author; null removes it"
+}

addedInput schema / properties / cover

Added value: +{
+  "anyOf": [
+    {
+      "enum": [
+        "atw:1",
+        "atw:2",
+        "atw:3",
+        "atw:4",
+        "atw:5",
+        "atw:6"
+      ],
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "A built-in cover, `atw:1` to `atw:6`; null removes it"
+}

addedInput schema / properties / date

Added value: +{
+  "description": "The page's date, `YYYY-MM-DD`; null removes it",
+  "type": [
+    "string",
+    "null"
+  ]
+}

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

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnly=false, idempotent=true, destructive=true, so safety framing is partly covered; the description adds the genuinely useful partial-update guarantee that the annotations do not convey. The gap is that destructiveHint=true is never explained — nothing says whether moving a page between spaces or null-clearing cover/author loses data, and no permission requirements are mentioned.

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, the capability list front-loaded and the boundary condition second. No restatement of the title and no filler.

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 present, return values need no explanation, and the description covers selection and invocation adequately for an 8-parameter update. The remaining omission is the meaning of the destructive flag — what an agent should warn about before clearing or moving — which matters for a tool explicitly annotated destructive.

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 only 63%, and the description compensates well: every optional parameter surface (name, icon, cover, author, date, space, folder) is named, and "set or clear" signals the null-removal semantics that the schema documents only for cover, date, and authorId. It stops short of the `toFolderId` fallback behavior (own-space default when `toSpaceId` is absent), which only the schema states.

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 and then enumerates the exact mutable facets: name, icon, cover, author, date, and space/folder location. It also names the sibling it is not (`page.edit`), so an agent can separate metadata updates from content edits 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?

Explicitly routes content changes to `page.edit` and states the partial-update contract ("Only what you name changes"), which tells the agent it must not resend untouched fields. The when-to-use and when-not-to-use conditions are both present in one sentence.

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?