Skip to main content
Glama

Create Sheet View

view.create

Add a view to a sheet, with its settings in one call. Types: TABLE, KANBAN (board: columns by a Status or Select field — groupBy), CALENDAR, GANTT_CHART and TIME_LINE (rows placed on a Date field — dateField; a timeline's rows come from resourceField), GALLERY (needs at least one File List field on the sheet), CARD, EMAIL (only on an email sheet, one with the message_id and account fields a connected mailbox creates), BLOG (posts are the pages of a Document field — contentField) and PROCESS_MAP (how cards move between the values of one Status, Select, Employee or Team field — groupBy, required). Settings by field NAME: filter (the sheet.read filter form), sort, groupBy for a table's or card view's groups, hiddenFields / shownFields (TABLE, KANBAN, CARD). An unknown field name is refused with the names that exist. Vista views are not creatable here.

Input Schema

NameRequiredDescriptionDefault
iconNoBootstrap icon name, e.g. 'bi-kanban'.
nameYes
sortNoRow order, up to three keys; `field` is a name or code. `[]` clears it.
typeYes
filterNoRows the view shows. `null` clears the filter.
groupByNoField name or code to group by: a board's columns (Status/Select), or a table's or card view's groups.
sheetIdYes
dateFieldNoDate field name or code that places rows on a CALENDAR, GANTT_CHART or TIME_LINE.
shownFieldsNoField names or codes to show again (TABLE, KANBAN and CARD views).
contentFieldNoBLOG only: the Document field whose pages are the posts. Default: the sheet's first one.
hiddenFieldsNoField names or codes to hide (TABLE, KANBAN and CARD views).
resourceFieldNoTIME_LINE only: the field whose values become the timeline's rows, e.g. Assignee. Default: the title.

Output Schema

NameRequiredDescriptionDefault
viewIdNoId of the new view
sheetIdYesSheet the view was added to
spaceIdYesSpace of that sheet; null outside a space or when unknown

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / type / enum
      Previous value: -[
      -  "TABLE",
      -  "KANBAN",
      -  "CALENDAR",
      -  "GALLERY",
      -  "GANTT_CHART",
      -  "TIME_LINE",
      -  "CARD",
      -  "EMAIL",
      -  "BLOG"
      -]New value: +[
      +  "TABLE",
      +  "KANBAN",
      +  "CALENDAR",
      +  "GALLERY",
      +  "GANTT_CHART",
      +  "TIME_LINE",
      +  "CARD",
      +  "EMAIL",
      +  "BLOG",
      +  "PROCESS_MAP"
      +]
  2. Changed2 schema fields changed
    • removedOutput schema / properties / spaceId / anyOf
      Removed value: -[
      -  {
      -    "type": "number"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / spaceId / type
      Added value: +[
      +  "number",
      +  "null"
      +]
  3. Changed12 schema fields changed
    • addedInput schema / properties / contentField
      Added value: +{
      +  "description": "BLOG only: the Document field whose pages are the posts. Default: the sheet's first one.",
      +  "minLength": 1,
      +  "type": "string"
      +}
    • changedInput schema / properties / dateField / description
      Previous value: -"CALENDAR only: attribute CODE of the Date field to place events on."New value: +"Date field name or code that places rows on a CALENDAR, GANTT_CHART or TIME_LINE."
    • addedInput schema / properties / filter
      Added value: +{
      +  "anyOf": [
      +    {
      +      "description": "The sheet.read filter form: `{ conditionOperator: \"AND\", filters: [{ attribute: \"Stage\", queryOperator: \"NEQ\", value: \"Won\" }] }`. `attribute` is a field name or code; Status, Select, member and team values may be their names. Groups nest.",
      +      "properties": {
      +        "conditionOperator": {
      +          "default": "AND",
      +          "enum": [
      +            "AND",
      +            "OR"
      +          ],
      +          "type": "string"
      +        },
      +        "filters": {
      +          "items": {
      +            "additionalProperties": {},
      +            "propertyNames": {
      +              "type": "string"
      +            },
      +            "type": "object"
      +          },
      +          "minItems": 1,
      +          "type": "array"
      +        }
      +      },
      +      "required": [
      +        "filters"
      +      ],
      +      "type": "object"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "description": "Rows the view shows. `null` clears the filter."
      +}
    • changedInput schema / properties / groupBy / description
      Previous value: -"KANBAN only: attribute CODE of the Status/Select field to group columns by."New value: +"Field name or code to group by: a board's columns (Status/Select), or a table's or card view's groups."
    • addedInput schema / properties / hiddenFields
      Added value: +{
      +  "description": "Field names or codes to hide (TABLE, KANBAN and CARD views).",
      +  "items": {
      +    "minLength": 1,
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / resourceField
      Added value: +{
      +  "description": "TIME_LINE only: the field whose values become the timeline's rows, e.g. Assignee. Default: the title.",
      +  "minLength": 1,
      +  "type": "string"
      +}
    • addedInput schema / properties / shownFields
      Added value: +{
      +  "description": "Field names or codes to show again (TABLE, KANBAN and CARD views).",
      +  "items": {
      +    "minLength": 1,
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / sort
      Added value: +{
      +  "description": "Row order, up to three keys; `field` is a name or code. `[]` clears it.",
      +  "items": {
      +    "properties": {
      +      "direction": {
      +        "enum": [
      +          "asc",
      +          "desc"
      +        ],
      +        "type": "string"
      +      },
      +      "field": {
      +        "minLength": 1,
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "field",
      +      "direction"
      +    ],
      +    "type": "object"
      +  },
      +  "maxItems": 3,
      +  "type": "array"
      +}
    • changedInput schema / properties / type / enum
      Previous value: -[
      -  "TABLE",
      -  "KANBAN",
      -  "CALENDAR",
      -  "GALLERY"
      -]New value: +[
      +  "TABLE",
      +  "KANBAN",
      +  "CALENDAR",
      +  "GALLERY",
      +  "GANTT_CHART",
      +  "TIME_LINE",
      +  "CARD",
      +  "EMAIL",
      +  "BLOG"
      +]
    • addedOutput schema / properties / sheetId
      Added value: +{
      +  "description": "Sheet the view was added to",
      +  "type": "number"
      +}
    • addedOutput schema / properties / spaceId
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "number"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "description": "Space of that sheet; null outside a space or when unknown"
      +}
    • addedOutput schema / required
      Added value: +[
      +  "sheetId",
      +  "spaceId"
      +]
  4. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare a non-destructive, non-idempotent write; the description adds real behavioral context on top: unknown field names are rejected with the list of valid names, Vista views are rejected, and several type/sheet preconditions are surfaced. It stops short of stating permission requirements or what happens if a similarly named view already exists.

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?

Purpose is front-loaded in the first clause and every subsequent sentence carries type-specific constraints, so little is wasted. It is, however, one dense paragraph of nested parentheticals; a short list of per-type requirements would scan faster for a 12-parameter tool.

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?

For a complex tool with 12 parameters and 10 enum values, the description covers type prerequisites, field-name semantics, and rejection behavior, and an output schema exists so return values need no explanation. Missing only auth/permission needs and handling of duplicate names, which are secondary for correct invocation.

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 75%, so the schema carries much of the load, but the description adds applicability the schema does not: `groupBy` means board columns for KANBAN and is required for PROCESS_MAP, `dateField` places rows on CALENDAR/GANTT/TIME_LINE, and hidden/shown fields are limited to TABLE/KANBAN/CARD. That conditional mapping is genuinely useful beyond the field-level descriptions.

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 ('Add a view to a sheet') and then enumerates the ten supported view types with the fields that distinguish them, so an agent knows exactly what this creates. The closing exclusion ('Vista views are not creatable here') separates it from related view operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear per-type preconditions: GALLERY needs a File List field, EMAIL only works on an email sheet, PROCESS_MAP requires `groupBy`, BLOG needs a Document field. It also states a when-not (Vista views) but does not route the agent to view.update for modifying existing views or view.publish/restore, which are the obvious siblings.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources