Create a project task module, assign only project members, and notify them automatically. The API key determines the project, so no project ID is required.
创建任务模块。需 work:manage 权限（project:manage 等价放行，超管不受限）。assigneeIds 必须全部为项目成员；创建后通知被分配成员。 POST /api/projects/{id}/work-modules 项目由当前 API 密钥自动确定，无需传 projectId。
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare write (readOnlyHint=false), destructive, openWorld, and non-idempotent, so the safety profile is covered. The description adds meaningful context beyond them: the auth/permission model and the side effect that assigned members are notified after creation.
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?
Front-loads the action, then permissions, constraints, endpoint, and the projectId note in a tight structure with zero filler. Every clause carries actionable information.
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 write tool with no output schema, it covers permissions, assignee constraints, side effects, and project resolution well. It does not indicate what the creation returns (e.g., the new module id), which would help an agent chain follow-up calls.
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 0% across a nested 7-field body, so the description carries the burden and only partly compensates. It adds real meaning for assigneeIds (must all be project members) and clarifies that no projectId is needed, but leaves name/endAt/startAt/location/description/requiredCount to the schema.
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 (create) and resource (task/work module), cleanly separating it from CRUD siblings like anon_get_work_modules, anon_patch_work_modules_mid, and anon_delete_work_modules_mid. An agent can identify the operation without opening any schema.
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?
Provides concrete prerequisites and context: requires work:manage (project:manage grants equivalent, super-admin unrestricted), assigneeIds must be project members, and the project is auto-derived from the API key. It gives clear operational context but does not explicitly name alternative tools or when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.