Skip to main content
Glama

Create task

create_task

Create a new Kanban task with a required title plus optional description, links, tags, priority, status, and metadata; use dryRun to validate before writing.

Instructions

Create a new task with title, description, and metadata. Pass fields (e.g. ["id","title","status"]) for a compact answer instead of the full task object; pass dryRun to validate without writing anything. LINKS merge: links ADDS every listed taskId+type pair to the new task and parent (when given) is folded into the same union, so sending both merges once and a pair named twice is a no-op — the same MERGE semantic update_task has, where a link you do not name is simply absent (a new task has nothing to preserve). links: [] is REFUSED — omit the field for no links. Use it for a new unit of work; use update_task to change an existing task, and add_comment to discuss one without editing it.

Input Schema

NameRequiredDescriptionDefault
urlNoURL the annotation targets. Together with selector this makes the task annotated (overlay-verifiable); omit both for a plain task.
tagsNoTags for filtering (list_tasks --tag matches every listed tag). Omit for untagged.
typeNoTask type. Defaults to Task; use Research for an investigation (it reaches review on its attached .md report, with no verification verdict).Task
linksNoADD the listed links to the new task (merge, same as update_task's `links`). Combined with `parent` as a union; a pair named twice is a no-op. `links: []` is REFUSED — omit the field for no links.
titleYesTask title — the only required field.
dryRunNoPreview only: validate the input and report what WOULD be created without writing a task file.
fieldsNoReturn only these task fields (e.g. ["id","title","status"]) instead of the full task object. Omit for the full object — same selector list_tasks and get_task take.
parentNoParent task id (full id or unique prefix) to create this task as a child. Omit for a root task; merges with links as one union when both are given.
statusNoInitial status. Defaults to todo; pass another status only to create the task already in motion.todo
sortKeyNoExplicit board ordering key. Omit it — core auto-assigns one — unless you must place the task exactly.
priorityNoPriority tier, driving claim order (Critical first). Defaults to Medium.Medium
selectorNoCSS selector of the annotated element (default "/", meaning the whole page). Only meaningful with url./
cssSelectorNoAlias of selector for clients that prefer the explicit name; both write the same field.
descriptionNoLonger task body (what to do, acceptance criteria). Optional; omit when the title says it all.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed12 schema fields changedv0.22.0
    • addedInput schema / properties / cssSelector / description
      Added value: +"Alias of selector for clients that prefer the explicit name; both write the same field."
    • addedInput schema / properties / description / description
      Added value: +"Longer task body (what to do, acceptance criteria). Optional; omit when the title says it all."
    • addedInput schema / properties / dryRun / description
      Added value: +"Preview only: validate the input and report what WOULD be created without writing a task file."
    • addedInput schema / properties / parent / description
      Added value: +"Parent task id (full id or unique prefix) to create this task as a child. Omit for a root task; merges with links as one union when both are given."
    • addedInput schema / properties / priority / description
      Added value: +"Priority tier, driving claim order (Critical first). Defaults to Medium."
    • addedInput schema / properties / selector / description
      Added value: +"CSS selector of the annotated element (default \"/\", meaning the whole page). Only meaningful with url."
    • addedInput schema / properties / sortKey / description
      Added value: +"Explicit board ordering key. Omit it — core auto-assigns one — unless you must place the task exactly."
    • addedInput schema / properties / status / description
      Added value: +"Initial status. Defaults to todo; pass another status only to create the task already in motion."
    • addedInput schema / properties / tags / description
      Added value: +"Tags for filtering (list_tasks --tag matches every listed tag). Omit for untagged."
    • addedInput schema / properties / title / description
      Added value: +"Task title — the only required field."
    • addedInput schema / properties / type / description
      Added value: +"Task type. Defaults to Task; use Research for an investigation (it reaches review on its attached .md report, with no verification verdict)."
    • addedInput schema / properties / url / description
      Added value: +"URL the annotation targets. Together with selector this makes the task annotated (overlay-verifiable); omit both for a plain task."
  2. Changed2 schema fields changedv0.21.1
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / fields
      Added value: +{
      +  "description": "Return only these task fields (e.g. [\"id\",\"title\",\"status\"]) instead of the full task object. Omit for the full object — same selector list_tasks and get_task take.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
  3. First observedv0.20.0

TDQS

A4.7/5.0
Behavior5/5

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

Goes well beyond the annotations: discloses that `links` is an additive MERGE unioned with `parent`, that duplicate pairs are no-ops, and that `links: []` is REFUSED — non-obvious failure behavior an agent would otherwise trip on. dryRun explicitly validates without writing, consistent with destructiveHint=false.

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?

Front-loads the core action and the usage routing first, then the tricky merge semantics. The merge paragraph is dense but every clause carries non-obvious information; only slight redundancy (repeating the links refusal in both schema and prose) keeps it from a 5.

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

Completeness4/5

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

For a 14-parameter mutation tool with no output schema, the description covers the risky areas (link merging, dryRun, field selection) that an agent must get right. Edge parameters (sortKey, selector/cssSelector alias, type enums) are adequately handled by the 100%-covered schema, so nothing critical is missing.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3, but the description adds real semantics the schema does not: the union/merge behavior of `links`+`parent`, the refusal of an empty array, and equivalence of the `fields` selector with list_tasks/get_task. Minor params like sortKey and cssSelector alias are left to the schema, keeping it short of a 5.

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

Purpose5/5

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

States a specific verb and resource ("Create a new task with title, description, and metadata") and immediately contrasts it against update_task (change existing) and add_comment (discuss without editing). An agent can distinguish it from every sibling without opening the schema.

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

Usage Guidelines5/5

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

Explicit routing: "Use it for a new unit of work; use update_task to change an existing task, and add_comment to discuss one without editing it." It also gives when-to-use guidance for dryRun (validate without writing) and fields (compact response), leaving little to inference.

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