Capable

Define field value

define_enum_value

DestructiveIdempotent

Admin-only add, relabel, recolor, position, archive or reorder of built-in pick-list values listed by describe_schema. An existing value_key patches only supplied label/color/position/archived fields; its key and semantic role never change. A new key needs a label and, for behavior-driving fields, a semantic_role. archived:true removes a value from new picks; stored data stays valid and archived:false restores it. Nothing is deleted. Send order alone with every value_key, including archived keys, for atomic reordering. Changes apply immediately. Returns the stored value or reordered values.

When to use: An admin changes a field's available pick-list choices.

Example: Add a 'pilot' lifecycle stage that means active_customer.

Input Schema

Name	Required	Description
`color`	No	Optional hex color for the value's chip, e.g. "#2563eb"; display only. Null clears the color; omitting it keeps an existing value's color.
`field`	Yes	The enum field's key on that object, e.g. lifecycle_stage, type, status, priority; describe_schema lists each field's values.
`label`	No	Display label. Required for a NEW value (its slug becomes the value_key unless value_key is set); on an existing value_key it relabels. Omit to leave a label as is.
`order`	No	Reorder form: the field's COMPLETE value_key list in the wanted order (every current key once, archived included). Send alone with object_type + field; a partial or unknown list is refused with the current keys.
`archived`	No	true retires an existing value from new picks (stored data keeps it, reversible); false restores it. Omit to leave the state as is; a new value is never born archived.
`position`	No	0-based sort position among the field's values, lower first. A new value defaults to 0; omitting it keeps an existing value's position. To set the whole order, use `order` instead.
`value_key`	No	Stable machine key (lowercase, underscores). Defaults to the slugified label; pass an existing key to relabel, recolor, reposition, archive or restore that value.
`object_type`	Yes	Built-in object owning the enum field, e.g. account, opportunity, subscription, touch, task, lead.
`semantic_role`	No	Required only for a NEW value on a behavior-driving field: account.lifecycle_stage takes prospect / active_customer / at_risk / churned / dormant, opportunity.type new / post_sale, subscription.status live / inactive (a refusal names the allowed roles). Locked once the value exists; omit or null otherwise.

Output Schema

Name	Required	Description	Default
`note`	No
`order`	No
`values`	No
`updated`	No
`enum_value`	No
`current_keys`	No
`known_fields`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 24, 2026
- removedInput schema / properties / color / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedInput schema / properties / color / type
```
Added value: +[
+  "string",
+  "null"
+]
```
Changed1 schema field changedOct 20, 2026
- removedInput schema / $schema
```
Removed value: -"https://json-schema.org/draft/2020-12/schema"
```
Changed6 schema fields changedOct 19, 2026
- removedOutput schema / $schema
```
Removed value: -"https://json-schema.org/draft/2020-12/schema"
```
- removedOutput schema / additionalProperties
```
Removed value: -{}
```
- removedOutput schema / properties / enum_value / additionalProperties
```
Removed value: -{}
```
- removedOutput schema / properties / enum_value / propertyNames
```
Removed value: -{
-  "type": "string"
-}
```
- removedOutput schema / properties / values / items / additionalProperties
```
Removed value: -{}
```
- removedOutput schema / properties / values / items / propertyNames
```
Removed value: -{
-  "type": "string"
-}
```

Changed2 schema fields changedOct 19, 2026

changedInput schema / properties / order / description

Previous value: -"Reorder form: the field's COMPLETE value_key list in the wanted order (every current key exactly once, archived ones included — describe_schema lists them). Send it alone with object_type + field; a partial or unknown list is refused with the current keys."New value: +"Reorder form: the field's COMPLETE value_key list in the wanted order (every current key once, archived included). Send alone with object_type + field; a partial or unknown list is refused with the current keys."

changedInput schema / properties / semantic_role / description

Previous value: -"Meaning anchor, required only for a NEW value on a behavior-driving field: account.lifecycle_stage takes prospect / active_customer / at_risk / churned / dormant, opportunity.type takes new / post_sale, subscription.status takes live / inactive; the refusal names that field's allowed roles. Locked once a value exists. Omit or null for every other field."New value: +"Required only for a NEW value on a behavior-driving field: account.lifecycle_stage takes prospect / active_customer / at_risk / churned / dormant, opportunity.type new / post_sale, subscription.status live / inactive (a refusal names the allowed roles). Locked once the value exists; omit or null otherwise."

First observedOct 6, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=true; the description adds critical corrective context that nothing is deleted, that archived:true only removes a value from new picks while stored data stays valid and archived:false restores it, and that changes apply immediately. It also discloses the immutability constraint (an existing value_key's key and semantic role never change) and the atomicity rule for reordering, which annotations cannot express. It doesn't state permission mechanics beyond "admin-only" or failure modes for partial data, keeping it at 4.

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 operation set, then the patch/create rules, then archive semantics, then the reorder contract, and finally explicit when-to-use plus an example. Dense but every sentence carries a rule; only the return-value sentence is marginal given an output schema exists.

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?

Covers all four invocation shapes (create, patch, archive/restore, atomic reorder), the semantic_role gating for behavior-driving fields, reversibility, immediacy, and the absence of deletion. With 9 parameters and high-stakes mutation semantics, nothing an agent needs to call it safely 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 3 is the floor, and the description genuinely adds cross-parameter semantics: patches apply only to supplied fields, a new key needs a label and (for behavior-driving fields) a semantic_role, and order must be sent alone with a complete value_key list including archived keys. This is coordinated-usage knowledge the schema does not convey on its own.

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 set of verbs (add, relabel, recolor, position, archive, reorder) against a specific resource (built-in pick-list values), and grounds the resource by pointing at describe_schema as the source of those values. This clearly separates it from define_field/define_object/define_pipeline siblings that define the containers rather than the values.

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?

"When to use: An admin changes a field's available pick-list choices" plus a concrete example gives an agent a clear trigger, and the description distinguishes the patch form from the order form. It stops short of explicitly excluding sibling alternatives like define_field (which creates the field itself), so it's strong but not fully routed.

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

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

Resources

Need Help?