Skip to main content
Glama
SmartSuiteFoundry

SmartSuite MCP Server

by SmartSuiteFoundry
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

smartsuite_move_layout_field

Reorder a field in a SmartSuite record-view layout, move it under a section or to another tab, or set its column width.

Instructions

Move/arrange a field in the record-view layout — reorder it, place it under a section, or move it to a different tab. Requires readwrite/admin + SMARTSUITE_ENABLE_SCHEMA_WRITE. To move a field to ANOTHER tab, pass toTab = the destination tab id: the field is removed from its current tab and added to the destination (this is the cross-tab move — plain reorder can't pull a field in from another tab). Otherwise it reorders within the current layout. Pass afterField = a field slug OR a section__ slug to position this field right after it (right after a section marker = first field under that section); omit afterField for the end. In two-column layouts the field is placed alone in its row — which is NOT the same as full width: the column span lives on the field as params.width (1 = half, so the row renders with an empty right slot; 2 = spans both columns). Pass fullWidth:true/false to set it; that is a change_field write, so with fullWidth and no afterField/toTab this only changes the span and does not reorder anything. When tabs are enabled and toTab is NOT used, tabId is required (a tab id, "all", or "top") — with tabs on, the record view renders per-tab layouts, so a top-level edit is saved but invisible. Dry-run preview unless confirm:true.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
slugYesThe field slug to move.
tabIdNoFor within-layout reorder when tabs are enabled (required then): a tab id, "all", or "top". Ignored when toTab is set. Omit when tabs are disabled.
toTabNoDestination tab id — moves the field to that tab (removing it from its current tab). Use this for cross-tab moves.
confirmNoMust be true to apply (default false = preview).
fullWidthNoSet the field's record-view column span: true = spans both columns (params.width 2), false = half width (1). Omit to leave the span alone. Given without afterField/toTab, only the span changes — the field is not reordered.
afterFieldNoField slug or section__ slug to place this field after (default: end).
applicationIdYesThe application (table) ID.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.0.3
    • addedInput schema / properties / fullWidth
      Added value: +{
+  "description": "Set the field's record-view column span: true = spans both columns (params.width 2), false = half width (1). Omit to leave the span alone. Given without afterField/toTab, only the span changes — the field is not reordered.",
+  "type": "boolean"
+}
  2. First observedv0.9.8

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=false; the description carries the real behavioral load — required readwrite/admin plus SMARTSUITE_ENABLE_SCHEMA_WRITE, dry-run preview unless confirm:true, the cross-tab removal-then-add semantics, and the subtlety that fullWidth alone is a change_field write that changes only the span.

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?

Front-loaded with the core purpose, then dense with edge-case rules. Length is justified by the tool's complexity, though the parenthetical explanations (e.g. the two-column digression) are slightly verbose and could tighten without losing meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no output schema but 100% parameter coverage, the description supplies everything an agent needs: prerequisites, dry-run protocol, tab-enabled constraints, and the cross-tab vs reorder distinction. No evident gaps remain.

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 100%, so the baseline is 3, but the description adds genuine meaning beyond the schema: the section__ slug convention placing a field as the first under a section, the tabId-ignored-when-toTab-set interaction, and fullWidth's mapping to params.width (2=full, 1=half with an empty right slot).

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+resource ('Move/arrange a field in the record-view layout') and enumerates the three distinct operations (reorder, place under section, move to tab). It is clearly distinguishable from siblings like remove_layout_field, update_layout_section, and update_field because it alone governs positioning.

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?

Explicit routing: toTab for cross-tab moves, afterField for positioning, fullWidth for span, tabId when tabs are enabled and toTab is not used. It even warns when a plain top-level edit is saved but invisible, and states the dry-run default.

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

Deploy Server

Other Tools