create_taskSave a new task to your ZeroHrs account with title, description, status, priority, and due date. Use this to turn explicit requests into trackable tasks.
Create a Zero task for the signed-in user. Call only after the user explicitly asks to save the task.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| status | No | ||
| due_date | No | ||
| priority | No | ||
| description | Yes |
Changes observed during successful MCP inspections.
v0.3.0Input schema / properties / due_date / patternPrevious value: -"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$"New value: +"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$"v0.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that this is a mutating operation creating a task for the signed-in user, and it adds a consent boundary. With annotations all false and no output schema, it does not explain persistence, duplicate behavior, idempotency effects, or what happens 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?
The description is two sentences with no filler. The primary purpose is front-loaded, and the usage guardrail is a separate, purposeful sentence that earns its place.
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 mutating tool with no output schema, no useful annotation detail, and five parameters at 0% schema description coverage, this description is too thin. It leaves return behavior, differentiation from create_user_owned_task, and parameter semantics unaddressed.
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 the burden of explaining parameters, but it mentions none. Field names like title and description are somewhat self-explanatory, but status, due_date, priority, defaults, and required fields receive no explanatory context in the description.
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 ('Create'), a specific resource ('Zero task'), and a clear user scope ('for the signed-in user'). It is distinguishable from read/list siblings, but it does not clarify how create_task differs from the similarly named sibling create_user_owned_task.
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 an explicit trigger condition: 'Call only after the user explicitly asks to save the task.' This clearly prevents unsolicited creation. However, it provides no guidance on when to prefer this tool over create_user_owned_task or other creation-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.