Skip to main content
Glama

Create custom field

create_custom_field
DestructiveIdempotent

Create a custom field on a workspace, or REPLACE the options of one that already exists. Matching is by name: if a select field with this name exists, its option list is overwritten and every option missing from options is deleted, taking that value off every asset holding it. Always pass the complete intended option set, and check list_custom_fields first when the field may already exist. The workspace's built-in 'Status' field cannot be replaced through this tool; use update_asset_status to assign its value to an asset. For a select field (the default) or a multi_select field options cannot be empty. For a date, person, url or text field pass field_type and no options; an existing field with the same name and type is returned unchanged, and a name already used by a field of another type is refused. A NEW field is refused once the workspace reaches its plan's custom field quota — replacing the options of an existing field still works at the limit, so check list_custom_fields before assuming the workspace needs another field. A field's VALUE is set on an asset with update_asset's fields argument ({ "Priority": "High" }); there is no separate set-value tool. Field and option names are matched EXACTLY; update_asset answers an unknown one with an error naming the valid ones, and list_custom_fields has the spelling. Requires a write-scope token and workspace owner/admin permission.

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": "create_custom_field"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYesField name, e.g. 'Priority'. An existing field with this name is reused and its options replaced. The built-in 'Status' field is protected and cannot be replaced.
optionsNoThe complete set of values a select or multi_select field allows, e.g. ['Low', 'Medium', 'High']. Replaces the existing options; anything omitted is deleted. Required and non-empty for those; omit it for date, person, url and text fields.
field_typeNoWhat the field holds: 'select' (default) for one of a fixed set of options, 'multi_select' for any number of them, 'date' for an ISO date, 'person' for a workspace member, 'url' for a link, 'text' for one line of free text. Cannot be changed later, except that a select field can become multi_select.
organizationNoWorkspace slug, as returned by list_organizations. Omit it when the account has a single workspace — it is then resolved from your token. Pass it only when the account has several, or when you mean a workspace other than the obvious one.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • removedInput schema / additionalProperties
      Removed value: -false
  2. Changed3 schema fields changed
    • changedInput schema / properties / field_type / description
      Previous value: -"What the field holds: 'select' (default) for a fixed set of options, 'date' for an ISO date, 'person' for a workspace member, 'url' for a link. Cannot be changed later."New value: +"What the field holds: 'select' (default) for one of a fixed set of options, 'multi_select' for any number of them, 'date' for an ISO date, 'person' for a workspace member, 'url' for a link, 'text' for one line of free text. Cannot be changed later, except that a select field can become multi_select."
    • changedInput schema / properties / field_type / enum
      Previous value: -[
      -  "select",
      -  "date",
      -  "person",
      -  "url"
      -]New value: +[
      +  "select",
      +  "multi_select",
      +  "date",
      +  "person",
      +  "url",
      +  "text"
      +]
    • changedInput schema / properties / options / description
      Previous value: -"The complete set of values a select field allows, e.g. ['Low', 'Medium', 'High']. Replaces the existing options; anything omitted is deleted. Required and non-empty for a select field; omit it for date, person and url fields."New value: +"The complete set of values a select or multi_select field allows, e.g. ['Low', 'Medium', 'High']. Replaces the existing options; anything omitted is deleted. Required and non-empty for those; omit it for date, person, url and text fields."
  3. Changed3 schema fields changed
    • addedInput schema / additionalProperties
      Added value: +false
    • removedInput schema / properties / context
      Removed value: -{
      -  "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
      -  "type": "string"
      -}
    • changedInput schema / required
      Previous value: -[
      -  "name",
      -  "context"
      -]New value: +[
      +  "name"
      +]
  4. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already flag destructiveHint=true and idempotentHint=true, but the description goes further and specifies exactly what is destroyed: options missing from `options` are deleted and that value is stripped from every asset holding it. It also discloses the quota interaction (replacement works at the limit, creation does not) and the write-scope plus owner/admin permission requirement. Minor gap: it doesn't say what a successful call returns, though no output schema exists to cover that.

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 destructive replace behavior is front-loaded in the first sentence and every subsequent sentence carries a distinct rule. It is dense and long, with heavy capitalization for emphasis and some scope creep into update_asset/update_asset_status usage, but almost nothing is filler.

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 destructive, quota-limited mutation with four parameters and no output schema, the description covers destruction scope, permissions, quota behavior, type-immutability, name-matching exactness and the error behavior for unknown names. An agent has everything needed to call it correctly and safely.

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 would be 3, but the description adds cross-parameter rules the schema states only per-field: select/multi_select require non-empty `options` while date/person/url/text must omit it, and an existing same-name-same-type field is returned unchanged while a cross-type name collision is refused. The exact-match rule for field and option names is also only in the description.

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 plus the non-obvious upsert semantics ('Create a custom field on a workspace, or REPLACE the options of one that already exists'). This immediately separates it from list_custom_fields, delete_custom_field and update_asset, which an agent could otherwise confuse it with.

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?

Explicitly routes the agent: check list_custom_fields first when the field may already exist, use update_asset_status for the protected 'Status' field, and set values via update_asset's `fields` argument because no set-value tool exists. It also states when the tool refuses (type mismatch, quota reached), which is genuine when-not guidance.

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