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

Annotations already declare this is a non-read-only, non-idempotent, non-destructive mutation, so the description's main added value is the approval context: org-configurable MCP approvals plus always-on workflow approvals. That is genuinely useful operational context, but the description omits the critical semantics of an update — whether the `options` object merges with or replaces existing options, and whether changing `fieldType` on a populated field destroys data. Those omissions are significant given destructiveHint=false.

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

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

Two compact sentences, front-loaded with the action and followed by the approval caveat. Nothing is padded, though the approval sentence is phrased in organizational policy language rather than the direct agent-facing imperative ("requires approval; expect X") that would be more actionable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema and annotations reduce the description's obligations, but this is a mutation tool whose schema is completely undocumented and whose nested `data` object has replacement-vs-merge ambiguity. For an agent to call it correctly it needs to know whether omitted fields are preserved and whether field-type changes are safe — neither is addressed.

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

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

Schema description coverage is 0%, so the description carries full burden here, and it explains almost nothing: only the word "options" maps loosely to a nested property. The required `id` (a location custom field UUID) and the `data.name` / `data.fieldType` members — including the fact that fieldType is a closed enum of text/date/currency/select/multipart — are nowhere characterized in prose.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Edit a location custom field and its options"), which separates it from create_custom_field, delete_custom_field, and list_custom_fields by verb alone. It does not, however, distinguish itself from set_site_custom_field, which writes a value to a field and sits in the same sibling set — the reader must infer that this tool edits the field definition rather than its value.

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

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

There is no explicit when-to-use guidance, no prerequisites (e.g., that the field must already exist, or which field types can be converted), and no named alternatives despite several close siblings. The approval sentence describes an environment condition rather than telling an agent when to select this tool over another.

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