Create a new task on the work board; set title, tags, priority, description, and defined custom fields, or let it default to the first column.
在看板上新建一个任务。column_id 省略时放到第一列；fields 只接受在配置 board.fields 中定义过的键，传未定义的键会报错。
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | 标签 | |
| actor | No | 操作者标识，默认 agent | |
| title | Yes | 任务标题（必填，≤500 字） | |
| fields | No | 自定义字段（须在配置中已定义） | |
| task_id | No | 自定义 id；省略则自动生成 | |
| priority | No | 优先级，越大越优先 | |
| column_id | No | 目标列 id，省略则用第一列 | |
| description | No | 详细说明 |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses two behaviors beyond the schema: column_id defaults to the first column, and unknown keys in fields raise an error. It omits anything about required permissions, what an error response looks like, or whether task_id collisions are rejected.
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 tight sentences with the purpose front-loaded followed by the two conditional behaviors. Nothing is padded and every clause carries information an agent needs.
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 an eight-parameter mutation tool with no annotations and no output schema, the description should say what is returned (e.g., the generated task id) so an agent can chain calls. It covers defaults and validation well but leaves the return value and permission requirements unstated.
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 coverage is 100%, setting the baseline at 3. The description goes beyond the schema by documenting the omitted-column_id default and the board.fields key constraint on the fields object, adding real semantics for two of the eight parameters.
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: creating a new task on a board. It is inherently distinguishable from update_task/delete_task/move_task by the creation action, though it never names a sibling to sharpen the boundary.
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 explains defaults and validation but gives no explicit guidance on when to reach for create_task versus list_tasks, update_task, or board_config. There is no when-to-use/when-not framing and no prerequisites or permissions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.