Update a task's custom field by its key with a specified value. Use when you need to change task-specific data such as priority or status in your Clokio workspace.
Set one custom field value on a task, identified by field_key (never field_id). An API key sees PUBLIC fields only.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| value | Yes | ||
| field_key | Yes |
Changes observed during successful MCP inspections.
v0.1.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as non-read-only and non-destructive, so the description does not need to restate that. It adds useful behavior about API-key visibility and field_key identification, but it does not disclose overwrite/append semantics for array values or error 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?
Two sentences with no filler; the core action is front-loaded and the critical caveats are delivered immediately after. Every sentence adds value.
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?
For a simple three-parameter setter with annotation-covered safety and schema-typed parameters, the description gives enough to call it correctly. It lacks explicit return/error details, but no output schema exists and those are not essential for invocation.
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 must compensate, and it partially does by clarifying that field_key is the identifier and API keys see only public fields. However, it does not explicitly state that id is the task ID or explain how value should be interpreted.
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 description states a specific action ('Set one custom field value on a task') with a clear resource and scope. The distinction 'identified by field_key (never field_id)' and the API-key visibility caveat separate it from broader task update tools and give an exact purpose.
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?
It advises that API keys see only PUBLIC fields, which tells an agent whether this tool is usable for the intended field, and it explicitly says to use field_key rather than field_id. It does not name sibling alternatives or give a when-not-to-use statement, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.