Skip to main content
Glama

Add column

add_column
Destructive

Show a new column on a sheet. Uses the first hidden data slot and sets its header. Concurrent calls on the same sheet each get their own column. If another column change is still being saved, the call fails and asks you to try again. On a catalog sheet, call enable_catalog_sheet or adopt_catalog_sheet first. Write the new column later by the exact header from get_sheet_settings. If the name is Photo, Image, or Bilde, that column becomes the image field. barcode_standard is optional. On an existing sheet the stored standard changes only when barcode_standard is sent. If it is omitted, the sheet standard is left unchanged. Does not delete item values. Existing barcodes are not rewritten unless a later call includes confirm_token after the first call returned confirmation_required.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>"
    },
    "name": "add_column"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYes
sheet_idNo
sheet_numberNo
confirm_tokenNo
barcode_standardNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the annotations it discloses non-obvious behavior: it consumes the first hidden data slot, concurrent calls each get their own column, and a competing column save causes failure. It explicitly bounds the destructive surface by stating existing item values are not deleted and barcodes are not rewritten without confirm_token, which meaningfully refines the destructiveHint=true annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and concurrency behavior are front-loaded, which is good, but the barcode_standard rule is stated three times in slightly different words ("optional", "changes only when sent", "left unchanged"). That redundancy costs space without adding information.

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 mutation tool with annotations and no output schema, the description covers prerequisites, concurrency, confirmation, and side effects well. The remaining gap is how to choose between sheet_id and sheet_number, which the agent needs in order to actually invoke it correctly.

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

Parameters3/5

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

Schema description coverage is 0%, so the description must carry parameter meaning, and it only partly does. It explains name as the header, barcode_standard as optional and only applied when sent, and the confirm_token retry flow, but sheet_id and sheet_number are never mentioned, nor are the enum values or the 60-character name limit.

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?

"Show a new column on a sheet. Uses the first hidden data slot and sets its header." names a specific verb and resource and states the mechanism. It also implicitly disambiguates from the sibling add_photo_column by explaining that names like Photo/Image/Bilde turn the column into the image field.

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 prerequisites are given: on a catalog sheet, call enable_catalog_sheet or adopt_catalog_sheet first. It also tells the agent when a retry is required (a concurrent column save fails the call) and when confirm_token is needed (a later call after confirmation_required).

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