Atwork

Read Record Layout

peek.read

Read-onlyIdempotent

Read a peek and return its kind (form: it collects new rows; record: a record layout, how a row opens), its layoutStyle, its layout array and options. Items reference sheet attributes by code; a record layout also holds Tabs blocks (tabs, and tabId on the items inside a tab), Related rows (display), History and Comments, and marks the fields shown under the record's title underTitle: true. Use before changing a record layout with peek.add_layout_item, peek.remove_layout_item, peek.reorder_layout, peek.update_options or peek.update_field_options; a form is changed with form.update.

Input Schema

Name	Required	Description	Default
`peekId`	No

Output Schema

Name	Required	Description
`kind`	Yes	form: it collects new rows; record: how a row opens
`name`	Yes
`layout`	Yes
`peekId`	Yes
`options`	Yes
`sheetId`	Yes
`description`	Yes
`layoutStyle`	Yes	A form's layout: classic (side by side by width) or steps (one question at a time); a record layout: columns

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 6, 2026

addedOutput schema / properties / layout / items / properties / underTitle

Added value: +{
+  "const": true,
+  "description": "A field on the line under the record's title (at most 4 short fields)",
+  "type": "boolean"
+}

Changed7 schema fields changedNov 5, 2026

addedOutput schema / properties / kind

Added value: +{
+  "description": "form: it collects new rows; record: how a row opens",
+  "enum": [
+    "form",
+    "record"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / layout / items / properties / display

Added value: +{
+  "description": "How a Related rows block shows",
+  "enum": [
+    "list",
+    "table"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / layout / items / properties / sectionId

Added value: +{
+  "description": "The section (an item of type 'section') this item sits in",
+  "type": "string"
+}

addedOutput schema / properties / layout / items / properties / tabId

Added value: +{
+  "description": "The tab this item sits in",
+  "type": "string"
+}

addedOutput schema / properties / layout / items / properties / tabs

Added value: +{
+  "description": "A Tabs block's tabs; pass a tab id as tabId to peek.add_layout_item",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "id": {
+        "type": "string"
+      },
+      "title": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "id",
+      "title"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / layoutStyle

Added value: +{
+  "description": "A form's layout: classic (side by side by width) or steps (one question at a time); a record layout: columns",
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "peekId",
-  "sheetId",
-  "name",
-  "description",
-  "layout",
-  "options"
-]New value: +[
+  "peekId",
+  "sheetId",
+  "name",
+  "description",
+  "kind",
+  "layoutStyle",
+  "layout",
+  "options"
+]

AddedNov 4, 2026

TDQS

A4/5.0

Behavior3/5

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

The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful semantic detail about the returned layout structure, but it does not add behavioral context such as permissions, rate limits, or side effects beyond what the annotations already establish.

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?

The description is front-loaded with the core action and then adds relevant layout details and usage guidance. It is somewhat dense, especially the parenthetical explanations and output-structure details, but most sentences carry useful information and there is no obvious 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?

The tool has rich annotations and an output schema, so the description does not need to carry the full burden of return-value or safety documentation. It covers purpose, output semantics, and when to use it versus sibling mutation tools, though it leaves the sole input parameter undocumented.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has one parameter, peekId, with 0% schema description coverage, and the description never explains what peekId identifies or how it should be obtained. The phrase 'Read a peek' implies an identifier is needed, but the description does not compensate for the missing schema documentation.

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?

The description states a specific verb and resource: read a peek and return its kind, layoutStyle, layout array, and options. It clearly distinguishes form peeks from record-layout peeks and explains what a record layout contains, so an agent can identify the tool without opening the 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?

It explicitly says to use this before changing a record layout with named sibling tools such as peek.add_layout_item, peek.remove_layout_item, peek.reorder_layout, peek.update_options, and peek.update_field_options. It also names form.update as the alternative for form peeks, giving clear when-to-use and alternative guidance.

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?