Weft

Create Task

create_task

Use this when the user says 'add a task', 'remind me to …', or otherwise asks to capture work. If columnId is omitted the task goes to the Backlog. Priority defaults to medium unless urgency is implied (use 'high' for words like urgent/asap, 'low' for nice-to-have).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "title": "<title>"
    },
    "name": "create_task"
  }
}

Input Schema

Name	Required	Description	Default
`dueAt`	No	The day this is due, as an ISO date-time (only the date part is used, e.g. "2026-10-31T00:00:00Z"). Put a date on anything the user said has a deadline or a day to check back — dated tasks show on the user's Weft calendar and in their subscribed Google/Apple/Outlook calendar. Pass null to clear.
`title`	Yes
`project`	No	Project name (case-insensitive) or project ID
`startAt`	No	The day work begins, same format as dueAt. With dueAt it makes a span on the calendar ("measure 5–12 November"); never after dueAt. Pass null to clear.
`assignee`	No	Executor: a member's name, first name or email (case-insensitive), 'me' to assign to yourself (the calling agent), or 'none' to unassign
`columnId`	No
`priority`	No		medium
`sprintId`	No
`blockedBy`	No	Tasks that must finish before this one can start. The task derives agentState "blocked" while any of them is open, leaves ready-sets, and unblocks itself the moment the last blocker completes. Cycles are refused.
`description`	No
`verification`	No	How to verify this task is actually done — the server executes these checks on complete_task. {mode, checks[]}: mode "executable"/"state_delta" lets fully-passed work move to Done by itself; "checklist"/"human" always stops at the user. Check kinds: http (GET url → expected status, optional mustContain phrase), citation (url + quote that must appear on the page), string_check (receipt must contain/equal/match value), file_hash (an artifact must carry this sha256), human_checklist (items only a person can judge — resolved when they accept). Give every task at least one machine check when you can: unverifiable "done" is the failure mode this board exists to close.
`requiresReview`	No	Stop at the user before this is called done. Set it ONLY for the irreversible: money, publishing outward, production, anything legal. Everything else finishes without them — a queue everything enters is a queue nobody reads.
`estimateMinutes`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 14, 2026

changedInput schema / properties / assignee / description

Previous value: -"Executor: a member's name or email (case-insensitive), 'me' to assign to yourself (the calling agent), or 'none' to unassign"New value: +"Executor: a member's name, first name or email (case-insensitive), 'me' to assign to yourself (the calling agent), or 'none' to unassign"

Changed2 schema fields changedOct 23, 2026

addedInput schema / properties / dueAt / description

Added value: +"The day this is due, as an ISO date-time (only the date part is used, e.g. \"2026-10-31T00:00:00Z\"). Put a date on anything the user said has a deadline or a day to check back — dated tasks show on the user's Weft calendar and in their subscribed Google/Apple/Outlook calendar. Pass null to clear."

addedInput schema / properties / startAt

Added value: +{
+  "anyOf": [
+    {
+      "format": "date-time",
+      "pattern": "^(?:(?:\\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)))$",
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "The day work begins, same format as dueAt. With dueAt it makes a span on the calendar (\"measure 5–12 November\"); never after dueAt. Pass null to clear."
+}

Changed1 schema field changedOct 9, 2026
- removedInput schema / $schema
```
Removed value: -"https://json-schema.org/draft/2020-12/schema"
```

Changed1 schema field changedOct 8, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

First observedSep 16, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare this is a non-destructive write, so the bar is lower; the description adds real behavioral context by revealing that an omitted columnId lands the task in Backlog — information absent from the schema, where columnId has no description at all. It does not mention side effects (calendar subscription, review gating) or what happens on invalid project/sprint references.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the trigger and then the defaulting rules; there is no filler. The priority sentence partially restates the schema default and enum, so it is slightly less economical than the first.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Placeholder.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 54% schema coverage across 13 parameters, the description covers only columnId and priority, leaving dueAt, startAt, assignee, project, sprintId, blockedBy, verification and requiresReview to the schema. The priority heuristic is also slightly at odds with the enum, which offers 'urgent' while the text tells the agent to use 'high' for urgent language.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific action (capture work as a task) and anchors it to concrete user phrasings ('add a task', 'remind me to …'). It distinguishes the single-task case implicitly from bulk_create_tasks by framing it as one captured item, but never names the bulk alternative explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Trigger conditions are stated clearly with example user utterances, and two decision rules are given for ambiguous cases (missing columnId, priority inference). It stops short of when-not-to-use guidance or routing to bulk_create_tasks / add_task_to_sprint for adjacent scenarios.

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

All Weft tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.