write_set_custom_fields

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

Beyond the annotations, it discloses that dropdown values are validated against field options before anything is sent, that null clears a field, and that values are read back after the operation. This materially informs the agent about preconditions, deletion semantics, and return behavior.

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?

Three short sentences deliver a purpose statement, an example, and key behavioral caveats with no filler. The first sentence front-loads the core action; the rest adds essential details without repetition.

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?

The description covers the main semantic requirements for a 2-parameter tool: what fields means, how clearing works, validation, and that a readback occurs. It leaves the exact return shape unspecified and does not explicitly define the id parameter, but the references and annotation set make it reasonably complete for an agent.

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?

With 0% schema description coverage, the description compensates well for the 'fields' object by giving a concrete name-value example and explaining null and dropdown handling. The 'id' parameter is only implied as the card identifier by the phrase 'on a card', not explicitly described in terms of type or format, so some burden remains.

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?

The opening phrase 'Set custom fields on a card by name' names a specific verb, resource, and mechanism, and the example mapping makes the intent unmistakable. This distinguishes it from sibling write tools like write_update_card, which handle ordinary card fields, and from read_custom_field_options.

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?

The description gives clear context: the tool is for setting named custom fields on a card, and it explicitly points to read_custom_field_options for dropdown options, implying a pre-call step. It does not explicitly state when not to use it versus write_update_card or other write tools, so it stops short of a full exclusionary usage guide.

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