Skip to main content
Glama

task

Open a goal with a checklist, track items until closed, then archive it automatically. Use related functions to manage, add, and comment on items.

Instructions

Open a task: a goal and a checklist, kept until its items are closed.

Stored as type='task'. Work it with task_item(), grow it with task_add() and discuss it with task_comment(); it archives itself once every item is done or dropped, and must_read() lists the open ones.

Free text cites another item only as [[#id]], which reads back as its current number and label; a label -- a title, an item's text -- never carries one. To a person, name it item n of its task.

Input Schema

NameRequiredDescriptionDefault
alsoNoother domain paths this belongs to, comma-separated: the subjects that cut across the tree `domain` sits in, such as the end-to-end flow a routine is one step of. Every read scoped to one of them returns it. A path `domain` already sits under is dropped as redundant. At most 200 characters each.
goalYesthe brief an agent with none of this session's context works from: what the work is and why, where it lives, the decisions and constraints that bind it, and what done looks like. Short, but complete enough to act on -- a few compact paragraphs, at most 2000 characters. Plain prose: a task is not a sectioned type, so no `INTENT:` / `GOAL:` / `WHY:` labels -- those are how checkpoint, anti_pattern and reasoning bodies are read back. edit_memory(goal=...) rewrites it when the scope changes.
tagsNocomma-separated synonyms the goal and items never use; retrieval is BM25 over content and tags. The type name is not added for you: a word every task carries ranks no task above another.
itemsYesone checklist item per line, blank lines ignored, at most 50. Each is a short label, verb first, at most 80 characters: lists and every DEPENDS ON that names it show it whole, so its detail goes in the item's brief (task_note). Each gets an id for task_item(); the result lists them in order, each as {id, n}.
titleYeswhat the task delivers, in a few words someone would look for it by. At most 120 characters.
domainNothe subject this belongs to, as a path from the outermost scope in ('acme/x100/p200'). File it as deep as the fact is specific -- a note about one routine goes on the routine, and still comes back when someone asks about the module or the product above it. At most 200 characters.
sessionNogroups what one conversation writes. Leave it empty to use this server process's own stamp.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed15 schema fields changedv0.16.1
    • addedInput schema / properties / also / description
      Added value: +"other domain paths this belongs to, comma-separated: the subjects that cut across the tree `domain` sits in, such as the end-to-end flow a routine is one step of. Every read scoped to one of them returns it. A path `domain` already sits under is dropped as redundant. At most 200 characters each."
    • removedInput schema / properties / also / title
      Removed value: -"Also"
    • addedInput schema / properties / domain / description
      Added value: +"the subject this belongs to, as a path from the outermost scope in ('acme/x100/p200'). File it as deep as the fact is specific -- a note about one routine goes on the routine, and still comes back when someone asks about the module or the product above it. At most 200 characters."
    • removedInput schema / properties / domain / title
      Removed value: -"Domain"
    • addedInput schema / properties / goal / description
      Added value: +"the brief an agent with none of this session's context works from: what the work is and why, where it lives, the decisions and constraints that bind it, and what done looks like. Short, but complete enough to act on -- a few compact paragraphs, at most 2000 characters. Plain prose: a task is not a sectioned type, so no `INTENT:` / `GOAL:` / `WHY:` labels -- those are how checkpoint, anti_pattern and reasoning bodies are read back. edit_memory(goal=...) rewrites it when the scope changes."
    • removedInput schema / properties / goal / title
      Removed value: -"Goal"
    • addedInput schema / properties / items / description
      Added value: +"one checklist item per line, blank lines ignored, at most 50. Each is a short label, verb first, at most 80 characters: lists and every DEPENDS ON that names it show it whole, so its detail goes in the item's brief (task_note). Each gets an id for task_item(); the result lists them in order, each as {id, n}."
    • removedInput schema / properties / items / title
      Removed value: -"Items"
    • addedInput schema / properties / session / description
      Added value: +"groups what one conversation writes. Leave it empty to use this server process's own stamp."
    • removedInput schema / properties / session / title
      Removed value: -"Session"
    • addedInput schema / properties / tags / description
      Added value: +"comma-separated synonyms the goal and items never use; retrieval is BM25 over content and tags. The type name is not added for you: a word every task carries ranks no task above another."
    • removedInput schema / properties / tags / title
      Removed value: -"Tags"
    • addedInput schema / properties / title / description
      Added value: +"what the task delivers, in a few words someone would look for it by. At most 120 characters."
    • removedInput schema / properties / title / title
      Removed value: -"Title"
    • removedInput schema / title
      Removed value: -"taskArguments"
  2. Addedv0.6.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already cover the write/non-destructive/non-idempotent profile, and the description adds real behavior: storage as type='task', self-archiving once every item is done or dropped, and the [[#id]] citation convention with its label rules. It stops short of describing permissions, limits, or failure modes, but the lifecycle disclosure is substantive context the annotations do not provide.

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 definition, then the sibling routing, then the citation convention, with no filler sentences. Some phrasing ('To a person, name it item n of its task') is dense and slightly opaque, keeping it out of the top band.

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?

All 7 parameters are fully documented and the description supplies the lifecycle, storage type, and cross-tool workflow for a write tool with no output schema. Little is missing for an agent to invoke it correctly; return-shape detail is conveyed only briefly ('{id, n}').

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 description coverage is 100%, so the per-parameter semantics are already carried by the schema and the baseline is 3. The description adds the cross-reference grammar ([[#id]] reads back as current number and label, labels never carry one) that the schema does not state, giving it genuine added value.

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?

Opens with a specific verb and resource — 'Open a task: a goal and a checklist' — and immediately differentiates itself from the task_item/task_add/task_comment siblings by naming what each one does. An agent can tell this is the creation entry point of the task family 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.

Usage Guidelines4/5

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

Explicitly routes follow-up work: task_item() to work it, task_add() to grow it, task_comment() to discuss it, must_read() to list the open ones. It lacks a comparative statement about when to open a task versus a note or checkpoint, so it is clear context rather than full when/when-not guidance.

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