Onplana

create_workspace_column

Add a column to an existing workspace table (list), placed after its last column. colType is one of: TEXT, TEXTAREA, NUMBER, DATE, DROPDOWN, MULTI_SELECT, CHECKBOX, URL, EMAIL, PHONE, CURRENCY, RATING, RELATION (default TEXT). options (string[]) holds the choices of a DROPDOWN or MULTI_SELECT. required is a boolean. A RELATION column links each row to a row of another list in the same organization and takes relationConfig { targetTableId, cardinality: MANY_TO_ONE or ONE_TO_ONE }. Returns the new column with its id, which update_workspace_row and create_workspace_row take as a cell key. A list holds a fixed maximum number of columns.

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": {
      "tableId": "<tableId>",
      "name": "<name>"
    },
    "name": "create_workspace_column"
  }
}

Input Schema

Name	Required	Description
`name`	Yes	Column name.
`colType`	No
`options`	No
`tableId`	Yes	The list, from list_workspace_tables.
`required`	No
`idempotencyKey`	No	Optional idempotency key. Pass a stable unique value (e.g. a UUID) to make this create safe to retry: calling again with the same key within 24h - even from a new session after a reconnect - replays the original result and creates no duplicate. Org-scoped; works across conversations.
`relationConfig`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 14, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare this is a non-readonly, non-destructive creation with no natural idempotency, so the baseline is lower. The description adds useful behavior beyond annotations: column placement, the returned column id and its downstream use as a cell key, that RELATION targets another list in the same organization, and the maximum-column limit. It does not cover failure modes or permission requirements, but the annotations carry the safety profile.

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 dense but front-loaded, leading with the core action before parameter details. Some enum values are repeated from the schema, which is slightly redundant, but each detail generally earns its place.

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 seven parameters, a nested relation object, and no output schema, the description is substantially complete: it explains the return value (the new column with its id), the meaning of key parameters, and a structural limit on columns. It lacks explicit error or permission guidance, but the annotations already establish the safety profile.

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 description coverage is 43%, so the description must compensate, and it does for the most complex parameters: it explains that options holds DROPDOWN/MULTI_SELECT choices, that RELATION requires relationConfig with targetTableId and cardinality, and that colType defaults to TEXT. It adds little for tableId and name, but those are already documented in the schema.

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 opens with a specific verb and resource: 'Add a column to an existing workspace table (list)', and clarifies placement after the last column. This is clearly distinguishable from sibling tools like create_workspace_table and update_workspace_column.

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

Usage Guidelines3/5

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

It implies usage by naming downstream tools that consume the returned column id (update_workspace_row and create_workspace_row), but it never explicitly says when to choose this over update_workspace_column or create_workspace_table. The 'fixed maximum number of columns' note is a helpful constraint but not a selection guideline.

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

All Onplana 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.