SmartSuite MCP Server

smartsuite_create_view

Create a view in a SmartSuite application by choosing a mode like grid, kanban, or calendar. Validates fields and filters, returning a dry-run preview until confirmed.

Instructions

Create a view (report) in an application. Requires readwrite/admin mode AND SMARTSUITE_ENABLE_SCHEMA_WRITE=true. Supply applicationId, label (must be unique — the tool checks and suggests an alternative if taken), and viewMode (grid, card, kanban, calendar, timeline, gantt, chart, map). Optionally set the initial configuration: visibleFields (array of field slugs), filters (array of {field, comparison, value}) with filterOperator ("and"/"or"), sort (array of {field, direction:"asc"|"desc"}), and groupBy (array of {field,...}). TWO MODES NEED A FIELD BINDING OR THEY OPEN UNUSABLE: a calendar requires dateField (a date-type slug) — without it the view is created, reports success, and shows nothing; a kanban requires stackBy (a status or single-select slug) for its columns — groupBy is a different axis and leaves the board with no columns (swimlaneBy sets the optional second axis). Both are reported back on the view and a missing one returns a warning. Omit config to create a view with SmartSuite defaults. Field slugs are validated against the schema. Dry-run preview unless confirm:true. (For forms use smartsuite_create_form; dashboards are separate.)

Input Schema

TableJSON Schema

Name	Required	Description
`sort`	No	Optional: sort rules [{field, direction:"asc"\|"desc"}].
`label`	Yes	The view name (must be unique within the application).
`confirm`	No	Set true to create; otherwise returns a dry-run preview.
`filters`	No	Optional: filter conditions [{field, comparison, value}].
`groupBy`	No	Optional: group-by rules [{field, ...}].
`stackBy`	No	KANBAN only, and required for one to work: the status/single-select field slug whose values become the columns. Not the same as groupBy.
`viewMode`	Yes	View type: grid, card, kanban, calendar, timeline, gantt, chart, or map.
`dateField`	No	CALENDAR only, and required for one to work: the date-type field slug records are placed on. Omitting it creates a blank calendar.
`swimlaneBy`	No	KANBAN only: optional second axis (rows).
`description`	No	Optional view description.
`applicationId`	Yes	The application ID the view belongs to.
`visibleFields`	No	Optional: field slugs to show, in order.
`filterOperator`	No	Combine filters with AND or OR (default and).

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv1.0.3Sep 12, 2026

addedInput schema / properties / dateField

Added value: +{
+  "description": "CALENDAR only, and required for one to work: the date-type field slug records are placed on. Omitting it creates a blank calendar.",
+  "type": "string"
+}

addedInput schema / properties / stackBy

Added value: +{
+  "description": "KANBAN only, and required for one to work: the status/single-select field slug whose values become the columns. Not the same as groupBy.",
+  "type": "string"
+}

addedInput schema / properties / swimlaneBy

Added value: +{
+  "description": "KANBAN only: optional second axis (rows).",
+  "type": "string"
+}

First observedv0.9.8Jul 29, 2026

TDQS

A4.8/5.0

Behavior5/5

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

With only readOnlyHint=false from annotations, the description carries the behavioral load and does so: dry-run default unless confirm:true, unique-label checking with suggested alternatives, schema validation of field slugs, and the crucial warning that calendar/kanban views can be created 'successfully' yet render unusable when dateField/stackBy is missing, with a `warning` returned. This is exactly the kind of non-obvious behavior an agent needs.

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 action and prerequisites, then the mode-specific caveat. It is long, but nearly every clause (env var, uniqueness check, calendar/kanban bindings, dry-run) carries information. Parenthetical asides are dense rather than padded.

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 13-parameter mutation tool with no output schema and minimal annotations, the description covers required args, env/permission gating, mode-specific requirements, validation and warning behavior, and the dry-run escape hatch. Nothing needed to invoke it correctly is missing.

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 baseline is 3, but the description adds real semantic value beyond the schema: it distinguishes groupBy from stackBy (and notes swimlaneBy as the optional second axis) and explains the consequence of omitting mode-specific bindings. Slight overlap with schema text keeps it from a 5.

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?

Opens with a specific verb+resource ('Create a view (report) in an application') and explicitly disambiguates from adjacent creators by naming smartsuite_create_form and noting dashboards are separate. An agent can identify this tool's role without inspecting 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?

States the exact prerequisites (readwrite/admin mode plus SMARTSUITE_ENABLE_SCHEMA_WRITE=true), the confirm:true gate versus dry-run, and routes to the sibling tools for forms and dashboards. Explicit when-to-use and when-to-use-something-else guidance.

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

Deploy Server

smartsuite_create_view

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools